> >But a POJO <--> XML binding is essential for business > applications that interoperate via web services standards > (i.e., SOAP, XML, WSDL). > > > i do not agree. if you have POJO you should use RMI if all > you services > are Java or CORBA if you can assure that everybody get the > same IDL that > is under central control and changes can be controlled and updates > rolled out. > > that will work way better then using XML as serialization format ...
But, in many (probably most) real world scenarios not all the services are Java or CORBA. For example, when 2 companies merge, and they want to integrate systems, many would like to be able to integrate Java (POJO and EJB), .NET, SAP (and other packages), CICS, etc. via web services standards. Furthermore, doesn't integration of services over the internet have to be done via XML over HTTP (can you do RMI over the internet?? - i've never heard of anyone doing it). > XML schemas and WSDL should be crafted first so only > appropriate level > of coupling is required and Web Services peers can interact > independent > form programming language, and in particular independent if they use > POJO, data bindings or just work with XML directly. > > message medium contract (XML, SOAP, and WSDL/XS/...) should be the > essential for business applications - of course that is theory but in > practice ... > yes, in practice the services are usually around long before the message, medium, contract have been agreed upon ... > > And there are always going to be lots of different ways > that people do it (e.g., JAXB, Castor, XmlBeans, custom > mappings, etc). > > > > > i would add JiBX as it seems to be the most complete of all those > mappings. JAXB Castor and Xmlbeans are not POJO - there is > lot of stuff > inside those "POJOs" they generate ... (BTW: i think JAXB > does not even > generate POJO as it generates interfaces and not classes ...) yes, I need to learn more about JiBX. Note also that even the "POJOs" generated by the Axis 1.x WSDL2Java contain a lot of "stuff". And you are right about JAXB - it uses interfaces. The internals of the implemenations are far from "POJO"! > >This approach requires that you create an API for the java > binding plug-in. A shortcoming of Axis 1.x is that the > SAX-based java binding mechanism is deeply intertwined with > the SOAP handling mechanism. Axis2 needs a clean separation > of SOAP handling (i.e, header processing) from the java > binding that is required for web service invocation. > > > > > i do not see that this separation ca work. headers needs data binding > (even DOM or SAAJ can be called databinding as they provide > java view on > XML and many more may be needed...) yes, you are right - the distinction is not Header vs. Body, but SOAP handling vs. web serivce invocation. And you are also right that even basic SOAP handling needs some data binding, but isn't one goal of Axis2 to limit the data binding that goes on prior to web service invocation as much as possible? > > >The components of such a plug-in binding API primarily would > include: type mapping registry, [de]serialization (binding) > context, [de]serializers, and a deployment mechanism for > POJOs (that allows you to specify the binding to use). > > > > > i am very uncomfortable with lossy conversions - unless yo have > extremely reach mapping metadata you loose infoset in XML->Java > conversion and when doing Java->XML you may be no longer able to > construct XML required in contract (XML Schema etc.) > > moreover some handlers may need to access XML Infoset even even after > data binding(s) were executed For a web service, doesn't the WSDL provide the contract (XML Schema etc.)? The loss of information going from XML request -> Java request -> Java response -> XML response for the purpose of web service invocation shouldn't be a problem as long as the XML response is valid per the WSDL contract. The Java response -> XML response conversion is the responsibility of some serializer that is specified (perhaps as part of a registry) as part of the web service deployment. If the guy deploying the web service wants to use a lossy binding, that shouldn't be a problem as long as his serializer generates XML that is valid wrt the WSDL. Am I missing something? > >Of course, going from XML --> POJO via any deserializer > requires pulling the entire XML into memory. > > > actually it does not require it if you have deserializer that > can read > from XML event stream (SAX, XmlPull, StAX, etc) for example: > > public Object deserialize(XmlPullParser pp, BindingContext ctx) > > which i think is already more or less provided by JiBX AFAIK > Techincally, you are right, but I think that in most scenarios the POJO that gets generated is going to use at least as much memory as a DOM representation of the original XML. And, even when that is not the case, you are still going to get the performance hit becuase you are almost always going to have to "pull" the entire XML stream through your parser once to generate the POJO aren't you? Maybe an exception to this is when your XML has some binary attachment thingy on it that you are not pulling into the POJO, but other than that, I don't see how you can do a deserialization without reading the entire XML stream. > >So perhaps the Axis2 engine should be designed so that the > java binding is handled by a separate pool of threads from > the AXIOM-based handler chain? Users who really care a lot > about server performance could configure it so that seperate > CPUs handle SOAP processing (high volume) vs. java binding > (memory intensive). > > > > > actually clustering AXIS2 engines would be much more > efficient in case > when services are relatively contained and stateless How would such clustering be implemented? Wouldn't you, for example, have one Axis2 engine process a SOAP request up to the point where its target web services has been identified and then hand off to another Axis2 engine to do the java binding and invoke the service?
