Services Orientation – The Architecture Formerly Known As SOA – Introduction

This is the first in a series of articles about enabling an enterprise to the Services Orientation model.

Summary
We’ve all heard it: Services Oriented Architecture is it; it is “The One”. It is the architecture that will save our skins. It will slice, dice, chop, grate, drop and julienne (that very thin cut; typically for garnish, if you were wondering).

So, you might ask: "What is SOA"? I’d like to answer that, but first, I’d like to tell you what I think SOA is not.

From a technical perspective (and in my opinion), SOA is misnamed. If you think it through, there really isn’t any such thing as a services-oriented architecture per se. Applications are still applications, network protocols are still network protocols, data is, well, you get the drift.

Applications and their interactions represent a logical architecture and data flow. Other pieces of the puzzle represent physical architecture, providing the necessary infrastructure on which applications and data services can live. The design of the data flows and mapping of the logical to the physical is where the potential for services originates.

So, if SOA is the wrong name, what is the right name? While we’re at it, what is a service?

First things first: let’s discuss the name. SOA has become quite a maligned term of late. I place the true intent of “SOA” firmly in the methodology court. That is, defining a “services-oriented methodology” that describes how we would make a data request using a standardized pattern to form the request, and receiving the response data in a standardized pattern for consumption. As there can be many services in an enterprise, this methodology typically demands the use of a services bus, which is a logical transport layer between services and consumers.

The use of the services and bus methodologies creates the opportunity to expose the data from applications of all shapes and sizes (and ages: let’s not leave legacy applications out in the cold; they can play in this realm too), as services.

An application written to conform to a services interface and methodology can be described as being “exposed as a service”. Through this exposure, data contained within the application can be requested and exposed to the enterprise. These services can interact with each other, consuming each others’ output to produce rich enterprise-wide data results.

I’ve covered the methodology; but what is a service? Compare a data service to a service business. A service business accepts requests from customers for particular tasks the business provides; this might run the gamut from legal to janitorial, fast food to buying books online. In all these cases, each business offers discrete services to potential customers. Service businesses must advertise their offerings to make customers aware of the availability.

In this analogy, a data service is the company. Consumers are obvious at the first level (requesting data), but I’ll address primary, secondary and composite consumers in more detail later. The analogy will break down in a few places which include redundancy, consistency, differentiation and advertising.

Let’s isolate the fast food vendor for the moment. In the real world, you have many companies, all competing with each other for customer attention. Multiple fast food vendors offer the same types of services: the preparation of meat, cheese, dough and vegetables, but with differing levels of quality, presentation (burger or taco), availability (scheduled hours or 24-hour drive through), delivery (or pick-up), and so on. Marketing makes the effort to differentiate fast food vendors from each other in the real world, and customers decide how to satisfy their palate for that meal.

Going deeper:

• Raw materials (meat, cheese, dough and vegetables) are delivered and stored until they’re used.
• Consumers request specific presentations (burger or taco, depending on the vendor; some may offer both).
• Consumers pay for their request.
• Employees prepare the raw materials in accordance with published recipes and guidelines.
• Employees serve consumers the end product.
• Consumers consume, and go on their merry way.

So, now we have happy consumers, paying for their food and eating their fill. While most data services won’t require payment, they will require authentication and/or authorization. Payment is essentially a method of authorization: you pay for it, it’s yours.

Authentication is the means to obtain and confirm the identity of the requestor; in the fast food case, it is public and anonymous. Anyone who wants to eat at the vendor and is willing to pay for the food and service can do so. Exceptions include those for whom “No Shirt, No Shoes No Service” or “We reserve the right to refuse service”, apply.

Like a vendor, a data service provides product (result sets or data streams) from raw materials (inputs) and a preparation effort (system processes). The data service authenticates the requestor (some services will be public, others will not) and authorizes the requestor to receive the appropriate level of data.

Follows some of the differences between the fast food vendor and data service:

• Result set / data stream quality and presentation is always consistent and bound by contract to the consumers.
• The availability is constant; essentially whenever the system is activated. In a 24/7 system, the service needs to be available all the time.
• The delivery methodology is always the same: a response to a request from an outside consumer.
• The service must advertise, but not because of competition. In a good design, a particular data service represents the sole source for the service it provides to the enterprise. But note: the data service advertisement is more like the counter menu at the fast food vendor than a billboard that drives traffic into the store.

Data service advertising bears further discussion. Looking at the counter menu, you see items and prices. The implication is “pay us the printed price for the item”, and we all understand it. If you were to do a menu item nutritional review, you could dig very deeply into what you’re getting for your money, including the number of ounces of meat, cheese, dough and vegetables. If the lookup to the nutritional information represents a return set of data, you could surmise that the inputs are:

• Item name
• Cash price

The outputs are:

• 3 ounces ground beef
• 1 ounce cheese
• 2 ounce bun (or tortilla)
• ½ ounce lettuce
• 1 ounce tomato
• 1 serving Thousand Island dressing
• And so on.

There is no obvious need to extend the counter menu to this level of detail; in fact, we’d all find it annoying. We all agree that the burger (or taco) is a food item, and that it contains the detailed list; even though we don’t need it at our level of consumption.

However, a request to a data service (using a weather metaphor) might include:

• City code (Seattle)
• State code (WA)
• Temperature (could be wind speed and direction, precipitation, etc.)

The result might include (I used comma-separated for the second return example; in a web services world, the two returns would be formatted in XML):

• String=“The temperature in Seattle, Washington is 60 degrees F, at 12:34pm, June 15, 2004.”
• Fields=”Seattle,Washington,60,F,12:34:00,20040615”

You’ll note the service returns two data: a formatted string and a series of fields. This gives the consumer some options as to which return to accept and use in their application. The point of this example is to illustrate the negotiation that must go on to adopt a services orientation and methodology; the service must advertise it’s need for three data inputs (city, state and weather data point, in this case, the temperature) and it will return two outputs: a formatted string and a series of fields.

In a web services world, such advertisement can be accomplished in a Web Services Definition Language (WSDL) document, typically available by doing a request of the service root on a web server.

A Note on Web Services
I’ve not delved into web services in this article thus far, and I’ll not start now. There are misnomers about the role web services plays in a services orientation, but the short story is this: web services enable services-oriented methodologies. They are not service-oriented components by themselves. I will address these issues in another article.

Summary
This article explains what SOA isn’t, addressing services orientation as a methodology and design practice than architecture. The fast food metaphor is presented as a model that all can understand as to the interactions that go on behind the scenes in the real world and how similarities exist when discussing data services. The weather service example shows a simple input / output / consume scenario that I’ll expand on later.