wsif evaluation questions

Hello!

We have to develop an application which need to parse WSDL
file, extract list
of available methods from it and expose to upper layer as a
list of interfaces
like below:

public interface FunctionInterface {
    public ObjectParam exec(ObjectParam param);
};

ObjectParam offers methods like
String getItem(String name);
byte[] getItem(String name);
...

setItem(String name, String value);
setItem(String name, byte[] value);
...

So in general it seems to be possible to map fields in
ObjectParam to create
some form of SOAP request to given method with given
attributes and types.

We need to implement one or several implementations of
FunctionInterface,
which could create SOAP call to given service, knowing the
parameters which
are needed to call the service, and obviously convert the
data from
ObjectParam properties into some form expected by the
method.

One of key feature is there should be no generated source,
needed to be
shipped together with software package, so every parsing and
call needs to be
invoked dynamically.

For now I have several questions:

- is it possible using WSIF get list of functions exposed by
some service as a
WSDL descriptor?

- is it possible to recognize parameter types, and
dynamically bind some
marshallers/unmarshallers to them?

Thank you in advance!

-- 
Eugene N Dzhurinsky

Hi,

I did a similar project using WSIF. Mine involved consming
several web
services that are exposed through thier WSDL.

However as you know there are simple types and custom types
in WSDL files.

Total dynamic invocation will work fine for simple types
where parameter
types will be recognised on the fly.

You will have to generate stubs if your WSDL has
complex/custom types. The
process is thus not totally automated.

If you have downloaded WSIF you will see and example of dii
in the
simpletype example and also one on complex types using
stubs.

Otherwise it is very easy to create a wrapper object and
call appropriate
methods and build that into a standalone library which you
can use
anywhere.

Hope that helps!

Murvin

> Hello!
>
> We have to develop an application which need to parse
WSDL file, extract
> list
> of available methods from it and expose to upper layer
as a list of
> interfaces
> like below:
>
> public interface FunctionInterface {
>     public ObjectParam exec(ObjectParam param);
> };
>
> ObjectParam offers methods like
> String getItem(String name);
> byte[] getItem(String name);
> ...
>
> setItem(String name, String value);
> setItem(String name, byte[] value);
> ...
>
> So in general it seems to be possible to map fields in
ObjectParam to
> create
> some form of SOAP request to given method with given
attributes and types.
>
> We need to implement one or several implementations of
FunctionInterface,
> which could create SOAP call to given service, knowing
the parameters
> which
> are needed to call the service, and obviously convert
the data from
> ObjectParam properties into some form expected by the
method.
>
> One of key feature is there should be no generated
source, needed to be
> shipped together with software package, so every
parsing and call needs to
> be
> invoked dynamically.
>
> For now I have several questions:
>
> - is it possible using WSIF get list of functions
exposed by some service
> as a
> WSDL descriptor?
>
> - is it possible to recognize parameter types, and
dynamically bind some
> marshallers/unmarshallers to them?
>
> Thank you in advance!
>
> --
> Eugene N Dzhurinsky
>



------------------------------------------------------------
---------
To unsubscribe, e-mail: wsif-user-unsubscribews.apache.org
For additional commands, e-mail: wsif-user-helpws.apache.org

On Wed, Oct 17, 2007 at 03:21:00PM +0100, Murvin Bhantooa
wrote:
> Hi,
> 
> I did a similar project using WSIF. Mine involved
consming several web
> services that are exposed through thier WSDL.
> 
> However as you know there are simple types and custom
types in WSDL files.
> 
> Total dynamic invocation will work fine for simple
types where parameter
> types will be recognised on the fly.
> 
> You will have to generate stubs if your WSDL has
complex/custom types. The
> process is thus not totally automated.
> 
> If you have downloaded WSIF you will see and example of
dii in the
> simpletype example and also one on complex types using
stubs.
> 
> Otherwise it is very easy to create a wrapper object
and call appropriate
> methods and build that into a standalone library which
you can use
> anywhere.

Does it mean I can ever about the usage of  WSIF but create
my own library?
I'm not sure it is easy to parse WSDL descriptor and then
call the method
through SOAP?

Or it is possible to create simple wrapper/facade over WSDI
core, which will
convert things from ObjectParam into something acceptable by
WSIF, and parse
back results returned by WSIF methods back into
ObjectParam?

-- 
Eugene N Dzhurinsky

You can do dynamic invocation using WSIF even if complex
types are 
involved.  You just can't do simple data binding.

Suppose without loss of generality that the web service
requests and 
responses are in the form of SOAP messages.  The complex
types included 
in a response will correspond to some XML elements in the
message.  If 
you are doing dynamic invocation, you're not going to have
Java classes 
defined corresponding to each of the complex types unless
you generate 
code from the WSDL.  Presuming that you're not going to do
that in a 
dynamic invocation, you can work with the
org.w3c.dom.Element itself or 
some wrapper class you build around it.  Thus, any complex
type is 
deserialized into an Element or your ComplexTypeWrapper.  In
the latter 
case, the type name extracted from the wsdls corresponding
to the 
element can be included in the wrapper instance, and then
the 
information extracted from the wsdl and schemas about the
type can be 
applied during processing by the client.  Similarly, when
building a web 
service request, you'll have to assemble Elements
corresponding to the 
complex types needed in the input.  Nothing is really lost
here because 
again, you don't have a class around in your application
corresponding 
to that complex type anyway.

The only special WSIF machinery you need for this is a type
mapping for 
each complex type to ComplexTypeWrapper or Element.  These
type mappings 
would be created on each invocation based on information in
the wsdl and 
schemas.  They are usually only needed for the complex types

corresponding to the "parts" of the input and
output messages.

Jeff

Murvin Bhantooa wrote:
> Hi,
>
> I did a similar project using WSIF. Mine involved
consming several web
> services that are exposed through thier WSDL.
>
> However as you know there are simple types and custom
types in WSDL files.
>
> Total dynamic invocation will work fine for simple
types where parameter
> types will be recognised on the fly.
>
> You will have to generate stubs if your WSDL has
complex/custom types. The
> process is thus not totally automated.
>
> If you have downloaded WSIF you will see and example of
dii in the
> simpletype example and also one on complex types using
stubs.
>
> Otherwise it is very easy to create a wrapper object
and call appropriate
> methods and build that into a standalone library which
you can use
> anywhere.
>
> Hope that helps!
>
> Murvin
>
>   
>> Hello!
>>
>> We have to develop an application which need to
parse WSDL file, extract
>> list
>> of available methods from it and expose to upper
layer as a list of
>> interfaces
>> like below:
>>
>> public interface FunctionInterface {
>>     public ObjectParam exec(ObjectParam param);
>> };
>>
>> ObjectParam offers methods like
>> String getItem(String name);
>> byte[] getItem(String name);
>> ...
>>
>> setItem(String name, String value);
>> setItem(String name, byte[] value);
>> ...
>>
>> So in general it seems to be possible to map fields
in ObjectParam to
>> create
>> some form of SOAP request to given method with
given attributes and types.
>>
>> We need to implement one or several implementations
of FunctionInterface,
>> which could create SOAP call to given service,
knowing the parameters
>> which
>> are needed to call the service, and obviously
convert the data from
>> ObjectParam properties into some form expected by
the method.
>>
>> One of key feature is there should be no generated
source, needed to be
>> shipped together with software package, so every
parsing and call needs to
>> be
>> invoked dynamically.
>>
>> For now I have several questions:
>>
>> - is it possible using WSIF get list of functions
exposed by some service
>> as a
>> WSDL descriptor?
>>
>> - is it possible to recognize parameter types, and
dynamically bind some
>> marshallers/unmarshallers to them?
>>
>> Thank you in advance!
>>
>> --
>> Eugene N Dzhurinsky
>>
>>     
>
>
>
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: wsif-user-unsubscribews.apache.org
> For additional commands, e-mail: wsif-user-helpws.apache.org
>
>
>   


------------------------------------------------------------
---------
To unsubscribe, e-mail: wsif-user-unsubscribews.apache.org
For additional commands, e-mail: wsif-user-helpws.apache.org

Excellent point Jeff.

I lost some hours around this issue in WSIF and finally gave
up dnamic
invocation and generated all my stubs with WSDL2Java axis
library. I could
then map my types handy.

When I read that JROM had been removed from WSIF I gave up
my dii dreams.

I would really appreciate a sample code where you actually
implemented
that dude.Would that be possible?

I believe in mutual support. Given that we both seem to SOA
oriented we
could share stuffs and help each other.

Murvin

> You can do dynamic invocation using WSIF even if
complex types are
> involved.  You just can't do simple data binding.
>
> Suppose without loss of generality that the web service
requests and
> responses are in the form of SOAP messages.  The
complex types included
> in a response will correspond to some XML elements in
the message.  If
> you are doing dynamic invocation, you're not going to
have Java classes
> defined corresponding to each of the complex types
unless you generate
> code from the WSDL.  Presuming that you're not going to
do that in a
> dynamic invocation, you can work with the
org.w3c.dom.Element itself or
> some wrapper class you build around it.  Thus, any
complex type is
> deserialized into an Element or your
ComplexTypeWrapper.  In the latter
> case, the type name extracted from the wsdls
corresponding to the
> element can be included in the wrapper instance, and
then the
> information extracted from the wsdl and schemas about
the type can be
> applied during processing by the client.  Similarly,
when building a web
> service request, you'll have to assemble Elements
corresponding to the
> complex types needed in the input.  Nothing is really
lost here because
> again, you don't have a class around in your
application corresponding
> to that complex type anyway.
>
> The only special WSIF machinery you need for this is a
type mapping for
> each complex type to ComplexTypeWrapper or Element. 
These type mappings
> would be created on each invocation based on
information in the wsdl and
> schemas.  They are usually only needed for the complex
types
> corresponding to the "parts" of the input and
output messages.
>
> Jeff
>
> Murvin Bhantooa wrote:
>> Hi,
>>
>> I did a similar project using WSIF. Mine involved
consming several web
>> services that are exposed through thier WSDL.
>>
>> However as you know there are simple types and
custom types in WSDL
>> files.
>>
>> Total dynamic invocation will work fine for simple
types where parameter
>> types will be recognised on the fly.
>>
>> You will have to generate stubs if your WSDL has
complex/custom types.
>> The
>> process is thus not totally automated.
>>
>> If you have downloaded WSIF you will see and
example of dii in the
>> simpletype example and also one on complex types
using stubs.
>>
>> Otherwise it is very easy to create a wrapper
object and call
>> appropriate
>> methods and build that into a standalone library
which you can use
>> anywhere.
>>
>> Hope that helps!
>>
>> Murvin
>>
>>
>>> Hello!
>>>
>>> We have to develop an application which need to
parse WSDL file,
>>> extract
>>> list
>>> of available methods from it and expose to
upper layer as a list of
>>> interfaces
>>> like below:
>>>
>>> public interface FunctionInterface {
>>>     public ObjectParam exec(ObjectParam
param);
>>> };
>>>
>>> ObjectParam offers methods like
>>> String getItem(String name);
>>> byte[] getItem(String name);
>>> ...
>>>
>>> setItem(String name, String value);
>>> setItem(String name, byte[] value);
>>> ...
>>>
>>> So in general it seems to be possible to map
fields in ObjectParam to
>>> create
>>> some form of SOAP request to given method with
given attributes and
>>> types.
>>>
>>> We need to implement one or several
implementations of
>>> FunctionInterface,
>>> which could create SOAP call to given service,
knowing the parameters
>>> which
>>> are needed to call the service, and obviously
convert the data from
>>> ObjectParam properties into some form expected
by the method.
>>>
>>> One of key feature is there should be no
generated source, needed to be
>>> shipped together with software package, so
every parsing and call needs
>>> to
>>> be
>>> invoked dynamically.
>>>
>>> For now I have several questions:
>>>
>>> - is it possible using WSIF get list of
functions exposed by some
>>> service
>>> as a
>>> WSDL descriptor?
>>>
>>> - is it possible to recognize parameter types,
and dynamically bind
>>> some
>>> marshallers/unmarshallers to them?
>>>
>>> Thank you in advance!
>>>
>>> --
>>> Eugene N Dzhurinsky
>>>
>>>
>>
>>
>>
>>
------------------------------------------------------------
---------
>> To unsubscribe, e-mail: wsif-user-unsubscribews.apache.org
>> For additional commands, e-mail: wsif-user-helpws.apache.org
>>
>>
>>
>
>
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: wsif-user-unsubscribews.apache.org
> For additional commands, e-mail: wsif-user-helpws.apache.org
>



------------------------------------------------------------
---------
To unsubscribe, e-mail: wsif-user-unsubscribews.apache.org
For additional commands, e-mail: wsif-user-helpws.apache.org

I'm afraid the code is proprietary.  I've tried to help a
number of
people on this list do dynamic invocation with complex types
at one
time or another, but I can't share code.  I started from
the
DynamicInvoker sample.

Jeff

On 10/17/07, Murvin Bhantooa <mbhantoocis.strath.ac.uk> wrote:
> Excellent point Jeff.
>
> I lost some hours around this issue in WSIF and finally
gave up dnamic
> invocation and generated all my stubs with WSDL2Java
axis library. I could
> then map my types handy.
>
> When I read that JROM had been removed from WSIF I gave
up my dii dreams.
>
> I would really appreciate a sample code where you
actually implemented
> that dude.Would that be possible?
>
> I believe in mutual support. Given that we both seem to
SOA oriented we
> could share stuffs and help each other.
>
> Murvin
>
> > You can do dynamic invocation using WSIF even if
complex types are
> > involved.  You just can't do simple data binding.
> >
> > Suppose without loss of generality that the web
service requests and
> > responses are in the form of SOAP messages.  The
complex types included
> > in a response will correspond to some XML elements
in the message.  If
> > you are doing dynamic invocation, you're not going
to have Java classes
> > defined corresponding to each of the complex types
unless you generate
> > code from the WSDL.  Presuming that you're not
going to do that in a
> > dynamic invocation, you can work with the
org.w3c.dom.Element itself or
> > some wrapper class you build around it.  Thus, any
complex type is
> > deserialized into an Element or your
ComplexTypeWrapper.  In the latter
> > case, the type name extracted from the wsdls
corresponding to the
> > element can be included in the wrapper instance,
and then the
> > information extracted from the wsdl and schemas
about the type can be
> > applied during processing by the client. 
Similarly, when building a web
> > service request, you'll have to assemble Elements
corresponding to the
> > complex types needed in the input.  Nothing is
really lost here because
> > again, you don't have a class around in your
application corresponding
> > to that complex type anyway.
> >
> > The only special WSIF machinery you need for this
is a type mapping for
> > each complex type to ComplexTypeWrapper or
Element.  These type mappings
> > would be created on each invocation based on
information in the wsdl and
> > schemas.  They are usually only needed for the
complex types
> > corresponding to the "parts" of the
input and output messages.
> >
> > Jeff
> >
> > Murvin Bhantooa wrote:
> >> Hi,
> >>
> >> I did a similar project using WSIF. Mine
involved consming several web
> >> services that are exposed through thier WSDL.
> >>
> >> However as you know there are simple types and
custom types in WSDL
> >> files.
> >>
> >> Total dynamic invocation will work fine for
simple types where parameter
> >> types will be recognised on the fly.
> >>
> >> You will have to generate stubs if your WSDL
has complex/custom types.
> >> The
> >> process is thus not totally automated.
> >>
> >> If you have downloaded WSIF you will see and
example of dii in the
> >> simpletype example and also one on complex
types using stubs.
> >>
> >> Otherwise it is very easy to create a wrapper
object and call
> >> appropriate
> >> methods and build that into a standalone
library which you can use
> >> anywhere.
> >>
> >> Hope that helps!
> >>
> >> Murvin
> >>
> >>
> >>> Hello!
> >>>
> >>> We have to develop an application which
need to parse WSDL file,
> >>> extract
> >>> list
> >>> of available methods from it and expose to
upper layer as a list of
> >>> interfaces
> >>> like below:
> >>>
> >>> public interface FunctionInterface {
> >>>     public ObjectParam exec(ObjectParam
param);
> >>> };
> >>>
> >>> ObjectParam offers methods like
> >>> String getItem(String name);
> >>> byte[] getItem(String name);
> >>> ...
> >>>
> >>> setItem(String name, String value);
> >>> setItem(String name, byte[] value);
> >>> ...
> >>>
> >>> So in general it seems to be possible to
map fields in ObjectParam to
> >>> create
> >>> some form of SOAP request to given method
with given attributes and
> >>> types.
> >>>
> >>> We need to implement one or several
implementations of
> >>> FunctionInterface,
> >>> which could create SOAP call to given
service, knowing the parameters
> >>> which
> >>> are needed to call the service, and
obviously convert the data from
> >>> ObjectParam properties into some form
expected by the method.
> >>>
> >>> One of key feature is there should be no
generated source, needed to be
> >>> shipped together with software package, so
every parsing and call needs
> >>> to
> >>> be
> >>> invoked dynamically.
> >>>
> >>> For now I have several questions:
> >>>
> >>> - is it possible using WSIF get list of
functions exposed by some
> >>> service
> >>> as a
> >>> WSDL descriptor?
> >>>
> >>> - is it possible to recognize parameter
types, and dynamically bind
> >>> some
> >>> marshallers/unmarshallers to them?
> >>>
> >>> Thank you in advance!
> >>>
> >>> --
> >>> Eugene N Dzhurinsky
> >>>
> >>>
> >>
> >>
> >>
> >>
------------------------------------------------------------
---------
> >> To unsubscribe, e-mail:
wsif-user-unsubscribews.apache.org
> >> For additional commands, e-mail:
wsif-user-helpws.apache.org
> >>
> >>
> >>
> >
> >
> >
------------------------------------------------------------
---------
> > To unsubscribe, e-mail: wsif-user-unsubscribews.apache.org
> > For additional commands, e-mail:
wsif-user-helpws.apache.org
> >
>
>
>
>

------------------------------------------------------------
---------
To unsubscribe, e-mail: wsif-user-unsubscribews.apache.org
For additional commands, e-mail: wsif-user-helpws.apache.org

No bother Jeff,

Thanks for the concept anyway. I'll try to figure it out. I
wish I got
more free time!!

Murvin

> I'm afraid the code is proprietary.  I've tried to help
a number of
> people on this list do dynamic invocation with complex
types at one
> time or another, but I can't share code.  I started
from the
> DynamicInvoker sample.
>
> Jeff
>
> On 10/17/07, Murvin Bhantooa <mbhantoocis.strath.ac.uk> wrote:
>> Excellent point Jeff.
>>
>> I lost some hours around this issue in WSIF and
finally gave up dnamic
>> invocation and generated all my stubs with
WSDL2Java axis library. I
>> could
>> then map my types handy.
>>
>> When I read that JROM had been removed from WSIF I
gave up my dii
>> dreams.
>>
>> I would really appreciate a sample code where you
actually implemented
>> that dude.Would that be possible?
>>
>> I believe in mutual support. Given that we both
seem to SOA oriented we
>> could share stuffs and help each other.
>>
>> Murvin
>>
>> > You can do dynamic invocation using WSIF even
if complex types are
>> > involved.  You just can't do simple data
binding.
>> >
>> > Suppose without loss of generality that the
web service requests and
>> > responses are in the form of SOAP messages. 
The complex types
>> included
>> > in a response will correspond to some XML
elements in the message.  If
>> > you are doing dynamic invocation, you're not
going to have Java
>> classes
>> > defined corresponding to each of the complex
types unless you generate
>> > code from the WSDL.  Presuming that you're not
going to do that in a
>> > dynamic invocation, you can work with the
org.w3c.dom.Element itself
>> or
>> > some wrapper class you build around it.  Thus,
any complex type is
>> > deserialized into an Element or your
ComplexTypeWrapper.  In the
>> latter
>> > case, the type name extracted from the wsdls
corresponding to the
>> > element can be included in the wrapper
instance, and then the
>> > information extracted from the wsdl and
schemas about the type can be
>> > applied during processing by the client. 
Similarly, when building a
>> web
>> > service request, you'll have to assemble
Elements corresponding to the
>> > complex types needed in the input.  Nothing is
really lost here
>> because
>> > again, you don't have a class around in your
application corresponding
>> > to that complex type anyway.
>> >
>> > The only special WSIF machinery you need for
this is a type mapping
>> for
>> > each complex type to ComplexTypeWrapper or
Element.  These type
>> mappings
>> > would be created on each invocation based on
information in the wsdl
>> and
>> > schemas.  They are usually only needed for the
complex types
>> > corresponding to the "parts" of the
input and output messages.
>> >
>> > Jeff
>> >
>> > Murvin Bhantooa wrote:
>> >> Hi,
>> >>
>> >> I did a similar project using WSIF. Mine
involved consming several
>> web
>> >> services that are exposed through thier
WSDL.
>> >>
>> >> However as you know there are simple types
and custom types in WSDL
>> >> files.
>> >>
>> >> Total dynamic invocation will work fine
for simple types where
>> parameter
>> >> types will be recognised on the fly.
>> >>
>> >> You will have to generate stubs if your
WSDL has complex/custom
>> types.
>> >> The
>> >> process is thus not totally automated.
>> >>
>> >> If you have downloaded WSIF you will see
and example of dii in the
>> >> simpletype example and also one on complex
types using stubs.
>> >>
>> >> Otherwise it is very easy to create a
wrapper object and call
>> >> appropriate
>> >> methods and build that into a standalone
library which you can use
>> >> anywhere.
>> >>
>> >> Hope that helps!
>> >>
>> >> Murvin
>> >>
>> >>
>> >>> Hello!
>> >>>
>> >>> We have to develop an application
which need to parse WSDL file,
>> >>> extract
>> >>> list
>> >>> of available methods from it and
expose to upper layer as a list of
>> >>> interfaces
>> >>> like below:
>> >>>
>> >>> public interface FunctionInterface {
>> >>>     public ObjectParam
exec(ObjectParam param);
>> >>> };
>> >>>
>> >>> ObjectParam offers methods like
>> >>> String getItem(String name);
>> >>> byte[] getItem(String name);
>> >>> ...
>> >>>
>> >>> setItem(String name, String value);
>> >>> setItem(String name, byte[] value);
>> >>> ...
>> >>>
>> >>> So in general it seems to be possible
to map fields in ObjectParam
>> to
>> >>> create
>> >>> some form of SOAP request to given
method with given attributes and
>> >>> types.
>> >>>
>> >>> We need to implement one or several
implementations of
>> >>> FunctionInterface,
>> >>> which could create SOAP call to given
service, knowing the
>> parameters
>> >>> which
>> >>> are needed to call the service, and
obviously convert the data from
>> >>> ObjectParam properties into some form
expected by the method.
>> >>>
>> >>> One of key feature is there should be
no generated source, needed to
>> be
>> >>> shipped together with software
package, so every parsing and call
>> needs
>> >>> to
>> >>> be
>> >>> invoked dynamically.
>> >>>
>> >>> For now I have several questions:
>> >>>
>> >>> - is it possible using WSIF get list
of functions exposed by some
>> >>> service
>> >>> as a
>> >>> WSDL descriptor?
>> >>>
>> >>> - is it possible to recognize
parameter types, and dynamically bind
>> >>> some
>> >>> marshallers/unmarshallers to them?
>> >>>
>> >>> Thank you in advance!
>> >>>
>> >>> --
>> >>> Eugene N Dzhurinsky
>> >>>
>> >>>
>> >>
>> >>
>> >>
>> >>
------------------------------------------------------------
---------
>> >> To unsubscribe, e-mail:
wsif-user-unsubscribews.apache.org
>> >> For additional commands, e-mail:
wsif-user-helpws.apache.org
>> >>
>> >>
>> >>
>> >
>> >
>> >
------------------------------------------------------------
---------
>> > To unsubscribe, e-mail:
wsif-user-unsubscribews.apache.org
>> > For additional commands, e-mail:
wsif-user-helpws.apache.org
>> >
>>
>>
>>
>>
>
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: wsif-user-unsubscribews.apache.org
> For additional commands, e-mail: wsif-user-helpws.apache.org
>



------------------------------------------------------------
---------
To unsubscribe, e-mail: wsif-user-unsubscribews.apache.org
For additional commands, e-mail: wsif-user-helpws.apache.org

On Wed, Oct 17, 2007 at 09:44:31AM -0700, Jeff Greif wrote:
> You can do dynamic invocation using WSIF even if
complex types are 
> involved.  You just can't do simple data binding.
> 
> Suppose without loss of generality that the web service
requests and 
> responses are in the form of SOAP messages.  The
complex types included in 
> a response will correspond to some XML elements in the
message.  If you are 
> doing dynamic invocation, you're not going to have Java
classes defined 
> corresponding to each of the complex types unless you
generate code from 
> the WSDL.  Presuming that you're not going to do that
in a dynamic 
> invocation, you can work with the org.w3c.dom.Element
itself or some 
> wrapper class you build around it.  Thus, any complex
type is deserialized 
> into an Element or your ComplexTypeWrapper.  In the
latter case, the type 
> name extracted from the wsdls corresponding to the
element can be included 
> in the wrapper instance, and then the information
extracted from the wsdl 
> and schemas about the type can be applied during
processing by the client.  
> Similarly, when building a web service request, you'll
have to assemble 
> Elements corresponding to the complex types needed in
the input.  Nothing 
> is really lost here because again, you don't have a
class around in your 
> application corresponding to that complex type anyway.
> 
> The only special WSIF machinery you need for this is a
type mapping for 
> each complex type to ComplexTypeWrapper or Element. 
These type mappings 
> would be created on each invocation based on
information in the wsdl and 
> schemas.  They are usually only needed for the complex
types corresponding 
> to the "parts" of the input and output
messages.

Hello, Jeff Greif!
Thank you for prompt response, however it's still not clear
for me:

1) could you please explain how can I get list of available
methods using
WSIF?

2) is it possible to get type definitions for the parameters
and return values
for certain method using WSIF somehow?

3) if I will know such information, will I be able to
prepare SOAP call and
invoke remote method with WSIF?

Thank you in advance!

-- 
Eugene N Dzhurinsky

If I remember correctly, the javadoc in the WSIF package
does not 
include the packages in the wsdl4j library which is part of
the 
distribution.  That library contains the classes for
analyzing a WSDL 
document and extracting the information you want.  I don't
remember 
where that project is currently being maintained, but if you
find it via 
Google, you can get the documentation for the relevant
classes.  The 
other piece that may be useful is the org.apache.wsif.schema
package, 
which has a relatively superficial representation of a
schema useful for 
web service invocation.

Jeff

Eugeny N Dzhurinsky wrote:
> On Wed, Oct 17, 2007 at 09:44:31AM -0700, Jeff Greif
wrote:
>   
>> You can do dynamic invocation using WSIF even if
complex types are 
>> involved.  You just can't do simple data binding.
>>
>> Suppose without loss of generality that the web
service requests and 
>> responses are in the form of SOAP messages.  The
complex types included in 
>> a response will correspond to some XML elements in
the message.  If you are 
>> doing dynamic invocation, you're not going to have
Java classes defined 
>> corresponding to each of the complex types unless
you generate code from 
>> the WSDL.  Presuming that you're not going to do
that in a dynamic 
>> invocation, you can work with the
org.w3c.dom.Element itself or some 
>> wrapper class you build around it.  Thus, any
complex type is deserialized 
>> into an Element or your ComplexTypeWrapper.  In the
latter case, the type 
>> name extracted from the wsdls corresponding to the
element can be included 
>> in the wrapper instance, and then the information
extracted from the wsdl 
>> and schemas about the type can be applied during
processing by the client.  
>> Similarly, when building a web service request,
you'll have to assemble 
>> Elements corresponding to the complex types needed
in the input.  Nothing 
>> is really lost here because again, you don't have a
class around in your 
>> application corresponding to that complex type
anyway.
>>
>> The only special WSIF machinery you need for this
is a type mapping for 
>> each complex type to ComplexTypeWrapper or Element.
 These type mappings 
>> would be created on each invocation based on
information in the wsdl and 
>> schemas.  They are usually only needed for the
complex types corresponding 
>> to the "parts" of the input and output
messages.
>>     
>
> Hello, Jeff Greif!
> Thank you for prompt response, however it's still not
clear for me:
>
> 1) could you please explain how can I get list of
available methods using
> WSIF?
>
> 2) is it possible to get type definitions for the
parameters and return values
> for certain method using WSIF somehow?
>
> 3) if I will know such information, will I be able to
prepare SOAP call and
> invoke remote method with WSIF?
>
> Thank you in advance!
>
>   


------------------------------------------------------------
---------
To unsubscribe, e-mail: wsif-user-unsubscribews.apache.org
For additional commands, e-mail: wsif-user-helpws.apache.org