Lecture 06 - Service Classification


Published on

Lecture 06 - Service Classification

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Lecture 06 - Service Classification

  1. 1. Book Author: Nicolai M. Josuttis Chapter Six: Service ClassificationIT-Slideshares http://it-slideshares.blogspot.com/
  2. 2. Contents A Fundamental Service Classification Basic Services Composed Services Process Services Other Service Classifications Technical and Infrastructure Services Beyond Services Summary
  3. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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.