Re: wsif evaluation questions

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: [email protected]
> For additional commands, e-mail: [email protected]
>
>
>