Friday, September 11, 2009

The Services Layer


Getting back to SOA. . .  Because of SOA’s roots as a reuse technique that evolved from the reuse of functions and libraries, it’s not surprising that there is a degree of debate on what actually constitutes a service. There is a view out there that services are akin to “functions on steroids”. The problem with this perspective is that functions are typically too fine-grained to truly stand alone or to be distributed efficiently. Dynamic libraries, functions, and object classes are not really services for the simple reason that these reuse elements are not designed with the attribute of location transparency. Distributing them in a willy-nilly fashion would have severe performance implications and thus is not recommended practice.



In the SOA taxonomy there is a hierarchy of elements with specific purposes. There are the elements needed to allow code reuse, and then there are services and applications. The primary reuse elements (libraries, functions, and objects) are ideal to allow the reuse of code within an application or a specific service implementation, but with services we are trying to reuse business processing elements; not necessarily code.
In the legacy view, an application is a monolithic piece of code that does everything for you: grabs the data, massages this data, performs calculations, determines the execution flows, presents the information, accepts and validates the user input and so on. With SOA, the application is simply the entity tasked with handling the business workflow, keeping all manners of state, and being the orchestrators responsible for calling the appropriate services. The application drives the sequencing of service calls and interactions with the user for purposes of delivering a clear business function. An application is thus the brain of the solution, but in SOA, the brunt work of implementing each specific business process or data manipulation aspect is expected to be performed by the underlying service fabric; not by the application.
The role of a service in this new paradigm is to provide a discrete function representing encapsulated logic with the following characteristics that must meet many of the transparency tenets discussed earlier:
· Designed and implemented independently from the specifics of the client or requester.
· Movable. The service can be executed anywhere “in the cloud”
· Any service may be invoked by any qualified client, or by any other service, without having to change the implementation of the service.
· Encapsulable. While some services are entirely self-contained, others rely on other services for a portion of their logic.
· Replicable. A Service may be available from more than one server. It can’t be assumed that it is the only allowed instance in the system.
· Interface-driven. Having an interface decoupled from the implementation with the client seeing only the interface and never having to worry about the details of the implementation. This formally defined service interface represents an unbreakable contract with the client.
In this context, it’s easy to see why many other popular reusable objects or components such as Dynamic Libraries, Portlets, and RMI-Callable Objects aren’t really services because they miss one or more of these characteristics.
The key point in describing a service is this:
For SOA purposes a service represents a unit of work that a non-technical person can understand as providing a valuable stand-alone capability.
Admittedly, this definition allows some wiggle room, but it hopefully helps to more crisply define what can and cannot be considered a service. Let me emphasize the “non-technical” bit: if you can’t explain what the services does in non-technical terms then it is probably not a service. “The service calculates the Module 8 checksum of the credit card number,” does not mean much. “The service checks that the credit card number is valid,” sounds like a true service. This discussion is important because maintaining a service life-cycle and properly managing and administering service repositories and deployment can be an extremely expensive and complex proposition.
Creation and management of services follows a very similar lifecycle to the lifecycle of applications, but the types of governance, skills, controls, and rules governing their workflow are different and must be handled by specialized technical staff. For this reason, identifying what does and doesn’t constitute a service is not sufficient. There is also a need to understand the general role of the service.
There’s an anonymous saying, “There are two types of people in this world: those who divide people into two types, and those who don’t.” I confess. I am firmly in the former group. You can extrapolate that quote to: “There are two types of people in this world: those who classify services into several types and those who don’t.”
Knowing how to classify services according to classes, types, and delivery patterns, as I do in the following sections, helps define the framework for their use, their limitations, and their ultimate scope. More importantly, if you plan to establish a well-constructed service portfolio to ensure that all services in the portfolio are created, deployed, maintained, and sunset according to very strict life-cycle rules, then you will do well to identify the degree of control you will establish for each of these components.
Later on I’ll discuss the aspects related to the governance on services, including organization and lifecycle required to develop and maintain services, but for now let’s delve deeper into the classes of services available in our SOA toolkit.