VBUG Service Orientation Presentation Notes

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.