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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
>> >> For additional commands, e-mail: [EMAIL PROTECTED]
>> >>
>> >>
>> >>
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
