Welcome to CodeRanch!
James Ashford wrote:What happens in the gap between the XML document being received by a consumer and having that data in the generated classes? I had assumed that was handled by a part of an application server. Show the server the XSD, show it the JAR containing the generated classes and have it automatically unmarshall data in the incoming XML document into those classes. I don't know if that's how it's supposed to happen or if I have to manually process the XML and instantiate and populate the classes.
I'm not aware of any application servers that work that way. You can use JAXB independent of any application server. Some application servers use web service
SOAP stacks that
use JAXB under the hood (JAX-WS for example). If you are using JAXB independently then you are expected to invoke the XML document
unmarshal process manually - the generated Unmarshaller does the actual unmarshalling work. Conversely you use the generated Marshaller to
marshal the data stored in the Java content tree into an XML document.
James Ashford wrote:The XML schema for the data is an industry standard. ... The business logic of the application is contained within a set of classes and a session facade provides coarse-grained entry points. ... I am sure that this is actually all very simple.
Not necessarily (actually unlikely) - I suspect that there is an "impedance mismatch" between the "industry standard XML" and the data that is used by the session façade and that is likely to become the main source of friction in your solution.
James Ashford wrote:A version of that facade exposes functionality to web service clients. ... I need the simplest thing that works.
"The Simplest Thing That Could Possibly Work" depends on your perspective. If it is simple from the development perspective it can potentially be problematic from the web service client perspective.
Having the "luxury" of an "industry standard XML schema", the schema should serve as the basis for your web service façade design. It defines the standard XML documents used to structure information in your domain. Looking at the schema you have to decide which XML documents you expect to accept and which documents you expect to return in response. Just keep in mind that with document-orientation you can only accept exactly one XML document and return at most one XML document (that single document could "wrap" multiple "sub" documents;
wrapped document/literal convention). The notion of a "web method" is only retained for the sake of code generators which are used for building web clients and services - the "web method" doesn't appear anywhere in a document-oriented web service request. On a document-oriented SOAP web service endpoint the "XML schema type" of the incoming XML document contained in the web service request
implies which "web method" will be invoked in the service logic (i.e. no two "web methods" can accept the same XML schema document type).
If you then decide to build a SOAP-based web service façade with JAX-WS (for example) you can define a WSDL (Web Services Description Language) that uses the "industry standard XML schema" to define your web service and use the WSDL as input to a WSDL-to-Code generator (wsimport) that will generate the service skeleton and object representations for the XML document types. Just keep in mind that there are options other than SOAP for "XML-based" web services.
The remaining challenge is then to "cross the chasm" between the web service calls and the calls to the existing session façade. Apart from granularity and sequencing issues, you are still responsible for the transformation of the data in the generated classes to the classes used by the session façade (and back).
James Ashford wrote:What arguments should be accepted by the methods on the web service facade? A String type for an XML document or the generated classes?
That question reveals that you are thinking in terms of RPC,
not "document-oriented web services". Document-oriented web services always accept
a single XML document and return at most one single XML document. Depending on the type of web service technology you use, the XML documents may be unmarshalled as (generated) objects which themselves can be marshalled back to XML documents of the appropriate type.