This post originated from an RSS feed registered with .NET Buzz
by Marcus Mac Innes.
Original Post: Contract First, Guinness Second
Feed Title: Marcus Mac Innes' Blog
Feed URL: http://www.styledesign.biz/weblogs/macinnesm/Rss.aspx
Feed Description: Issues relating to .NET, Service Oriented Architecture, SQL Server and other technologies.
Yesterday evening, night and the early hours of this morning … (very sore head now) I had the pleasure of meeting Christian Weyer who via INETA was speaking IrishDev.ie’s Christmas Cinema Party.
Christian started off the evening with an excellent talk on the realities we are faced with when building web services. Unlike most talks on this topic, Christian actually provided some of the answers and one pretty good answer in particular.
The biggest problem that plagues the .NET community to date when build Service Orientated Architecture (SOA) applications is the lack of defined process. While SOA is not a new concept, it certainly is a new term and for most, a whole new way of thinking. In the same way that patterns provide standard ways of implementing the same old problems, SOA provides a standard way of architecting applications in order to minimise coupling and maximise interoperability.
Everyone loves the ideas and design paradigms proposed by SOA and everyone can visualise without too much hesitation the advantages and benefits of the final result. Not everyone knows exactly where to start however…
Right at the beginning of Christian’s talk yesterday evening, immediately following his introduction, he alt-tabbed to an eagerly awaiting Visual Studio perched in the background. As he clicked Add Solution, Add New Web Project, my hopes for a serious talk on Web Services were fading fast into the distance. I really thought we were now in for a “here’s how you build your web services using Visual Studio” when all of a sudden my fears were firmly put to rest… “This is not how you should build Web Services”, Christian exclaimed, and now, like the beginning of a good movie, it was time to site back and listen to a man that knows.
When Visual Studio first arrived back in 2001, everyone as Christian points out was amazed by the new productivity features and of course as “Web Services” was fast becoming the next big thing, VS.NET did them too!
I must admit, I was among the impressed when I realised how easy it was going to be to build Web Services using this new tool which gave developers the power to simply adorn their methods with the attribute “[WebMethod]” and have Visual Studio create all the necessary code, Schema and WSDL for you. Within minutes, literally, you could build an application that could communicate using XML and SOAP over HTTP.
It was only when you start to look at a little deeper that you realise that like most things in Visual Studio, this was a “play” implementation of an architecture, great for demos, useless in reality.
The first problem with [WebMethod] is that you are restricted to the RequestResponse pattern. Get something in, process and send something back out the way it came. HTTP is a perfect transport for such an architecture as it is after all a RequestResponse transport.
At this point Christian asked a question of the audience which I shall file away for later use and one which reminded me of Eric Rudder’s recent talk in Dublin when asked about open source software. Eric pointed to a table at the back of the room filled with bottles of water. “Why do we buy bottles of water, when there is perfectly good drinking water available free from the tap downstairs?” Christian asked “When you send a letter in the post, do you wait by the postbox for a reply?”
How could you architect your applications using the RequestResponse pattern having heard this analogy? Problem with Visual Studio number one…
Next we should look at another important aspect of application design, maintainability. The value of software is proportional to the business benefit it provides and is inversely proportional to effort required to make modifications.
As most experienced Visual Studio developers will tell you, Visual Studio is all about productivity. It provides an unparalleled ability to efficiently produce software which provides the business benefit and hence the value I spoke about. What most experienced Visual Studio developers will also tell you is that it provides absolutely no assistance in minimising the impact of later change. This in my opinion negates all the productivity benefits and hence renders most of the toolset useless or as I like to put it, the tools are for “play” only.
The problem here is routed in the fact that Visual Studio is generating code for you. This quickstart is absolutely fantastic and works perfectly until you realise that something is missing or the design isn’t exactly what you require. The code generation templates are fixed and you have a take or leave it scenario.
Building WebServices using the Visual Studio approach falls victim to this problem and everything that is done for you under the covers is going to come back and bite you as your requirements move from those of the demo world to those of the production or real world.
Let’s examine what happens when you add [WebMethod] to a C# or VB.NET method:
Without even thinking about it, you are automatically now using the RequestResponse pattern. Maybe you didn’t even notice, but you are now effectively building a Remote Procedure Call (RPC) web service. Is that what you wanted? Is your design being guided by the implementation tool?
Next the XML Schema and the WSDL are generated for you. But have you had an opportunity to specify whether types are to be shared between methods? Will your Customer class in one method be generated on the client side into a difference namespace from that same Customer class in another method? What will your client proxies look like and will they use clumsy arrays or useful collections for lists? Do you have any opportunity to control what is produced? Not really…
What about Schema validation on received messages or do we just let the deserializer throw exceptions? And aren’t exceptions expensive? Wouldn’t this be a prime target for a denial of service attack? Can we even examine the XML that was received? Not really…
And when version 2 comes along, what are we going to do about backward compatibility?
The list goes on…
If we now look at what has been produced for us by VS.NET, it doesn’t take a genius to realise that we have simply created a XML based interface to an existing Domain Model. This is not Service Orientation or even close.
Service Orientation is about shifting your thinking from an Object Orientated Domain Model to a new architecture which is quite different. This shift is analogous to the shift in mindset from procedural to OO programming and design.
The question comes back then, is Visual Studio assisting us with this process and mind shift or is it actually hampering the process and reducing our options?
Christian obviously felt, as I do, that the latter is the case and has been thinking along with his colleagues at ThinkTecture about ways to help developers overcome these early stumbling blocks. All this thinking has resulted in one of the most important tools available today for the building of real world web service applications. Christian presented “Contract First” a tool and a methodology for the design and flexible generation of the some of the components required to build real world web services.
Previous Topic
