Manners Externalize Service Semantics for Automated
Service Composition Ali Arsanjani IBM Global Services, Maharishi University of
Management aarsanjani@acm.org Francisco Curbera IBM Research curbera@us.ibm.com
Nirmal Mukhi IBM Research mukhi@us.ibm.com ABSTRACT Architectural mismatch can
be alleviated through the ubiquity of the protocols for service composition
(syntax); yet the semantics remain elusive. We suggest the use of manners for
explicit service semantics representation in a re-configurable architectural
style. We describe the base requirements for automated component and services
composition and show how automated assembly of components and services can be
accomplished through a dynamically re-configurable (DyRec) architectural style.
We show how this vision of dynamic reconfiguration is naturally supported by the
Web services framework, because it derives from some of the core requirements of
the Service Oriented Architectures (SOA) style embodied by Web services.
Further, we discuss how such a DyRec architectural style can be implemented
using grammar-oriented object design (GOOD) and describe a project that led to a
tool called the Business Compiler, to accomplish dynamic composition and
collaboration. Keywords Manners, service composition, service-oriented
architecture, component-based software engineering, Grammar-oriented object
design, context-aware components, on-demand computing, dynamically
reconfigurable software architecture. 1. INTRODUCTION Business agility is
achieved through a business model that supports rapid response to changes inside
and outside an organization. Such business models require the support of a
software enterprise architecture that absorbs and allows dynamic alterations and
enhancements to applications. Cost-effective and timely alternations are
typically feasible when they do not rely on intrusive changes; as such changes
typically introduce architectural entropy and side-effects to the application
and runtime architecture of the applications, making the architecture more
brittle with every unanticipated change. We propose that a dynamically
re-configurable architectural style is required to realize these rapid changes
in business needs and quality of service (QoS) to support an enterprise’s
systems and applications. We will show how the web services set of standards is
already defining a framework in which dynamic reconfiguration is enabled as a
first class characteristic of network applications. In this dynamic environment,
an automated assembly-oriented paradigm, one of dynamic composition, is needed
to augment current component-based software engineering practice. The
elusiveness of dynamic composition arises from the fact that manual composition
has not yet been realized on the orders of magnitude of productivity that were
envisioned [13]. Part of the problem has been the lack of ubiquitous standards
in additional to the lack of general availability of commercial components to
meet the wide spectrum of functional and extra-functional requirements. 2.
Service-oriented Architecture This dynamic composition paradigm is already
emerging in response to a shift in the way enterprises conduct their business.
Vertically integrated enterprises are being replaced by networked ones which
rely on other businesses to provide them with services. As a consequence, IT
infrastructures in which every application used is managed by a single
enterprise are being replaced by networks of applications owned and managed by
many business partners. Basic enablers of this transformation are a pervasive
networking infrastructure and a set of standard protocols. The Service Oriented
Computing (SOC) paradigm aims at recognizing this new computing environment and
enabling a fully automated integration of diverse software applications and
processes. We summarize the assumptions of the SOC model as follows: 1. Services
are software applications that must be able to operate in a natively
cross-organizational setting. Applications may access services owned by
different, autonomous enterprises, and which may be deployed across the Web
using heterogeneous system environments. 2. Service interaction fundamentally
relies on a set of open standards that provide universal interoperability at the
middleware level. Industry-specific, business level interoperability and
semantics will gradually be Permission to make digital or hard copies of all or
part of this work for personal or classroom use is granted without fee provided
that copies are not made or distributed for profit or commercial advantage and
that copies bear this notice and the full citation on the first page. To copy
otherwise, or republish, to post on servers or to redistribute to lists,
requires prior specific permission and/or a fee. Conference ’00, Month 1-2,
2000, City, State. Copyright 2004 IEEE. developed. In other words, the technical
barriers to cross-enterprise interaction have disappeared. 3. The interaction
between services is naturally conversational, or peer-to-peer, and loosely
coupled. Loosely-coupled services combine traditional decoupled messaging-style
interactions (data-exchange) with the explicit application contracts of
tighter-coupled (interface-driven) object-oriented interaction styles. 4.
Services declaratively define their functionality and Quality-of-Service (QoS)
requirements and capabilities in a standard, machine readable format, enabling
dynamic (runtime) and automated service discovery and use. In particular, no
out-of-band or implicit assumptions about service implementations (including
their local middleware use and execution environment) are acceptable, since they
would compromise interoperability. 5. Service composition is at the core of the
application development task. Applications are created by combining the basic
building blocks provided by other services according to certain a business
logic. Service compositions may themselves become services, following a model of
recursive service composition. Particularly relevant to this paper is the
component oriented aspect of the SOC model. Because of the lack of centralized
control, the encapsulation of function in service components becomes
unavoidable; at the same time, the interoperability requirement demands not only
standardized access protocols, but also standard service (component) description
languages able to represent service capabilities and behavoior in a machine
readable format. We claim that this characteristics naturally make SOC a
component oriented paradigm. SOC, realized in the Web services framework,
presents a new face to the CBSE effort. In this paradigm a service provider
publishes a service which may later be found by a service consumer attempting to
find a service. When a match is found, the service description is used to
directly bind and later invoke the service. However, the ability to find a
service is seldom sufficient to support a business process’ use-case goal;
rather an orchestration of services is often required to accomplish anything of
value to the underlying business. Service orchestration is a common term used
for describing the task of service composition.. Often, orchestration is done
statically. The ability to perform dynamic orchestration will become a
centerpiece of a dynamic enterprise architecture. In addition, the ability to
syntactically find and bind to compatible services or components in no way
guarantees that the composed whole will satisfy the semantics of the domain in
the form of functional and extra-functional requirements. Garlan et al., point
out, that there are “a variety of types of mismatch that center around the
assumptions a reusable part makes about the structure of the application in
which is to appear” [1], including programming language, data model and
architectural mismatches. Extending Parnas’ notion of encapsulating design
decisions to achieve units of composition [2], Arsanjani et al., have suggested
the externalization of this composition through the notion of manners and
context-aware software components, to achieve a dynamically re-configurable
architectural style [3]. As it turns out, this form externalization can be
achieved in the Web services framework, and is a natural consequence of the SOC
assumptions we have just discussed. The basic characteristics for a
service-oriented architecture (SOC) thus form the base requirements for a
dynamic architecture; reconfigurability criterion needs additional
characteristics which shall be outlined below. 2.1 Service Composition It is
first necessary to distinguish between computation and composition and
collaboration. Computations are the fine grained activities performed by using
general purpose programming languages (such as Java or C#) that typically
include mathematical calculations, Boolean evaluations and performance of
functions based on these evaluations. Composition languages such as Piccola [8]
aim at a small syntax with the aim of component assembly. Collaborations are
defined by flows (BPEL4WS or DAML-S, for example) which may be workflows or
other forms of purposeful integration of component behavior to achieve a
collective goal; for example, for supporting a business. 2.2 Re-configurability
Run-Time and Dynamic Re-configuration are characterized by the ability of
underlying software architectures to rapidly respond and dynamically alter the
functionalities of its components and services as well as the interconnection
between them to suit the problem, and then re-configure necessary
extra-functional aspects to maintain QoS and service level agreements (SLA).
Practical considerations of performance, security and interoperability make
these models currently difficult to realize although the advent of Web services
standards in these areas are promising to alleviate many of the problems. The
above characteristics have been researched to a large extent within
hardware-related systems [27, 28, 29]. We would like to extend this to software
systems and architectures. But in order to do so, we cannot take the paradigm
and use it as is, from the hardware world; software components and services are
not, despite common (mis)conception, “lego™”-like building blocks; but rather
are more like organs in the body which are larger conglomerations of more minute
components and provide a distinct function and goal within a context. They also
exhibit a certain degree of resilience to changes in their functional and
extra-functional capabilities. Thus, the re-configurability of software services
and components is key. We maintain that this is achievable by exploiting Web
services standards and applying novel methods through methods and techniques for
composition such as grammar-oriented object design (GOOD). 2.3 The Web Services
Framework The Web Services framework consists of a set of open standards, being
defined by organizations such as the W3C and OASIS, that collectively act as a
realization of the SOC paradigm. . Currently many of the specifications are just
proposals or recommendations, but are on the path to standardization and have
broad industry support. It is important to note that the framework is not
predicated on any software, hardware or networking platform. Standards-based
integration and composition of services promises the broadest reach and
satisfies assumption (2) of the SOC model. At the base level, the standards
consist of a set of communication protocols. In principle, the framework allows
any standard protocol to be used. However, SOAP, an XML-based protocol, is the
most widely used. The availability of XML parsers and SOAP implementations for a
variety of platforms guarantees that data can be exchanged in a
platform-independent manner. Applications owned by autonomic enterprises,
deployed in heterogeneous systems, can thus communicate in a standard way using
SOAP. This satisfies assumption (1) of the SOC model. Standards for security,
reliability, transactions and QoS are defined over these base communication
protocols. These are defined up front in a platform-independent manner as well,
so there can be no underlying assumptions about the platform support, as
described in assumption (4) of our SOC model. Currently there are a variety of
competing specifications in this space. Service descriptions are defined using
WSDL, the Web Services Description Language. This language supports the
description of many different kinds of interactions – message-driven,
asynchronous, or interface driven and synchronous. WSDL can act as a normalized
description of many kinds of software, enabling them to be exposed as Web
Services with minimum effort. WSDL descriptions are also the unit of service
composition in the Web Services framework. The service description includes the
abstract description of the service interface and the types of the data
exchanged. This abstract description is then realized through a binding, which
describes how the required message exchanges can take place according to a
specific protocol such as SOAP. The loose coupling between the service
description and its implementation satisfies assumption (3) of our SOC model.
Finally, WSDL allows description of specific deployments of a service as well.
WS-Policy defines an abstract framework for applying defining various kinds of
policies related to a service. Other specifications will define domain-specific
policies that can be declared in Web service descriptions. The WS-Security and
WS-Transactions proposals for example define specific policies within the
framework defined by the WS-Policy specification. UDDI and WS-Inspection are
proposals that allow the publication and discovery of information related to
services, enabling dynamic lookup and binding. BPEL4WS is the dominant Web
Services specification in the domain of service composition. It defines
interactions between services at their abstract interface level, as defined in
WSDL. These interactions can be conversational or peer-to-peer. The actual
protocol, data format, etc. used are of no concern to the modeler. Compositions
can themselves be exposed via WSDL as services. This specification covers
assumption (5) of our SOC model, and the Web services framework allows
alternative specifications to be used as well. 3. The Dimensions of a
Reconfigurable Architectural Style We distinguish here three levels at which an
a componentized architecture can be dynamically reconfigured. 1. Dynamic
component reconfiguration. Individual components, the basic building blocks of
the composition, can externalize those aspects of their behavior that are allow
run-time or assembly time reconfiguration. We refer to theses aspects as the
Configurable Profile of the component. 2. Automated component assembly. The
selection of runtime components that form part of an executable composition can
be performed at runtime, based on specific deployment and runtime considerations
(such as execution context data, user choices, etc.) 3. Automatic composition.
Based on a set of high level goals or business rules, a new composition model is
generated or existing compositions are modified, at development or, more
interestingly, at run-time. 3.1 Dynamic Component Reconfiguration In the
beginning there were requirements; for applications and systems. Changes needed
to meet new requirements of functionality and quality of service
(extra-functional requirements) may be accomplished in two broad categories:
intrusive and non-intrusive. Intrusive changes are notorious for project failure
as cycle times of re-design, re-implementation, testing and deployment often
exceed budgetary and time scale requirements. Non-intrusive changes can be more
efficiently incorporated using variation-oriented design (VOD); involving the
encapsulation of design decisions and aspects of the application or system that
tend to vary. VOD involves a process of externalization of variant aspects [25];
often into a Configurable Profile (CP). Generally, the CP holds two types of
characteristics: functional and extrafunctional. The functional aspect is itself
divided into the aspects of business architecture (BA) and application
architectures (AA). The BA aspect deals with the flow of the application
corresponding to the business processes and how they operate. The AA aspect
deals with the functional components and services required to fulfill the BA.
The extra-functional aspects define the QoS characteristics of the architecture
or large-grained component owning the CP. Thus, the general principle is that
each architectural element (composite component at what ever level of
granularity we are focused on) externalizes their variant aspects into a CP.
Externalization is a design-time or refactoring –time activity whereby
variations are encapsulated and a description of the axes of variation of a
component are externalized into a Configurable profile (CP). A component offers
interfaces, abides by contracts and has manners. The manners of the
architectural component are contained in the CP [4]. The composition of
components is SOAP (Logical Messaging) Messaging WSDL Quality of Service
Transactions BPEL4WS XML, Encoding Other protocols Reliable Messaging Security
Description Discovery Discovery WS-Policy UDDI, Inspection Composition
accomplished by wiring the ports and connectors of the component into a set of
collaborating elements. The automation of the composition process introduces
interesting new requirements which will be discussed in its corresponding
section below. The dynamic re-configuration of an architectural component
therefore consists of a) selecting an appropriate level of granularity which
encompasses all necessary elements, b) changing the manners of the component by
applying the necessary changes to its CP from both functional and operational
(extrafunctional) aspects. There at least two main scenarios in which a CP can
be used to achieve reconfiguration of a component. A particular component manner
may be explicitly selected in components that provide an explicit
reconfiguration interface; in the simplest case, a “setManner()” operaton may be
made available by the component. More often, however, component manners would be
automatically selected based on the execution context associated with component
interactions. That is, the presence or absence of particular fields in the
execution context passed to the component will trigger a (re-)configuration of
the component; an example would be how the presence of a specific transactional
context allows the component to understand the type of transaction protocol in
which it is expected to participate. 3.1.1 Support for Dynamic Reconfiguration
in the Web Services Framework Driven by the need for explicit, declarative
descriptions of service functional and extra-functional behavior, typical of
service oriented architectures, the Web services framework is developing a set
of mechanisms that allow the encoding of both fixed and configurable
characteristics of a service in a standard, machine readable format. WSDL
service descriptions capture functional and protocol characteristics of a
service, while Web services policies provide descriptions of non-functional and
business behaviors. At the protocol level, a core notion in WSDL is the ability
to offer service functionality over multiple protocols; it is up to the service
user to decide what the most appropriate protocol is by selecting among a set of
alternative “ports”. WS-Policy, on the other hand provides a simple architecture
in which the different extrafunctional behaviors supported by a service
component can be externalized and combined using basic Boolean connectors.
Alternative authentication schemes, the set of business rules followed, or all
the supported transactional protocols are simple examples of the type of
policies that can be attached to a service component. Explicit representation of
the execution context data that a component may receive and process has been
proposed in [WSContext]. WS-Context extends WSDL to allow the representation of
middleware information exchanged in an interaction. Context variables can then
be used as preconditions that support (and trigger) specific service
capabilities; to make this capability explicit, service policies declaratively
encoded using the WSPolicy mechanism, identify context variables supported,
required or accepted by the service as trigger of specific middleware or
business capabilities. 3.2 Component Assembly The first attempts for component
assembly have been at best theoretically prescriptive [30] and without the
benefit of automation, including the ability to hardwire component connectors to
ports. In distributed environments, some form of registry must be accessed that
will return a “handle” or reference to a designated object or component. Using
that reference, components are statically bound to each other in a static
composition using a general purpose programming language, such as Java. This
signifies that interface and implementation separation was merely at design
time. During run-time, the two aspects merged to be indistinguishable: i.e.,
interface and implementation cannot be distinguished at run-time. The
implication of this implicit run-time indistinguishability was that certain
tacit underlying protocols (HTTP, SMTP, TCP/IP or proprietary protocols) had to
be present on client and server machines. The flexibility to decide what
protocol to bind to was not a run-time decision. Thus, anonymous or automated
composition between ad hoc parties was not an option. With the advent of
service-oriented architecture, however, static binding that resulted in merging
of interface and implementation was relaxed and a WSDL [20] description
(interface) was used to find and bind to a service whose implementation could
thus be determined at runtime. Thus, the two aspects of interface/implementation
separation were implemented in a standardized, ubiquitous fashion. In addition,
a third aspect of separation of concerns was introduced due to the distributed
nature of web services; namely, protocol separation. Thus, the binding of the
implementation to a given transport or messaging protocol was deferred using the
WSIF standard [18], until run-time, where the most appropriate protocol may be
determined in real-time. Automated Component Assembly must pass through four
levels of compatibility determination before assembly of components, namely:
interface (syntax) , functional (semantic), operational (extra-functional or
QoS) and contextual (group and goal oriented semantics). In order to find a
functional /semantic match for a service consumer’s request, a “matchmaking”
engine or service is necessary to augment the UDDI “yellow pages” notion of
service registration. Explicit, publicly registered component descriptions that
include component configuration profiles play an important role in supporting
the selection and assembly time configuration of service components. 3.3
Requirements for Automated Component and Services Composition Service
orchestration refers to the assembly of loosely coupled components and the
coordination of multiple asynchronous conversations over coarse-grain
communication protocols. Implementing orchestration logic in an application
produces a consistent set of technical infrastructure requirements, such as
managing non-linear state and long-lived application context, supporting
parallel activities and sophisticated join patterns, handling exceptions and
events generated by local and remote components, compensating for failed or
cancelled business transactions, and graceful upgrading and management of
application functionality. The BPEL4WS specification defines a language with an
XML syntax for describing service compositions, called processes. The BPEL4WS
process itself is basically a flow-chart like expression of an algorithm. Each
step in the process is called an activity. There are a collection of primitive
activities: invoking an operation on some Web service (