Re: wsif evaluation questions
"Murvin Bhantooa" <[email protected]> Thu, 18 Oct 2007 09:32:55 +0100 (BST)
| Newsgroups | gmane.comp.apache.webservices.wsif.user |
|---|---|
| Message-ID | <34278.87.194.184.126.1192696375.squirrel@webmail.gsi.strath.ac.uk> |
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] >