Hats off to Christian Weyer for creating his WSCF 'Web Services Contract First' tool to help provide Visual Studio tool support for building web services by starting with the XML schema and then generating the code.

The key to creating interoperable web services is to ‘build from the centre out’ and start by designing the messages that will be exchanged on the wire (the contract) and then work back to the implementation model that is used at the sender and receiver.  There are two basic approaches to building web services 'contract first' in .NET: code-based or schema-based.  The first approach is to start with the code and add Webmethod and XML Serialization attributes and allow .NET to generate the 'contract' (the WSDL file).  The second apporach involves XML Schema first and using this to create the WSDL file and generate the code, which happens to be Simon Guest’s number 1 recommendation for building interoperable web services.  Visual Studio has good support for the code-based approach to web service design, but up to now hasn't provided much support for the XML Schema approach.  This is where Christian’s WSCF tool comes in.

The tool performs two key tasks.  Firstly, the WSCF tool allows you to create the WSDL file from an XML Schema that describes the web services message.  Secondly, the WSCF tool can generate the code for the client- and server-side web services proxy classes that can be called from your .NET code.

Christian has a useful walk-through that illustrates how the WSCF tool can work.  The steps include:

• Using the Visual Studio XML Editor to create a schema for the data or entities that will be used in the web services messages.
• Creating a second schema that models the messages that will be sent and received by the web service.  This is done by imports the first schema file (using xs:import).  I liked keeping these two schemas separated using this technique.
• Using the WSCF tool to take this second schema and match up the web service operations with the messages to create the WSDL file.  I like that this step highlights the availability of Request/Response and One-Way message exchange patterns.
• Using the WSCF tool to create client- and server-side proxies from this WSDL file (including supporting public properties, serializable classes and collections).

As well as being a VS plug in the tool can also be run from the command line, making it easy to run as part of build process for instance.

While not everyone will want to design web services starting from the XML Schema, for those that do this tool will be a useful timesaver.  It also helps drive home the concept that web services are about messages and not objects.

Christian spoke about this tool and the general ‘contract first’ approach at a recent INETA-sponsored presentation at IrishDev.  You download the slides as well as reading good summaries from Marcus Mac Innes Contract First, Guinness Second as well as Keiran Lyman with Contractual Obligations (or, 'First Contact with Contracts').

Via Rob Caron’s awesome list of Visual Studio Team System resources I came across Sam Guckenheimer’s presentation about Designing for User Experience in Visual Studio Team Systems which had the following gem. 

Apparently the VSTS design team visited a major bank where a bunch of managers assured them that unit testing was a standard team practice.  However, after doing a 4 hour contextual interview with a developer the interviewer asked how they did unit testing to which the developer replied:

Haven’t you seen me? I’ve been doing it all along – every time I press F5 that’s unit testing.

Brilliant!  This beats the time when I was assured that a team were ‘100% into Unit Testing’ only to find that all of the NUnit tests were set to Ignore.

The ‘Understanding Web Services’ MSDN event back in November went very well.  It was great to see over 200 people who were interested enough to spend a day learning about web services.  Simon Harriyott has a good report of his day at the event.  Simon also has a great post on the different pronunciations of web service terminology where he questions why UDDI isn’t pronounced as ‘uddy’:

WSDL is pronounced "Wizzdull".

WSE is pronounced "Wizzy".

UDDI is NOT pronounced "Uddy", but as spelt.

ASMX is pronounced "Azumex".

Best of all is WSE-WSDL, which is of course "Wizzy-wizzdull".

It was Mike Shaw’s last day as a Microsoft employee after 13 years.  To celebrate his final talk he showed a VPC demo of Microsoft Bob, which sadly didn’t end up working.  He did mention Bob’s amazing security system which let the user choose a new password after three mistakes!  Valery Pryamikov posts more on Bob and how it demonstrates how Microsoft has improved its approach to security.

Since I make a habit out of blogging conference talks I thought that I should try doing my own talk “Service Orientation Today” from the VBUG 10^th Annual Conference last month.  Here’s a quick brain dump of the points that I covered, which I go through in more detail below.

• Service orientation is a philosophy rather than a product or a technology.  Using web services does not necessarily mean that your application is service oriented.  Web services specifications and supporting technology can be used as glue for ‘traditional’ distributed systems in ways that aren’t very service-oriented.
• Service orientation is built on many existing distributed application architectural concepts, like encapsulation, loose coupling and messaging.
• Service-orientation is about hooking together separate applications via messaging.  These messages need to be based on coarse-grained messages related to business processes. 
• Service-orientation aims to reduce coupling.  Coupling can be though about in a range of ways (e.g. technology, message format, temporal coupling).  Coupling is measured on a continuum rather than a two-point coupled/not coupled scale.  The same is true of service-orientation – it is a more/less thing rather than a black and white service-oriented/not service-oriented concept.
• Since service-orientation is about business processes there are useful design patterns such avoiding CRUD-style operations and sharing transactions (preferring patterns such as reservation)
• Web services provide good support for basic interoperability.  WS-I shows that the base stack is working today.  The security and higher order specifications are still coming.

Is Service Orientation based on a product or a technology?
Service-orientation is a design philosophy, not a product or a technology.   It’s plainly silly to say than an application is ‘SOA-enabled’.  This is where service-orientation is a better term than service oriented architecture (SOA).  SOA sounds like something concrete, whereas service-orientation implies that it is an approach or a philosophy.

Some people think that any application built with Indigo will be service-oriented.   While Indigo is a set of technologies that can be used to create service-oriented applications it can also be used to simply ‘change the plumbing’ on existing distributed applications.  It is the design of the systems, rather than simply the technology that impacts the degree of service orientation.

Service orientation is about building systems rather than applications.  Systems can be made up of, or can make use of, many different applications.  This means that service-orientation is more likely to be relevant when there are multiple applications involved.  If you’re just designing an n-tier public facing website that works against a private database, with no interaction with other systems then I’d argue that service-orientation may be less relevant than a system designed to share data with external groups or applications.

Service orientation is based on many existing distributed application architectural concepts
Service-orientation is more of an evolution than a revolution in system design.  Service-orientation is based on many of the existing design philosophies such as encapsulation, messaging and loose coupling.   Many of these principles apply whether you are writing object oriented or procedural based systems.  

Loose coupling is also a Good Thing.  Loose coupling is the ability to change or swap out part of an application without breaking its behaviour.  It’s worthwhile defining Loose Coupling.  I watched a Gregor Hohpe webcast several months ago where he defined coupling as a continuum, from more tightly coupled to more loosely coupled.  He also split it into four different types of dependencies:

• Technology coupling.  How many assumptions are made about the technology platform used at a remote point (e.g. .NET remoting makes the assumption that each endpoint uses a specific version of .NET.  This is more tightly coupled than web services which only assume that the remote end point is able to process a text stream)
• Temporal coupling.  Systems that assume the remote point is always available and will respond straight away are more tightly temporally coupled than a system that can handle long-running asynchronous calls.
• Location dependency. Systems that hard-code the IP address of the remote systems in the code are more location dependent than systems that use logical names and lookups to locate the remote system.
• Data Format dependency. Systems that demand proprietary binary formats are more tightly coupled than systems that communicate via text streams.

Service-orientation is concerned with reducing these forms of coupling.  Service-orientation is a continuum just like coupling, so it’s not possible to say that a system is or isn’t service oriented, it’s only possible to say that it is more service-oriented or less service-oriented.

Gregor also points out that the more loosely coupled an application, the fewer assumptions it makes about other systems that it interacts with.  So it doesn’t assume that it will be talking with a .NET box that is always available, with the IP address baked into the code of the application, exchanging a proprietary .NET byte stream.  With these reduced assumptions it means that there are more decisions to be made at design time.  Making lots of assumptions makes designing the application easier, but makes it harder to maintain or extend the application in future.  Making fewer assumptions when designing makes designing and building the application more difficult, but should make it easier to maintain and extend the application in future.

Service orientation is about hooking together separate applications via messaging
A cornerstone of service orientation is that the communication between systems is done via messaging.  Yes, method calls within a VB application could be considered to be messages.  So you could think about these VB applications as being service-oriented, but they are less service-oriented than say an application that is communicating web services over TCP for instance.  Neither is better, just more or less service-oriented.

Since services are concerned with connecting applications, and we’d like to make these connections as loosely coupled as possible then we come the problem of how to define the interfaces to these services.   So we have the ‘famous’ 4 tenets of service orientation from Microsoft.  We need to make the boundaries explicit, share an agreement about a compatible way of viewing what is on the wire, describe the requirements of the service in policy and ensure that the service is autonomous and minimizes its dependency on others. 

Use coarse-grained messages based around business processes
But how do we apply these to the problem of designing the interfaces at the edge of our applications?  How should we design these interfaces?  In order to ensure that these interfaces make as few assumptions as possible they need to be based at the business process level.  Base the interfaces around sharing documents, rather than method calls, since this will lead to a less chatty interface and acknowledge the cost of crossing a boundary (especially a distributed boundary).  A useful analogy is to think about sending a form via the post compared to someone talking you through the questions over the telephone.

Avoid CRUD-style operations
This means that CRUD (Create, Read, Update and Delete) style operations are definitely less service-oriented.  See Maarten Mullender’s “CRUD, Only when you can afford it” MSDN article.  While CRUD style operation might be relevant if you were offering a data management service this isn’t most business’s business so it’s really an edge-case.  CRUD-style operations on a specific business entity are more likely to be used in a distributed component system.  They are better when there is a low cost to sending the message and the application owns the entities in question.

I think it is useful to reconsider CRUD interfaces even if it just involves minor changes to the operations are named.  Instead of an operation like DeleteEntity consider renaming it to AmendOperation or CancelOperation, which suggests that instead of deleting a particular record in a database, a reverse entry is placed.  Think for instance about a reservation system.  Cancelling (note, not deleting) the reservation may involve certain costs such as a cancellation fee.  There’s a business process there, rather than just a simple database action.   See Ron Jacob’s Patterns and Practices Webcast on Service Orientation for more background( I liked this webcast though Jeff Schneider thinks it was shallow to which Jeff Newson posted a thoughtful reply).

Avoid sharing transactions across services
If we take this position that services manage interaction at the business level, then the notion of sharing transactions, or more specifically database transactions, across services isn’t the right choice.  A more loosely coupled solution is to use a reservation pattern, where a resource can be reserved for a certain period.  The service would also create a time-out on the reservation so that if the client doesn’t return (a good service doesn’t depend on its customers to behave correctly) then the system can release the reservation on the resource.

How interoperable are web services in the real world?
Well the WS-I group have done a great job making the base profile stack of technologies interoperable.  It’s now possible to use SOAP, WSDL, Schema etc to publish a web service and be called from multiple platforms.  This is a tremendous leap forward.  In terms of advanced web services, momentum is building around interoperability with some of the WS-Security stack, but then there are WS-* specifications others, such as WS-Policy and WS-SecureConversation that still have limited cross-vendor support.  Gregor Hohpe makes a useful suggestion that we think about these WS-* specifications as architectural design guidelines, rather than hard standards. 

It will be interesting to see whether the momentum around web services will mean that some of the higher order specifications become standards.  I think that the further we get from the core WS-* standards, the more fracturing there is between different groups and the less agreement there will be.