May 2005 Blog Posts

ASP.NET Web Services with .NET 2.0 will include testing for Basic Profile compliance. In the mean time, the WS-I has testing tools written in both C# and Java to help developers determine whether their Web services are conformant with WS-I profile guidelines.

With .NET 2.0, there is an SDK tool sgen that allows you to pregenerate the assemblies produced by the XmlSerializer. When you instantiate an XmlSerializer on a given type for the first time, the code internally writes out a C# source file that contains the code to save and load the appropriate XML. This gets compiled into a temporary assembly and means that the first time you hit this code, there is a delay while this accomplished.

This can be quite noticeable for web service clients hitting a complex service or a number of different services, particularly if the application is often started to perform a particular operation and then closed afterwards. The serializer cost is paid each time the application is run.

There is a hotfix available from Microsoft PSS that provides support for pregenerated XmlSerializer assemblies for web service clients with .NET 1.1 (SP1).

Detecting and Resolving Stalled and Stuck I/O Issues in SQL Server 2000 SP 4 is an interesting article highlighting the changes in SP4 that help to diagnose I/O issues. At Microsoft UK in Reading, we have a scalability lab configured to allow customers to come for a week and measure their application performance in an isolated environment. The goal often includes helping to identify and solve performance issues. I've seen a few customers start the week with massively I/O bound databases and this will provide additional information when we look at this. It will also be great for PSS to help diagnose I/O issues remotely, which can be a time consuming process. Beyond that, of course, it will help customers to identify and solve these problems independently.

There is a continuing (and welcome) debate about the merits of "SOA", although the position of some contributors doesn't seem to be coming across very clearly. Clemens Vasters suggested on Monday that maybe SOA doesn't really exist. This caused some outcry from those arguing that you can build a service oriented architecture. Richard Turner repeats his calls for caution around the SOA nomenclature.

We have two groups: the SOA crowd and SO crowd, the latter being those supporting service orientation but as part of the picture and trying to avoid the marketing hype.

Here's the thing: none of these people believe that service orientation is without merit. They all agree that there is value in building distributed systems using services. Mostly they think a pragmatic approach is valuable. Aside from the fact that it's difficult to find two people who agree on the definition of a service oriented architecture (there are different views of n-tier and probably client-server), it seems from my standpoint that the main disagreement is about the impact of service orientation on the overall architecture of systems. The SOA group suggest that services are the foundation of a system architecture and make such a fundamental difference that this is the centre piece of the design. The SO group propose that service orientation take its place alongside object orientation as a tool making up part of a bigger picture, a significant one nonetheless.

As you probably guess, I'm currently with the SO people: in talking with customers and discussing how to approach their application architectures using services it quickly becomes clear that this isn't the be all and end all. Sure it's important and it places emphasis on issues such as managing change that are sorely needed but it isn't enough and you still need skills in distributed applications within those services. Don't get me wrong, I'm not dismissing the notion of SOA because it isn't new; I'm dismissing it because it isn't complete. Yes, with WinDNA you still needed other skills but the difference was generally that those skills were related more to implementation and less to architecture, which was already wrapped up.

So here we are: service orientation has its place, a really important one, but to my mind it doesn't qualify as an architecture just yet.

A few weeks ago, I wrote about the Basic Profile support in ASP.NET Web Services (ASMX) with .NET 2.0. Since then, Beta 2 has been released changing the details slightly.

Beta 2 incorporates support for the Basic Profile v1.1 (Beta 1 supported v1.0). The syntax for declaring that your web service conforms to BP1.1 has changed slightly (different property and enum names).

<%@ WebService Language="C#" Class="SimpleService" %>

using System.Web.Services;
using System.Web.Services.Protocols;

[WebService(Namespace="urn:simple")]
[WebServiceBinding(ConformsTo=WsiProfiles.BasicProfile1_1,EmitConformanceClaims=true)]
public class SimpleService {

        [WebMethod]
        public string Hello(string s) {
                return string.Format("Hello, {0}!",s);
        }

}

The EmitConformanceClaims property now causes the following claim to be included in the WSDL:

<wsdl:documentation>
<wsi:Claim conformsTo="http://ws-i.org/profiles/basic/1.1" xmlns:wsi="http://ws-i.org/schemas/conformanceClaim/" />
</wsdl:documentation>

According to the WS-I site, "The Basic Profile 1.1 is derived from the Basic Profile 1.0 by incorporating to-date errata and removing to the Simple SOAP Binding Profile those requirements related to the serialization of envelopes and their representation in messages."

Tomas Restrepo calls out  Richard Turner for not being very pragmatic. Richard outlines his opposition to building a communications "bus" for the enterprise in the hope that it solves all the integration needs of the business. Instead Richard is relying on WS-* to deliver the necessary interop. Tomas says:

My humble opinion on the matter (not being an expert on either ESBs nor WS-*) is that Richard's comment is, well, not very pragmatic and overly optimistic, at best. In theory, I'd agree 100%, it certainly sounds like a very compelling vision of the future. In practice, however, I can't see how this would ever be a reality.

To the contrary, this comment actually describes my opinion of the Enterprise Service Bus (ESB) approach. You see, for the last few years the ESB proponents have been offering essentially the same vision under various different guises. They say that your current systems that look something like this...

...can be changed, if you spend enough money on their particular middleware/server/ESB/whatever infrastructure, into something that looks like this...

Much neater. And here's where I would choose to apply Tomas' quote: "In theory, I'd agree 100%, it certainly sounds like a very compelling vision of the future. In practice, however, I can't see how this would ever be a reality." The problem is that a radical enterprise wide overhaul of systems to make them fit into this pattern is just too hard to achieve.

Where I agree with Tomas is that BizTalk Server provides an excellent platform for integrating enterprise applications. It really is a fantastic way to bring disparate systems together and makes it easy to place a service oriented interface around existing applications. In fact, Microsoft could promote BizTalk as the solution for how to provide an ESB using the Windows platform. I think, though, that this would be a mistake.

The pragmatic approach I promote is to use BizTalk where necessary to integrate applications into islands of functionality. It may be useful to build a solution around two or three existing business applications and to expose this collectively as a service to the rest of the enterprise. In other areas, new systems will be built as native services and will participate in service oriented applications directly. Rather than seeing the enterprise built upon a common service "bus", consider an enterprise wide directory enumerating the disparate services made available within the organisation. UDDI fulfils this role and allows services to be catalogued and searched. This way, if your organisation already has a zip code or postal code look-up service, or a payment gateway service, or an invoicing service, or a credit checking service, or whatever you need, then you can reuse an existing service if it provides the functionality you need. Alternatively, you might be able to extend an existing service if it doesn't provide everything. This is how I see the value and promise of service orientation being delivered and it doesn't require a centralised message "bus".

We've come so far with web services in the last three or four years and the future promises to move just as quickly. I respect the doubts that Tomas has about whether we will arrive at a compatible WS-* world. I certainly share some of those concerns as the complexity level of the web service protocols increases. I remain positive, though, that the goal of greater interop is one that we will continue to be pursue. For the places where we need localised integration, tools like BizTalk will deliver that functionality without demanding enterprise wide agreement. More broadly, integrating business services either through BizTalk or simply in application code will be the best way forward.

There is a lot of industry buzz around service orientation and "SOA" and a number of prominent voices within Microsoft are trying hard to articulate the approach the company is taking in this area. I think it is important, first of all, to emphasise that there is no Microsoft product that represents the hub of service orientation - there isn't anything that you have to buy to be "doing" service orientation. In this post I want to outline my thoughts on how to consider your application in terms of services in a pragmatic way and as important point out what I don't think service orientation means.

In the late 80's and early 90's languages came to the fore that allowed you to represent your data as classes together with the associated operations that could be run with that data. This was a shift from the block structured programming that was in favour previously where code and data was kept apart and code modules were formed around areas of functionality independent from where and how data was stored. Today writing code using objects and classes is the norm but it took a number of years for it to become mainstream: C programming gave way to C++, Turbo Pascal introduced class-like types, and bit by bit Visual Basic adopted object-like constructs. This progression was how we entered the world of object orientation.

Service orientation is an evolution of object orientation. Just like the way object orientation didn't mean one specific language, platform, or technology, service orientation represents an approach to building systems in a technology agnostic way. Object orientation got us a long way down the road to building more manageable and maintainable systems but as we moved to building more and more distributed applications it became clear that thinking about everything in terms of objects didn't work any more. While the concept of both local and remote code appearing in our programming models as instances of objects was attractive, it turned out that to build reliable, scalable and performant distributed applications it really did matter where code was located. We needed to treat remote objects differently from local objects because of the speed and reliability of the network. Starting to consider different aspects of our applications as independent services helps to address these issues.

Another problem that we ran into with distributed objects was one of versioning. Because the different distributed object technologies typically exposed implementation details, it became difficult to update and extend parts of an application without impacting other areas. For example, how many times have you broken a DCOM or COM+ application by deploying a change to a server component and then finding that there is a compatibility issue with some of the applications that rely on that code? What cumbersome processes have you put in place or what annoying compromises have you made to try to reduce the headaches caused by binary compatibility? Service orientation is about reducing the coupling between different parts of your application so that these problems are easier to solve.

Okay, so I've talked about object orientation and some of the problems with distributed or remote objects and that somehow service orientation solves these problems but what is it? What do we mean by service orientation? Well, service orientation is an approach to building distributed applications by creating independent services that cooperate through loosely coupled interfaces to deliver the desired application functionality. A service is a logical unit of code that operates in a well defined area of the application with clear responsibilities through a well known interface. In fact, we have four tenets that guide us in building service oriented systems:

  • Services have explicit boundaries
  • Services are autonomous
  • Services share schema and contract and not class
  • Service compatibility is governed by policy

There has been a lot already written about these so I only want to cover them quickly.

Explicit boundaries: it is important for services to define their areas of responsibility and to expose their functionality only through explicit interfaces. Because crossing service boundaries impacts the performance and scalability of our systems, we want to be explicit about when we make those calls and don't want them masked by technology that hides the difference between local and remote code.

Services need to be autonomous so that, in a changing world, we can extend and enhance both the functionality of a service and of its consumers in an independent way and deploy those services as we see fit. Autonomy also means we need to plan for and accommodate failures when consuming other services. This is something that is usually discouraged by object remoting technology.

Sharing schema and contract not class means exposing the "shape" of the data we deal with rather than the implementation detail of our service. Typically when we use DCOM or COM+, we install type libraries and proxies on the client that expose details of the class id's used on the server. With .NET Remoting, we usually have to make the types we expose on the server available on the client for the CLR to make the remote calls. Service orientation breaks this coupling and allows clients to be implemented independently from the service.

Finally, we want to allow the way we communicate with services to be governed by deployed policy. This means that I can expose my service end-points using a variety of technologies and allow the client to select the one it prefers and to understand the requirements for that end-point, for example determining what to use for security and reliability. This is an area that is pretty weak in most of today's protocol stacks but is being improved and will become increasingly important.

It's taken a fair amount of time for me to arrive at the point of this post. Sorry about that. What I've written so far is really background information. The key take away is that service orientation is an approach to building systems and provides a roadmap towards building loosely coupled distributed applications. Nobody should be able to argue that loose coupling is a bad thing - if you go back and read those block structured programming guides from the 80's, you'll see them talking about high cohesion within and loose coupling between application modules.

It is really important that you keep this in mind as you consider whether and how service orientation applies to the systems you are building. Don't try to interpret the four tenets too strictly: take a pragmatic view. I've seen too many people dismiss service orientation arguing that it doesn't apply to their application. Take the fundamental principles of service orientation and apply them as it makes sense. Think about how you will version and deploy the parts of your application. Work through how you will maintain a loose coupling between those parts. Don't throw the baby out with the bath water.

Service orientation doesn't mean you have to deploy different services using completely independent databases. Don't dismiss service orientation because you think it means having to kill application performance by doing cross database joins at the application tier. That's taking the autonomy story too far. By all means keep the data in the same database and do joins if appropriate with SQL, just make sure you understand and have documented which service is responsible for managing which data. I recommend only doing this cross service data access in a read-only way.

Service orientation doesn't mean that you have to throw out all your existing applications and start over. On the contrary, one of the defining properties of service orientation is that by building a service facade around existing applications, you can start to use them in new and interesting ways that were never conceived of when the application was originally built. You don't have to have a huge company-wide revolution to adopt service orientation - evolve your applications, choose to build services as you write new code, think about the lifetime of the systems you are building and how you will manage change, pull out subsystems and expose them as services when it makes sense.

How many times have you worked on systems that just can't sustain further development? Why does this happen? Usually it is because of the tightly coupled nature of the different application modules. Service orientation promotes loose coupling and asks you to consider how things will evolve. The promise of service orientation is that you will be able to rebuild and extend smaller parts of your application one at a time in future without having to consider a big bang rewrite. It will also allow you to leverage your infrastructure in new ways allowing your business greater agility in the marketplace.

I've used the same word a few times and it is the purpose of this post: "pragmatic" service orientation is about understanding the benefits of this approach and applying them in a sensible and flexible way. Please be pragmatic.