Pattern Based SOA Deployment

Abstract

A key function of a Service Oriented Architecture is the separation between business logic and the platform of its implementation
and deployment. Much of the focus in SOA research has been on service design, implementation, composition, and placement.
In this paper we address the challenge of configuring the hosting infrastructure for SOA service deployment. The functional
and non-functional requirements of services impose constraints on the configuration of their containers at different levels.
Presently, such requirements are captured in informal documents, making service deployment a slow, expensive, and error-prone
process. In this paper, we introduce a novel approach to formally capturing service deployment best-practices as model-based
patterns. Deployment patterns capture the structure of a solution, without bindings to specific resource instances. They can
be defined at different levels of abstraction supporting reuse, and role-based iterative refinement and composition. We show
how we extended an existing model driven deployment platform to support pattern based deployment. We formally define pattern
semantics, validation, and refinement. We also present an algorithm for automatically instantiating such patterns on multiple
distributed service environments. Our approach has been verified in a large prototype that has been used to capture a variety
of functional and non-functional deployment constraints, and demonstrate their end-to-end maintenance and realization.

Full text

Page 1

Pattern Based SOA Deployment
William Arnold, Tamar Eilam, Michael Kalantar, Alexander V. Konstantinou,
and Alexander A. Totok
IBM T.J. Watson Research Center, Hawthorne, NY, USA
{barnold, eilamt, kalantar, avk, aatotok}@us.ibm.com
Abstract. A key function of a Service Oriented Architecture is the sep-
aration between business logic and the platform of its implementation
and deployment. Much of the focus in SOA research has been on service
design, implementation, composition, and placement. In this paper we
address the challenge of configuring the hosting infrastructure for SOA
service deployment. The functional and non-functional requirements of
services impose constraints on the configuration of their containers at dif-
ferent levels. Presently, such requirements are captured in informal doc-
uments, making service deployment a slow, expensive, and error-prone
process. In this paper, we introduce a novel approach to formally captur-
ing service deployment best-practices as model-based patterns. Deploy-
ment patterns capture the structure of a solution, without bindings to
specific resource instances. They can be defined at different levels of ab-
straction supporting reuse, and role-based iterative refinement and com-
position. We show how we extended an existing model driven deployment
platform to support pattern based deployment. We formally define pat-
tern semantics, validation, and refinement. We also present an algorithm
for automatically instantiating such patterns on multiple distributed ser-
vice environments. Our approach has been verified in a large prototype
that has been used to capture a variety of functional and non-functional
deployment constraints, and demonstrate their end-to-end maintenance
and realization.
1Introduction
Much of the focus in SOA research has been on service design, implementation,
composition, and placement [1]. In order to fully realize the promise of SOA, sim-
ilar attention must also be paid to the deployment, configuration, and runtime
management phases of the service life cycle. While SOA allows designers and
programmers to access business logic independent of implementation platform,
from the operator’s view the situation is the extreme opposite. SOA services
are typically implemented using standard distributed application platforms such
as J2EE, CORBA, and .NET, and are hosted on large middleware stacks with
complex configuration interdependencies. Deployment of SOA services, and the
composite applications that implement them, often involves creation of opera-
tional resources such as databases, messaging queues, and topics. The runtime
container of the service must then be configured to access these resources. Es-
tablishing access may require installation and configuration of client software,
B. Kr¨ amer, K.-J. Lin, and P. Narasimhan (Eds.): ICSOC 2007, LNCS 4749, pp. 1–12, 2007.
c ? Springer-Verlag Berlin Heidelberg 2007

Page 2

2W. Arnold et al.
security credentials, as well as network-level configuration. Deployers must assure
that all service resources have been correctly instantiated and configured, satis-
fying all functional and non-functional requirements. Cross cutting interdepen-
dencies and constraints make this a very challenging and error-prone task [2]. In
addition to the communication and hosting configuration challenge, SOA poses
additional challenges in transforming non-functional requirements and goals to
deployment solutions including configuration for security, availability, and per-
formance.
One approach to reducing the complexity of designing the deployment of ser-
vices is to capture common deployment patterns. Such patterns describe proven
solutions that exhibit certain non-functional properties. For example, experts
in WebSphere Process Server (WPS) have identified 12 best practices patterns
for WPS deployment [3]. Each pattern offers a different set of capabilities (high
availability, scalability, security) and supports classes of applications with dif-
ferent characteristics. Today, these SOA deployment patterns are still captured
informally in lengthy unstructured documents. Information about what com-
binations of products and versions are known to work must be looked up in
manuals and documents libraries. Tradeoffs between cost, availability, security,
scalability, and performance are investigated in an ad hoc fashion. There are no
models, methodology and tools to define, reuse, assemble, customize, validate,
and instantiate SOA deployment patterns.
In this paper we present a novel approach to capturing SOA deployment pat-
terns through formal methods, models, and tools. We use and extend a model-
driven deployment platform that we have previously presented in the context of
middleware[4] and network[5] configuration design, validation and deployment.
We present how we extend the platform with the ability to express model-based
patterns representing abstract deployment topologies. These models are used by
experts to capture the essential outline and requirements of a deployment so-
lution without specific resource bindings. We formally define the semantics and
validation of the realization of such abstract patterns. Using our deployment
platform, we enable non-expert users to safely compose and iteratively refine
such patterns to design a fully specified topology with bindings to specific re-
sources. The resulting desired state topology can be validated as satisfying the
functional service requirements, while maintaining the non-functional properties
of the pattern. We also show how automatic resource binding can be introduced
to reduce the steps required to reach a valid and complete deployment topology.
The desired state of the complete deployment topology can then be provisioned
automatically by generating a one-time workflow as we presented in [6].
The paper is structured as follows. In Section 2, we describe our deploy
platform resource model, architecture and concepts. In Section 3, we present
our novel pattern modeling constructs, their semantics and validation. We also
present an algorithm to automate the instantiation of patterns over an existing
infrastructure. Section 4 covers related work. Finally, we conclude with a brief
discussion of our prototype implementation and on-going work.

Page 3

Pattern Based SOA Deployment3
2Deployment Platform
Our model-driven SOA deployment platform supports the construction of desired
deployment state models that are complete, correct, and actionable. These mod-
els include detailed software stacks and configuration [4,5]. They are consumed
by provisioning automation technologies [7] to drive automated provisioning [6].
The deployment platform is built on a core configuration meta-model, and ex-
poses a number of services for model extension, validation, problem resolution,
resource discovery, query, and provisioning.
2.1Core Configuration Meta-model
The core model captures common aspects of deployment configuration syntax,
structure and semantics. Core types are extended to capture domain-specific
information. Domain objects and links are instantiated in a Topology which is
used to design the desired state of the infrastructure after deployment. The Unit
core type represents a unit of deployment. A Topology contains Unit instances
that may represent resources that are already installed, or ones that are to be in-
stalled. The install state of a unit is a tuple (init,desired) representing the install
state of the unit when it was provided to the topology, and its state after pub-
lishing. The values of init and desired can be one of {uninstalled,installed}.
Installable Units, may be associated with one or more Artifacts. A Unit may
also represent a configuration node, such as J2EE data source, in a hierarchi-
cal structure (current or desired). A Unit can contain any number of Capability
instances. Subtypes of Capability group domain-specific configuration attributes
by function. The relationships of a Unit with other Units are expressed through
containment of Requirement objects. The core model defines three types of rela-
tionships: hosting, dependency, and membership. Each Requirement is associated
with one of these types. Relationships are represented using a Link association
class. All these types extend a common DeployObject super-type. All DeployOb-
ject can be associated with any number of Constraint instances. The semantics
and validation of a Constraint are defined by the subtypes extending it. The con-
text of Constraint evaluation is the object on which it is defined. In the case of a
Constraint contained in a Requirement, the constraint context is the target of the
requirement link. This allows users to define constraints that must be satisfied
by the resource at the other end of a relationship. Figure 1 outlines a deploy-
ment Topology instance model example. The topology captures the deployment
of a new J2EE Enterprise Application (EAR) on an existing IBM WebSphere
Application Server (WAS), using a pre-configured J2EE data-source. We have
similarly defined extension schemas and instance models for a variety of other
product domains and vendors.
2.2Deploy Platform Architecture
The overall architecture of our model-based SOA deployment platform is de-
picted in Figure 2. At its base lies the core configuration model, on top of which

Page 4

4W. Arnold et al.
<<Unit>
EarUnit
state = {uninstalled, installed}
<<Requirement>>
J2eeDatasource
type=dependency
<<Requirement>>
J2eeContainer
type=hosting
<<Unit>>
Was6Unit
state={installed, installed}
<<Capability>>
J2eeContainer
version=1.4
<<Capability>>
WasServer
version=6.0
Hosting Link
<<Unit>
Db2DataSourceUnit
configurationUnit = true
state={installed, installed}
<<Capability>>
WasV6DataSource
jndiName=“jdbc.plants”
Dependency Link
<<Requirement>>
WindowsOS
type=hosting
<<Requirement>>
WasServer
type=hosting
version >= 6
Hosting Link
<<Capability>>
WebService
<<Artifact>>
file=plants.ear
jndiName=“jdbc:plants”version >= 1.4
version >= 5.1
collocate=J2eeContainer
Fig.1. Topology instance example modeling the deployment of a J2EE Application
a number of extensible services are supported. The platform defines the deploy-
ment service interfaces and provides the managers for registering extensions.
The Domain Service is used to extend the core model types in domain-specific
schemas. The Validation Service is used by domain authors to inject semantic
validation logic. An example validation rule may express that the database name
attribute of a J2EE datasource must match the actual name of the database on
which it depends. The validation service invokes the validation rules when types
from the domains with which they are associated are instantiated or changed.
Validation rules generate semantically rich status errors markers. These error
markers identify the areas in the model that violate a registered validation rule.
The Resolution Service is used to declare logic for fixing the errors underly-
ing the markers generated by validators. For example, in the earlier datasource
database name validation example, a resolution may be declared to propagate
the name of the database to all of the datasources that have a dependency rela-
tionship to it. For a given error status, the resolution service can be queried to
provide the list of possible resolution actions. These resolutions can be invoked,
either manually or programmatically, to modify the model. The core platform is
packaged together with a core set of Constraints, Requirements, and an accom-
panying set of core validation and resolution rules. The Provider Service is used
to discover and query configuration repositories (e.g. CMDBs), so that units that
represent existing resources can be discovered and incorporated in deployment
topologies. The Publisher Service is used to register provisioning agents whose
role is to configure the infrastructure to match the desired state expressed in
the topology. Finally, the platform supports a Core Editor which is a standard
graphical interface for creating and editing topologies. The editor interfaces with
the existing platform services for resource discovery, topology validation, error
resolution, and publishing.

Page 5

Pattern Based SOA Deployment5
Core Model
Core Editor
Validation
Service
Domain
Service
Provider
Service
Publisher
Service
Resolution
Service
Fig.2. Deployment Platform Extension Architecture
2.3Valid Deployment Models
Users construct deployment models by adding or modifying units, and by execut-
ing resolution rules. The goal is to reach complete and valid deployment topolo-
gies that do not contain any error markers. A topology is validated against a set
of core validation rules, a set of domain-specific type-level rules, and the con-
straints associated at the object instance level. The core validation rules check
the cardinality of the topology links, as well as the type and configuration of
their endpoints. Domain-specific validation rules can be expressed at the type
level, to apply to all instances, or at the instance level as constraints. Formally,
we say that a topology T is valid w.r.t. a given set of validation rules V iff (1)
all core link validation rules are satisfied, (2) all type-level validation rules v ∈ V
evaluate to true on any object u ∈ T, and (3) all constraints on topology objects
evaluate to true in the context of their evaluation. Recall that for a constraint
defined in a capability the evaluation context is the capability’s attribute set,
while for a constraint defined in a requirement the context is the target of the
relationship (and its contained capabilities). The logic for evaluating constraints
is itself extensible.
3Pattern Platform
A common requirement across different SOA deployments is the ability to de-
scribe a deployment topology at various levels of abstraction. At a base level
of abstraction, the topology may represent a fully defined deployment struc-
ture that is only missing the relationships to the specific resources on to which
it will be deployed. At higher levels of abstraction, the topology may partially
specify the configuration of resources, focusing on key parameters and structures,
while leaving others to be determined at deployment time. The deployment plat-
form described in the previous section is well suited for modeling the concrete
desired state of services, components, and their relationships that are directly
mappable to native configuration models. In this section, we describe how we
extend the deployment platform to support abstract models, termed patterns.
As depicted in Figure 3, pattern models are defined by experts using a rich de-
sign tool and instantiated by deployers, potentially using a simple installation
wizard for resource and parameter selection. First, we describe the modeling
extensions, including structural constraints, virtual units, and realization links.
Then we describe how we use views to execute the original set of validation rules