Fundamental Design
Terminology and Concepts
|
|
Elements of
Service-Oriented Computing
|
|
Goals and Benefits of
Service-Oriented Computing
|
|
Service-Oriented Computing
in the Real World
|
|
|
|
Service-Oriented Computing in the Real World
|
Service Models (Part II)
...continued from previous page
Task Services
A business service with a functional boundary directly associated with a specific parent business task or process is based on the task service model. This type of service tends to have less reuse potential and is generally positioned as the controller of a composition responsible for composing other, more process-agnostic services.
When discussing task services, one point of clarification often required is in relation to entity service capabilities. Each capability essentially encapsulates business process logic in that it carries out a sequence of steps to complete a specific task. An entity Invoice service, for example, may have an Add capability that contains process logic associated with creating a new invoice record.
How then is what a task service encapsulates different from what an entity service’s capabilities contain? The primary distinction has to do with the functional scope of the capability. The Invoice service’s Add capability is focused solely on the processing of an invoice document. To carry out this process may require that the capability logic interact with other services representing different business entities, but the functional scope of the capability is clearly associated with the functional context of the Invoice service.
If, however, we had a billing consolidation process that retrieved numerous invoice and PO records, performed various calculations, and further validated consolidation results against client history billing records, we would have process logic that spans multiple entity domains and does not fit cleanly within a functional context associated with a business entity. This would typically constitute a “parent” process in that it consists of processing logic that needs to coordinate the involvement of multiple services.
Services with a functional context defined by a parent business process or task can be developed as standalone Web services or components – or – they may represent a business process definition hosted within an orchestration platform. In the latter case, the design characteristics of the service are somewhat distinct due to the specific nature of the underlying technology. In this case, it may be preferable to qualify the service model label accordingly. This type of service is referred to as the orchestrated task service.
The example on the top right shows a task service with a sole exposed capability required to initiate its encapsulated parent business process.
Task services are also known as task-centric business services or business process services. Orchestrated task services are also known as process services, business process services, or orchestration services.
Utility Services
Each of the previously described service models has a very clear focus on representing business logic. However, within the realm of automation, there is not always a need to associate logic with a business model or process. In fact, it can be highly beneficial to deliberately establish a functional context that is non-business-centric. This essentially results in a distinct, technology-oriented service layer.
The utility service model accomplishes this. It is dedicated to providing reusable, cross-cutting utility functionality, such as event logging, notification, and exception handling. It is ideally application agnostic in that it can consist of a series of capabilities that draw from multiple enterprise systems and resources, while making this functionality available within a very specific processing context.
The example on the right shows a utility service providing a set of capabilities associated with proprietary data format transformation.
Utility services are also known as application services, infrastructure services, or technology services.
|
|
