javax.xml.bind.JAXBException

[Grady Jamyson]

I am writing a web service client to pass a custom type to the server but get a error message,

[javax.xml.bind.JAXBException: class com.example.mypachage.WineData nor any of its super class is known to this context.]

The server side code is as following,

   
    @WebMethod(operationName = "saveText")
    public boolean saveText(@WebParam(name = "wineData")
    Object wineData) {
 
        return WineMidLayer.writeWineText((WineData) wineData);
    }
 

And the client code is as following,

    
   com.example.mypachage.WineToolWSService service = new          com.example.mypachage.WineToolWSService();
   com.example.mypachage.WineToolWS port = service.getWineToolWSPort();
   boolean result = port.saveText(wineData);

Is there anything I need to know while using the custome type as parameter passing around web services?

[Peer Reynders]

You are trying to impose Object-Orientation on the Service-Oriented domain.

Even in the OO domain your method is lying (potentially resulting in a class cast exception during runtime). It advertises that it will accept any "Object" which implies that it will only use the interface of "Object" and then it turns around and promptly downcasts to "WineData" - so it should really be up front and only accept WineData objects.

Services exchange messages (not objects); polymorphism relates directly to the Liskov Substitution Principle:

If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.

Messages unlike objects do not manifest behavior.

Messages don't hide anything - all the data is public.

It follows that if a service advertises that it will accept a super-type then the client will only send the data that is part of the super-type (because that is all that is needed). Therefore it would be impossible for the service to downcast the content of the message.

To be able to do what you are trying to do the service would have to include all the supported sub-types in the service contract - however there is simply no point in doing that if it is only going to use the data that is present in the super-type (which is what the contract is promising to do).

Polymorphism is a concept that does not translate well into the Service-Oriented domain. Polymorphism requires inheritance and Services themselves do not support inheritance as that would interfere with their Service Autonomy and increase their inter-service coupling (p.459 SOA Principles of Service Design). Therefore you shouldn't expect inheritance to be supported by the messages or the elements that are used inside the messages.

Ironically XML Schema does support inheritance to maximize reuse which means that some tools will use it inside of the service contract. However practical experience has shown that use of XML Schema inheritance/polymorphism features will usually adversely affect interoperability and lead to increased coupling - so use of XML Schema inheritance/polymorphism is in fact discouraged (p.44 SOA in Practice).

"Toto, I've got a feeling we're not in Kansas anymore."

"Oh dear! I keep forgetting I'm not in Kansas!"