Originally posted by Andrew Black:
but I still don't understand the relationsship between JAXB and and RPC.
JAXB is heavily used by JAX-WS 2.0. It's basically a code generator that looks at a specified XML Schema Definition and builds a Java unmarshaller, marshaller and object model to manipulate the information of XML documents that adhere to that schema.
It is part of the earlier JWSDPs as JAXB is one of the (by Sun) recommended technologies for XML document manipulation - in addition to SAX and DOM. JAXB is easier to use than SAX and may not require as much memory as DOM.
Lately StAX has been thrown into the mix � it�s a "Pull-Parser" while SAX is a "Push-Parser". Basically SAX tells you through "events" that it parsed the next item and you better do something with the information now - all the parsing is routed through one central event handler - with StAX you tell it when you are ready to process the next bit, so in addition to whatever you data you store your location within your logic also defines your parsing state.
Then of course there is TRaX that can help you with your XSLT work. Many of these XML manipulation technologies are joined under the JAXP umbrella.
JAXP 1.2 (XML 1.0, XML namespaces, XML Schema, XSLT 1.0 (TRaX), SAX 2.0, DOM Level 2)
JAXP 1.3 (XML 1.1, XML namespaces, XML Schema, XSLT 1.0 (TRaX), XPath 1.0, XInclude 1.0, DOM Level 3, SAX 2.0.2)
(Elliotte Rusty Harold's
Processing XML with Java is a great resource.)
All these XML manipulation technologies are necessary as the primary purpose of SOAP Web Services is the
exchange of (potentially large) XML documents which have to be created and later processed. RPC in the SOAP context is more of a "convenience feature" - the top level element of the SOAP payload isn't actually an XML document, it's simply an element representing a "message" to an operation that should process the contents of that "message" element.
Remember the expansion of the SOAP acronym "Simple Object Access Protocol" has been officially dropped - for a good reason. It's neither simple nor has it anything do with objects - its all about moving XML data in a controlled manner (with the inherent overhead). Those who try to use SOAP Web Services as a remoting mechanism for their ordinary (fine-grain) Java objects are likely to find the disappointment that was experienced by those who tried to do the same with
EJB.