The goal of Service Oriented Analysis to identify and model service candidates.
In his books, Service-Oriented Architecture Concepts, Technology, and Design [Erl 2005], SOA Design Principles [Erl 2008] and SOA Design Patterns [Erl 2009], Erl discusses the concept of service layers. He identifies four service layers, and asserts that each service exists in exactly one of the four logical architectural layers:
Orchestration layer / Orchestrated services
Entity layer / Entity services
Task layer / Task services
Utility layer / Task services
These layers are fundamental to the development process as the services in each layer may require different steps to be performed during the analysis, design, and development of services in that layer. Erl defines each of these layers are follows:
Orchestration layer / Orchestrated services
"The orchestration service layer introduces a parent level of abstraction that alleviates the need for other services to manage interaction details required to ensure that service operations are executed in a specific sequence. Within the orchestration service layer, process services compose other services that provide specific sets of functions, independent of the business rules and scenario-specific logic required to execute a process instance."
Entity services
"A service that encapsulates processing logic associated with a specific business entity. Entity-centric business services are designed to provide a set of features that provide data management related only to their corresponding entities. They are therefore business process-agnostic. The same entity-centric business services can (and should) be reused by different process or task-centric business services."
Task services
"A service that encapsulates business logic specific to a task or business process is a task service. Task-centric services have limited re-use potential."
Utility services
“The utility application service layer intentionally abstracts non-business-related logic (logic that is not derived from an organization's business models) into a set of services that can simply be referred to as application services (or utility services). Their purpose is to provide reusable functions that address cross-cutting concerns by representing common enterprise resources and capabilities.”
The main source of candidate services is from the business process models. In addition, entity services may be identified from the domain model, and utility services from common utility functions observed within the IT infrastructure.
The business process model describes the interaction between services. These may be existing services or they may be new, candidate services. The first step is to identify the existing services, through inspection or interrogation of a service repository and / or registry or other location for service descriptions. Where services are required that do not currently exist, they should be modeled as candidate services. Generally speaking, entity and utility services should be modeled first, followed by task services and finally orchestrated services.
Service modeling at this phase consists primarily of determining the type of service, identifying the candidate capabilities of a service, and determining if the service can be decomposed into composite services. When identifying candidate capabilities, or the tasks that a service performs, it is very important that we focus on the tasks, or capabilities, of a service and not assume that these map to the Web services operation that a Web service might provide. As part of service modeling the example messages should be associated with the service candidates.
In the purchasing example, the following service candidates can be identified from the business process model. These are:
Buyer
CreditAgency
Store
Assume the CreditAgency service exists, and focus on the Store. What type of service is the Store? What tasks does it perform? Is it composed of other services? Store must do more than manage domain entities, and it provides business logic, not utility logic, so it must be either a task service or orchestrated service. Both provide process specific business logic, the main difference is whether the service can be decomposed and the anticipated composition style. Store provides at least one capability, that being “buy”.
What is required to perform this buy task? This may not have been specified by the business analyst. At this point all they have communicated is the high level requirements of the global process. It is up to the SOA analyst and / or architect to decompose the Store service and its buy task. For example, does the Store need to calculate the price, or access information about the customer? If so, then additional candidate services such as PriceCalculation and CustomerEntity may be added. Also, the PriceCalculation service may require information from the CustomerEntity, when calculating the price, to apply business rules regarding the discount that can be offered to the requesting customer. Since the Store is composing the PriceCalculation and Customer Entity services, it can be classified as an orchestrated service.
We may also want to extend this example, to consider human task integration. For example, once the discount has been determined, if it is above a certain percentage then it may be necessary to obtain approval from a manager. In this case, the manager's task could be modelled as an additional candidate service (i.e. DiscountApprover), which internally dispatches the approval task to the appropriate person, and then returns a response once the approval has either been given or rejected. Modelling the involvement of people as services (or participants in the choreography), enables the internal implementation details to be hidden, and therefore allows the human involvement to be replaced by an automated solution at a later date.
Service-oriented analysis will identify other services that may be involved in delivering the required functionality - and the interactions between these services can be captured in another set of more detailed scenarios. These scenarios can then be checked for compatibility with the higher level scenarios - or at least with the behavior defined for the participant in the choreography model being modeled as part of the Service Oriented Analysis.
So we might have two situations:
1) where the participant in the choreography maps onto a single service, I.e, there is no further service decomposition, and therefore the business requirement scenarios are sufficient.
2) where the participant's service is more complex and can be decomposed into composite services, requiring more detailed analysis scenarios to define the interactions between the candidate services - where the 'client' of the scenario is the public participant interface within the choreography - and thus can be checked for validity in that respect.
Where more detailed analysis scenarios are defined, then either these can be documented in the business process model's choreography, or if appropriate, in specific choreographies associated with the participant. For example, a choreography can be defined that represents the internal interactions between the candidate services associated with the Store participant in the high level business process choreography.
This is an example of the interactive nature of the development process. Service-oriented analysis can result in further business analysis and choreography modeling.
The tasks in this phase are:
Comments