> -----Original Message----- > From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]] > > > Also I can't be of much help right now I think that the Cocoon<-->WS > issue is quite important to be addressed, and incorporated into the > "core". Hence, I'm willing to hear your discussions here, on > this list. > > Lurking here, > Vadim > > > > Suggestions? > > > > Matthew
I believe Cocoon and Web Services have a natural fit, especially on the client side. Conceptually, client side processing is pure XML play: access WSDL doc. ( an XML document ), create and send the request document based on WSDL description( an XML document ), receive and interprete the response document ( an XML document ). One could even think of additional XML processing steps like search UDDI to get WSDL, use XML ontologies to perform XML element translations and so on. A lot of attention is on creating Java APIs to do these. And these make sense in the static world where WSDLs don't change and you could hard code method names and parameters in your dynamic invocation or generate the stubs during development time. However, for totally dynamic world of Web Services ( though, I must add -- current generation of marketing folks don't like too much dynamism and are happy to take WS as a plug-n-paly mechanism for s/w components ) and Semantic Web, a pure XML approach make a lot of sense. Cocoon has some pieces like SOAP logicsheet and XScript that are in this direction but a lot more work is needed. Server side support requires more thinking. We must come up with an architecture that leverages both Axis and Cocoon. Axis is good at deployment of RPC mode Web Services. Cocoon is good at handing huge documents and transformations. A combination would be quite formidable. /Pankaj. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
