by Jürgen Kress, Berthold Maier, Hajo Normann, Danilo Schmeidel, Guido Schmutz, Bernd Trops, Clemens Utschig-Utschig, Torsten Winterberg
Part of the Industrial SOA article series
Services have to meet different architecture and governance requirements whose relevance is determined by how the services are reused. The arrangement and structure significantly affect the analysis and design of the services, which in turn determine the level of granularity. Categorizing services makes it easier to arrange them according to service usage in the procedural landscape, which helps prevent unwanted entanglements.
SOA architectures that have not undergone categorization quickly become "adapter" SOAs that lack a clear division of responsibilities. The orchestration of business processes in these architectures is interspersed with technical service calls that can lead to unaccountable call sequences.
To tackle these challenges, a vocabulary that SOA professionals can use to describe different types of services has been developed. We explore the various possibilities for categorizing SOA services in this article, before introducing the range of service categories that we have successfully implemented in projects. The SOA service categorization matrix in Figure 1 contextualizes the concepts that
| ||Category||External View||Internal View||Calls|
|Business Process Service (BPS)|| ||executable business process|| |
|Business Activity Service (BAS)|| || || |
|Business Entity Service (BES)|| || || |
|Business Rule Service (BRS)|| || || |
|Utility Service|| |
|Private Service|| || |
Public services are implemented using private services. Private Services are a subset of Public Services and often as exposed by existing applications. For public services, the language or application they are realized in does not matter. It is key to standardize their interface description.
Private services have little to no local life-cycle governance.
Examples: Right-click-Java_Service, Controller-EJB, Siebel_Customer_Service
Figure 1 – The SOA Service Categorization Matrix
The service categories that are most applicable to functionally motivated services will first be described. These functionally motivated or "public business services" are usually published in a registry such as UDDI. Different ways in which these public services can be implemented with the help of "private services" are discussed, along with an exploration of several other useful categories.
A business process service (BPS) consists of the purely functional aspects of business processes. This type of service is based on process models that are written in languages like BPMN or with event-driven process chains (EPCs), before being translated into executable processes of different forms such as BPEL or BPMN 2.0 and used to orchestrate purely functional services.
In other words, the functionality is determined on the functional side. Designers no longer need to tinker with the structure as they are now able to tweak the process skeleton, which can be automatically or manually generated. The designers can also enhance the structure with the technical details that are required for execution in the engine.
For the sake of clarity, the business process steps and invoked services should outsource any deeper functional or technical details, such as transformations, into different data dialects. Organizations usually arrange business processes into a hierarchy in order to manage their complexity. A BPS is typically long-running, as differentiated from use case controller, and often incorporates user interaction via workflow functionality.
In order to achieve the loose coupling and flexibility that is promised by BPM, using functional terms to characterize only what a process does and not how it is performed is critical during the process design. The "how" is covered in the implementation of the process steps, which may have multiple alternatives. BPSs exclusively focus on the functional aspects. Technical aspects such as the data transformations into and out of the canonical model should be outsourced to the integration logic, so that BPSs can deal exclusively with data defined by the canonical service data model. Changes to the process should be made in the business model, and the link between the business model and the more technical implementation should be maintained as closely as possible. Business Activity Service (BAS)
A business activity service (BAS) responds to functionally relevant business events and encapsulates context-specific controller logic. The context of a BAS may be the process step of a business process or the use-case controller of an application. A BAS works on more generic and basic services, such as business entity services (BES) and business rules services (BRS). As part of a BPM project, however, a BAS may also invoke a business process service (BPS). This ensures that each process step is mapped to a BAS, the implementation of which may consist of anything from simple service calls to
The design of a business activity service often contains a composite service that calls more than one servicetypically a BES or another BAS. . BASs also include a wrapper or functionality extension that enhances services (usually generic BESs) with context-specific logic (usually a set of business rules).
Business logic that is not context specific should be associated to the BES that manages the related data. This decision depends on whether or not it is context-specific, meaning it was designed for a specific use case (BAS) as opposed to general all-purpose (BES).
BASs are usually created in an ESB, which is where XSLT-based mappings between the required data types are organized. BPEL is used to orchestrate more complex scenarios while ESBs are used to route or allocate BPEL processes.
Start with a verb that describes the activity, then the noun that the verb is acting upon, and end with the category abbreviation "BAS."
The implementation paths that are enclosed in parentheses in each example are categorized as "private services" in the following sections.
The business entity service (BES) encapsulates the data and functionality that are related to a logical business entity, such as a customer or contract, in a specific context that is either across the organization or specific to a domain, subdomain, or department. BESs are core services on the entity level that are as loosely coupled as possible. Important definitions that are often discussed in projects include the fact that BESs always encapsulate an entity, meaning composite entities like "Contract"
Even though many SOA architects prefer using a BAS over a BES containing complex logic so that the complexity can be bypassed, we prefer using the latter option. A service should be defined based on its externally perceivable interface and not based on its implementation. This decision takes into account the fact that a service agreement not only constitutes exchanged data but runtime behavior as well. If BESs were defined in a taxonomy as "stateless and short-term," that would lead to longer-term operations being moved from a BES to a BAS.
Start with a noun that functionally describes the entity, followed by the category abbreviation "BES."
Business entity services often have operations whose behavior is determined by the entity's current status. Depending on the circumstances, it may be useful to outsource the context-specific functionalities to individual BASs that can work with static and even more basic entities.
For example, consider a context-specific "CustomerUponSaleBAS" that carries out work for the generic "CustomerBES." This is how the BAS's nature as a facade for context takes shape.
The data and functions of entity services are based on one or more sources that can come in the form of applications or individual components. Business logic that is tightly connected with the entity and therefore not strongly context-related can be merged with an entity service. Highly complex entities that have a variety of operations can themselves be subdivided into individual and coherent entity services. The criterion of coherence is essential since the context, data, and functionality within each entity
MDM needs to be associated with entities that are encapsulated by a BES. Transactional operations such as "write" can lead to longer runtimes for BESs, especially if the writing operation requires user interaction. The alternative would be to raise BES operations to the business process level.
Since one of the main functions of the BES is to perform searches, a possibility would be to outsource the filters above the call to the BES. The BES would return an entire business object that is re-filtered using the search criteria to deliver the exact data needed for a specific context. Another alternative would be for the BES to provide a wide range of precisely defined search/find operations for each search context. Both options, however, would overload the contract and increase the effort required for governance, which burdens the service lifecycle with the high rate of change.
A recommended design as a solution for overloading is for the BES to define a generic finder method, which exposes the types in XML format. The fields to be returned when calling the method can be defined as a "find criteria" object, which can be removed at runtime.
Business rule services encapsulate decisions in a decision tree, such as "If 'Good Customer,' then...", as well as validations that are often used as preconditions for a function. Validations ensure that the data is in the correct state and context-specific when required, such as "Customer data is correct."
Use a meaningful name that expresses the result of the rule, followed by the abbreviation "BRS."
Defining the concepts of loose coupling and "separation of concerns" in terms of SOA necessitates differentiating between "public" and "private" services on a higher level of abstraction, to maintain a division between the service contract and implementation.
This distinction clarifies how existing functionality can be incorporated into public, reusable, and loosely coupled services. Object-oriented programming distinguishes between the concepts of "private" and "public" to define the visibility and scope of objects and methods. A private method or property is a detail that is related to implementation and not externally visible, while the public method is an interface that can be accessed and usually used as well.
Public services are constructed over the functional interface as a facade over the implementation. The implementation can be any number of private services. Public services are therefore entirely motivated by the customer's needs and functional perception. They are also strictly implementation-neutral, as their interface only deals with behavior that can be seen externally so that implementation details are not exposed. A BES that internally accesses the database on the private and utility service levels can provide functional data without externally propagating any of the technical details, such as DB keys.
Public services are designed to allow for service reuse, which requires the service to be as minimally context or status-specific as possible. This enables reuse in a maximum range of contexts, although each service type corresponds to a different degree of context dependence. Business activity services are therefore significantly more context-specific than business entity services. Public services only exchange data in the canonical data format and are categorized as "public services" in (UDDI) service registries.
These services also provide their entire functionality to operations as a contiguous set that is logically coherent with the respective concept. The public service is categorized according to the service taxonomy as either a business process service (BPS), business activity service (BAS), business entity service (BES), or business rule service (BRS).
For example, a public service operation that checks for customer creditworthiness receives customer data that it uses to verify whether or not the customer is creditworthy. The module calling the service should not be able to view its method of implementation, regardless of whether a complex workflow that evaluates the applicant's property is followed or a third-party credit rating service engaged. The advantage provided by this method is that the form of implementation can be replaced without affecting the customer, as long as the WSDL remains stable.
Large sections of context-specific logic, such as use-case controller logic and data format mappings, should not be stored within public services. If this rule is violated, the service layer will have a high level of dependency on all of the specific contexts, making public services much more difficult to reuse. Front-end controllers accurately encapsulate these aspects and call up generic BASs.
Extensions and changes to service contracts resulting from new contexts, such as a new Web portal, should be conducted using public services through a strict governance regime that regulates the service lifecycle. The logic for roles and rights should be kept in a central entitlement component that is accessible to services, front-ends, and back-ends.
Public services are typically defined using a WSDL, which contains types for each operation that is defined using XML schemas. Some consumers, however, speak other languages like comma-separated values (CSV) and even Cobol. The translation into these languages may need to be outsourced to special adapters that translate on top of the public services, since the service contract cannot be overburdened. This option, however, would bloat the architecture again.
Another solution is for the ESB to support the appropriate bindings into these languages, so that the service contract with the WSDL and associated XML schemas can remain as-is. The defined operation can be tied in with a CSV, Cobol, or another language's binding that is configured in the ESB.
Once a common language has been created, services can be placed into each category in order to facilitate intercommunication. Differentiating between public and private services simplifies the creation of the services that are entirely functionally motivated and can come together to build a modular library of services. Focusing on behavior that is visible from the outside inherently leads to loose coupling, along with services whose implementation elements can be replaced without impacting consumers.
Implementing these steps means that flexibility in executable business processes can finally be achieved, as categorization into BPS, BAS, BES, and BRS helps lend structure to services. Calls to services become part of a meta-concept that facilitates a better understanding of the service functions. A service call sequence can be easily read, such as when a "CarRentalBPS" calls a "calculateRentalFeeBAS." This service then uses "returnCustomerConditionsBES" and "returnBillingAddressBES," which respectively implement functionality from the "CarRentalSystem" and "InvoiceSystem."
Evaluations and reports that provide information on the numbers and reusability for each type of service can be generated for the public business services that have been properly registered. These reports also help simplify the billing process, as fees can be charged based on reported service usage.
Implementation teams can efficiently design reusable services by adhering to a system of clearly defined service categories. Service categorization is the first step towards integrated governance and should be embedded in the project design guidelines. Although not every SOA project requires BPS, BAS, or BES, differentiating between public services and private services remains essential.
D. Krafzig, K. Banke, and D. Slama. Enterprise SOA: Service-Oriented Architecture Best Practices. Toronto: Prentice Hall, 2004.