I have done some work with SOAP services dealing with complex types and I think I have a pattern. When one has to move beyond the add two numbers example, there is a need to balance between creating a bunch of unrelated RPC calls (easy) and taking a more OO approach (harder). Ideally, I would like to create proxy objects with full processing capabilities that would shield the application from the notion that it is working remotely. Every time I have to deal with classes, say a SubscriptionManager (that manages Users, Services and so on), I find myself with 1) server classes that basically have only methods (i.e. stateless or a bunch of RPC callls), that use complex types from the common library as parameters 2) common classes that basically have only properties (that end in the types section of WSDL) and methods that call the SOAP services from a client perspective passing objects of the common library (adding their own ID so that the server knows wich object it has to treat). 3) client classes that use common objects Do you think this is rightfully a pattern, or is it just that I did not tackle the problem from the right perspective? If there really is such a pattern, it would be nice to explain it well in order to save a lot of time to other fellows. If you think I have been too short please tell me, I will try to elaborate the idea a little more. One side effect is that there is always a JAR or DLL to distribute: the common classes.
