Lecture 06 - Service Classification

1. Book Author: Nicolai M. Josuttis
Chapter Six: Service Classification
IT-Slideshares http://it-slideshares.blogspot.com/

2. Contents
 A Fundamental Service Classification
 Basic Services
 Composed Services
 Process Services
 Other Service Classifications
 Technical and Infrastructure Services
 Beyond Services
 Summary

3. 6.1 A Fundamental Service Classification
 Service 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

4. 6.2 Basic Services
 The 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 services
 Basic data services
 Basic login services

5. 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. 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

7. 6.2.2 Basic Logic Services
 Basic 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.

8. 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)

9. 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.

10. 6.3 Composed Services
 The 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.

11. 6.3.1 Composed services for Multiple back-ends
 Composed 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.

12. 6.3.2 Composed service for One Backend
 Composed 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 name
 More or fewer attributes and so on.
 Typical applications would be provide backward
compatibility or to map service to a required interface.

13. 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)

14. 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.

15. 6.3.4 Security
 The introduction of composed services raises another issue
: Security
 We 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.

16. 6.4 Process Services
 The 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

17. 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.

18. 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.

19. 6.5 Other Service Classifications
 In 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).

20. 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.

21. 6.5.2 Reading Versus Writing Services
 Another obvious distinction that can be made is the
distinction between reading services and writing
services.
 Fewer problem of reading services
 Inherently idempotent.
 Do not require transaction contexts for different back-
ends or rollbacks in the event that they only partially
succeed.
 Fewer problem of writing services
 Require an additional amount of security so that
modifications can be traced

22. 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

23. 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

24. 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)

25. 6.7 Beyond Services
Are 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.

26. 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.