How do I create a "document-centric" Web Service?

Question

By document-centric I'm talking about receiving a SOAP message on the server-side, where the initial parsing and security processing (this aspect is very important) is performed but then allowing the developer to access the delivered "payload", i.e. the XML, and perform whatever mapping/processing that is required without automatically mapping to the "standard" auto-generated Java objects.
It is important that the client receives the "full" complex WSDL and can therefore generate their proxy classes with whatever tool (or language) that is appropriate.
On the server side we do not want to create hundreds (if not thousands) of Java Bean clases as we already have the legacy code to map XML to Java. The idea is that JAX-RPC only instantiates the SOAPElements that represent the "raw" message, or, if possible, doesn't instantiate any objects whatsoever.
I've spent many days now trying to find a single well-worked example for this type of Web Service without success - many, many references of the style "..and you can then create a document style web service.." but without the all important "how".
From what I've read a custom type-mapping and/or serializer/deserializer could be the answer but again no good, solid examples are forthcoming.
Another alternative seems to be to create the server side stub-classes using a "dummy" WSDL with the elements set to "anyType" but then distribute the "genuine" WSDL to the clients - we've got a simple example of the kind working but I don't like the idea of "tricking" the system in this way.
I'm working with WASD 5.1, which in theory conforms with JAX-RPC so any ideas offered here should also apply in that environment.
Has ANYONE successfully created a service of this type?
Any help with this issue would be very much appreciated and rewarded (with Duke Dollars of course).
Chris.

Answer 1

Chris,
I too noticed that most vendors take the RPC centric approach. Its because most of the industry examples of how WSs were used were simple enough to implement using RPC and anything more (document literal) would add to the complexity of implementation. This is something that is feared by many developers, especialy the .Net crowd who seem to want everything done through a wizard menu interface and don't care about other WS implementations at all.
This is sort of changing. J2EE 1.4 is WS-I compliant, so when you compile server side ties from WSDL you can specify a document literal option and WS-I compliance. This gives you access to the SOAPElement objects. There's still issues with going between W3C DOM and SOAP elements but that's just API inconvenience, not a show stopper. As the inudustry develops more complex WSs we will see the vendors change their tools to better support this...
Anyway, some more help...
I use the the following wscompile options to build from WSDL for document literal WSs.
wscompile.bat -d . -nd . -s . -f:documentliteral -f:wsi -keep -model model.gz -import config.xml
wscompile.bat -d . -nd . -s . -f:documentliteral -f:wsi -keep -model model.gz -gen:server config.xml
My "wrapper" elements look like this...
<xs:element name="AComplexXMLResponse">
     <xs:complexType>
          <xs:sequence>
               <xs:element ref="myNS:MYComplexXMLType"/>
          </xs:sequence>
     </xs:complexType>
</xs:element>
If I do this:
<xs:element name="ASimpleXMLResponse">
     <xs:complexType>
          <xs:sequence>
               <xs:element name="AName" type="xs:string"/>
          </xs:sequence>
     </xs:complexType>
</xs:element>
I still get the JAXRPC language bindings to a string, but in my case I don't really care. This may well be different for you.
What I do to manage these elements is to split up the WSDL, WS wrapper element definitions and actual data XML schema definitions into separate documents. This means I have a WSDL which IMPORTS my message schema (this is where I define wrappers for in and out XML) which INCLUDES the actual DATA XML schema that I have.
The WSDL import looks like this:
<types>
     <xs:schema>
          <xs:import namespace="http://schemaURI" schemaLocation="./relativePath/WrapperElementSchema.xsd"/>
     </xs:schema>
</types>
The wrapper element schema has:
<xs:include schemaLocation="./ActualDataSchema.xsd"/>
This way I can easily replace the wrapper documents with just anyType references if something doesn want to play nice. The data schema file and the WSDL stay the same. This minimises the impact on what you have to change in your distribution. This is important as the WSDL is often generated on the fly by your WS environment and so can not be easily changed once you build your WSs, but the schema files it references are easily changed without affecting your code.
Another reason for the wrapper elements was a JWSDP 1.2 issue (I don't know if this has been fixed in 1.3), where if you had the same method parameter signature in a web service (the parameters it took were the same XML types, for instance if you have an add and update methods for the same document input) JWSDP would get confused at runtime. It did not take account of the SOAP action that came along with the request to determine which operation to call. It just took the incoming XML, saw that it was of a certain type and it passed it to the first operation that took this element, which is VERY wrong. By using the wrapper elements, I could give all my input and output elements for each method different names (I used a naming stragegy that appended a 'request' or 'response' string to the method name to form a method parameter element name. This is a pain in the ass, but works and does wonders for interoperability with other WS vendors. Like I said before, I've got this working with JWSDP, BEA and .Net servers and clients.
Hope this helps,
If you think there is a real need for a public HOWTO on this, I could write one with a full step by step guideline that shows where I broke my legs getting this stuff to work. But this would eat into my sleep time :-/ TO JUDGE INTEREST I call on all people interested in a tutorial to respond to this thread (esp people involved with the JWSDP WS tutorial documentation). If I get 5 or more different people responding I will loose some sleep for the good of this community. Otherwise, I will just try to help you when I have time to read the forums.
Kuba