Friday, September 25, 2009

A Sample View of Services in a System

Before I present a sample view of services as applied to a hypothetical airline reservation flow, I would like to cover yet other dimensions to the categorization of services: the manner of the service delivery and its disposition.
In SOA, as in life, for any given service request you will be deciding between these three service delivery patterns:
Asynchronous: The service request is posted by the client with the expectation that the action will take place at the server’s leisure and that the client will not expect a related response from the service call. As the client is not waiting for an immediate response, he/she can continue to do whatever it is that clients do. The service is posted asynchronously and possibly queued up in a wait area until the system (the server) is able to process it. Any response resulting from processing the asynchronous request will also be sent back asynchronously to the client.  The service interface designer is responsible for defining and filling-in a correlation identifier, if there is a need to match a request with its response. An example of asynchronous exchanges is a request for support from a vendor via email, with the expectation (but not certainty!) of a reply sometime later. Implicit in the way asynchronous services are handled is the idea that a queuing system of some sort must exist in the system infrastructure to properly handle the various aspects related to this pattern: How do we ensure delivery of the request? How do we prioritize the handling of the service? In the email example, the mail server takes care of all these details.
Query/Reply: This is the predominant service pattern for transactional systems. Here, a service request is made with the expectation that a response to the request will be given immediately. The fact that the client actually waits for a response gives this pattern very definite sensitivities as far as performance is concerned. If email exchanges are a representative example of asynchronous exchanges, you can think of chat or even telephone exchanges as an example of Query/Reply. Instead of sending an email, you establish a two-way real-time dialogue between yourself and the service provider.
Event Driven. This pattern is also known as Pub/Sub because it relies on the Publish/Subscribe idea. In this pattern the service request is for an asynchronous response that will take place upon the satisfaction of the event criteria. This pattern is typically used in a manner similar to the synchronous pattern in that the calling client need not wait for a response, but on occasion, a design may call for the client issuing the subscription request to sit idly by until a response occurs.

With that covered, let me now display a sample generic service flow, orchestrated from a putative airline reservation application with a client requesting via a natural language interface, all available flights to a chosen destination. The example shows a number of service types interacting to construct the appropriate response. 

Hopefully most of the diagram is self-explanatory. The services shown to the left of the vertical line are meant to indicate those that can be accessed by the outside world and are thus considered to be Access Services. The Natural Language Parse, for example, could well be an external service provided by another company on a SaaS basis. The Update Customer profile could be available to external B2B partners to update the profile as per commercial agreements.  Clearly, the Find Best Fare service could also be made available externally if desired, but the example here depicts a Best Fare Service that is applying internal rules that we do not wish to expose to the world.  The various services could be classified as follows:









Understanding the attributes of each service will enable you to apply predefined standards for their use. For example, Access services will be expected to provide public interfaces and will be hardened for public use. Access services are also cases where you may have to keep state across multiple service calls. Such state information may have to be kept in non-volatile storage (disk, or replicated cache). Composite services will be allowed to keep some state, but only for the duration of the service call. Atomic services will have highly streamlined execution paths, including avoidance of state.
Ideally, everything would follow an asynchronous pattern in the sense that not having to wait for a response is the most flexible way to optimize system resources and meet service level agreements. However, the reality is that you may need to adjust the overall solution against this ideal. Designing a system to do asynchronous messaging whenever possible may be seen as a desired goal, but fact of the matter is that you will need to use the Query/Reply patterns more often than not, particularly in transactional environments, to ensure prompt responses. Alas, I have witnessed actual designs that attempt to force asynchronous patterns in transactional systems (making everything flow through queues); resulting in very odd behaviors and unsatisfactory performance.
Finally, there is another category of “services” I have not yet defined. These are the services needed to facilitate or simplify the workings of SOA. I refer to these services as meta-services, and they are usually called upon to perform a specific SOA activity such as ensuring transaction integrity, forking the delivery of a service request, routing a service request to an alternate location, and other tasks.  In fact, there are various patterns identified for these types of services, but the most interesting aspect is that a portfolio of meta-services is being bundled and it comprises a large portion of what is rapidly evolving to be a separate SOA middleware enabling layer: The Enterprise Service Bus. 
If you recall the SOA taxonomy that I presented earlier, I will include these Enterprise Service Bus elements as part of the Service Fabric, to be discussed at a later date.

Friday, September 18, 2009

Service Categories

Pursuing the analogy of SOA services mirroring the way civilization is structured around individuals and institutions that provide services to others can help us to understand the value of classifying the classes and types of services. After all, if you think of a repair shop, for example, one can see that the services provided by the receptionist are not the same as the services provided by the repair technician in the backroom, or even the services of the cashier who will collect your payment later on.  You would not normally consider putting the receptionist in a repair role, or the repair technician in the role of cashier. It’s best when every individual performs the role for which they are optimally qualified. 
Then there is at the manner in which the individuals render their services. Some have a role as orchestrators of other people’s work. The shop manager is someone who offers a coordination service that makes the business run coherently. Others perform a specific, specialized role. They do what they do without requiring others help (like those who order you out of the kitchen!). Then there are those whose main role relies on accessing a data repository of sorts. They front end actual information resources.  How much salary you afford and how much value and attention you confer to each, ultimately depends on a combination of all these attributes.
Similarly, with SOA we can define three service classes: Access Services, Enterprise Services, and System Services. 

Access Services are often implemented as wrappers for legacy applications and encapsulate the internal business service logic while taking a role as proxies to the clients. This role usually involves keeping and managing the state of a business flow on behalf of the external client. This is often needed in order to hide proprietary logic from external users. As a consequence, interfaces in this class of “services” will be extremely coarse and therefore somewhat verbose. In travel, for example, the Open Travel Alliance XML protocols tend to be extremely elaborate because of the very high level of service interface abstraction required for diverse companies to interoperate.
If you have control of the actual calling application, then you can implement the orchestration logic directly within them and provided the application runs internally, inside your DMZ scope. They can bypass the Access Services by calling the backend enterprise business services directly. 
Access Services and Enterprise Business Services classes are best defined in terms of their business value—as something easy to explain in terms of the business services they provide. But just as there are business services, there are also system services. 
System Services are the services that support the system and don’t usually have a direct business mapping, even though they indirectly support the business.   Still, remember that, as per our definition, you ought to be able to explain what these services offer to a layman, even if the services are not providing direct business functionality. Just because a service has a system focus, as opposed to a direct business focus, does not mean that the service should be so fine–grained that it simply serves some obscure function which could be better handled via a library or a subroutine.  
All service classes should comply with the guidelines and standards established for service life-cycle, but I suggest that the specific elements of the lifecycle will be different for each service class. Access Services will probably be public and should be normalized to industry standards as much as possible, while Enterprise Services should be governed by your internal architecture group. The likely user of the System Services will be your company’s operation team.

Now, let’s talk about Service Types. . . Just as services can be divided into Access, Enterprise Business, and System Services classes, they also need to be classified based upon their intrinsic roles and in the way they are internally structured so that you can assign their maintenance to the proper development organization.
Services that implement functionality requiring access to other services are known as Composite Services. Services of this type may at times keep a session state, but only for the duration of the execution (having services keep state across multiple service calls is generally not recommended, unless the service is an Access Service as discussed above).  On the other hand, services that provide function without needing to call upon other services are known as Atomic Services.  These services provide coarse-grained functionality in a single-shot.  A specific type of Atomic Services is Data Access Services.  The latter supports one of the key principles in SOA: avoidance of data base visibility from functional services, whether Composite or Atomic, and the interfacing of all interactive data requests via service interfaces. The diagram below gives an example of the kind of service classes and types you would see in a reservation system. 

Next week I will cover the service delivery patterns and I will provide an example of how all these service categories fit into an actual system design. Till then!

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.

Friday, September 4, 2009

Interlude One: Four random lessons that could prove useful to you.

I was planning to publish a blog on the Service layer this week. Then I realized that, as amazing as SOA happens to be, the subject tends to be dry at times. This being Labor Day weekend, I figured, “Heck, this is my blog and I can do something different once in a while!” So, let’s take a small diversion from the discussion on services, SOA, and the like and talk instead about some random stuff that you might find fun to ponder?
I have always thought of myself as a visionary—an innovation factory of sorts. My nagging question (and my wife’s) has always been this: if I am such a visionary, why do I still have to peddle my services for a salary? Why am I not a multimillionaire?
Let’s face it, during the last sixty years the computer industry has been one of the biggest breeder of fortunes. Early on, the players best positioned to take advantage of the computer invention were the big corporations: IBM, Sperry-Univac, Burroughs, etc., but in time, independent garage-based entrepreneurs began to appear; enter Bill Gates at Microsoft, Steve jobs at Apple, and assorted others. I asked the question asked by many, “Why not me too?”
Like many, during the eighties, I watched as the PC revolution passed me by. I was idealistic and not interested in money. I developed software for the pure love of doing so and made it available via Compuserve as “freeware” (asking for “voluntary” contributions which netted me around $200 for a sprite animation software I had developed).  Even though I’m mentioned in Wikipedia as one of the pioneers of game simulation thanks to my “Strength of Nations” game, which I had suitably offered for free to the online community of the day, it would have been nice to share in the fate of others more business-savvy than I, who had developed PC solutions earning them well-deserved riches.
Lesson #1. “It’s okay to be idealistic, but it doesn’t hurt to look for an economic angle as well.”
During the nineties I continued in the pioneering forefront and worked diligently to advance the novelty of the Web.  In the process of experimenting and setting up the first Intranet for my employer, I created a web page that would ultimately contain all the employee photos. Lacking the actual individual photos, I inserted random pictures as placeholders: Mickey Mouse, Homer Simpson, one or two actors whose names I no longer recall and, well, a photo of the Unabomer (what can I say? The guy happened to be in the news back then). The setup was meant to be temporary, but little was I aware that someone in HR, hoping to ingratiate herself with this Intranet thing (and probably trying to steal the credit as well) chose to “demonstrate” this work in progress to the CEO. . . without  informing me!
I don’t know if it was the fact that the Unabomer was so disliked by corporate America given his expressed desire to target captains of industry, or the fact that my company’s particularly conservative CEO didn’t even believe in the Internet, but I found myself in hot water. Rumor says the CEO stormed out of the presentation and demanded to have that ridiculous “Intranet-thing” shut down. After much pleading he allowed it to stay, provided no photos were ever placed in it. My career in that company was not looking very sweet.
Lesson #2: I don’t know if there is broader lesson to be learned her other than the obvious: “Don’t use a photo of the Unabomer as a placeholder.”
After this incident, I sat down with my good friend, Ron, to explore business opportunities for the Internet.  In line with Lesson #1, this time I wanted to come up with a grand idea that would make us rich. I, as well as another million or so hopefuls, was ready to benefit from the spoils of the Dot-Com Gold Rush of the nineties.
Brainstorming ideas with Ron, I decided search engines were out of the question. After all, hadn’t Altavista already captured that market?  In retrospect, the fact that you had to enter a long-winded domain name to access it (www. should have tipped me off as to how little interest DEC had for support of the product! We continued brainstorming throughout the afternoon, accompanied by a case of Coronas, but nothing seemed novel or legal enough (online gambling sites, I surmised would not be well received by the US Justice Department). Deflated, by the end of the day, I concluded, “I think everything that can be done with the Internet has already been done, my friend. I am afraid we are too late.”
I continued in my profession and thankfully most of it was successful and rewarding, but in the process I witnessed the emergence of Google, eBay, Skype, Twitter, Facebook, MySpace, and hundreds of other truly-valuable Internet franchises.
Lesson #3: It is never too late for anything!
Another story:  Having just graduated from College, I was in a desperate search for a job. I finally landed an interview to work for a factory on the outskirts of the city where I lived and grew up (Mexico City, if you must know). I felt I had nailed the interview.  I had answered most of the questions well and sensed I was a contender for the job. Then, suddenly, the interviewer pulled a mechanical contraption from his desk drawer. “Tell me,” he asked, “do you know what this is?”
I had no clue what the piece was or its purpose.  I deployed my keenest analytical instincts in examining the piece to try and figure it out. It was made of metal and had grooves and even though it appeared to be a passive device, requiring no electricity, its form suggested it served some useful purpose. Still its function escaped me.
Feeling like a losing contestant on a game show with a ticking clock in the background, I finally offered a guess. “Is it some kind of valve?”  The interviewer looked at me intently and replied in the negative. You have to realize, I had been in the market for quite some time and was desperate for a job (actually I was desperate for the money the job would bring, but you get my drift), so I tried to think even harder. The piece didn’t have any moving parts, but it had an odd shape. What could it be?  “Is it some kind of sensor?” I ventured.
No. The man shook his head. I sighed and said, “Sorry, I don’t know what it is.” I threw my arms up hoping I would score some points for at least having been honest enough to admit my ignorance.
Then the interviewer held the piece directly on front of me and waited, expectantly. It was awkward because here I was hoping he would finally tell me what the blasted thing was and he just sat there, silent. What was he expecting of me?  The standoff lasted for less than a minute but it felt like an hour to me.  Hadn’t I already admitted my ignorance?
Finally, he slowly placed the piece back in the drawer and politely thanked me and told me I would be called if offered the job.
I didn’t get that job and it took me years to realize why I didn’t: I never asked him what the damned piece was or what it was for! (Till this day I wish I knew the answer).
Lesson #4: If you don’t know something, just ask.
That’s it. This concludes this interlude. Sorry if I’ve digressed a little. Next week, I will cover the Services Layer.
Enjoy the weekend!