The worst of the commonly held misconceptions about web services is a service is somehow a new take on distributed objects (which Werner Vogels does a great job of debunking), but web services can still benefit from some of the standard best practices for building distributed applications.The suggestion I have in mind is to use data transfer objects (aka DTOs) to decouple what goes on the wire from what the application interacts with. The classic motivation for DTO is to insulate a remote facade from fine-grained interaction, and I claim that this is essentially what we're doing, although the motivation is to insulate the application from fine-grained manipulation of wire-format data.The following order of operations is suggested:
Design the desired web services at the service level, i.e., create the WSDL and XML schema.
Either use a tool (like AXIS's WSDL2Java) or hand-map the wire-format XML to an as-dumb-as-possible local representation. By "as-dumb-as-possible", I mean that the local representation should not do anything other than act as a container for data. A good measure of dumbness in Java is that all methods should either start with "get" or "set" - or that there are no methods at all). (DTO makes sense here, but I also like to call these DDB - "dumb data buckets" - to make their role explicit.)
Follow the rest of the classic DTO pattern and do what you need to do with the domain objects.
I definitely agree that versioning and extensibility of XML schemas is a challenge that needs to be addressed, but I also think that web services architects should be insulating applications from it by design.
Previous Topic
