In just about every enterprise, there will be business model documents that define the organization's relevant business entities. Examples of business entities include customer, employee, invoice, and claim. The entity service model (Figure 3.18) represents a business-centric service that bases its functional boundary and context on one or more related business entities. It is considered a highly reusable service because it is agnostic to most parent business processes. As a result, a single entity service can be leveraged to automate multiple parent business processes.
Figure 3.18 An example of an entity service. Several of its capabilities are reminiscent of traditional CRUD (create, read, update, delete) methods.
Entity services are also known as entity-centric business services or business entity 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 (Figure 3.19). 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.
Figure 3.19 An example of a task service with a sole exposed capability required to initiate its encapsulated parent business process.
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.
About the author
Thomas Erl is the world's top-selling SOA author, Series Editor of the "Prentice Hall Service-Oriented Computing Series and editor of The SOA Magazine. His books have become international bestsellers and have been formally endorsed by senior members of major software organizations such as IBM, Microsoft and Oracle. He is the founder of SOA Systems Inc., a company specializing in SOA training, certification and strategic consulting services with a vendor-agnostic focus.
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.
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.
About the book
SOA: Principles of Service Design is dedicated to service engineering and establishing service-orientation as a design paradigm. This manual for establishes concrete links between specific service-orientation design principles and the strategic goals and benefits associated with SOA.Purchase the book from Amazon.com.
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 (Figure 3.20) 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.
Figure 3.20 An example of 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.
Use the following table of contents to navigate to chapter excerpts.
SOA: Principles of Service Design
Home: Service-oriented computing and SOA: Introduction
1: Design fundamentals: Design characteristics
2: Design fundamentals: Design principles and design paradigm
3:Design fundamentals: Design pattern and design pattern language
4:Design fundamentals: Design standard
5:Design fundamentals: Best practices
6:Introduction to service-oriented computing
7:Service oriented architecture
9:Understanding service oriented computing elements
11:Web services and service oriented computing
12:Service inventory blueprints
13:Service-oriented analysis and service modeling
15:Goals and benefits of service-oriented computing
16:Increased intrinsic interoperability
18:Increased vendor diversification options
19:Increased business and technology domain alignment
21:Increased organizational agility
22: Reduced IT burden