For more on this, I'd also suggest: 1. Yasser Shahoud's blog and recent articles on MSDN [1] 2. Christian Weyer also blogs [2] about this, and has recently released an "Contract first" VS.NET-integrated replacement for WSDL that generates web-services and proxies. [3] 3. Something like CapeClear's WSDL editor encourages this type of explicit interface development, but doesn't replace WSDL.exe. [4]
John [1] http://weblogs.asp.net/yassers/Rss.aspx [2] http://weblogs.asp.net/cweyer/ [3] http://weblogs.asp.net/cweyer/posts/39070.aspx [4] http://www.capeclear.com/products/download/enterprise.shtml -----Original Message----- From: Moderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Shawn A. Van Ness Sent: 17. desember 2003 07:46 To: [EMAIL PROTECTED] Subject: Re: .NET, XML serialisation and encapsulation (was: Web Service Desig n Question) Well expressed, Arlie. I'm with you guys. If you think about it, MIDL.exe was nothing more than a codegen tool. IDL went in, and a bunch of C code came out. The C code implemented the proxy and stub sides of the wire, to handle all the ugly, monotonous serialization of arguments. Sure, later COM-era versions of MIDL.exe would precompile some of that code into a dll -- and sundry other binary formats, like typelibs and /Oicf metadata -- so it began to look and feel a lot like a compiler. But really it was just a codegen tool, all along. If you're old enough to remember IDL back in the days of RPC, when it just emitted C, it's true nature is a little more clear. :) There's no reason we can't build an analagous system for web services -- a codegen tool which consumes WSDL and produces a C# interface file -- and possibly even some "proxy" and "stub" implementations, to help with things like SOAP Section 5's id/href rep for object graphs... IDL was a language of nightmares, but WSDL is just XML, so we're free to use virtually any modern codegen tool we like. CodeSmith [1] has a lot of momentum -- I haven't been keeping up, but I wouldn't be surprised to learn someone in that community has been making WSDL-centric templates. The problem, you may recall, with COM-style interface centric development is that it's a lot of typing! Especially early-on in the development phase... every small change to the interface file requires a corresponding change to client- and server-side code. With IDL/C++, it was not uncommon to have to juggle 4 or more files: the .idl file, the servers' .h and .cpp files, and of course all the client references! I think this is the problem MS was trying to solve with [WebMethod] and friends. And it's a great tool for rapid prototyping -- but that's about it. Should come with a big disclaimer in the docs, or even emit a compiler warning. ;) [1] http://www.ericjsmith.net/codesmith/ Cheers, -Shawn http://www.windojitsu.com/ -----Original Message----- From: Arlie Davis [mailto:[EMAIL PROTECTED] Sent: Monday, December 15, 2003 15:36 Subject: Re: .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 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 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
