close link to particular applications, these systems are also called embedded workflow management systems.
Business processes are also realized in online shops, such as train reserva- tion systems or electronic book stores, where steps of an interaction process are depicted in graphical form. This graphical representation guides the user in his interaction with the Web site. In a train reservation online shop, for instance, there are interaction steps for querying train connections, for get- ting detailed information on the connections, for selecting connections, for providing payment information, and for booking and printing the train ticket.
Since this type of interaction process can easily be realized using traditional Web page design, workflow management systems are not required. However, these examples show that the business process paradigm is helpful also in application scenarios that do not require dedicated workflow support.
Enterprise application systems, such as enterprise resource planning sys- tems, realize literally thousands of business processes. These processes can be customized to fit the particular needs of the company that runs the system. In most cases, the business processes are realized within the system, so no inte- gration issues emerge. If the predefined business processes cannot be tailored in a way that fits the needs of the company, then integrated process modelling functionality can be used to model new processes.
2.5.1 Service-Oriented Architectures
Steve Burbeck, one of the early advocates of service-oriented architectures, defines service-orientation as follows.
Services are loosely-coupled computing tasks communicating over the internet that play a growing part in business-to-business interac- tions. [...] We reserve the termservice-oriented for architectures that focus on how services are described and organized to support their dynamic, automated discovery and use. We do not address systems based on manually hardwired interactions, such as those used in EDI systems.
In this definition, services communicate over the Internet. This means that services are expected to be used in business-to-business scenarios, where the participants are connected by the Internet. Although not explicitly ruled out, services that are provided and used within a company do not fully qualify in Burbeck’s definition.
The second interesting aspect of this definition is the high degree of flexi- bility provided by late, run time finding and binding of services. Matching a service request to a set of service specifications in a service registry is a com- plex task, especially if automated discovery and use are sought, as implied by the definition.
Burbeck’s definition mirrors the long-term vision of service-oriented ar- chitectures. But this architectural style is not only useful in Internet set- tings, where the services are provided by different organizations in business- to-business scenarios, but also in intracompany settings. Therefore this book adopts the following definitions.
Definition 2.7 Aservicecaptures functionality with a business value that is ready to be used. Services are made available by service providers. A service requires a service description that can be accessed and understood by potential service requestors.Software services are services that are realized by software systems.
Service-oriented architectures are software architectures that provide an environment for describing and finding software services, and for binding to services. Descriptions of software services provide a level of detail that facili- tates service requestors to bind to and invoke them.
Service-oriented architectures are especially important in environments where many services are available and where the set of available services changes over time. Burbeck investigates this aspect in more detail and states as follows.
To work easily, flexibly, and well together, services must be based on shared organizing principles that constitute a service-oriented ar- chitecture.
In a service-oriented architecture, organizations may use services offered by other companies, and companies may provide services to a growing services market. The vision is for information systems to use business functionality of service providers, so that reuse of functionality is realized at a level of coarse granularity. New applications can be built with less effort and existing applications can be efficiently adapted to changing requirements, reducing maintenance and development cost.
Service Requestor Service Provider
Service Registry 4: bind / invoke
2: req
uest 1: publish
3: reply
Fig. 2.21. Roles in service-oriented architectures
Figure 2.21 depicts the classical service-oriented architecture, as intro- duced by Burbeck. This architecture is based on roles that participating orga- nizations can play. Service providers offer services. To enable service requestors to find and use them, they are specified, and their descriptions are stored in a service registry.
The interactions between the three primary roles in service-oriented archi- tecture are publish, request/reply, and bind. The service provider publishes service specifications in a service registry, and the service requestor searches the service registry and finds suitable services. The service registry provides the service requestor with information that allows the service requestor to bind to the service and, eventually, invoke it.
In this section, service-oriented computing is characterized in an informal way. Web services as the current implementation of service-oriented architec- tures will be covered in Chapter 7.
2.5.2 Enterprise Services
In enterprise computing environments, the functionality of application systems can be described and provided by services. Figure 2.22 visualizes a service- enabled application system. The functionality of the application system is provided through services, depicted by semicircles on top of the application system. Services need to be specified in a way that the specification of services
OS DBMS ERP System ERP Enterprise
Services
ERP Database
Fig. 2.22.Service-enabled application system
is decoupled from their implementation. Detailed specification of services fa- cilitates the flexible configuration of services by composing services to achieve complex functionality.
In an existing application built with several services provided by different business partners, the partners can modify the realization of their services, as long as the service specification does not change. Based on the service speci- fication, an improved service implementation can be integrated seamlessly in a service-based application. New potential business partners can use publicly available service specifications to offer their own implementations of the ser- vices. As a result, individual parts of a complex service-based application can be exchanged without redesigning the application.
Service orientation is also one of the main influencing factors for enterprise application integration. Enterprise services architecture characterizes the de- velopment of added-value applications that take advantage of existing func- tionality provided through standardized interfaces.
Enterprise services architecture is based on the understanding that com- plex applications will be increasingly built on top of existing functionality.
This functionality is provided by legacy systems, which are an important as- set of companies. Making this functionality reusable is a challenging task. The idea is to encapsulate the functionality of existing software systems in a ser- vice, realizing enterprise services. Enterprise services can be used to realize enterprise application integration scenarios.
As pointed out by Woods, there are a number of business drivers that foster the development of enterprise services. The main driver is change: the ability to change the enterprise application system infrastructure is a compet- itive advantage for an enterprise. There are a number of current trends that motivate the development of enterprise services:
• Rise in the power of the customer: Value-added services are essential, be- cause customers can change suppliers easily, without much effort. Positive user experience is important, as the success of online auctioning sites and online shops with community building indicates.
• Systems transparency: The Internet has brought customers and suppliers inside a company’s IT infrastructure. Weak or missing integration of en- terprise application systems will be immediately exposed to the customer.
• Rise in computer mediated interaction with customers and suppliers: Com- panies differentiate themselves on their service to their customers. Dan Woods indicates that “Outsiders can now peer into the glass house of the data centre and see if it is a mess.” An example of a messy situation is one where a customer cannot be serviced well, because the client inter- face provides information only about one aspect of the customer, and the other aspects are hidden in application systems that are not accessible.
Due to lack of integration, this valuable information is not available, so the customer does not feel well cared for.
• Products as services: Corporations are increasingly perceived by the set of services they provide. These services exposed to the market can be realized by enterprise services, which provided by the back end application systems of the enterprise. But also services provided by third parties can be integrated, so that better applications and end user services can be provided to the customer.
• Multi-tier applications: There is also a trend towards multi-tier applica- tions, where each tier is provided by a different enterprise. This means that the tier 1 company provides value-added services directly to a customer, using the tier 2 services from a set of business partner companies. These companies might use tier 3 services provided by other companies. By flexi- ble integration based on the service paradigm, many new applications and services can be realized.
Composite Service-Based Applications
With this background in enterprise services architectures, an intra-company scenario is sketched, where new applications should be built on top of an exist- ing customer relationship management system, a supply chain management system, and an enterprise resource planning system. These systems expose enterprise services via standardized interfaces. The applications built on top are known as composite applications, as shown in Figure 2.23. Composite applications invoke enterprise services that provide the functionality of the underlying back-end systems. User interaction is realized by dedicated graph- ical user interfaces that sit on top of composite applications.
Technological advance has paved the way for enterprise services. The main cornerstones of these developments are the full suites of enterprise applica- tions that are available off-the-shelf today. There are rich middleware and enterprise application integration products that can be used for technical in- tegration, most of which host a dedicated workflow component for process enactment. To integrate multiple application systems, data transformation is essential. With the advent of the extensible markup language (XML), there is an industry standard for data and message format specifications. While this
OS DBMS Composite Application 1
OS DBMS
OS DBMS Composite
Application 2
Composite Application 3
CRM System SCM System ERP System
CRM Enterprise Services
SCM Enterprise Services
ERP Enterprise Services
Fig. 2.23.Enterprise systems expose functionality through enterprise services
base technology is in place, the integration logic still needs to be defined and implemented in each integration project.
As shown in Figure 2.23, applications that use the functionality of existing application systems are called composite applications. Processes are a key factor in realizing composite applications, because they provide a link from high-level business processes to the information technology layer.
The structure of composite applications can in many cases be expressed as a business process. The activities of these processes are implemented by invoking enterprise services. Additional execution constraints like conditional execution can be represented by business process models; these can be realized by process orchestrations.
Enterprise services can also be used to realize business interactions of mul- tiple enterprises. In multi-tier scenarios for realizing innovative applications, interactions between the software systems of the business partners involved are required. These interactions are governed by a process choreography. Process choreographies have been defined informally above; they are subject of further investigation in Chapter 5.
While the vision for enterprise services includes business-to-business pro- cesses, most enterprise services today are used in an intra-company setting, where the goal is to develop composite applications on top of well-specified business functionality represented by enterprise services.
Enterprise Services and Service-Oriented Architectures
The roles in service-oriented architectures as discussed above are not com- pletely filled in typical enterprise scenarios. The specification of services is
typically done by the provider of the service, i.e., by the system architects responsible for service-enabling the particular application.
The service registry is installed locally, and its access by other companies is usually disallowed. The most striking difference to service-oriented archi- tectures as defined by Burbeck is the absence of dynamic matchmaking. As enterprise services are developed, they are specified and registered in a local registry. When a new composite application is developed, the designers con- sult the registry to find suitable services that can be used to perform certain tasks in the composite application. This search is a manual process, which in some cases is assisted by a taxonomy and a textual description of the services.
There are a number of hard problems in this context that are unsolved today. One of the main problems regards the scoping of services: the func- tionality provided by one or more application systems that is suitable for an enterprise service. If the granularity is small, then the level of reuse is small too, because many enterprise services need to be composed to achieve the desired functionality.
If on the other hand the granularity is large, then there might be only few scenarios where the enterprise service fits well and where using it makes sense. Tailoring of services of large granularity is also not a valid option, since extensive tailoring hampers reuse. As in many related cases, there is no general answer to this question. The choice of a suitable service granularity depends on the particular usage scenario and on the properties of the application systems to integrate and the composite applications to develop.
In enterprise services architectures, each enterprise service is typically as- sociated with exactly one application system. This is a limitation, since build- ing an enterprise service on top of a number of related back-end application systems involves system integration, so that reuse is simplified.
To illustrate this concept, an example is introduced. Consider a purchase order enterprise service in which an incoming purchase order needs to be stored in multiple back-end application systems. In this case, the enterprise service can be used with ease, since it is invoked once by a composite application and it automatically provides the integration of the back-end system by storing the purchase order—with the relevant data mappings to cater to data type heterogeneity—in the respective back-end application systems.
An integration of legacy systems can be realized within an enterprise ser- vice. This allows using enterprise services at a higher level of granularity, so that integration work can actually be reused in multiple composite applica- tions.
2.5.3 Enterprise Services Bus
In a recent development, enterprise application integration middleware pro- vides standardized software interfaces to the enterprise applications that it integrates. As the term enterprise service bus indicates, each of these enter-
prise applications is then attached to this bus, which acts as a centralized component to integrate these applications, as shown in Figure 2.24.
ERP System CRM System SCM System
Inventory Management Data Warehouse Human Resources
Application Enterprise Service Bus
Fig. 2.24. Enterprise service bus
An enterprise service bus hides the heterogeneity of the enterprise appli- cations by introducing service interfaces. To realize these service interfaces, traditional enterprise application integration adapter technology is typically used that is also in place in traditional enterprise application integration mid- dleware, as discussed in Section 2.2.2.
By introducing standardized interfaces to the outside world using services, however, an enterprise service bus goes one step beyond traditional enterprise application integration middleware. It must not be overlooked, however, that the term enterprise service bus is also used by software vendors to rebrand existing technologies for marketing reasons.
2.5.4 Service Composition
To realize composite applications in service-oriented enterprise computing en- vironments, service composition techniques are appropriate. The general prin- ciple of service composition is depicted in Figure 2.25, where application sys- tems in the lower part of the figure represent services that can be used to realize composite applications.
The composite application shown uses functionality provided by a CRM system, an SCM system, and an ERP system. The application logic realized in the composite application defines a process consisting of three activities.
The ordering of these activities can be specified in a process model.
Since the business process is realized by a composition of services, processes of this kind are also called service compositions. The service composition shown in Figure 2.25 realizes a business process that can be embedded in a composite application, which adds a graphical user interface to the service layer.
Enterprise application integration middleware in general and enterprise service bus middleware in particular provide a good technical basis to realize
SCM System
CRM System ERP System
Composite Application
Get Customer Status
Plan Customer Inventory
Store Customer Data
Fig. 2.25.Using service composition to realize composite applications
service compositions, because they provide standardized services interfaces that can be used in service compositions. Typical enterprise application inte- gration middleware features a system workflow component that uses either a proprietary format for system workflows or, if it is based on services, the Busi- ness Process Execution Language for Web services, discussed in Chapter 7.