This is great to hear about, but information on WS/XSUL looks scarce (I found your slide set - or is that slajd set?).
woes of trying to do power point to html conversion ... (BTW "slajd" is in Polish for slide :) )
Can you point me at anything that's usable?
WS/XSUL just reached 1.0 version though i am not making it generally available as there is still lot to do such as WSDL and WSIF-like style API.
I'd love to include WS/XSUL in a round of doc/lit performance tests I'm running.
internally all XML (and more such as message context) is represented using XML Infoset API i cooked (XB1 in XPP3) that supports storing XML information items and Java objects** in the same tree (so you can gradually do type binding by converting parts of it between XML and Java types), it is xpath enabled, JDK 1.5 ready (when JDK 1.5 is out of beta), etc etc
I thought from the beginning that XMLBeans would be a great basis for a WS implementation, and told the BEA people that I hoped they were working on integrating it.
i think that XmlBeans is pretty well integrated in WebLogic GUI/IDE/tooling.
Something like this is probably what's needed for the next generation of Apache SOAP.
i like to think about WS/XSUL as an approximation of what could look like a refactored next gen AXIS to make it truly modular. for example i have client-side only XSUL JAR that is 87K and requires only XPP3/XB1 for client side SOAP (whole WS/XSUL is 250K and will require XmlBeans and security related jars depending on what modules are used easily making it large but you can mix and match modules to meet your requirements and ddependencies)
The only problem I see with an XMLBeans approach is that you're once again tying your application code directly to the wire format of the SOAP messages
first there is XML Infoset (and that is the only assumption) and XSUL is just happy to exchange XML messages. SOAP support is an additional layer on top of XML messaging layer that is implemented as a set of modules to work with SOAP 1.1 and 1.2 compatible XML infoset. then there is type mapping layer currently either simple direct binding to few XML Schemas primitive types and SOAP env arrays (for small WS clients) or full blown XmlBeans type binding for doc/lit exchange (with validation if needed).
- I think they should often be decoupled. On the other hand, that way the schema really is the definitive reference - if you change the schema you have to rebuild your derived classes and modify your application code to match.
yes and that is where i think that real challenge for type binding is: how to make it so that systems can evolve and be robust in face of changes of XML messages
I've got my own lightweight SOAP framework built around JiBX. I'll try to get something out about that, probably adding it as a subproject in conjunction with the beta 3a release next week, so that people who are interested in a decoupled approach will have something to try.
what do you use as as example service to test for doc/lit? i was thinking about Google WS but maybe there is something better?
thanks,
alek
-- The best way to predict the future is to invent it - Alan Kay
