Garbis, Jason wrote:

Your option 1 below, is pretty distasteful, since you're bypassing any typechecking, and (more importantly) excluding
important information from the WSDL metadata. That is, a user would have to consult some external metadata to understand what is and isn't valid input. This defeats the purpose of using WSDL.

I belive a dictionary/data driven approach is a good choice when the interface is unstable or likely to change. Typechecking depends on the nature of the keys used and the argument being passed in.


Or, could you change the XML type definition for the input message to support optional fields? Then, in the handler that receives this invocation, you'll have to figure out which set of input parameters are actually in the SOAP message, and dispatch it to the appropriate resource (e.g. Java class).
(This assumes you even want to write this dispatching code...)
That would be one approach- it sounds very like a generic method, the most specific version of the.method is selected for the arguments supplied. It's a way to work around the fact that SOAP/WSDL doesn't offer much by the way of polymorphism. It's not btw, a million miles away from using a dictionary. Another option is not to use a custom interface, instead see if the service can be described in terms of HTTP methods, which are stable, polymorphic and highly generic and bind the WSDL to that.


This is a real challenge in building tightly-coupled distributed systems with WS
It is, but, the point of using WS is to build loosely coupled systems with coarse grained messages. Another take is that tightly coupling systems through fine grained method calls is not a good approach for building web distributed systems the problems Rajal is running into simply reflect that it's an antipattern at best.

(As an aside, not using a finegrained approach is no evidence of 'not thinking enough'- far from it)

Bill de hÓra
--
Propylon
www.propylon.com





Reply via email to