Introducing Contract First

So much of the literature about writing application now involves Web services. Many publications and blogs consider Web services to be the silver bullet because they are so easy to implement in .NET and do very easily interoperate with disconnected systems. But are people really using Web services the way they should be used? I beg to differ on that point.

Oh yes. Web services programming is easy. Who likes those crazy angle brackets crossing their networks, anyway? Who is interested in all the fancy details of those elaborate specifications? Developers just want to write software. All that they need are good tools that hide all the obviously unnecessary details.

Gotcha. Who can tell you what is necessary and what is not? Can you really ignore XML? In this article, I'll demonstrate how today's views about Web services are somewhat wrong and how to fix this situation. I'll show you a totally different approach to Web services design and implementation than what you've experienced in the past years implied by major tools and platform vendors. There is one fact you can be sure about: Web services' potential is much higher than what we can leverage with today's tools.

The Problem

It is just some six years ago that the first major release of SOAP hit the table. In those days developers shouted "Simple Object Access Protocol" when they talked about this new and revolutionary piece of technology. SOAP is one of the most basic and most important standards in the Web services realm. With the help of SOAP you pour an XML document into a certain shape, the message, which will then be sent over the wire. It does not matter which operating system, programming platform, or vendor is participating in this scenario. A simplified collaboration should be enabled just through the use of XML and ubiquitous transport mechanisms like HTTP, TCP, MSMQ or SMTP. Of course, on top of all that, SOAP in conjunction with HTTP can cross just about any existing network obstacle like firewalls. Welcome to the brave new world.

At least that's the theory. If you read the wording of the SOAP 1.1 specification you'll see that it tries to suggest a certain usage of SOAP. It actually seems that SOAP is a perfect means for achieving the long chased-for aim: platform agnostic remote method calls. A Java programmer just wants to call .NET objects and an AppleScript kid cannot stand to speak to some remote Java instances. This is how the picture of SOAP (and thus Web services) developed as platform independent remote procedure calls implemented using XML. SOAP as a simple object access protocol.

But this should not be it. Honestly, nobody in 1999 could ever imagine and see that developers would use SOAP to solve much more than just the afore mentioned technical low level problem. Because a lot of software communication problems come down to solving aspects of integration and interoperability, developers just need to get past the simple idea of connecting objects. In actuality, you often need to avoid it.

The Service Ecosystem

Many years in the software development business showed that creating and using abstractions are a very helpful means to focus on the real problem and its solution. For example, developers would not be able to build extensive and powerful applications if they still used assembler op-code. Likewise, they would not be able to produce maintainable and extensible programs without the notion of and tools for object-oriented programming.

But developers need more if they're going to achieve interoperability between systems running on different and heterogeneous platforms. It is simply not just about "wiring up" a connection between object A in .NET and object B in Java. A good software architect (whatever that means) wants to hide as many implementation details and internals of the Java applications from the .NET client and all other possible consumers of the application. This is because developers have learned a lot about deploying software systems that have coupling that is too tight. Sure, sometimes tight coupling and intimate knowledge of all the other "objects" is required and a good thing. But at least when developers talk about enterprise application integration (EAI) scenarios, all parties try to minimize the dependencies between all related systems and thus enable the highest possible flexibility in assembling application architectures. Welcome to the world of service orientation.

This article is surely not the right place to discuss all pros and cons of service orientation. But we can adhere to the fact that service orientation is a new level of abstraction in the software design and development world, beyond objects. Just to be clear on this point: it is not about objects vs. services, but merely services with objects, because you might implement a service with objects, but you are not required to do so. For this article, a service is a program that can accept messages and can send messages on it own?nothing more, nothing less.

In order to more thoroughly understand the universe of services, consider the diagram in Figure 1 which shows all the involved artifacts and their dependencies.

Let's look at the most important concepts in the diagram and apply the famous four rules for service-orientation:

1. Boundaries are explicit.
2. Services are autonomous.
3. Services share schema and contract (not implementations).
4. Service compatibility is negotiated through policies.

The most important rule for our needs is that a service always has a boundary to other services or parts of an application system. These boundaries are there because you want them to be there: they are explicit. This system boundary needs to be communicated through an interface, as you'll see shortly. And obviously you need to technically describe the interface to the service so that others can start communication with the service.

As you can see from Figure 1, the service contract is a very important element in the service ecosystem. Despite the fact that "contract" is an overloaded term, you can see a service's interface description as the service's contract. (There is more to tell about the contract story, but I'll just focus on this aspect here). A contract defines the whole interaction between services and service consumers. It contains the definition of all messages and their formats and manifests the message exchange sequences. In order to not further blur the term contract, I'll use interface contract when talking about such kind of contract. The service's interface contract consists of the data and message contracts (more on this later).

The second most important rule from the list above is that you share only schema and contract information between parties. This is one of the foundation pillars of service orientation and cannot be stressed enough. You do not need to know anything about the service's internal implementation. You just need to know the interface contract and which messages to send to a service and which messages you should expect to receive from a service.

OK, enough theory for now! With those basic ideas in mind, developers need a good and reasonable set of technologies to actually realize the essentials of services and service orientation. So let's talk about Web services.

By: Christian Weyer

Christian Weyer is co-founder of thinktecture (http://www.thinktecture.com/), a company that helps software architects and developers to build projects with .NET and distributed applications technologies. He is a recognized XML, Web services, and service-orientation expert. As a Microsoft MVP for Solution Architecture and one of the few independent Microsoft Regional Directors, he has made a name for himself in the developers and architects community. He has worked for many years with Microsoft technologies like COM/DCOM, COM+ and .NET. Christian has spoken at many well-known developer conferences and forums worldwide and is a published author, editor, and writer of numerous articles for various German and international technical magazines. Visit his Weblog at http://weblogs.asp.net/cweyer/ to find out more about Web services and service-oriented integration and programming, not just on the .NET platform.

Website: http://www.thinktecture.com/

Weblog: http://weblogs.asp.net/cweyer/

christian.weyer@thinktecture.com