Agreed, but I would say that WSDL is specifically a good match to DCOM-style interfaces that follow the signature pattern:
BundleOfReturnData DoCommand(BundleOfInputData dataBundle); Unlike standard interfaces that are primarily orientated towards specifying behaviour, these interfaces are state-orientated in as much as the important bits are the data structures of the input parameters and return value - something for which WSDL is well suited in terms of describing complex message types using XML schema. Moreover, providing such complex datatypes are generic Value-object type containers then they create an effective abstraction layer between service interface and implementation as they are only loosely coupled to the underlying object model of the service. In other words, when designing web services focus on interface abstraction via generic complex input parameters and return values?.. (I guess it's worth pointing out that this is not the same as those "questionable" COM interface designs where all the parameters were wrapped up in an XML node so you got no compile-time type checking, as the complex types will be fully specified in the WSDL message definitions) Julian -----Original Message----- From: Arlie Davis [mailto:[EMAIL PROTECTED] Sent: 15 December 2003 23:36 To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] .NET, XML serialisation and encapsulation (was: Web Service Desig n Question) I think that's a very fair criticism. Partly, I think this is due to a sense of "decompression" after the strict interface-based world of COM. COM interfaces were a good idea. But COM forced everything through interfaces, since it had no real concept of "classes" beyond class factories and a set of instance-related interface references. This made a lot of object reuse difficult and awkward. The CLR, though, finally fixes that, with a good interoperable class/type system. So I think there was a swing back toward a mix of classes and interfaces, rather than the pure interface world of COM. In some respects, I think this is good. However, as you rightly point out, this has allowed (and even encouraged) a degree of sloppiness in designing of web services. Because it is easy to build web services in C# / VB / whatever, and to generate WSDL from those web services, people tend to develop this way. They implement something, then expose the implementation via WSDL. This is in contrast to COM, where you you write the IDL, then build code that either uses or implements the interface. A web service has a set of data structures (messages and their components) and a set of operations that can be invoked. The current system of generating the WSDL implicitly, via [WebMethod] & friends builds that contract implicitly. Therefore, that interface definition is often seen as a second-order concern in the design process. I think your criticism is that it should be a primary or THE primary concern in designing a web service -- and I agree. That said, I don't see an easy solution, at least in the current generation of CLR. A potential redesign would be to start with WSDL, and tools for generating and validating WSDL descriptions. Then, instead of C#/VB generating WSDL, a tool could generate managed *interface* definitions from the WSDL. The web service class would then implement that interface, and would therefore be responsible for matching its method signatures to those of the WSDL. So, to boil it all down, interfaces may be a better match to WSDL than classes. Thoughts? -- arlie -----Original Message----- From: Moderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Julian Everett Sent: Monday, December 15, 2003 11:02 AM To: [EMAIL PROTECTED] Subject: [ADVANCED-DOTNET] .NET, XML serialisation and encapsulation (was: Web Service Desig n Question) Something about the whole notion of XML serialisation of objects in relation to web services has been niggling at me recently - then in a moment of nostalgia last week I was browsing DB's Essential COM and suddenly I realised what it was. "The first rule of COM is separation of interface from implementation" - wise words indeed, but what the heck happened in .NET especially in relation to web services!? Shouldn't WSDL play the same central role in web services design that IDL played in COM? Instead however, with VS.NET we have the "VB approach" where IDL/WSDL is dynamically generated at compile time, tightly coupled to the particular details of the service implementation. For this reason, I try to use XML serialisation only for GoF Value object-type containers that have nothing to do with my service implementation details. Moreover, to me at least the first thing I think of when someone says object serialisation/deserialisation is remoting - something I don't like as obviously web services have nothing to do with remoting. Rather, I try to think in terms of "service serialisation", i.e. describing data structures that encapsulate abstracted entry points into the set of interacting objects that comprise my service. Indeed, perhaps it's me but rejecting "the first rule of COM" seems to be a common theme throughout the .NET base libraries. I always thought that compared to Java, a massive strength of MS's component model was that it was built upon the principle of class factories that return interface references - something Java only caught on to after the pain of deprecating earlier APIs, with the introduction of frameworks like the Collections API. As I understand it, IDL was introduced primarily to address language interop issues (something that is obviously not relevant with .NET) rather than to promote abstraction, however I can't help feeling that Microsoft took a step backwards when they decided against a interface-based architecture in their implementation of the CLR... Any thoughts? regards Julian =================================== This list is hosted by DevelopMentorŪ http://www.develop.com Some .NET courses you may be interested in: NEW! Guerrilla ASP.NET, 26 Jan 2004, in Los Angeles http://www.develop.com/courses/gaspdotnetls View archives and manage your subscription(s) at http://discuss.develop.com _____________________________________________________________________ This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Control Centre. For further information visit http://www.star.net.uk/stats.asp IMPORTANT NOTICE This communication contains information, which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. If you have received this communication in error please return it to the sender. The opinions expressed within this communication are not necessarily those expressed by Teletext Ltd. Teletext Ltd. Building 10 Chiswick Park 566 Chiswick High Road London W4 5TS Registered in England number 2694814 _____________________________________________________________________ This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Control Centre. For further information visit http://www.star.net.uk/stats.asp =================================== This list is hosted by DevelopMentorŪ http://www.develop.com Some .NET courses you may be interested in: NEW! Guerrilla ASP.NET, 26 Jan 2004, in Los Angeles http://www.develop.com/courses/gaspdotnetls View archives and manage your subscription(s) at http://discuss.develop.com
