Business Process Management (Part-1 Foundation[Chapter II Evolution of Enterprise Systems Architectures ] ) Sec M -- By Mathias Weske

Enterprise Services and Service-Oriented Architectures


The roles in service-oriented architectures as discussed above are not completely
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 architectures
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 consult
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 functionality
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 associated
with exactly one application system. This is a limitation, since building
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 service.
This allows using enterprise services at a higher level of granularity, so
that integration work can actually be reused in multiple composite applications.


Enterprise Services Bus


In a recent development, enterprise application integration middleware provides
standardized software interfaces to the enterprise applications that it
integrates. As the term enterprise service bus indicates, each of these enterprise applications is then attached to this bus, which acts as a centralized component to integrate these applications
An enterprise service bus hides the heterogeneity of the enterprise applications
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 middleware,
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.

Service Composition


To realize composite applications in service-oriented enterprise computing environments,
service composition techniques are appropriate. The general principle
of service composition is depicted in Figure 2.25, where application systems
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.
Enterprise application integration middleware in general and enterprise
service bus middleware in particular provide a good technical basis to realize
service compositions, because they provide standardized services interfaces
that can be used in service compositions. Typical enterprise application integration
middleware features a system workflow component that uses either a
proprietary format for system workflows or, if it is based on services, the Business
Process Execution Language for Web services.