Sam Gentile's Blog (if (DeveloperTask == Communication && OS == Windows)

Last time in Part 3, I talked about the definitions of SOA, from the Architectural and Business standpoints. Left over, was a discussion of the Four Tenets of SOA. However, we really do need to try to define a Service itself and see if there are any Design Patterns to help guide us in shaping what constitutes or becomes a service. These Design Patterns help to put the “A” in SOA and we will be spending a lot of time in Part 5 with the Architectural Patterns that make up SOA.

First. let’s review from last time, the concept of Service Orientation (SO). Service Orientation is a general design concept or paradigm, a conceptual model for application-to-application and application-to-enterprise connectedness, composed of a specific set of design principles. The focus is on the data being transmitted, rather than a particular type system, operating system or platform. Applications that are built with a service oriented paradigm are concerned with sending or receiving messages that adhere to a specific structure. Applications that send and receive these messages are Services. Service Orientation has its own design paradigms and principles. design pattern catalogs, pattern languages, a distinct architectural model, and related concepts, technologies, and frameworks. [1] Service Oriented Principles, IMHO, are essentially a paradigm shift, a new skill set for developers to learn. Things that you emphasize in SO and SOA are often quite different that than the things you would in OO, DDD and N-Tier design.

The Four Tenets of SOA

There has been, recently, a discussion on whether the Tenets are still viable and should be retired to which Don replied, “we published those tenets simply to be transparent about the principles we were using to define indigo - that is, what were the characteristics of systems and services we expected people would build using indigo.”

Don leaves it up to us. I say, that a break had to be made at the time with what was being done in COM/DCOM/CORBA and how this was going to be different. I also say that I still find, and my students still find, them useful. Not everyone is at Harry’s level and I find that most people have NOT made the transition to being Service-Oriented and away from designing RPC systems to messaging systems. Since I find them useful, that’s all I will say on the controversy. Let other people argue it out. However, I do think that the 4 Tenets are far from enough and we have to add additional principles particularly as we moved away from SOAPified RPC to document-centric message passing systems with or without SOAP. I will list those in the next section.

First, let’s state them and then I will try to articulate what they mean to me:

• Boundaries Are Explicit
  • Services only interact explicitly outside boundary via explicit message passing
  • Service agnostic to choices of platform, middleware or implementation language
• Services Are Autonomous
  • Independently functioning, deployed and versioned
• Services Share Schema & Contract, Not Class
  • interact solely on their expression of structures using schema and behaviors via contracts
• Service Compatibility is Based On Policy
  • Operational requirements, SLAs, policy assertions

Boundaries are Explicit

When I am presenting on this, I like to start with Boundaries are Explicit. I ask if there are any COM programmers in the audience, and then ask the COM programmers if there is any difference, in the programming model, between calling a service local in-proc and one somewhere else. The thing is there isn’t. Sure there is the mandatory one week wrestle with DCOMCONFIG but the programming model does not look any different. And that’s the problem.

Most programmers have no idea of the massive differences in latency and have little skill sets with distributed computing in general. I have worked with some notable skilled DDD/Agile people that just wanted to “replicate” or just “extend” the domain model out over the wire. Why not they shriek, that’s what CORBA did! Yeah, and look what twenty years of COM, CORBA, DCOM and RMI got us. Nowhere but creating incompatible islands of rigid crap that required the same exact object model on both sides of the wire. So this principle sets in stone, for me, that SO/SOA design is very different. You should be well aware of where the boundaries are in a Service and what the (immense) cost will be going outside of them.

So what’s the net? You just can’t take your whole DDD/OO skill set and instantly have an SOA skill set. While great OO and DDD models emphasize objects, methods, and Properties, you have to design very differently here. Even if you are using the lowly Service Facade Pattern, you don’t want to expose all that “chatty” property and event stuff out of your Service boundary. The shapes of the messages that can be sent in and received are the only way to access the service, period and it’s all about the Contract. So the focal design skill here is designing Contract-First and designing the messages, which can be very different in my experience.

Services Share Schema, Not Type

I think this one is super-important too. Again, a big break is being made with COM/DCOM/COBRA/RMI/Remoting. We are so done with that, been there done that. We know know that sending objects over the wire is just plain stupid. Why? It requires the same exact runtime, programming model, and frequently OS on both sides of the wire. Interop is pretty much impossible. A lot of us fought these wars for 20 years and we now know it’s all about Interop. Contrary to what some people may have you believe, it’s a heterogeneous world out there and there are a lot of those “J” systems too :). 

So, if SO focuses only on the messages, we need a way to describe those messages and what the expectations are between participants. SOA systems express contracts in the widely understood languages of XSD and WSDL.

Service Compatibility Based On Policy

If I have a Service and I want to demand that everyone who comes to my service has to communicate with me have an X.509 certificate, I have to have a way to express that “policy.” WS-Policy gives us an way of expressing such requirements in an XML based policy.

Services (Should Be) Autonomous

To me, this is the most vague and difficult to achieve. Pure autonomy is impossible.

Service-Orientation as a Design Paradigm and Additional Principles

• Asynchronous Messaging versus RPC
• Loosely-Coupled
• Standardized Service Contract
• Service Reusability
• Stateless Services
• Services are Discoverable
• Coarse-Grained Agnostic Services
• Conversational (as in MEPs NOT chatty)
• Reliable
• Secure/Identity
• Services are Composable

What is a Service?

There are, of course, more than one definition of a service. We can start out with one of my favorites:

“a software component of distinctive functional meaning that typically encapsulates a high-level business concept.” [3]

But let’s bring it down out of the abstract. Think about travel agency, utility company, ISP, etc. They offer:

• Publicized package of functionality that is
• Composable (Travel agency makes use of
  transportation)
• Discoverable on descriptions, terms & conditions
• Use based on agreed-upon contract
• Some Quality of service

Likewise, this analogy can be applied to Software services. Software services, however, are not just described by contract but by business terms.

Software Service characteristics:

• Available at particular endpoint
• Receives/sends messages & behavior
• Contract governs behavior
• Quality requirements via policy

Let’s say you buy all this stuff I have been writing and you want to get concrete about it. In other words, you want to expose a chunk of stuff as a “Service.” How do you go about? Well, luckily there are various Pattern sources like Fowler [Fowler03], POSA [Buschmann96] , and Enterprise Solution Patterns Using .NET [PnP02] to help guide us.

Service Interface Pattern [PnP02]

Problem

How  do you expose your application's functionality over a network so it can be consumed by disparate applications?

Forces

• Separation of concerns – business logic and service contract issues
• Consuming applications may require different channels for
  optimization
• Consumers application may want to communicate with application using different technologies

Solution

• Design your application as collection of software services, each with a service interface through which consumers of the app may interact with the service
• Use the Service Interface pattern to describe behavior of a service and the messages required to interact with that service.
• The service interface does the following:
  • Describes operations that your service provides that a client can use
  • Describes the format for information being passed to and from operations
  • Describes the message exchange patterns that the service implements, such as: request/reply, one-way, and duplex

So that was helpful, but also how do we approach the overall architecture of a system that we want to be “Service Oriented” and part of an SOA. It turns out that there is a useful pattern there too.

Three-Layered Services Application [PnP02]

Context

You are designing a Layered Application [Buschmann96]. You want to expose some of the core functionality of your application as services that other applications can consume, and you want your application to consume services exposed by other applications.

Problem

How do you layer a service-oriented application and then determine the components in each layer?

Forces

In addition to the forces discussed in Layered Application, the following forces apply: