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!
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.
These are the types of tenets you can laminate in plastic and frame for the office wall next to the water cooler. They don’t often change, but change they do.These tenets usually define the current state of the industry preferences for specific technologies. While usually applicable to current environments, there is no guarantee they won’t eventually need to be revised. Take a trip down memory lane and imagine a return to the year 1969. Yes, Woodstock happened and you probably don’t remember it, either because you hadn’t been born yet or because you were in fact there. After listening to Janis Joplin, Santana, and Jimmy Hendrix, you show up to the office and are given the task of defining the tenets for a data processing application. You clear your mind and readjust to the fact you are back at work. You define a tenet that states customer records shouldn’t exceed 80 characters. Why? Because each record must fit on a punch card, and a punch card holds a maximum of 80 columns. Clearly, when there’s a need to code for the year field, you’ll opt for conciseness and drop the “superfluous” 19 from the year, etc.Another tenet might have been to make certain that all job submissions are hand-delivered to the “Batch Service” window with the user signing the log sheet.
Unlike Category I tenets that tend to be industry-agnostic, Category II tenets have a more focused applicability. Some of these tenets will be more appropriate for a particular industry segment, geography, or IT situation.If you are in a service industry, for example, you will have tenets that emphasize functionality over other attributes; if you are in the manufacturing industry, you will probably focus on tenets geared to reducing costs, and if you are in the videogame industry, your tenets will highlight usability and playability.
The list of Category II Tenets can therefore be extremely large. Below, I show some such tenets as examples. Again, when it comes to creating your own tenets, you’ll need to assemble your team and map those tenets that best apply to your specific conditions and that contribute to meeting the category I tenets previously defined:
·Move to a common development environment to maximize use of common support processes and tools within any of the deployed platforms.
·Object-oriented methodologies and approaches will be pursued whenever possible. Percentage of reused code will be a success factor.
·Use state-of-the-art programming tools and techniques to ensure maximum development productivity. Use Life Cycle and Service Studio components to facilitate service reuse. Optimize the development cycle by using design methodologies that permit analysis of the system under a business view and rapid prototyping for proof of concept. Use UML whenever possible.
·Ensure reliability through redundant clustering, either purchased or built.The strategy is to seek system level resilience via n-plus one redundancy with automatic fallback/recovery.
·Consider security requirements from the start. Establish security, logging and billing mechanisms based on service-oriented constructs.
·Message queuing is the strategic middleware standard. Mapping to other middleware will be supported as required, but the canonical service distribution protocol will be SOAP based.
·Unify connectivity protocols and communications interfaces end-to-end.Reduce the number of different access methods and protocols used inside the central complex. Use open, off-the-shelf protocols and systems. TCP/IP is the preferred connectivity protocol.
·Hide the complexity of the DBMS from the applications, users, and processes that access the data, by encapsulating these database accesses with service oriented APIs.
·Enable distributed data access with connectivity to heterogeneous DBMS within one unit of work.
·AvoidDBMS access across the wide area network. Propagate remote data queries via a service-oriented approach.
·Portals will deal with user sessions and presentation and will orchestrate the user interaction, including content presentation, but the business services will be provided by backend engines and will not reside in the front end portals.
·All systems to be adapted, built, or bought must provide the following features:
oProactive and reactivemonitoring capabilities
oFault tolerant, load balancing, and fail-over capabilities
oPerformance measurement, logging, and system health reporting
oIntegration with system administration and management standards.
In addition, Category II Tenets are the natural realm for all SOA-related tenets. Those tenets deal with desired levels of service-granularity, SOA governance, SOA management approaches, etc. Because the grand theme of IT Transformation is the use of SOA, I will later cover these tenets in detail.
The Category III Tenets
These are the tenets that are defined at the departmental level. They describe naming conventions, documentation standards, reporting mechanisms, and pretty much anything dealing with the nitty-gritty of running a project and are therefore as important as the other categories.It is a good idea to keep a formalized track of how these tenets are defined, communicated, and enforced.
A typical challenge is that sometimes, tenets are created as Level III when in fact they ought to be vetted with a Level II scope. The opposite is also true. A sure sign of an organization trying to over-control a project is having Category II tenets that should be left to a subsidiary unit. Remember that allowing a degree of departmental freedom in choosing tenets at this level is actually a good way to ensure fluid dynamics and engagement of the base in the overall standardization process. In the end, you may have something akin to British Common-Law whereby Level III tenets become so widely adopted that in time they emerge as de-facto Level II tenets!
In my experience, developers tend to converge around novel tools that, due to their emerging nature, have not yet come onto the radar of the corporate bigwigs. Sometimes this results in conflicting viewpoints between the directives driven from the top and the preferred technologies driven from the grassroots.When thishappens you will need to open the floor to debate and be prepared to make some compromises.
An example of this situation is the manner in which TCP/IP was adopted as the preferred networking protocol. It is a fact that TCP/IP emerged from the grassroots, even as corporate directions coming from the top were trying to enforce the OSI or SNA protocol stacks. The ‘can-do-now’ and ‘can-do-cheaper’ pragmatism espoused by departmental gurus won over the ‘comprehensive’ and ‘structured’ OSI dogma espoused by the architects.
Because the OSI standard was a camel (i.e. a horse designed by committee), it was practically impossible to implement, and the grassroots’ preference for TCP/IP did turn out to be the right choice. To be fair, there are examples where grassroots-driven adoptions ended up being counter-productive. Take the wildfire adoption of the distributed Novel servers in the latter part of the eighties that ultimately led to the organic emergence of extremely complex environments; environments with a high degree of data heterogeneity and processes that companies had a hard time extricating themselves from.Now, I am not suggesting that the Novel corporation or its technology was at fault (after all, it was in fact a fairly leading technology for its time). Rather the issue was that much of the deployment of this technology happened pretty much ‘under-the-radar’.Most companies ended-up with duplicate data bases, data bases that lacked the necessary security, badly managed data, and in many instances, application code that was written for the very proprietary vendor environment and which could not be reused.
So what are examples of Category III tenets? The list can become fairly detailed and nuanced. I suggest breaking down these tenets into logical groups so that you have at least a means to compare and contrast tenets coming from different groups. The following groupings are recommended:
Data Tenets. Specific to the data, these tenets would include naming conventions, partitioning approaches, etc.
Foundational Tenets. Tenets dealing with system infrastructure and management would come here. Network IP standards, server naming standards, etc. would come here.
Presentation Tenets. These cover usability standards, use of presentation elements, navigation, etc.
SOATenets. XML tags, repository placement, service levels, etc.
General Tenets. Tenets dealing with general governance and project processes, including vender-selection strategies, evaluation and testing methods, etc..
Also, as a matter of fact, if you can also group the Category II Tenets along these lines, it would be a extremely useful way to ensure coherence between the Category III and Category II Tenet narratives.
That’s it. . .If you are “teneted-out” I don’t blame you. It’s time to dive into the Level II Architecture stage and, in particular, into SOA as the solution for that architecture level.
This blog covers the practical techniques, trials and tribulations associated with the transformation of IT systems from legacy technologies to systems using SOA and modern open systems. I also include the occasional interlude with rants about technology in general.
About Me
Name: Israel del Rio
Location: Atlanta, GA, United States
Israel has been recognized by Computerworld as one of their Premiere 100 IT honorees. Israel is a business and technology leader who has contributed the technology vision as key strategist and designer behind the enterprise technology roadmaps of large hospitality and travel companies. Israel has also have developed and deployed various mission-critical systems and in the process, he's been instrumental in creating and building effective and skilled development organizations.
