Entity services and business entities explained

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.

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

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.

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 (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
  8:Service compositions
  9:Understanding service oriented computing elements
  10:Entity services
  11:Web services and service oriented computing
  12:Service inventory blueprints
  13:Service-oriented analysis and service modeling
  14:Service-oriented design
  15:Goals and benefits of service-oriented computing
  16:Increased intrinsic interoperability
  17:Increased federation
  18:Increased vendor diversification options
  19:Increased business and technology domain alignment
  20:Increased ROI
  21:Increased organizational agility
  22: Reduced IT burden