Hi Alek, I was searching for something similar in order to directly use XML and found the following. --------------------------------------------- >I was wondering if you plan to include the >functionality of invoking by directly passing the XML >message to send and directly extracting the XML from >the response, without object >serialization/deserialization in WSIF. > absolutely yes and to make things smoother to have also DOM API implemented on top of WSIFMessage and allow easy execution of XPATH queries on WSIFMessage as well ! ---------------------------------------- I was wondering what is the status of allowing users direct access to a DOM with XPath as stated above. It would be a great feature. The second question is related, I think. Have you given any thought to how the WS-* specifications fit in with WSIF. For instance WS-Addressing provides for statefull web services by including reference parameters in the endpoint references and using MessageIds, but these WS-Addressing Elements map to SOAP headers which do not exist in non-SOAP invocations such as EJB. Thanks, Ron
________________________________ From: Aleksander Slominski [mailto:[EMAIL PROTECTED] Sent: Tue 3/29/2005 3:07 PM To: [email protected] Subject: Re: Dynamic Invocation with complex types Miguel Alves wrote: > Hi, > > I'am trying create a service that invoke any Webservice without > knowing that input/output types. The examples for dynamic invocation > only work with simple types, if I mention any complex type I receive > the fowlloing error > > org.xml.sax.SAXException: Deserializing parameter 'return': could not > find deserializer for type {urn:GoogleSearch}GoogleSearchResult > > In this case the GoogleSearch type. I know that I could use WSDL2Java > to generate the interfaces and so on...however my problem is that this > should work for any webservice so I can't write any code before > invoking a new service. > > I also tried XSUL, http://www.extreme.indiana.edu/xgws/xsul/ WSIF > implementation and it works fine showing the results without any problem > > I guess I can solve this problem by writing a generic deserialization > class, that for example, put the return object in a DOM object. > hi Miguel, yes that should work and i think somebody worked on something like that and posted about it in axis-dev. HTH, alek -- The best way to predict the future is to invent it - Alan Kay
