SOA Service Design

This is draft content of SOA Enterprise PatternsServices, Orchestration and
Beyond by Dragos Manolescu and Boris Lublinsky, to be published by MorganKaufmann Publishers in 2007. You can find more information about the book
in the About section of the Web site (http://orchestrationpatterns.com/
about).
We are making this draft available for comments. Heres what you can do if youd
like to get involved:
PY
Visit the Web site http://orchestrationpatterns.com/ for additional

drafts.
CO
Send feedback on the material you read. Try to answer the following questions: Do the patterns convince you about the Problem? Are there any other
important Forces? Is the Solution clear to the extent that you can now solve
the problem? Do you know of other Known Uses for these patters? Are we
missing any Related Patterns?
What would make the pattern better?
FT
What other aspects of SOA and Service Orchestration youd like to see covered in this book?
RA
There is also a Yahoo! group (orchestrationpatterns-book) for broadcasting

and discussing drafts. The drafts we send to the group also get posted on the Web
site. If drafts are all you care about then theres no need to subscribe to the group.
RA
FT
CO
PY
c 20042006 Dragos Manolescu and Boris Lublinsky

Copyright
http://orchestrationpatterns.com
PY
CHAPTER 2
CO
SERVICE-ORIENTED
ARCHITECTURE Defined
Why Service-Oriented Architecture?
FT
2.1
RA
Business and technical people alike are interested in Service-Oriented Architecture. Some are taking the Service-Oriented Architecture path because it allows
them to sharpen their value proposition. The service-oriented enterprise can focus
on its core competency, outsourcing the non-core competency functions to trading partners who offer higher quality at a lower price (i.e., rightsourcing). Others
are interested in Service-Oriented Architecture because of it moves software development away from the large vertical, regional office-driven projects. The service oriented approach shifts from the monolithic, command-and-control vertical
to small, opportunistic, business value-driven applications. There are many, many
other reasons behind the interest in Service-Oriented Architecture. Not all of them
are sound; some exploit the confusion and hype around this term. Theyve had
partial success. There are projects that went down this path only to be buzzwordcompliant.
What is Service-Oriented Architecture? Many people talk about it, yet there is lit3

Copyright
tle agreement of what this widely popular three letter acronym actually represents.
The many competing definitions in place make it hard to sort out its true essence.
SearchWebServices.com [sea] announced a contest for the best definition. They
received a slew of submissions and little chance of selecting the best one.
One of the main reasons why it is hard to define Service-Oriented Architecture is
because it means different things to different people [Bro05]:
PY
From the point of view of a business executive and business analyst, ServiceOriented Architecture is a set of services that constitute business IT assets
and can be exposed to their customers and partners, or other portions of the
organization
CO
From the point of view of an enterprise architect Service-Oriented Architecture is an architectural style that promotes the concepts of business processes and the orchestration of enterprise-level business services [LT03]. It
is also a set of architectural principles, patterns and criteria which address
characteristics such as modularity, encapsulation, loose coupling, separation of concerns, reuse, composability, etc.
FT
From the point of view of a project manager Service-Oriented Architecture

is a development approach supporting massive parallel development.
From the point of view of a tester and/or quality assurance engineer ServiceOriented Architecture represents a way to simplify overall system testing.
RA
From the point of view of a software developer Service-Oriented Architecture is a programming model complete with standards, tools and technologies such as Web Services.
2.2
Application-centric Architecture
There is one theme common to many of the Service-Oriented Architecture definitions which gets to its core: it is a way to decompose enterprise IT systems
into smaller, more manageable software artifacts called services. Through service
orchestration these services can be assembled to implement enterprise business
processes.
4
2.2. APPLICATION-CENTRIC ARCHITECTURE

Decomposition is a technique formalized by classical system theory in the late1950s. System theory stated that the more complex a system is, the more unknowns it contains and thus the harder it is to automate it. This theory prescribed
decomposing complex systems into smaller, more manageable ones, which are
easier to control and then treating the whole system as a composition of its parts.
The same applies to the complex software development initiatives.
PY
Decomposition represents one of the cornerstones of the good software engineering [Par72]. Architects and designers employ decomposition to influence many
architectural qualities.
Manageability Decomposition can split a complex problem into a set of a simpler ones, thus making the overall solution more manageable.
CO
Specialization Decomposition can promote the separation of concerns, leading to

design and implementation of specialized parts. This also allows for using
different tools (including programming languages) for different parts of the
system.
Testability Decomposition can promote the independent testing of each part, thus
simplifying overall system testing.
FT
Maintainability Decomposition can localize change, thus improving maintainability and decreasing the total cost of ownership (TCO).
RA
Development speed Decomposition can facilitate the parallel development of

parts, thus decreasing overall development time.
Reusability Decomposition opens up the possibility of reuse through the creation
of parts which can be used in multiple systems.
Evolution of Decomposition in Software
2.2.1
The first software decomposition approach (introduced in the early 1960s) was
splitting applications into separate jobs, each implemented by a separate program. Later, as more insight into the program internals was gained, each program
itself was split into modules or subroutines, according to their function.
The object-oriented paradigm introduced by Simula and Smalltalk in the 1970s
gave decomposition a big push by introducing objects: modules of code, each of

Copyright
PY
which implemented a model of a real thing. The idea was to represent in software
the things of the problem domain, for example customer, order, or trade.
However the abstractions provided by objects turned out to be too fine-grained and
intertwined with technical concepts to have a meaning on the business level. For
various reasons many object-oriented developers wound up spending most of their
time dealing with technical constructs such as collections, graphical widgets, and
so on. As a result, in most cases the objects of the problem domain disappeared
inside amorphous modules which no longer represented anything recognizable by
domain experts.
CO
In the continued search for a better design paradigm, a different approach to decomposition was introduced in the late 1990s: components. The idea was to fix
the problems of object-orientation by introducing a different abstraction, more
tightly linked with the business things, and use objects for its implementation.
According to version 2.0 of the Unified Modeling Language (UML) the component concept addresses the area of component-based development and componentbased system structuring, and is modeled throughout the development life cycle
and successively refined into deployment and run-time [Obj].
A component has the following characteristics:
FT
It is a type, i.e., it supports a specific set of concepts and interfaces.

It is visible and tangible throughout the development life cycle and at the
run-time.
RA
It can be built and deployed autonomously; an example of autonomous deployment is updating a system with a new version of the component.
It is intended to be combined and composed with other components with
which it collaborates to deliver solutions.
While components followed objects and thus represent the next evolutionary step,
the increased level of abstraction has additional requirements. Components require advanced middleware capabilities (component-ware), supporting features
such as:
Separation of interfaces and implementationallowing for substitution of
the implementation without changing the interface.
6

Incremental deployment.
Instance poolingallowing for efficient resource utilization.
Transactional supportsimplifying implementation support for ACID transactions, spanning multiple components.
Security supportproviding a standard security model and simplifying the
implementation of security on individual components.
CO
PY
Today several commercial implementation of component ware are available on

the market, most notably COM/DCOM (Microsoft), EJB/J2EE (open specifications headed by SUN), and CORBA components from various vendors following
OMGs standards. These platforms, along with the corresponding development
and deployment tools, significantly simplify the development, deployment and
maintenance of components. But this power has its price:
The component interface definition has to follow the rules of the particular platform. For example, EJB interfaces are expressed in Java, CORBA
components implement IDL-based interfaces, and so on.
FT
The component implementation has to follow the rules and conventions of

the imposed by the middleware platform. This usually prohibits the introduction of existing software or packaged applications as first class components.
RA
Interoperability between component-ware platforms both on the design and

implementation level is problematic.
The introduction of software components improved the creation of flexible, better

structured, and more manageable software applications. However the it did not
solve the main enterprise IT problem: its application centric nature. Both objects
and components focus on the better design/development approaches for individual
applications.
2.2.2
Problems of Application-Centric Architecture
Traditional architecture is concerned with a collections of applications. Typically

the development, enhancements and maintenance of software systems revolved

Copyright
around applications. But this application-centric approach to software development and evolution is one of the major contributors to expensive, inflexible and
siloed IT systems (see sidebar on the economics of IT).
Sidebar: The Economics of IT
RA
FT
CO
PY
In the last 30 years, Software Engineering has made tremendous advances in terms
of system complexity and delivery efficiencies through new levels of modeling and
abstractions. As a result, the productivity of developers has grown dramatically, to
the point where any IT organization has to deal with a large number of applications
and systems automating all but business functions and roles. Incidentally this
number is often greater than its own headcount. For each system individually, a
clear Return-On-Investment (ROI) justified its construction. However, the levels
of automation we have reached have also created a landscape where the data model
of any given organization spreads across many systems. As an illustration, Figure
below represents a mockup of the number of attributes of business entities such
as Customer, Order, Bill of Material, in different functional systems (ERP, CRM,
SCM,).
Furthermore, these systems are built over periods of time during which infras8
tructure technologies evolves, creating a de facto broad and complex technology

landscape. As new systems get added the cost of integrating and evolving systems
added to the cost of managing secure and available information systems will grow
probably to the point where it consumes entirely any given IT budget leaving little
room for innovation.
RA
FT
CO
PY
Lets understand why by looking at the value and cost of adding a single new information system to an organization versus the number of systems that are already
supporting this organization. At first, the value increases rapidly because organizations automate the most productive business processes. Over time, lower value
processes are automated, though the complexity of adding these new systems remains constant or even increases. It may also happen that adding yet another
system could potentially decrease the value of existing systems as it is not uncommon to find information workers that utilize many applications to perform
their day-to-day activities. This often lowers productivity because they need to
switch context, increasing the risk of inconsistencies between similar data inputs,
increasing training costs, ...
Figure above summarizes the plausible trends of cost and value of adding new
systems versus the number of systems in a given IT organization (this figure is not
based on real data). The reason why IT yields less and less competitive advantage
today is because most organizations have reached the cross over point and have
entered a situation where their financial margins can no longer be improved by
IT projects. Even tough many organizations still find innovative ways to improve

Copyright
their business, the costs, risks and complexity of the existing IT landscape prevents
most of the projects to go forward.
PY
IT could restore its leadership in supporting business innovation by using technologies and application models that promote reuse and flexibility while reducing
integration costs. The bottom line is that IT can no longer afford to build new systems of record, nor it is necessary. Silos, supported by monolithic architectures,
can no longer exist within IT. In parallel, new levels of value could be achieved
by consuming third party services that provide access to information that cannot
be hosted within the boundaries of a corporation (e.g. credit check) and by improving information worker productivity via composite applications that provide
single views for all user activities. This is precisely what SOA and Web Services
technologies are about.
CO
Jean-Jacques Dubray, SOA Enterprise Architect, Safeco Insurance
FT
Large numbers of heterogeneous applications and systems, each of which with its
own data store(s) create segregated islands of data within the enterprise architecture. These islands of data have the following characteristics [Lub01a]:
RA
Each island of data has its own meaning and/or definition of enterprise objects. For example, while in one application price denotes the net price,
in another application the same term also includes the sales taxes. Alternatively an address can have the same meaning in two applications, but
one of them is defining it as a set of address lines, while another one treats
it as street address, city, state, zip and country. Both cases create semantic
dissonance between applications.
Each island of data has information that overlaps with the contents of another island. For example, applications dealing with the management of
health and dental claims also store the demographics information for the insured. At the same time CRM application contains both insured addresses
and demographics. This duplication creates integrity issues
By itself, none of the islands can provide a complete picture of the enterprise
data. For example, a mortgage management application doesnt contain information about the borrowers loans from other lines of business. Creating
10

a unified view of the enterprise data requires integrating information from
multiple sources.
PY
The Application-centric approach also leads to creation of islands of automation.

Each application is built for a single purpose (e.g., loan decisioning, dental claim
management, etc.) and for a single set of users. As such it implements only a
subset of the enterprise functionality, typically without concerns about integration
throughout the entire enterprise. The islands of automation have the following
characteristics:
CO
Each island of automation focuses on a limited set of activities within the

enterprise. For example, the health claim management application deals
only with the processing of health claims. This requires users to perform
application hopping to perform their work, thus impacting their productivity.
FT
There is duplication between business processes contained within different islands. For example, as a result of a merger or acquisition an insurance
company can have several claim processing systems. This requires synchronization of business rules, between multiple applications, implementing the
same process.
The effects of the islands of data and automation are invisible at the level of individual applications. However they cause significant problems at the enterprise
level, most notably:
RA
Information fidelity The redundancy of business data between applications creates an inaccurate representation of enterprise data, even when periodic synchronization occurs. The representations themselves are difficult to reconcile, or at worst contradictory. As the individual applications evolve independently, the complexity of the problem increases.
Business processes fragmentation Individual applications provide a limited piece

of enterprise functionality. Implementing business processes requires linking together the applications containing partial implementations of process.
Solving these problems brought Enterprise Application Integration (EAI) and Enterprise Information Integration (EII) at the focal point of many enterprise projects.
Today these activities consume (and will continue to do so) a significant fraction
of the enterprise IT budget.
11

Copyright
Characteristic
Application-centric
architecture
Function-oriented
Built to last
Long development cycle
Design and
implementation
Application silos
Tightly coupled
Object-oriented interactions
PY
Resulting system
Service-Oriented
Architecture
Coordination-oriented
Built to change
Built and deployed
incrementally
Enterprise solutions
Loosely coupled
Semantic message oriented
interactions
Table 2.1: Application-centric vs. SOA
From Applications to Processes and Services
CO
2.2.3
Service-oriented computing is an approach that promises to do for enterprise

IT what components have done for applications. The introduction of ServiceOriented Architecture leads to a gradual shift from applications to architectural
elements that are closer to business-level abstractions.
RA
FT
Two key Service-Oriented Architecture abstractions promote the alignment between the business and the IT. Business processes define the functioning of the
business. They orchestrate services which represent the activities of these processes. In effect, at the heart of Service-Oriented Architecture lies the elimination
of the applications as they are known today in favor of flexible business processes
implemented on top of enterprise business services.
Table 2.1 summarizes the key differences between these application-centric and
service-oriented architecture approaches.1
Service-Oriented Architectures charter is to create software systems as a set of interacting services, where every service implements a particular business thing
or function, which are defined in the context of the overall enterprise. To put
it precisely: components provide decomposition for a particular application,
whereas services provide decomposition for enterprise IT system as a whole
(role which was previously played by the applications).
1 Based
12
on correspondence with Jean-Jacques Dubray.
2.3. SERVICE-ORIENTED ARCHITECTURE AS AN ARCHITECTURAL

STYLE
2.3
Service-Oriented Architecture as an Architectural Style
Now that we have positioned Service-Oriented Architecture as the successor to the

application-centric architecture we can present a more formal description of what
it is. Dont hold your breath though for a formal definition that everybody will
agree with: we arent going to attempt that. People have yet to reach agreement
about what software architecture is.2
2.3.1
CO
PY
There have been several attempts to present Service-Oriented Architecture as either a new form of distributed systems architecture, as an extension of objectorientation, or as a the next generation EAI. Lets take a closer look at these
analogies.
Service-Oriented Architecture and Distributed Systems
The W3C Architecture group defines SOA as a form of distributed systems architecture [Gro04], typically characterized by the following properties:
FT
Logical view The service is an abstracted, logical view of actual programs, databases,
business processes, etc., defined in terms of what it does, typically carrying
out a business-level operation. In other words service is defined as a business meaningful action.
RA
Message orientation The service is formally defined in terms of the messages

exchanged between provider and consumer, and not the properties of the
provider and consumer themselves. The internal structure of implementation is deliberately abstracted away. In other words service interface is
separated from the service implementation.
Description orientation A service is described by machine-processable metadata
service definition.
Granularity Services tend to use a small number of operations with relatively
large and complex messages (payloads).
2 The
SEI maintains a list with software architecture definitions. Currently this list contains
more than 50 different definitions.
13
PY

Copyright
Figure 2.1: W3Cs SOA model
CO
Network orientation Services tend to be oriented toward use over a network,

though this is not an absolute requirement.
Platform neutral Messages are sent in a platform-neutral, standardized format
delivered through the interfaces. XML is the most obvious format that meets
this constraint.
FT
The Service-Oriented Architecture model from Figure 2.1 can be defined in terms
of invocation message, implementation, owning organization and metadata, describing the service.
RA
The Message Oriented model defines message in terms of its content (header
and body), delivery transport and originating and executing agents.
The Resource model defines resources (implementations) in terms of URI,
representation and owning organization.
The Policy model defines policy in terms of its subjects (resource and action) and organization, supporting policy.
2.3.2
Service-Oriented Architecture and Object-Orientation
Some practitioners consider Service-Oriented Architecture and services a direct

evolution of objects, considering services as object/components on steroids [Gos05].
14

STYLE
This is as far from the reality as it can get. The similarities do not extend beyond
system decomposition for definition, and encapsulation for implementation.
Additional features of objects such as inheritance and polymorphism are not ap what really sets the two apart is usplicable to Service-Oriented ArchitectureBut
age/programming model. (Trowbridge and colleagues [TMQ+ 03] have a closer
look at these differences in their comparison of Instance-Based and Service-Based
Collaborations.)
CO
PY
In the object3 paradigm objects are created along with their internal state.
This state represents a particular execution context which distinguish multiple object instances (potentially existing simultaneously) of the same type.
The objects lifecycle is controlled explicitly by its consumer. Every object
exposes multiple methods which are bound to a particular instance (execution context) and allow to manipulate variables on a given instance. In
general there is no cross-visibility between object instances.
FT
In Service-Oriented Architecture a service exists regardless of whether particular consumer invokes it or not. In other words, the service lifecycle does
not correspond to the lifecycle of any particular consumer. Services do not
support the execution context of a particular consumerthe typical service
invocation is statelessbut rather the state of the enterprise resource(s) associated with it. The programming model is the direct invocation of the
service with the assumption that it already exists.4
RA
This difference has a profound impact on the interface definition for objects and
services. In the object paradigm multiple methods defined on the interface always
physically belong to the same instance of the object because they are bound to the
same execution context. In contrast, since services dont have an execution context
the association of methods in the service interface is a pure logical construct. The
service (and consequently service interface) effectively represents a namespace
clustering the service methods,5 which are otherwise independent entities with
their own quality of service requirements, security, versioning strategy, etc. To
3 This
discussion is equally applicable to components. However to avoid saying objects and

components we are using only the former.
4 The notable exception to this rule is a conversational composite service. Conversational composite services usually have an execution context, supporting a particular conversation. However
this context is created implicitly, upon the receipt of the message starting conversation
5 A conversational composite service can be an exception and expose multiple methods, which
15

Copyright
make a programming language analogy, every method of the service is similar
to a FORTRAN subroutine, which can exist and be executed independently from
other functions.
PY
Sidebar: Execution state vs. Invocation state
There is a profound difference between the notions of execution and invocation

state:
CO
Execution state represents the state of the service during its execution. It always
exists and include internal variables, created during service execution. It is
used for keeping track of which part of service execution has completed,
storing results of partial service execution and passing parameters between
multiple components of service implementation. This state is encapsulated
in service implementation and invisible to the service consumers.
RA
FT
Invocation state is a shared context between service consumer and service implementation. In this case a consumer invokes different methods of the same
service, assuming that the information that was passed to the service during
particular invocation is available to the service during all consecutive invocations. A service, in this case, participates in multiple conversations with
different consumers and keeps track of each conversation separately. The
notion of invocation state is used, for example in the session variables, or
statefull session bean in J2EE. A better term describing this type of state is
session state.
Throughout this book when we talk about statefull vs. stateless invocation of services we are referring only to the invocation state.
physically belong to the same service, similar to objects. This usually happens when the composite
service defines multiple methods that implement conversations with the service consumer, for
example, create order, update order, get order status, etc.
16

STYLE
2.3.3
Service-Oriented Architecture and EAI
PY
Many practitioners are presenting Service-Oriented Architecture as the next generation EAI technology.6 Traditional EAI technology works well for integrating
separately-developed applications. However it is usually based on proprietary solutions from EAI vendors, thus creating lock in to the vendors platforms. With
the current proliferation of Web Services as a technology for providing transport solutions, Service-Oriented Architecture and Web Services are becoming
standards-based integration solutions. This makes them an extremely attractive
(i.e., vendor-independent) alternative to EAI. The introduction of the Enterprise
Service Bus (ESB) products made Web services-based, standards-based integration extremely popular.
2.3.4
FT
CO
More importantly, although the end result of EAI and Service-Oriented Architecture is the implementation of business processes with the existing application
portfolio, they achieve it in radically different ways. EAI focuses on exposing the
applications functionality, effectively shaping the enterprise model in the image
of the existing application portfolio. In contrast Service-Oriented Architecture
focuses (as we will discuss in part ??) on hiding the existing applications and
exposing a set of application-independent services instead.
Elements of Service-Oriented Architecture
RA
In spite of superficial similarities, Service-Oriented Architecture represents a radically different approach to building enterprise solutions that is based on the insights gained from distributed systems, objects, and EAI. Service-Oriented Architecture involves rethinking the abstractions and their relationships that provide the
foundation of the architecture.
Service-Oriented Architecture is an architectural style promoting the concept of

enterprise business processes that orchestrate the execution of enterprise business
services. Service-Oriented Architecture supports linking resources (in the form of
services) on demand by orchestrating them using business processes [RL05]. The
enterprise Service-Oriented Architecture defines a set of business-aligned IT services (available to participants throughout the enterprise across multiple lines of
business) that collectively fulfill an organizations business processes and goals.
6 The
Gartner Group has even come up with the term Service Oriented Integration (SOI).
17

Copyright
These services can be choreographed into enterprise business solutions and invoked through standard protocols.
Figure 2.2 illustrates the major elements of Service-Oriented Architecture.
Organization owns all of the Service-Oriented Architecture artifacts (models,
services, processes, resources) and governs their creation, usage, access,
and maintenance. The remainder of the artifacts support the organization
and its goals.
CO
PY
Business Model represents the primary representation of the business resources

and processes that are performed to meet operational, tactical and strategic
business goals. Service-Oriented Architecture provides the framework for
structuring and aligning IT to meet those goals. A business model is critical
to successful alignment of services with business goals and requirements.
FT
Semantic Data Model defines the standard business data objects for a given enterprise (such as customer, agreement, etc). These objects effectively create
an ontology of the enterprise data by defining common concepts (and their
content) which describe the functioning of the enterprise. Using this data
model for defining the business services interfaces leads to the creation of
interoperable semantic interface definitionsa semantic Service-Oriented
Architecture.
RA
Documents represent legal entities (such as financial documents, insurance policies and claims, and government regulations) that define the obligations of
the enterprise and its partners. Documents are a vital part of modern enterprises and have to be included in the Service-Oriented Architecture implementations as first-class citizens.
Services implement specific business functions and access enterprise data and resources. Well defined and business-aligned services are a critical ingredient
of a flexible, extensible enterprise. The structure of services allows them to
be independently developed and deployed. Correctly defining and aligning
them with the business and semantic models results in plug and play, allowing them to be effectively combined into different enterprise wide business
processes.
Information represents the data resources of the organization. Data resides in a
variety of different stores, applications and formats. Different levels of data
18
RA
FT
CO
PY

STYLE
Figure 2.2: Enterprise SOA Concepts
19

Copyright
are used by different levels of Service-Oriented Architecture constructs.
The semantic data model defines the data for business processes and services. The Service-Oriented Architecture defines the mechanisms for transforming data from its native operational format to the semantic data required
for the business services.
CO
Sidebar: SOA Reference Model
PY
Business Processes orchestrate the execution of business services to implement

enterprise functionality as specified in the business modelfor example,
order processing or claims processing. Business processes usually are associated with operational objectives and business goals (such as insurance
claims processing or engineering development processing); have defined
triggering (initiation) conditions for each new process instance (for example, the arrival of a claim); and defined outputs at its completion.
RA
FT
Since you are reading this book, there is an assumption that you are both interested in SOA and understand what it is. Perhaps at a high level, there is consensus
on SOA, but often getting more granular reveals conceptual level inconsistencies. Hence, a formal definition for Service Oriented Architecture varies greatly
depending upon whom you ask and in some cases, the definition is conflicting.
While the talk of SOA has dominated the press/analyst coverage, no formal standard definition exists. In 2004, a group attempting to work on a project realized
they had vastly differing opinions on SOA and felt it was irresponsible to try to
specialize SOA without core consensus on a generalized definition. The project,
the OASIS eBusiness SOA Technical Committee1, had a mandate to build a reference architecture for electronic business to marry the patterns of SOA with the
patterns of business. Eventually, the group became somewhat disillusioned when
they realized a vast disparity in how the patterns of SOA were depicted in various
contexts. The ebSOA group started asking some rather pragmatic questions about
SOA. If SOA is architecture, as the name implies it is, how can it be expressed
as architecture and how is that architecture different from other architectures? Is
SOA significantly unique to warrant its existence? Is Object Oriented equal to
SOA? What are the major differences? The group stopped work on the ebSOA
project and began work to reach consensus on these questions and foster a core
understanding and definition of Service Oriented Architecture.
20

STYLE
CO
PY
Rather than duplicating the work of the W3Cs Web Services Architecture Group
and build a reference architecture, the group focused on defining a more abstract
Reference Model, which can quickly confuse non-architects who have trouble
distinguishing between architecture and models. A Reference Model (RM) is
an abstract framework for understanding significant entities and relationships between them within a service oriented environment, and for the development of
consistent architectures supporting that environment. It is based on unifying concepts of SOA and may be used by architects developing specific service oriented
architectures or in training and explaining SOA. A reference model is not directly
tied to any standards, technologies or other concrete implementation details (like
Web Services). Hence, a good reference model provides common semantics
that can be used unambiguously across and between different implementations.
In fact, the reference model is equally applicable to building a coffee shop business as it is to software architecture, although the groups focus was on the latter.
RA
FT
The OASIS SOA RM Technical Committee goal was to deliver a Service Oriented Architecture Reference Model (SOA-RM). For the software discipline, the
RM for SOA was eventually defined as a paradigm for organizing and utilizing
distributed capabilities that may be under the control of different ownership domains. The intent was not to arrogantly define one single reference model which
the entire world should be forced to use, rather to place a stake in the ground so
individuals could qualify their definition of SOA by stating either when I say
SOA I am referring to the OASIS RM for SOA or when I say SOA, I mean the
OASIS RM for SOA with the following exceptions. . . Simply stated, it is a stick
in the mud (or FUD) by which users may map their own understanding to each
other.
The RM is also infused with patterns. Patterns are abstract templates that can
be reused. Each pattern shows a set of specific concepts mapped to each other,
complete with text to describe their externally visible properties and the nature of
the relationships between them.
The core pattern/view of the RM for SOA starts with the concepts of Service, Visibility, Service Description, Execution Context, Real World Effect and Contract
and Policy.
21
FT
CO
PY

Copyright
RA
A service is a mechanism to enable access to a set of one or more capabilities,

where the access is provided using a prescribed interface and is exercised consistent with constraints and policies (Contract & Policy) as specified by the service
description. The consequence of invoking a service (interaction) is a realization
of one or more real world effects, described in detail in the current draft of the
RM specification. The execution context of a service interaction is the set of infrastructure elements, process entities, policy assertions and agreements that are
identified as part of an instantiated service interaction.
Services have many other facets and axioms expressed in the current committee draft of the RM for SOA. As depicted below, services have action models,
process models and information models. Information models themselves have aspects such as semantics and structure which need to be universally interpreted and
understood by the community of potential consumers.
22
CO
PY

STYLE
RA
FT
In the pattern above (expressed as a concept map), more atomic aspects of interaction with a service are noted. Specifically, the information model (further decomposed into semantics and structure) and the behavior model (further decomposed
into the action and process models). An example of the behavior model might
be a simple request-response pattern or something more complex such as a subscription to receive multiple responses to various endpoints. An example of an
information model could be an XML schema to describe the structure of the instances of XML information being passed in and out of a service interface coupled
with a shared conceptualization of the meaning of each piece of information listed
on the schema.
So why is the Reference Model so important? Reference models are important for
all industries. The housing industry has an implied reference model Residential
Dwelling. It serves a purpose of providing habitable space for human beings.
It has clearly defined components such as a door (interface to the community),
floors, walls, rooms, a roof, plumbing, heating and electrical systems, windows
and more. The main purpose of this implied reference model is to ensure that the
entire industry has consensus on the meanings of these terms, which avoids general chaos when architecting and building houses. A house architects knows that
when he specified a front door for a house, that it will be universally understood
by the builder and user what the door does and how it may be built and used. They
know a door manufacturer makes that component within the guidelines required
23

Copyright
by the contractors. While the consensus exists, it in no manner constrains individual implementations and architects are free to design houses for many unique
situations, locales and clients, each with their own special requirements.
CO
PY
A parallel exists for the world of SOA. Major vendors need to align around the
core concepts of service oriented architecture. If a CIO composes architecture
for a specific facet of his companys infrastructure, he might utilize the reference
model to aid his design. This can be done in conjunction with other models such
as Model-View-Controller (MVC). He or she may elect to architect a visibility
mechanism, a service description, a service policy declaration and other core components of the reference model for SOA. When doing this, they require knowledge
that vendors will be capable of supplying components for fulfilling the functionality of each thing with a shared understanding of the what each piece does and
how it relates to other things in the architecture. This will also guide architects to
the standards that are commonly used to facilitate the functionality. In this example, the visibility mechanism may be implemented using WS-Enumeration; the
service description using the Web Services Description Language (WSDL); and
the policy declaration using WS-Policy and WS-PolicyAttachment.
RA
FT
The Reference Model for SOA9 is similar in this manner. In the IT space, architects, CIOs and other IT workers, ISVs and others all need to speak a common
language when discussing SOA. The OASIS RM for SOA focuses its views on
the abstract service, then progresses to divulge information on the other concepts
linked to the service. In some ways, SOA is really a view of architecture focusing
on specific views and things influenced by it. Note how the reference model is
highly abstract yet ties in the core concepts of SOA to tangible specifications on
the right hand side.
24
CO
PY

STYLE
RA
FT
There are a number of things that may not be immediately obvious with respect
to the reference model. First, it is non constrictive upon architects. They are
free to use only parts of it if they see fit. Secondly, the process of developing an
implementable architecture may involve several steps. The second step may be
to develop a Reference Architecture (RA), upon which SOA for specific verticals
may be based. The process of developing specialized architectures is within the
charter of the OASIS SOA RM TC, however as of April 10, 2006, they have only
recently begun work on a single reference architecture. The RA is based upon the
reference model for SOA, which is currently a Committee Draft and on its way
to becoming a Committee Specification by way of public review. It may progress
to become a full OASIS standard. Architects and other IT workers are welcome
(and encouraged) to download and view the work.
Duane Nickull, Chair, OASIS SOA Reference Model Technical Committee
Service-Oriented Architecture stands out as an architectural style promoting the

alignment of business and technology because all its elements have business meaning. In fact, all of them trace back to Enterprise Business Architecture. Lets take
a closer look at the two key elements, services and business processes.
25
CO
PY

Copyright
Figure 2.3: The evolution of decomposition approaches
2.4
Services
RA
FT
In an interview at Info World Grady Booch stated that the fundamentals of engineering like good abstractions, good separation of concerns never go out of style,
but he also pointed out that there are real opportunities to raise the level of abstraction again [Sca04]. Service-Oriented Architecture increases the abstraction
level above objects and components, to services. Figure 2.3 illustrates this evolution.
2.4.1
Services, Components and Objects
One can think about a service as a mini application, supporting specific functionality relevant to an enterprise as a whole and integratable by design. The
service functionality is defined by a service interface, which can be supported by
multiple implementations. Although this simplified explanation sounds very similar to the basic definition of components, there are important differences between
services and components:
Components represent application concerns and as such they are usually
26
2.4. SERVICES
local7 to a particular application. In contrast, services represent enterprise
concerna and are always remote to other services and processes invoking
or orchestrating them.
PY
A component represents a type, with multiple instances of it being present

in the system simultaneously. Every instance of component is created by its
consumer explicitly as necessary, with a specific execution context, defined
by a consumer. A service represents a singleton instance8 , shared by all
services consumers and supporting the enterprise context. A service is not
created by its consumers, but rather exists within an enterprise and is used
by all of its consumers. When multiple applications reuse the same component, this components implementation is physically packaged with each
application. In contrast, the same physical service implementation is reused
at run-time by all consumers.
CO
Component interfaces are defined based on the requirements of a specific

component platform. In contrast, the service interface is independent of a
particular middleware platform/language.
FT
Strong associations create a tight coupling, and, consequently, a dependency

between the involved types or components. In contrast, services are significantly more loosely coupled than components, and are more resilient to the
inevitable interface changes.
RA
Components support semantics of the application they are designed for. In

contrast, because services are used throughout the enterprise their interfaces
are usually based on enterprise semantics.
The granularity of services (and their interfaces) is usually larger than the
granularity of components, in order to minimize the amount of network
traffic. Services are usually built using components.
The relationship between services and components is similar to the relationship

between components and objects [RL05]. The component introduces a more in7 Term
local to the application does not mean in process invocation. There are numerous
distributed applications, build using remote components. The emphasis here is that component
addresses a particular application is not directly used (through remote invocation) by another application.
8 Although a service represents a logical singleton, there may be additional replication and
partitioning to support architectural goals such as availability, security, and so on.
27
PY

Copyright
CO
Figure 2.4: Hierarchy of Service Elements and Concepts
2.4.2
FT
dependent, higher granularity, and more abstract concept than objects, but in fact
is typically constructed using objects. Similarly, a service is a more independent,
higher granularity and more abstract concept than a component, but is frequently
constructed using components as illustrated in Figure 2.4.
Types of Services
RA
There are three common types of services: business services, integration services
and infrastracture services.
At the heart of the Service-Oriented Architecture are business services: programmatic implementation of the business concepts, defined by the enterprise business
model. Business services are independent from the current enterprise application
potfolio and define ideal enterprise architecture. These services are the foundation (building bloks) for the entrprise-wde business processes.
Integration services [Lub04a] define an architectural and implementation approach
to application integration. They represent a specific use of Service-Oriented Architecture platform technologies, usually Web Services, for simplifying the integration of applications and legacy systems within the enterprise. By leveraging
the interoperability standards of Web Services this approach promises better interoperability and lower cost. It also exploits the enormous hype around ServiceOriented Architecture.
28
2.4. SERVICES
There are two major types of integration services that are used:
Data integration services implement data integration between multiple applications [Lub01c]. They are usually invoked by the application or legacy system in which data has changed. This integration service is usually implemented when multiple applications work mostly independently, but data
changes in one applications impacts the functioning of other applications.
As such it is similar to publish-subscribe application integration.
CO
PY
Functional integration services expose the functionality of the existing applications for use by other applications and services [Lub01b]. The application
requiring this functionality invokes the integration service. Functional integration services can cover a wide spectrum, from simple data accessors
where the service implements data integration through an exposed functional interfaceto complexwhere the service makes an applications
functionality available to its consumers. Coincidentally, data recipients of
data integration are usually implemented using functional integration services, invoked by either dedicated business process or a centralized broker.
FT
Although integration and business services use the same technologies their architectures differ significantly:
RA
Collaborations Business services are exposed to business processes or other,

higher-level business services. In contrast, business processes do not invoke integration services directly. Business components or other business
services wrap integration services in order to expose them to the enterprise.
These business components and services separate enterprise business processes from the topologies and data of the existing applications. They may
also be responsible for additional functionality, extending the capabilities of
the existing applications.
Granularity Business services are coarse grained, implementing large chunks

of functionality. In contrast, integration services can be fine grained. The
granularity of the integration service is defined by the granularity of the
functionality exposed by the application.
Temporal Coupling To achieve temporal decoupling business services tend to
be invoked asynchronously. In contrast, synchronous invocation represents
the prevalent communication style with integration services.
29

Copyright
Transactionality Well-designed business services are independent, autonomous,
and have separate transactional scopes. In contrast, ACID are often a required property for integration services, especially when the they update
application data.
Security, Authentication, etc.

Error handling.
Logging.
Documents processing.
CO
Monitoring and management.
PY
Finally a third type of serviceinfrastracture services (sometimes referred to as

common services) are service-oriented implementations of enterprise IT concerns:
FT
The centralization of enterprise-wide IT functionality into a set of services ensures

its consistency and improves flexibility and modifiability. Although not directly
supporting enterprise business functionality, infrastructure services typically provide the foundation for Service-Oriented Architecture system implementations.
RA
In the reminder of this book we will concentrate on the business services. Unless
otherwise specified the term service means business service.
2.4.3
Service Implementation Concerns
The service implementation concerns span from the ones visible to the service
consumersuch as service definition, service interface, and access policiesto
the ones that are not exposed to the consumersuch as service implementation.
Figure 2.5 shows these elements and the relationships between them.
In this diagram:
The service interface describes the capabilities provided to potential consumers. The interface is defined as a service name (i.e., a namespace) and
30
PY
2.4. SERVICES
CO
Figure 2.5: Service implementation concerns
a set of operations supported by the service. The description of every operation includes definitions of the set of parameters required for service invocation (request) and, if applicable, the result returned by the service (reply).
The description also covers the operations functionality and its pre- and
post-conditions.
FT
The service interface is usually exposed to service consumers in the form of

service definition.
RA
The service contract defines one or more service endpoint addresses for
every operation. Defining multiple endpoint addresses allows for exposing
the same functionality (service operation) with different QoS, as required
by multiple consumers.
Each endpoint address is governed by a set of access policies. These policies define the communication protocol used for data transfer and actual
service invocation, security and privacy requirements, etc.
The service is business aligned with functionality of the enterprise and is
supporting the enterprise business goals.
Granularity and loose coupling represent important service attributes.
The service implementation strives for maximum reuse of the existing enterprise functionality.
31

Copyright
Service orchestration represents the prevalent mechanism for composing
services into larger ones.
PY
Some of the elements presented in Figure 2.5, such as interface and definition, resemble their counterparts from the component or object worlds. Others represent
Service-Oriented Architecture-specific characteristics that are key to meeting the
objectives outlined in Section 2.1. The following sections take a closer look at
some of them.
Business Alignment
FT
CO
Fundamentally Service-Oriented Architecture decomposes the enterprise IT systems in a set of flexible, integratable, reusable business services, providing required architectural qualities (performance, security, throughput. etc.). These
goals can be achieved only if the service definitions are aligned with the business
model of the enterprise. Consequently, an enterprise business model is a prerequisite for a successful Service-Oriented Architecture implementation. A high level
model needs to be in place to set the direction, partitioning and taxonomy of services. Its details can be developed over time, in parallel with development of the
services.
RA
This approach to the definition of the enterprise business services allows for better alignment of business, organizational and application (services) architectures
(as prescribed by Convergent Architecture [Tay95, Hub01]). Subsequently, it becomes easier to trace software implementations (services, processes) back to the
business architecture, thus making software applications easier to understand by
business analysts and simplifying the implementation of changes in the business
functionality.
Service Granularity
In Service-Oriented Architecture the communication channel between a service

and its consumers involves the network. In other words, all service invocations
are remote.9 The communication channels10 latency and availability determine
9 There
are application domains where Service-Oriented Architecture does not involve networks. However those are specialized rather than enterprise business applications.
10 In information theory parlance.
32
2.4. SERVICES
how the service consumers perceive these characteristics. Service-Oriented Architecture design makes explicit the very different characteristics of intra- (i.e.,
inside the service) and inter-service (i.e., across service boundaries) calls. This
differentiation emphasizes that service calls are expensive.
PY
In contrast, traditional distributed technologies such as CORBA and DCOM aim

for local/remote transparency. In other words, they present the same programming
model regardless of the targets location. On the one hand the consistency simplifies the programming model. On the other hand it allows developers to spend little
time thinking about and defining boundaries. This tradeoff between simplicity of
development and execution speed represents one of the major reasons behind the
poor performance of applications built with distributed objects. However this was
not a problem with the distributed objects technology, but rather the symptom of
fine grained object interactions across system boundaries [Lub02].
FT
CO
Service-Oriented Architecture makes this tradeoff explicit by making service always remote and consequently granularity one of the explicit goals of service
design. Because service invocation involves the network they are designed coarse
grained. In other words, services must deliver value that justifies the latency cost
of a network request. Similarly, the exposed service interfaces must be coarsegrained. Instead of exposing many interfaces that provide limited functionality
services should expose a small number of interfaces that allow individual requests
to perform complete business function.
RA
Proper service granularity allows not only create better performing systems, but
lowers the coupling. Large grained services tend to be self-contained and as a
result have less dependencies on other services.
Loose Coupling
Loose coupling of services is a prerequisite for the ability to use them to build
and modify flexible enterprise solutions, and support a federated development approach throughout the enterprise. Karin Duermeyer outlines the following consequences of coupling [Due]:
Tighter coupling tends to cost more over time:
Synchronizing multiple organizations on change
Adapting, redeploying updated components without affecting others
33

Copyright
Making changes is hard and expensive, or impossible:
Knowledge is distributed throughout the code.
Same people are solving business and infrastructure problems
Different parts of the solution are difficult to manage separately.
Hard to move, hard to scale, hard to distribute, hard to replace.
More coupling implies more expensive testing.
More design work

More implementation work
PY
Looser coupling requires greater investment up front:
CO
The notion of loose coupling is not new. Good object-oriented and component
software development practices revolve around low coupling. Service-Oriented
Architecture takes it even further, considering the coupling in several dimensions.
RA
FT
Functional Coupling Although interface-based design is not new, in ServiceOriented Architecture the (service) interfaces are based on the enterprise-wide
semantics. The importance of the enterprise-wide semantics for services interoperability was downplayed by the early Service-Oriented Architecture adopters.
The Web Services community hoped that the well defined content and structure of
SOAP messages, coupled with XML representation of the payload and standardization of the transport ensure interoperability of the Web Services communication. In reality this provides only technical interoperability, ensuring that a SOAP
message from one system can be received and successfully processed by the other
system. However it does not help in any way with the semantic interoperability,
i.e., the ability of two systems to understand each other.11 In order to provide
true semantic interoperability it is necessary to ensure that all services within an
enterprise use the same messaging semantic model.
Data Coupling The separation of interface and implementation extends to the
data as well. Services accommodate two completely different, but equally important data models [Hel]:
11 The
fact that many languages use the Roman alphabet does not mean that understanding the
alphabet alone allows one to also understand all these languages.
34
2.4. SERVICES
Internal data model used by services implementations. This data model relates
to the internal implementation of the service, and thus is specific to the underlying services and components. The internal data model is not exposed
to service consumers.
External data model used for inter-service exchanges. This data model must be
understandable by both the service and its consumers. This requirement
positions the enterprise semantic model as the logical choice for designing
the inter-service messages.
PY
Each service is responsible for the semantic brokering, transforming between the
enterprise and internal data models.
CO
Using the enterprise data model for defining service interfaces leads to the creation
of interoperable semantic interface definitions [Lub04b]. This semantic ServiceOriented Architecture provides significantly enhanced interoperability between
services: all of them work with the same objects at the interface level.
FT
Temporal Coupling Services and especially Web Services publications tend to

focus on synchronous service invocations. Usage of synchronous communications
for service invocations creates tight temporal coupling between service consumer
and provider:
The service provider has to be up and running in order for the service consumer to access it.
RA
Because synchronous invocation is a blocking call performance changes in

either service execution or message delivery can have a significant impact
at the service consumer.
Making a service call asynchronous with a separate return message allows the
consumer to continue execution while the provider has a chance to respond. This
leads to a temporally decoupled system. Temporary service provider outages and
network delays have little or no impact in this case. As long as service provider
returns a response, overall system functions properly.
Services represent coarse grain singletons in the overall software system, which
make scalability and high availability of services an extremely important issue.
This means that asynchronous invocation is a significantly better fit for ServiceOriented Architecture implementations.
35

Copyright
Transactional Coupling ACID transactions are usually implemented using transaction monitors (for example Tuxedo, CICS, Encina) or component platforms
(for example J2EE aplication server or MTS). This means that support for ACID
transactions requires coupling through the transactional environment, thus limiting interoperability and flexibility. Another requirement for ACID transactions
implementation is resource locking for the duration of transaction, which requires
guaranteed short execution time of services.12
Business Processes
CO
2.5
PY
ACID transactions, while perfectly appropriate for objects and components are
usually too restrictive for services. Service-Oriented Architecture favors business
transactions over the traditional two-phase commit protocol [Lub03, LF03].
FT
Business Services implement basic business functionality, not entire business solutions. Business solutions are created by combining functionality of multiple
services togethercreation of composite services. The ability to rapidly assemble or reassemble solutions using existing services is one of the main advantages
prevalent way of combing together multiple
of Service-Oriented ArchitectureThe
services is by implementing business processes13 that orchestrate the execution of
multiple services.
RA
Businesses today are defined through dynamic enterprise business processes that
are constantly expanding, contracting and changing as the business progresses.
Their survival requires constant management focus on business processes of all
types. Mere data mining capabilities, used to produce key performance indicators
of the completed processes, arent sufficient for sustained competitive advantage.
That requires obtaining fine-grained, accurate, real-time information that measures performance of the business processes.
Companies that want to increase their effectiveness and competitiveness have to

move toward making the process a basic unit of computer-based automation and
support. They have to shift their focus from systems of record to systems of
processes. Process processing ought to replace data processing. The shift
toward a process-centric enterprise has BPM on everybodys mind. At the heart of
12 Longer
transactions time usually leads to worsening of the overall throughput of transactional

resources.
13 In effect any service composition can be defined in the form business process
36
2.5. BUSINESS PROCESSES

BPM is the notion of orchestration, where a process engine orchestrates several
manual and automatic process steps while manipulating input/output data.
PY
Unfortunately BPM is often used for all the wrong purposes. This defeats its
fundamental purpose of redefining the way business processes are automated by
orchestrating loosely coupled, self-contained process steps. Service-Oriented Architecture makes the realization of BPM more practical. Business processes in
Service-Oriented Architecture facilitate the next phase of business process evolution from merely automated to managed flexibility. Automation shifts ServiceOriented Architecture focus to creation of services that could be reused in different ways and different processes. This shift allows enterprises to achieve dramatic
improvements in market capture, cost effectiveness and profitability.
CO
The goal of Service-Oriented Architecture is to expose an organizations computing assets as reusable services that can communicate and integrate more readily.
The dichotomy of business services and business processes pave the way to a truly
flexible enterprise:
FT
Business services support stable business artifacts, incorporating processing and rules whose interface changes fairly rarely. (Note though that the
service implementation can and typically does change frequently.)
Business processes support fairly fluid business procedures and rules, which
can change every few months or even weeks.
RA
The interaction between business processes and business services is based

on the enterprise semantics, which minimize impact of services changes
on the business processes and simplifies building processes from business
services.
Just as the object-oriented paradigm unleashed the power of code reuse, based on
the existing objects, a foundation of enterprise business services enables business
analysts and IT architects to reuse them thru business processes. This approach
shifts focus from automated business services creation to optimizing existing processes and implementing new ones. More importantly, once designed processes
can be quickly modified in response to market conditions. All this translates into
increasing the business flexibility and competitiveness without dramatically increasing incremental costs of making frequent process changes.
37

Copyright
While traditional BPM focused on business processes, Service-Oriented Architecture revolves around the business service-business process dichotomy (Figure 2.6):
Business services can be combined to deliver new, composite business functions or processes.
PY
A single business service can be reused within the context of multiple business processes.
A business service itself can be implemented as a process.
RA
FT
CO
This architectural style can be viewed as a set of design principles applicable

to both service assets and process assets. Since the design approach to both
services and process is similar, Service-Oriented Architecture provides a common language for process designers (i.e., business analysts) and service designers (i.e., software developers) alike. In other words many of the service patterns
discussed further in the book (e.g., service versioning, service registry, service
repository) also apply to business processes. This resulting U BIQUITOUS L AN GUAGE [Eva03] represents a first step towards closing the gapping chasm between
business and IT. As others observed, enterprise software has always suffered
from the mismatch between technical and business-related concepts and the different languages spoken by the people on both sides of the fence [KBS04].
38
FT
CO
PY
2.5. BUSINESS PROCESSES
RA
Figure 2.6: Relationship between services and processes
39
RA
FT
CO
PY

Copyright
40
CO
PY
BIBLIOGRAPHY
Alan W. Brown. Designing and building service-oriented solutions

with the ibm rational software development platform. In IBM IAA
User Group and Insurance Solutions Conference. IBM, Month 2005.
[Due]
Karin Duermeyer. Bridging business value to SOA: SOA best

practices. Available from http://www.websphere.org/docs/
presentations/Duermeyer-SOA Executive Event Muenchen.
pdf.
[Eva03]
Eric Evans. Domain Driven Design. Addison-Wesley, 2003.

James Gosling. SOA: Buzzworld whiplash or real meat? Available from http://blogs.sun.com/roller/page/jag?entry=
soa buzzworld whiplash or real, September 2005.
W3C Working Group. Web services architecture. Available from
http://www.w3.org/TR/ws-arch/, February 2004.
[Gro04]
RA
[Gos05]
FT
[Bro05]
[Hel]
Pat Helland. Data on the outside vs. data on the inside. an examination of the impact of service oriented architectures on data. MSDN
technical article.
[Hub01]
Richard Hubert. Convergent Architecture: Building Model Driven

J2EE Systems with UML. Wiley, 2001.
41

Copyright
Dirk Krafzig, Karl Banke, and Dirk Slama. Enterprise SOA: ServiceOriented Architecture Best Practices. Prentice Hall PTR, 2004.
[LF03]
Mark Little and Tom Freund. A comparison of web services

transaction protocols. Developworks, October 2003. Available from
http://www-128.ibm.com/developerworks/webservices/
library/ws-comproto/.
[LT03]
Boris Lublinsky and Dimitry Tyomkin.

Dissecting serviceoriented architectures.
Business Integration Journal, October
2003. Available from http://www.bijonline.com/Article.asp?
ArticleID=790&DepartmentID=9.
[Lub01a]
Boris Lublinsky. Achieving the ultimate EAI implementation. EAI

Journal, February 2001. Available from http://www.eaijournal.
com/Article.asp?ArticleID=303&DepartmentId=7.
[Lub01b]
Boris Lublinsky. Achieving the ultimate EAI implementation.

part 2: Message-level integration.
EAI Journal, February
2001. Available from http://www.eaijournal.com/Article.
asp?ArticleID=299&DepartmentId=5.
[Lub01c]
Boris Lublinsky.
Achieving the ultimate EAI implementation. part 3: Data-level integration.
EAI Journal, February
2001. Available from http://www.eaijournal.com/Article.
asp?ArticleID=301&DepartmentId=6.
RA
FT
CO
PY
[KBS04]
Boris Lublinsky. The key to superior EJB design. Java Developer

Journal, 7, January 2002.
[Lub03]
Boris Lublinsky. Transactions and web services. EAI Journal,

January 2003. Available from http://www.bijonline.com/PDF/
TWSLublinsky.pdf.
[Lub02]
[Lub04a]
Boris Lublinsky. SOA design: Meet in the middle. Java Pro, August
2004.
[Lub04b]
Boris Lublinsky. Unifying data, documents and processes. Enterprise

Architect, 2(2):611, Summer 2004.
42
BIBLIOGRAPHY
Object Management Group. UML 2.0 Infrastructure Specification.
Available from http://www.omg.org/docs/ptc/03-09-15.pdf.
[Par72]
David L. Parnas. On the criteria to be used in decomposing systems

into modules. Communications of the ACM, 15(12), December 1972.
[RL05]
Michael Rosen and Boris Lublinsky. Service-Oriented Integration:

Aligning SOA with enterprise integration. In Cutter Executive Report, volume 8. The Cutter Consortium, January 2005.
[Sca04]
Ed Scannell.
IBMs grady booch on solving complexity. Available from http://www.infoworld.com/article/04/02/
02/HNboochint 1.html, February 2004.
[sea]
Revisiting the definitive soa definition. Available from http:

//searchwebservices.techtarget.com/originalContent/0,
289142,sid26 gci1044083,00.html.
[Tay95]
David A. Taylor. Business Engineering with Object Technology. John

Wiley & Sons, 1995.
CO
PY
[Obj]
RA
FT
[TMQ+ 03] David Trowbridge, Dave Mancini, Dave Quick, Gregor Hohpe,
James Newkirk, and David Lavigne. Enterprise Solution Patterns
Using Microsoft .NET Version 2.0. Microsoft Press, 2003.
43

SOA Service Design

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SOA Service Design

Uploaded by

Copyright:

Available Formats

This is draft content of SOA Enterprise PatternsServices, Orchestration and

Visit the Web site http://orchestrationpatterns.com/ for additional

There is also a Yahoo! group (orchestrationpatterns-book) for broadcasting

c 20042006 Dragos Manolescu and Boris Lublinsky

Why Service-Oriented Architecture?

c 20042006 Dragos Manolescu and Boris Lublinsky

From the point of view of a project manager Service-Oriented Architecture

2.2. APPLICATION-CENTRIC ARCHITECTURE

Specialization Decomposition can promote the separation of concerns, leading to

Development speed Decomposition can facilitate the parallel development of

Evolution of Decomposition in Software

c 20042006 Dragos Manolescu and Boris Lublinsky

It is a type, i.e., it supports a specific set of concepts and interfaces.

2.2. APPLICATION-CENTRIC ARCHITECTURE

Today several commercial implementation of component ware are available on

The component implementation has to follow the rules and conventions of

Interoperability between component-ware platforms both on the design and

The introduction of software components improved the creation of flexible, better

Problems of Application-Centric Architecture

Traditional architecture is concerned with a collections of applications. Typically

c 20042006 Dragos Manolescu and Boris Lublinsky

2.2. APPLICATION-CENTRIC ARCHITECTURE

tructure technologies evolves, creating a de facto broad and complex technology

c 20042006 Dragos Manolescu and Boris Lublinsky

Jean-Jacques Dubray, SOA Enterprise Architect, Safeco Insurance

2.2. APPLICATION-CENTRIC ARCHITECTURE

The Application-centric approach also leads to creation of islands of automation.

Each island of automation focuses on a limited set of activities within the

Business processes fragmentation Individual applications provide a limited piece

c 20042006 Dragos Manolescu and Boris Lublinsky

Table 2.1: Application-centric vs. SOA

From Applications to Processes and Services

Service-oriented computing is an approach that promises to do for enterprise

on correspondence with Jean-Jacques Dubray.

2.3. SERVICE-ORIENTED ARCHITECTURE AS AN ARCHITECTURAL

Service-Oriented Architecture as an Architectural Style

Now that we have positioned Service-Oriented Architecture as the successor to the

Service-Oriented Architecture and Distributed Systems

Message orientation The service is formally defined in terms of the messages

c 20042006 Dragos Manolescu and Boris Lublinsky

Figure 2.1: W3Cs SOA model

Network orientation Services tend to be oriented toward use over a network,

Service-Oriented Architecture and Object-Orientation

Some practitioners consider Service-Oriented Architecture and services a direct

2.3. SERVICE-ORIENTED ARCHITECTURE AS AN ARCHITECTURAL

discussion is equally applicable to components. However to avoid saying objects and

c 20042006 Dragos Manolescu and Boris Lublinsky

Sidebar: Execution state vs. Invocation state

There is a profound difference between the notions of execution and invocation

2.3. SERVICE-ORIENTED ARCHITECTURE AS AN ARCHITECTURAL

Service-Oriented Architecture and EAI

Elements of Service-Oriented Architecture

Service-Oriented Architecture is an architectural style promoting the concept of

c 20042006 Dragos Manolescu and Boris Lublinsky

Business Model represents the primary representation of the business resources

2.3. SERVICE-ORIENTED ARCHITECTURE AS AN ARCHITECTURAL

Figure 2.2: Enterprise SOA Concepts

c 20042006 Dragos Manolescu and Boris Lublinsky

Sidebar: SOA Reference Model

Business Processes orchestrate the execution of business services to implement

2.3. SERVICE-ORIENTED ARCHITECTURE AS AN ARCHITECTURAL

c 20042006 Dragos Manolescu and Boris Lublinsky

A service is a mechanism to enable access to a set of one or more capabilities,