Creating JAX-WS webservice using Service Data Objects (SDO) instead of JAXB-bound POJOs

If you need to invoke a logic using Service Data Objects (SDOs) from a JAX-WS webservice under Websphere 7 without the SCA Feature Pack, it is possible to do it similarly to the old approach of generating a JAX-RPC webservice from a WSDL with an SDO facade (actually building on it).

The steps are:

1. Use RAD to generate a JAX-RPC webservice from a WSDL with an SDO facade.
2. Implement a JAX-WS webservice accessing directly its input as XML data (i.e. implement is as a WebServiceProvider for message payload)
   • Use Transformer and StreamSource/Result to convert from/to String containing XML
3. Copy the SDO-related classes from the JAX-RPC webservice to the JAX-WS one, exclude just the JAX-RPC webservice interface and implementation
4. Adjust the generated EMFSOAPElementUtil – change (de)serialize methods to expect/produce a String instead of SOAPElement
5. Put it all together in the WS implementation class created in #2
6. Finishing touches – add conversion of org.eclipse.emf.ecore.xml.type.internal.XMLCalendar to javax.xml.datatype.XMLGregorianCalendar

Howto: JAX-WS service with XML Source input instead of JAXB-produced POJOs (similar to JAX-RPC with SOAPElement input)

Sometimes you may want to create a JAX-WS webservice with its input defined by a proper, structured XSD yet accessing the input as raw XML object and not as POJOs produced by JAXB, similarly as with a JAX-RPC webservice having input of the type SOAPElement. This is possible using @WebServiceProvider with javax.xml.ws.Service.Mode.PAYLOAD.

Tip: Multiple webservice implementation classes available at the same time under WAS7

If you want to experiment with webservices by providing several alternative implementations of the same webservice (represented by the <wsdl:service> element), each having its own URL, and you’re using Websphere 7 and JAX-WS, then:

1. For each alternative implementation, add <wsdl:port> with a unique name under the <wsdl:service> element in the WSDL file. Beware: This is essential to enable multiple implementations.
2. For each alternative implementation, define a servlet and servlet mapping in web.xml like this:

   <servlet id="$IMPLEMENTATION_CLASS_NAME$">
   		<servlet-name>$IMPLEMENTATION_CLASS_NAME$</servlet-name>
   		<servlet-class>$IMPLEMENTATION_CLASS_NAME$</servlet-class>
   		<load-on-startup>1</load-on-startup>
   	</servlet>
   	<servlet-mapping>
   		<servlet-name>$IMPLEMENTATION_CLASS_NAME$</servlet-name>
   		<url-pattern>/$DESIRED_UNIQUE_URL$</url-pattern>
   	</servlet-mapping>

3. Create the implementations – likely as POJOs denoted with the @WebService annotation – and set the corresponding portName for each of them (@WebService(portName=”<unique port name>”, …))
4. Deploy and use