« Sony Ericsson P910 | Main | Indigo Programming Model »
24.01.05
Generic Implementation Interface
Christian Weyer asks for additions to the WSCF wishlist. This made me think about parameter and return type handling in ASP.NET Web Services …
You can help us improve WSCF, now
Take a look here if you work with WSCF and just think: “well, it’s nice, but…”.
We want to hear your ‘but’. Thanks.
I haven’t had that much time to investigate WSCF 0.4, but I think the tool generates code in a single way, only, i.e. the way the tool (or the author) sees fit. It generates parameter classes which map to the types defined in the XSD file. Although this approach is recommended in many ASP.NET and Contract First forums, I think it is still one step from really being “losely coupled”. Why? Because your implementation is bound to the types in your service description/interface. If the interface changes chances are that you’ll have to change the implementation (of the client), too. This would destroy the most important reason for SOA being independence. Service-oriented architecture is all about reducing dependencies as much as possible.
In order to achieve this independence concerning parameters and return types the implementation should use XMLElement and XPath to access and deliver parameters, return types respectively. If the service changes (non-breaking changes!) and the client isn’t interested in the new additional features, it still would work, because all necessary data is fetched from the XML tree via XPath queries. This approach might seem odd, because C# is a strongly typed language and string queries aren’t really typed … But service description aren’t C# typed either. They are typed by the XSD/WSDL which should be the only service and data definition! There are some (few) sources for this approach:
I like to call this approach the “generic implementation interface”, because the implementation expects an “untyped” XMLNode, which is accessed in a generic way by XPath queries. The opposite is the concrete or typed implementation interface. Both approaches are valid. Sometimes it’s just more effective to generate typed parameters and the corresponding proxies. But in most cases the generic approach largely adds to the losely coupled idea. I still have to investigate how to implement this with ASP.NET Web Services. Maybe there are some serious drawbacks. The idea is to define the fully typed (XSD) WSDL and to use XMLElement or XMLNode parameters and return types in the implementation.
Therefore my most wanted WSCF feature is to make the generation process configurable, perhaps by introducing a template based approach. I know this is much asked for, but you asked, didn’t you ;-) ?
Posted by Hartmut Wilms at 24.01.05 10:51
Comments
Hm… good ideas. But I do not think that will happen for a free version of this tool. Sorry.
Posted by: Christian Weyer at 25.01.05 14:28