As a middleware expert Jürgen works at Oracle EMEA Alliances and Channels, responsible for Oracle’s EMEA fusion middleware partner business. He is the founder of the Oracle SOA & BPM and the WebLogic Partner Communities and the global Oracle Partner Advisory Councils. With more than 5000 members from all over the world the Middleware Partner Community are the most successful and active communities at Oracle. Jürgen manages the community with monthly newsletters, webcasts and conferences. He hosts his annual Fusion Middleware Partner Community Forums and the Fusion Middleware Summer Camps, where more than 200 partners get product updates, roadmap insights and hands-on trainings. Supplemented by many web 2.0 tools like twitter, discussion forums, online communities, blogs and wikis. For the SOA & Cloud Symposium by Thomas Erl, Jürgen is a member of the steering board. He is also a frequent speaker at conferences like the SOA & BPM Integration Days, JAX, UKOUG, OUGN, or OOP.
Berthold Maier works in the T-Systems International department of Telekom Germany as Enterprise Architect. He has more than 19 years experience as developer, coach and architect in the area of building complex mission critical applications and integrations scenarios. Within eleven years as Oracle employee he has held several leading positions including chief architect in the consulting organization. Hi is the founder of many frameworks and take over the responsible for reference architectures around BPM/SOA and Enterprise Architecture Management. Berthold is also well-known as a conference speaker, book author and magazine writer.
Hajo Normann works for Accenture in the role of SOA & BPM Community of Practice Lead in ASG. Hajo is responsible for the architecture and solution design of SOA/BPM projects, mostly acting as the interface between business and the IT sides. He enjoys tackling organizational and technical challenges and motivates solutions in customer workshops, conferences, and publications. Hajo leads together with Torsten Winterberg the DOAG SIG Middleware and is an Oracle ACE Director and an active member of a global network within Accenture, as well as in regular contact with SOA/BPM architects from around the world.
Danilo Schmiedel is one of the leading BPM and SOA System Architects at OPITZ CONSULTING. He has been involved in large integration-, business processes automation and BPM / SOA development projects where he implemented solutions for various customers. His main field of interest is focused on the practical use of BPM and SOA on a large scale. Additionally he works as BPM and SOA project coach. Danilo is a frequent speaker in the German Java and Oracle communities and has written numerous articles about the above topics. Before joining OPITZ CONSULTING Danilo worked as Software Engineer in several international projects. The Leipzig University of Applied Science has awarded his outstanding reputation in 2009.
Guido Schmutz works as Technology Manager for the IT services company Trivadis. He has over 25 years as a software developer, consultant, architect, trainer, and coach. In Trivadis he is responsible for SOA, BPM and application integration, and is head of the Trivadis Architecture Board. His interests lie in the architecture, design, and implementation of advanced software solutions. He specializes in Java EE, Spring, Oracle SOA Suite and Oracle Service Bus. He is a regular speaker at international conferences and is the author of articles and several books. Guido is an Oracle ACE Director for Fusion Middleware & SOA.
Bernd Trops is a Senior Principal Consultant at Talend Inc. In this role he is responsible for client project management and training.
Bernd is responsible for all Talend projects within the Deutsche Post and the introductions of new versions and components.
Before Talend, Bernd was a Systems Engineer working on various projects for GemStone, Brocade and WebGain and therefore has extensive experience in J2EE and SOA. From 2003 to 2007 Bernd Trops worked as a SOA Architect at Oracle.
Clemens worked as Chief Architect for the Shared Service Centre, Global Business Services, Boehringer Ingelheim in architecture, master data, service management and innovation.
At the moment he works with holistic enterprise architecture that provides the methodological platform for the new master data management.
He previously worked as a Platform Architect at Oracle Inc. in the United States, where he helped to develop next product strategy as well as the SOA BPM Suite.
Torsten Winterberg works for Oracle Platinum Partner OPITZ CONSULTING. As a director of the competence center for integration and business process solutions he follows his passion to build the best delivery unit for customer solutions in the area of SOA and BPM. He has long-time experience as developer, coach and architect in the area of building complex mission critical Java EE applications. He is a known speaker in the German Java and Oracle communities and has written numerous articles on SOA/BPM related topics. Torsten is part of the Oracle ACE director team (ACE=Acknowledged Community Expert) and leads the DOAG middleware community.
Canonizing a Language for Architecture: An SOA Service Category Matrix Published: May 29, 2013 • Service Technology Magazine Issue LXXII PDF
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
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.
Business Process Service (BPS)
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.
Figure 2 - Business activity services assemble functions and data.
Recommended Naming Convention:
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.
Business Entity Service (BES)
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.
Recommended Naming Convention:
Start with a noun that functionally describes the entity, followed by the category abbreviation "BES."
Discussion: Context in BES Leads to BAS
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
Discussion: Master Data Management (MDM) and BES
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.
Figure 3 - MDM that is encapsulated as a BES.
Discussion: Designing Context-Specific Finder Operations
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 Service (BRS)
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."
Recommended Naming Convention:
Use a meaningful name that expresses the result of the rule, followed by the abbreviation "BRS."
Public Services versus Private Services
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.
Definition of a Public Service
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.
Treating Context-Specific Logic and Impacts on Service Lifecycle Management
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.
The Language Fluency of Public Services
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.
Summary: Benefits of Service Categorization
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.