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]
