SOA in PracticeThe Art of Distributed System Design

Book Author: Nicolai M. JosuttisChapter Six: Service Classification

IT-Slideshares http://it-slideshares.blogspot.com/

ContentsA Fundamental Service ClassificationBasic ServicesComposed ServicesProcess ServicesOther Service ClassificationsTechnical and Infrastructure ServicesBeyond ServicesSummary

6.1 A Fundamental Service ClassificationService classification have three categories following

Basic services Composed services Process services

Based on these three service categories Define three different service layers and stages of expansion (see Figure 6-1)

Fundamental SOA with has only a service layer of basic services. Federated SOA which in addition to the basic service s has a layer of composed

services. Process-Enable SOA , which has a third layer for process services

6.2 Basic ServicesThe first stage of expansion provides only basic services.

Which are services that each provide a basic business functionality.It doesn’t make sense to split into multiple services.

These services provide the first fundamental business layer for one specific backend or problem domain.Eg : These services are short-term running and conceptually

stateless .Synchronous calls may be useful.The role of these services is to wrap a backend or problem

domain so that consumers (and high-level services ) can access the backend by using the common SOA infrastructure.

There are two types of basic servicesBasic data servicesBasic login services

6.2.1 Basic Data Services Basic data services read or write data from or to one backend

system. These services typically each represent a fundamental business

operation of the backend. Basic services encapsulate platform-specific aspects and

implementation details from the out-site world. This services should provide some minimal business functionality . Guidelines for achieving an optimum level of granularity for a

lowest level services. It should be possible to describe the service in terms of function,

information , goals , rules , but not in terms of groups of other services. The function set of a service should operate as a family unit that offers

business capability. A Single role should take responsibility for the service The service should be self-contained as possible . Ideally , it should be

autonomous.

6.2.1 Basic Data Services(Cont) E.g : For customer services

Create a new customer Change the address of a customer Return the address of a customer Create a new contact/portfolio/account Return a list of customer according to some search criteria Return a customer’s balance Send an ordered item to a customer Return the number of customers Return details on a customer ‘ payment practices

These services encapsulate or abstract in such a way that some problems are solved basic services should have the so-called ACID properties . Atomic Consistent Isolated Durable

6.2.2 Basic Logic ServicesBasic logic services represent fundamental business

rules.These services usually process some input data and

return corresponding results.E.g Basic logic services might be services that

Define product catalogs and price lists.Define rules for changing customer contracts.Return whether a year is a leap year.Define allowed dates, which might be constraints or extensions

of real dates.These services are also wrappers of the backend systems

that provide this functionality The border between basic logic services and basic data services is not always clear.

6.2.3 Fundamental SOA With the basic services introduced , service consumers can use

ESB to process the business functionally that one backend is responsible for (see Figure 6-2)

6.2.3 Fundamental SOA (cont)• A backend may be anything that is responsible for a specific group of data and

functionality.• The important point here is that this backend plays a clear and more or less unique

role. Technically, a backend can be a database, a host, a mainframe, an SAP system, a

rules engine, a group of J2EE servers, a remote connection to another company, and so on.

It might consist of one or multiple systems. It is the task of the basic service adapters to hide the technical details and provide a

common service API so that the backend can be accessed through the ESB. In your organizational structures , Backend is a system (or group of system) that

from a business point of view play a specific role and it maintained by a specific group of people , it provides a certain general functionality , such as booking , customer management , order management , and so on.

Backend must not become inconsistent or corrupted . Note : A Basic service should never access more than one backend.

E.g : Service that a create a customer, update a customer’s address, query an address, search for an customer, and so on.

In a large systems , there are always multiple back-ends with redundant data. E.g : With CRM System and Billing System

The system that consume basic services can be very different. Note : In a large system it is not always easy to maintain consistency by giving this

responsibility to higher layers that have to ensure that multiple calls to multiple back-ends are consistent.

6.3 Composed ServicesThe second stage of expansion adds composed

services.This represent the first category of services that are

composed of other services (basic and/or other composed services).

In SOA terminology , composing new services out of existing services is called orchestration These services might therefore also be called orchestration services.

These services operate at a higher level than basic services , but they are still short-term running and conceptually stateless.

To use a workflow term , a composed service represents a micro flow :Micro flow is a short-running flow of activities

(services, in this case) inside one business process.

6.3.1 Composed services for Multiple back-endsComposed services are typically services that

access multiple back-ends and therefore are composed of multiple of multiple basic services.

Example A service that updates redundant date on multiple back-

ends. By providing a service that change a customer’s address on all the back-ends Ensure consistency across the back-ends.

A more complicated example would be a service that changes a phone contract.

A service that transfers money one backend to another backend .

The latter two example should the ACID properties .They should either succeed or have no effect.

6.3.2 Composed service for One BackendComposed services may also map or adapt

existing services in some way , Such services might also be referred to as “adapter services”

These services might be useful to provide a different interface for a service that :

Example :Has different nameMore or fewer attributes and so on.

Typical applications would be provide backward compatibility or to map service to a required interface.

6.3.3 Federated SOA Having both basic and composed services leads to the expansion

stage Call Federated SOA This stage introduces an additional layer for composed services

(Figure 6-3)

6.3.3 Federated SOA A typical example of composed service might be a service that make a global

modification of a customer’s address by calling the appropriate basic services of all backends where the address is kept.

This service would have to : Know which back-ends must be informed to update the address. Map the attributes of the new address to specific attributes provided by the individual

basic services of different back-ends. Deal with error handling (I.E : react appropriately if one or more address update fail)

Example : Transferring money from one backend to another.

Approach for handling such a requirement. 2PC (Two phase commit) Note : It is either not possible or to expensive. Compensation

A more loosely coupled approach. Make the business process more complicated. The backend do not need to provide technical support for a common transaction context. Implementing basic services become easier Maintain transaction safety over long-running business processes is almost impossible or

at least very resource –intensive.

6.3.4 SecurityThe introduction of composed services raises another

issue : SecurityWe need some mechanisms that help to guarantee

that those basic services are called only by higher services

Because :Conceptually , the ESB provides interoperability . So , even

when a composed service is provided to allow a task such as updating a customer’s address consistently across all back-ends , consumers still has the ability to call the low-level basic services that allow individual changes on each backend.

This reintroduces the danger of inconsistencies appearing across backends.

6.4 Process ServicesThe third stage of expansion add process services , which

represent long-term workflows or business process .From a business point of view , a process service

represents a macro flow. A macro flow is a long-running flow of activities (Services) that

is interruptible (by human intervention).A process service usually has a state that remains stable

over multiple calls Process service are typically stateful.Example :

Shopping-cart service A service that allows a customer to order a new insurance

policy.Another aspect to consider with process services is failover

6.4.1 Process-Enable SOA

Introducing process services leads to stage of expansion called process-enabled SOA. Additional layer for process services enables you to manage processes that might be

started and controlled by different frontends and be interrupted by human intervention (See Figure 6.4).

Note : BPEL as a web service standard doesn’t provide any ability for running process service to

trigger human interaction , which had an importance consequences for the general design of systems.

6.4.2 Service State Versus Backend State When dealing with process services, you have to make an importance

design decision. Should the process state be maintained in a backend, or in the service

itself? If the process data becomes “juristic data”, it is probably more appropriate to

manage the state in an ordinary backend. If the process data is just some persistent data that has no essential relevance

for your business , stateful services are fine. Example :

A business process for a customer creating a bank account, the related data will clearly be juristic.

A shopping cart service that allows a user to keep track of items she want to order , the related data doesn’t become juristic data until the customer elects to place the order or pay for the items in the shopping cart.

The importance thing to understand the difference between maintaining state in a service and in a backend.

This is an importance issue that you should always consider when introducing business process and workflow systems.

6.5 Other Service ClassificationsIn addition to the categories and layers introduced in the

previous section , several other categories and layers might exist.

Example : You might introduce special layers to separate external services from

internal services. You might also divide a process layer into different sub-layers ,

according to certain technical and/or business rules.Fundamental SOA , federated SOA , and process-enabled SOA

are not the only possible stages of expansion when establishing SOA.

Example :One important stage of expansion is when service management

(with service repositories) comes into play(which is somewhat independent from the stages).

6.5.1 Dealing with Different Types of Consumers One way to categorize services is to differentiate them according to their

target audience . The reason for these distinctions is that these services usually have

different requirements in terms of security and stability. Other differences may also exist between internal and publicly available

services . Having different kinds of consumers might lead to different tool ,

processes and service lifecycles. Another distinction is between national services and international services. There might be a special requirement for the same service to behave

differently in different contexts.• Have different options for dealing with this situation.

• Design different services for each country.• Handling by the routing capabilities of the ESB.• Providing different calling implementations .• …

• It is probably a good idea to introduce a special service category for these kinds of services.

6.5.2 Reading Versus Writing ServicesAnother obvious distinction that can be made

is the distinction between reading services and writing services.

Fewer problem of reading servicesInherently idempotent.Do not require transaction contexts for different

back-ends or rollbacks in the event that they only partially succeed.

Fewer problem of writing servicesRequire an additional amount of security so that

modifications can be traced

6.5.3 Business Categorizations The motivations for the categorization approaches introduced so far were

mainly technical (I.E : driven by the fact that the different types of services are treated differently by processes and tools).

These categorizations lead to differences in your infrastructure (including the corresponding processes).

Categorization according to Erl In [Erl05] Thomas Erl introduces a categorization of services whose terms are

similar to a possible classification of class categories in object-oriented modeling. Application services are services that “contain logic derived from a solution or technology

platform.” Business services are services that “contain business logic”.

Task-centric business services Entity-centric business services

Process services are services that “represent a business process as implemented by an orchestration platform and described by a process definition.”

Some additional service categories Integration services Wrapper and proxy services Utility services Controller services

6.5.3 Business Categorizations Other service-type terms used include activation services ,

coordinator services , registration services , and so on. All of these term have to do with a certain role , property , or ability

of the services . However , the different categories do not lead to differences in the infrastructure.

It’s importance to research your system’s detail and consider the alternatives.

Categorization according to Allen Paul Allen also specifies three key types of (business) services. However ,

here business-case aspects such as risk and market differentiation matter (See Figure 6.5) Commodity Services Territory services Value-added services

The stability of a service Possible risks involved in introducing and maintaining it

6.6 Technical and Infrastructure Services A defining characteristic of services that they represent some business functionally. In most SOA landscapes there are some common services that are not provided to

represent business functionally. These are often called technical or infrastructure services.

Such services typically use the service infrastructure to provide some “additional” functionality.

These services might: Query deployment information Monitor runtime statistics Print , log , or trace Enable or disable components and systems Verify interfaces

From a pure SOA point of view , these are not services. It may be best to avoid explicitly calling them services.

Be careful about introducing the impression that services do not have to represent seft-contained business functionalities.

Because it’s importance to maintain a clear abstraction layer that hides technical details. Example :

A service interface for legacy systems(i.e services that map existing database procedures , 3270 terminal escape sequence , or SAP BAPISs)

6.7 Beyond ServicesAre services all there is to a distributed system landscape?

Not , definitely not SOA is a concept for business processes distributed over multiple

backend systems with different owners. Example :

In your company , several other processes will exist. If the CRM backend has a specific client that maintains the back-end or deals only

with the data of this backend, it is not usually not appropriate to let this client communicate with the back-end only via services.

The price , in terms of both complexity and performance , is usually too height. Don’t let services become your “golden hammer” and start treating

every problem like a nail. The tasks such as synchronizing redundant data over multiple back-

ends are not distributed business processes. You might use the service infrastructure to perform these tasks , but

don’t come to the conclusion that they are service-oriented.

6.8 Summary Services typically fall into different categories . Based on how you categorize your services , you can define corresponding service layers and

stages of SOA expansion. The fundamental service classification specifies basic , composed ,and process service

categories . The corresponding stages of expansion are fundamental SOA, federated SOA and process-enabled SOA.

Basic services should always belong to only one backend system and are responsible only for consistency inside this backend.

Composed and process services are responsible for consistency over multiple back-ends. The usual approach to force consistency across multiple back-ends is compensation, not

transaction safety or two-phase commit (2PC) When designing long-running processes, think carefully about whether to implement them as

stateful process services or to keep the state in a backend, providing basic services to perform state transformations.

Other categorizations might be possible and useful. They don’t necessarily have to lead to clear, distinct service types.

Your SOA landscape may include technical or infrastructure services. Strictly speaking, they don’t fulfill the major service requirement of providing self-contained business functionalities. Consider carefully how to name and deal with these services.

Services are not a silver bullet for any type of communication between distributed systems. Their primary purpose is to allow distributed business processes. Synchronizations between redundant master and slave data, decoupling frontends, and so on are different tasks.