A Reference Architecture for

Service Oriented Architecture (SOA)

© Drexel University Software Engineering Research Group (SERG)

[Link]
1
Motivation

Why do we need SOA

 Redundancy
 Implementation inconsistency
 Lack of inter-operability
 “Wrapper”-Happy
 Lack of Modularity
Misconception: SOA is about design
and not technology (i.e.,
WebServices)
© Drexel University Software Engineering Research Group (SERG)
[Link]
2
What is SOA? ---- Randy
Heffner, Forrester Research
"A pattern of design, development, deployment, and management of (a)
applications and (b) software infrastructure and frameworks in which:
Applications are organized into business units of work (services) that are
(typically) network accessible
Service interface definitions are first-class development artifacts
Quality of service (QoS) characteristics (security, transactions, performance, etc.)
are explicitly identified at design time
Software infrastructure takes active responsibility for managing QoS and
enforcing policy for service access and execution
Services and their metadata are cataloged in a repository
Protocols and structures within the architecture are, optionally, based on industry
standards (e.g., the emerging SOAP stack of standards)”

[Link]

© Drexel University Software Engineering Research Group (SERG)

[Link]
3
What is SOA? ---- More
definitions

The orchestration patterns website outlines 12 additional

definitions of SOA from industry experts… The diversity in
definitions is interesting…
 “Service Oriented Architecture (SOA) is an approach to the development of
loosely coupled, protocol-independent distributed applications…”
 “SOA is a form of technology architecture that adheres to the principles of service
orientation…“
 "Service-oriented architecture is an architectural discipline…”
 “SOA is a style of design that strives to enable easy integration and flexible
applications…“
 "A service oriented architecture is an approach to design and integrate software
in a modular method where each module is precisely a 'loosely coupled
service' ,,,”
 “Service Oriented Architecture is nothing but business oriented architecture…”
 “SOA is a framework enabling application functionality to be provided, discovered
and consumed as re-usable
Source: Web Services sets…”
[Link]
 And so on…
© Drexel University Software Engineering Research Group (SERG)
[Link]
4
What is SOA? ---- More
definitions

The orchestration patterns website outlines

It’s a bit 12 additional
confusing… is SOA
definitions of SOA from industry experts… The diversity in
about:
definitions is interesting…
 “Service Oriented Architecture (SOA)1. is Web Services
an approach to the development of
loosely coupled, protocol-independent distributed applications…”
2. Business
 “SOA is a form of technology architecture that adheres to the principles of service
Architecture
orientation…“
 3. Services discipline…”
"Service-oriented architecture is an architectural
 “SOA is a style of design that strives to enable easy integration and flexible
applications…“
4. “Loose Coupling”
 "A service oriented architecture is [Link]
Integration
to design and integrate software
in a modular method where each module is precisely a 'loosely coupled
service' ,,,” 6. All of the above?
 “Service Oriented Architecture is nothing
7. Orbut business else…
something oriented architecture…”
 “SOA is a framework enabling application functionality to be provided, discovered
and consumed as re-usable
Source: Web Services sets…”
[Link]
 And so on…
© Drexel University Software Engineering Research Group (SERG)
[Link]
5
Microsoft and SOA…
A Microsoft View on SOA: “The goal for Service Oriented
Architecture (SOA) is a world-wide mesh of collaborating
services that are published and available for invocation on a
Service Bus. Adopting SOA is essential to delivering the business
agility and IT flexibility promised by Web Services…”

Microsoft uses a Metropolis

analogy to explain SOA…

The idea being that cities,

like an SOA, require services
(police, manufacturing,
shopping, etc.) and a
transportation (bus, railroad,
etc.) system to thrive

Source: [Link]
© Drexel University Software Engineering Research Group (SERG)
[Link]
6
IBM & SOA….

IBM’s Website on SOA

(linked here from
[Link])
is clearly targeted at
selling IBM tools and
professional services…

Source: [Link]

© Drexel University Software Engineering Research Group (SERG)

[Link]
7
SOA

You may either feel educated or sleepy by now, but

you probably know little more than when you
arrived at this class about SOA…

© Drexel University Software Engineering Research Group (SERG)

[Link]
8
SOA Buzz…
… you however will be well equipped to play
“buzzword bingo” at the meeting where somebody
tries to explain SOA…

© Drexel University Software Engineering Research Group (SERG)

[Link]
9
Service Oriented Architecture is
an Example of an Architectural
Style
An Architectural Style defines a family of
systems in terms of a pattern of structural
organization.
 What are the architectural components?
 What are the architectural connectors?
 What patterns guide the design of the components
and connectors?
 How are faults and unexpected events handled?
 Clear definition of the set of constraints on the
architectural components and the relationships
that are allowed between them
Because SOA is an Architectural Style a Reference Architecture can be
constructed to govern common aspects of all applications built in accordance
with this style…
© Drexel University Software Engineering Research Group (SERG)
[Link]
10
Service Oriented Architecture is
an Example of an Architectural
Style
SOA as an Architectural Style:
 What are the architectural components?
 Services
 What are the architectural connectors?
 Messages
 What patterns govern the design of the components and connectors?
 Data Services, Business Services, Composite Services
 How are faults and unexpected events handled?
 Language specific exception handling mapped to service faults
 Clear definition of the set of constraints on the architectural
components and the relationships that are allowed between them
 Services are network addressable
 Services are language and platform independent
 Services have flexible instantiation capabilities
 Services are stateless
 Messages are formally defined by a service contract
 …
© Drexel University Software Engineering Research Group (SERG)
[Link]
11
 The “Actors” in an SOA – Service
Consumers, Service Providers &
Messages
Service Provider

Service Consumer
Concret
e
Applicat Service

Intermedia
Message
ion

Service
ry
Service

Consumed Provided
Service Service
Interface Interface

© Drexel University Software Engineering Research Group (SERG)

[Link]
12
The Architectural Components -
Services
Services are a conceptual design component, and can be
implemented using a variety of different technologies
 Java Beans, (Enterprise Java Beans)
 .Net Class Files (ASMX)
 COBOL Programs
 Third party tools: Siebel
Services are designed to have flexible interfaces and are evolved
easily
 Services separate the concerns of the service consumer from the
service provider
Services can be instantiated in a variety of different ways
 Local components, Web Services, Sync-/Asynchronous Messages
Services are lifecycle managed by an application server container
of some sort
 CICS, .Net Framework, J2EE (WebSphere, Axis)
© Drexel University Software Engineering Research Group (SERG)
[Link]
13
The Architectural Connectors -
Messages
Services interoperate with each other using “messages”
capable of verifying and certifying their own syntax and
semantics
Architecture Requirements for Messages
 Messages do not assume any sort of delivery technology
 Messages support intermediaries and can be transformed
between the service consumer and the service provider without
either party being aware of the transformation process
 Messages can be secured end-to-end
 Messages can be deserialized into language-specific
components
 Language specific components can serialize themselves into a
valid message that adheres to both the syntactic and semantic
requirements of the message

© Drexel University Software Engineering Research Group (SERG)

[Link]
14
Messages and XML
In a SOA, messages are generally encoded as XML
documents
 Character-based encoding is the lowest-common denominator
for almost every computing and message-transport platform
 Research into XML parsing has produced parsers that can
produce and digest XML documents very fast
 The valid structure of messages encoded as XML can be
specified using a standard description language – XML Schema
 XML Namespaces support the flexible extension of service
interfaces
 XML is governed by a wide verity of standards
 Security
 Transformation
 Industry-specific business transactions
 Vendor-specific schemas
© Drexel University Software Engineering Research Group (SERG)
[Link]
15
Benefits of the SOA Architectural
Style
Its all about the interface…
 Loosen the coupling between a service component and the requesting
application
 Support easy and rapid evolution of the service interface with a maximum
degree of backward-compatibility
 Interface specifies the semantics used by the service provider
 Loosen the coupling between an application and the database
 Allows current data sources to be aggregated behind a service interface
 Allows the underlying data sources to evolve as authoritative data sources
are created
 Messages define the types used by the interfaces of the service
consumer and the service provider

© Drexel University Software Engineering Research Group (SERG)

[Link]
16
Best Practices for Service Design
in an SOA
Services for an SOA should be built using the “Design by Contract”
approach
 Service contract developed first using a standard description language,
typically XML Schema
 The service contract defines the service interface, encodes the message
structure, and defines the message semantics
 Services interfaces define the interface types, as such service
programmers should not be working at the XML level
 Objects should be generated for the service interface from the service
contract (i.e., XSDObjectGen for .Net, JAXB for Java)
 Service contracts should be designed for extension, and organized
around business events that the service supports
 Service contracts define “subject areas” that support the various
business events supported by the service
Service contract can be used by a service invocation framework
 Examples: WSDL for Web Services

© Drexel University Software Engineering Research Group (SERG)

[Link]
17
 Best Practices for Interface and
Message Design in SOA
Service interfaces should be build around the specification and execution of useful
application/business events
The service interface should define a collection of “subject areas” that are relevant
to the application/business events supported by the service

<ServiceRequestMessage>
<MessageHeader>
<!-- Miscellaneous Header stuff goes here -->
<BusinessEvent>
<!– Enumeration of supported business events goes here -->
</BusinessEvent>
</MessageHeader>
<MessageBody>
<SubjectArea1>...</SubjectArea1>
<SubjectArea2>...</SubjectArea2>
<SubjectAreaN>...</SubjectAreaN>
</MessageBody>
</ServiceRequestMessage>

The application/business event coupled with the provided subject areas dictates what a service
will do on behalf of the consumer, this model fits in naturally to business processes where the
“current view of the truth” might be dependant on the state of the business process.

© Drexel University Software Engineering Research Group (SERG)

[Link]
18
Some Misconceptions about
Services
Services are not Database API’s
 Use stored procedures for “black box” operations on data
A service can be implemented as a Web Service, but a Web
Service is not necessarily a service in an SOA
Reuse of a service is nice if you can find a requirement for it
 A service is best thought of as an authoritative access point to
execute application/business events around a particular business
subject area
 A service is a great place to get a business context aware “view of
the truth”

© Drexel University Software Engineering Research Group (SERG)

[Link]
19
We will see later that services come
in different styles

Service Styles
 Basic Services
 Integration Services
 Composite Services

© Drexel University Software Engineering Research Group (SERG)

[Link]
20
Anti-Best Practice for Creating
Services: The “Right-Click”
method…

© Drexel University Software Engineering Research Group (SERG)

[Link]
21
.Net is no better for directly
promoting a component to a
service…
Decorate a component interface with “[WebMethod]”
Create a file with an “.axmx” extension with a single line:

Any<%@
method in the components
WebService class that is public and decorated
Class="ClassName_Goes_Here" %> with
“[WebMethod]” becomes part of the service interface

© Drexel University Software Engineering Research Group (SERG)

[Link]
22
Design Service Like Mini-
Applications
Request- Service Interface Domain Object Data-Access Database
Tier Tier Tier Tier Tier

Web Data
Service Domain
Server Access
Implementation Objects
Objects Persisted
Structures
Message Business Event
Queue Message Change Publisher
Serialization Stored
The domain layer is bound to the data
Objects Procedures
access layer by action objects that
manage business event transactions
Databases
Message Domain Business Event
Validation Object Action Factory
Builder Mainframe
Transactions
The domain tier Data access
Local represents the Actions objects are Other…
Objects Services should use business domain (Events) aware of how (Messaging)
type-safe objects that and is unaware to persist
serialize/deserialize of how the business domain
to XML in accordance objects are persisted. objects in a
with the service Business logic goes database.
contract here.
© Drexel University Software Engineering Research Group (SERG)
[Link]
23
Outline

Objects and Components

Service Oriented Reference
Architecture
 SOA Functional View
 SOA Architectural View
 SOA Messaging
 SOA Interfaces (provided & required)
 ESB
© Drexel University Software Engineering Research Group (SERG)
[Link]
24
Objects and Components (again)

Services are the main entities in applications

constructed using SOA principles
Services are constructed using components,
which in turn, are created using objects
 Reviewing principles of objects and components is
helpful in understanding how to design services
 Services can then be placed in context of a
reference architecture for SOA

© Drexel University Software Engineering Research Group (SERG)

[Link]
25
Principles of OO
Abstraction
 An object is known by its data type and behavior, providing
a stable interface for communicating with and using the
object.
Encapsulation
 Implementation decisions are hidden inside of classes and
were protected by variables (properties) and methods that
were explicitly made public to the outside
 Allows for the separation of interface from implementation
Polymorphism
 The ability for an class to take on different behavior-based
on the runtime binding to object types

© Drexel University Software Engineering Research Group (SERG)

[Link]
26
Principles of OO
Inheritance
 The ability of one object to inherit the
representation and behavior from another
object. This inherited behavior and
representation can be selectively used “as
is”, extended, or replaced.
Identity
 A class is a template for objects and objects
are instances of classes
 All objects can be uniquely defined, have
their own unique identity, and manage their
unique state

© Drexel University Software Engineering Research Group (SERG)

[Link]
27
Design Principles for OO
Program to interface not implementation
To extend behavior, favor object
composition over inheritance – extended
behavior and original behavior are
preserved
 This prevents a change to the original behavior
from impacting inherited behavior
Minimize coupling between objects to
ensure that changes are localized and do
not propagate
Maximize cohesion within an object

© Drexel University Software Engineering Research Group (SERG)

[Link]
28
Design Principles for OO

Good interface design is essential

 It does not expose the underlying attributes
(class level) or the underlying classes
(subsystem/component level)
 Does not expose the underlying
implementation
 Does a logical unit of work
 A change to the system should not require a
change to the interface (property of good
abstraction)

© Drexel University Software Engineering Research Group (SERG)

[Link]
29
Problems with OO
The design principles of OO scale to design
principles for services in an SOA
OO has scalability and complexity limitations
 Classes have to have compile or link time visibility to
all other classes – this implies repackaging/deploying
an entire application unit when a class changes
 Distribution was handled manually using low level
network protocols
 Interface design had to be “perfect”, but this was
difficult to do in practice
 All types must be binary compatible
 Type conversion and object
serialization/deserialization was a manual process

© Drexel University Software Engineering Research Group (SERG)

[Link]
30
Components
Components aggregate classes and focus on
packaging and distribution
 OO design principles directly map to component
design principles
Yet component approaches to software design
have their problems:
 Components must still provide a stable interface
 Components are only able to provide a single
interface to their clients
 Designs using components are “chatty”, often
requiring many components to perform a “useful”
operation – this makes scalability difficult
Component frameworks are proprietary
 COM, DCOM, CORBA, J2EE/EJB

© Drexel University Software Engineering Research Group (SERG)

[Link]
31
Step 1: Containers to the
rescue…
Containers (a.k.a application servers) are like
application-aware operating systems that sit on
top of the native operating system (e.g.,
[Link], J2EE)
 Standardizes resource allocation and sharing that is
tightly integrated into component model
 Able to introduce component-aware semantics
 E.g., Secuirty attributes based on RBAC - beyond read,
write, read-write, allow, deny
Containers abstract many of the “hard” things:
 Finding things (directories), managing network
resources, reliability, availability, database
connections, security, “on demand”-stuff
Code running in a container is often called
“managed code”
© Drexel University Software Engineering Research Group (SERG)
[Link]
32
Step 2: Messaging infrastructure to
the rescue…
Traditional distributed inter-operability is generally
achieved by sending a binary-encoded message over a
synchronous network connection (e.g., socket)
This approach makes it hard to:
 Provide multiple interfaces for a component
 Support asynchronous programming models
 Support common architecture styles (e.g., Pub-Sub)
 Support severs implemented in a different technology from
the requestor
 Support applications with high-reliability requirements
 Support external routing information

© Drexel University Software Engineering Research Group (SERG)

[Link]
33
Step 2: Messaging infrastructure to
the rescue…

Messaging infrastructures are traditionally

implemented as queues where messages,
metadata and routing information are placed
into a queue and the messaging infrastructure
routes the message to from a source queue to
a destination queue
Queues may have properties such as triggers
so that when a message of a certain type
arrives it automatically invokes a component to
process the message

© Drexel University Software Engineering Research Group (SERG)

[Link]
34
Step 2: Messaging infrastructure to
the rescue…

Messaging infrastructures also have

their problems:
 The format for the encoded message is left
to the user – meaning the requestor and
server must agree on the format
 The asynchronous programming model is
more difficult for programmers to deal with
than a synchronous programming model
 Deployment of applications using
messaging infrastructure is fragmented

© Drexel University Software Engineering Research Group (SERG)

[Link]
35
Step 3: Standards to the rescue –
finally enablement of SOA is possible

SOA takes the best from OO, Components,

Containers, and messaging infrastructures
 OO and Components provide the design principles
 Containers and messaging infrastructures provide the
runtime environment
Now standards such as the WS-* set enable
containers to support distributed components
that:
 Can interoperate using messaging or synchronous
messages seamlessly
 Standardize the format and define semantics for the
messaging payloads
 Supports external definition of routing and QoS of
related to the delivery of messages

© Drexel University Software Engineering Research Group (SERG)

[Link]
36
SOA Revisited

SOA
 Represents every application or resources
as a service with a standardized interface
 Is based on having services exchange
structured information (as opposed to an
RPC call)
 Provides facilities via a container to
coordinate and mediate between the
services so that they can be invoked, used
and changed effectively

© Drexel University Software Engineering Research Group (SERG)

[Link]
37
Service revisited
A service is :
 A component that does something useful on behalf of an
application
 Exposes its functionality and hides the implementation details
 Not dependant on the context or state of other services
A service either provides information or facilitates the
processing of an application feature ensuring that the
application state is changed from one valid and
consistent state to another
Dependencies between services should be defined in
terms of an application process

© Drexel University Software Engineering Research Group (SERG)

[Link]
38
An SOA Reference Architecture

© Drexel University Software Engineering Research Group (SERG)

[Link]
39
SOA Reference Model 101
Message Type
Delivery Method
Delivery Channel
Transport Protocol
Payload Format Provider
Encoding Semantics
Extensions
Functio
Requestor
nal
Applicat Service

Intermedia
Message
ion

Service
ry
Service

Service
Interface

© Drexel University Software Engineering Research Group (SERG)

[Link]
40
 Components of the SOA Reference
Architecture
Application Specific Components

Service Integration Adapters

Service
Service Service
Functional
Style Interface
Type

Service Quality of
Messaging Service (QoS)
Models Characteristics

Application Service Integration

© Drexel University Software Engineering Research Group (SERG)
[Link]
41
Establishing the Functional Aspect of the
Service in an SOA
Service Service Provider
Message
Requestor (or Service Intermediary)

Service Types

Applicat
Partn

Code
ers

RPC

ion
Component Service
Simple services potentially acting on
single enterprise resource (e.g.,
Applicat

Legac
TCP/IP
Code database, code, etc) and are created

Applicatio
ion

3rd Party
by aggregating and/or encapsulating

y
one or more application-specific

ns
component interface(s)

Service Resources
Service Consumers

Business Service
Component services composed of

Messaging

Databas
Legac

Reliable
Transport

combinations of component services

y

and rules.
WS-

e
Data Service
Services

Services providing data querying,

Other

combination and transformation for

multiple data sources.

Partne
Messag

Broker

Event-Driven Service

rs
Services that react, publish or
e

Files
implement enterprise business events.
Web
App

Services
Business Process Service

Other
HTTPS
HTTP/

Long lived business processes

coordinating other services with
Port
al

external interactions.

Core Services Servic

Servic
Securi e e
ty Policie Mana
© Drexel University Software Engineering Research Group (SERG)
[Link] s ger 42
The Enterprise Architecture Reference Model
for SOA
Containers Process/PM
WebSph Micros
Databa Manage
ere oft CICS SDLC Methodology
se ment
J2EE .Net
Messaging / Transactions / EAI
3rd Party
Securi

Services Integration
ty

Application
Functional Services
Presentati Purchased
on Basic Service Application
Infrastructu

Component

Quality of Service
Service
s

Utility

Service Repository
Transformation
Proxy Service

Coordination
Applicatio Internal
re

Integration
Messaging / Transactions / EAI

Messaging / Transactions / EAI

n Wrapper Application
Componen Service s
ts
SOA Partner

ESB Infrastructure
Controller

Service Architectural Styles

Design Messagin Service Application


Clustering/

Balancing

g s
(Simple

Business Process
Core Infrastructure QoS -

Workflow
Load

Design & Business

Architectu Coordination
Process Component

Composition
Patterns

ral Service
Composition) s
Metadata
SOA

Patterns

Caching
(ACID

Routing
Workflow
Transaction)
Applicatio

Rules
Service
Inter-, Intra-,
and Extranet

n Legacy
Gateways

(Business


Framewor  Legacy
Process, Legacy
k Applicatio
Legacy
Business Applicatio
Componen Data Transformation Policy Enforcement XML Processing n
Applicatio
Transaction) n
ts n
Via Data
Service
Messaging / Transactions / EAI

Reporting / Information Management Storage

Operation Reporting ODS BOR
Warehou Data
Analytical se Mart
al Application
Reporting ETL
Reporting s

Enterprise
© DrexelApplication
University Software Engineering Research Group (SERG)
Corporate Messaging
Legend: Data Domain
Architecture
[Link] Domain Domain
Infrastructure Interface 43
 Messaging Taxonomy
SOA Transport Models for Messages Supported by the Reference Architecture

Payload Encoding Delivery Delivery

Protocol Extensions
Format Semantics Method Pattern

 TCP/IP  XML  RPC  Attachments  Synchronous  One-Way

The payload Command
HTTP/HTTPS Binary contains Message
   Asynchronous Event
attributes
that directly
Metadata
RMI SOAP

bind to (Security,  Delivery QoS  Request/
IIOP
service Session, At Least Once Reply
 XML-RPC parameters
Context, etc.) At
Point-to-Point
Most Once One-to-Many
.Net Remote CORBA
  Document-  Message Exactly Once
Centric  Publish/
MQ  Custom/ Schema
The payload Subscribe
Proprietary is encoded
WS-Reliable
as a
 Marshalling
Messaging  Serialized structured and Datatype
document Specifications
Object
 Endpoint
Addressing

© Drexel University Software Engineering Research Group (SERG)

[Link]
44
 Service Specification
Step 4: Step 5:
Step 1: Step 2: Step 3:
Define Supported Define Quality of
Select Service Select Service Specify Service
Messaging Service (QoS)
Type Style Interface
Models Characteristics

Each designed Once a service Each service A service may be A service should
service should type is defined, should provide integrated into also specify its
be classified by a service style a well- multiple required and
its service type should be designed applications provided QoS
selected based interface under different attributes such
on the desired encapsulating contexts, as security,
architectural the desired therefore, the transactions,
characteristics service service design performance,
of the service, behavior should also etc.
its required consider the
resources, and messaging
potential models that will
consumers be supported by
the service

© Drexel University Software Engineering Research Group (SERG)

[Link]
45
The Service Styles are Related
Basic Services Integration Services Composite Services

Controller
Basic Proxy Service
Service Service [adds externalized
workflow
[is a special type of] capabilities to]
[is a specialization of]
Workflow
Utility Wrapper Service
Service Service
[adds ACID
transaction
support to]
Coordinati
on
Service

© Drexel University Software Engineering Research Group (SERG)

[Link]
46
ESB
Where a container layered over the OS to
facilitate the managed code model, an ESB
lives within a container to provide function to
services in an SOA
An ESB
 Facilitates effective service communication
 Facilitates effective service integration
 Facilitates effective service interaction

© Drexel University Software Engineering Research Group (SERG)

[Link]
47
 ESB Interfaces

ESB Interface Description

Connection The ESB connection interface should fully support the synchronous and asynchronous web service
stacks as well as message-oriented middleware (MQ Series), HTTP/HTTPS, Microsoft .NET
Serviced Components, Java Remote Method Invocation (RMI), .NET Remoting, CICS host
transactions.

Change Rather than changing code in a service interface, the ESB is configured with metadata to handle
managing the service catalog, interface versioning, routing, quality of service (QoS), orchestration,
security, business rules, and other volatile duties.
Control The control interface provides enterprise management capabilities that are outside the scope of the
individual services managed by the ESB. The control interface integrates with standard
infrastructure management facilities, handles service provisioning to maintain QoS commitments,
and provides reports/logs on the health and operation of the ESB infrastructure.

© Drexel University Software Engineering Research Group (SERG)

[Link]
48
 ESB Features

ESB Features Description

Security The ESB supports security policies regarding service
usage
Quality of Service The ESB can persist requests to message
queues and retry service operations when
failures occur, implement failover to alternate
servers, and other steps to ensure that
ESB Features Description otherwise unreliable networks and services
can be made to provide the quality of service
required by the requester.
Communication Supports the ESB messaging requirements
(protocol, style, sync, async, etc.)
Service Registry and When maintaining a name space (service
Request Routing and Support for subject-, content-, and itinerary-based Metadata Management discovery), the ESB may extend the service
Versioning routing. The ESB transparently routes requests to metadata this requires (such as WSDL), to
the correct version of the service interface, as well enable services to be classified to ease
as managing the version instances. searching for reuse.
Transformation and Support for mapping of data formats of message Extensibility for A special case of semantic mapping,
Mapping payloads in cases where the service requestor and Message Enrichment enrichment enables database or table lookups
provider have different interface formats to be merged into a message stream so that
messages emerge from the bus richer with
Service Aggregation The ESB may implement microprocesses that data than when they arrived.
aggregate smaller services into larger
services, which may also require transaction
management. Monitoring and The ESB automate management as much as
Management possible, it will also be necessary to enable
Transaction The ESB provides support for compensated humans to investigate problems, find root
Management transactions, working with other TP monitors to causes, and take action to correct the issues
handle ACID transactions that are discovered.

© Drexel University Software Engineering Research Group (SERG)

[Link]
49
 Utility Service
<<Utility Service>>

<<component>> <<component>>
UML

Service
Interface

<<component>> <<component>>

<<reusable business logic>>

Description

A utility service encapsulates generic functionality intended to be reused within and across different SOA applications. In SOA,
most services are conceptual single-instance components that provide capabilities to one or more applications based on a
published service contract (i.e., the service interface). A utility service is a special case of a service in an SOA as it is intended to be
reused across (and not integrated into) multiple applications. Utility services are physically created by aggregating the desired
public interfaces of one or more application components into the utility service interface.
Guidance

Utility services are conceptually similar to library or framework components in traditional application architectures.
Design

© Drexel University Software Engineering Research Group (SERG)

[Link]
50
 Basic Service
<<Basic Service>>

<<component>> <<component>>
UML

Service
Interface

<<component>> <<component>>

<<business logic>>

A basic service encapsulates the functionality implemented in one or more business components by specifying a well-defined
Description

service interface that exposes a desired business capability. Each interface point in a basic service should be defined with a
granularity in terms of performing a useful business unit-of-work (BUOW). A basic service must perform a discrete BUOW. Basic
services can be orchestrated with other service styles to perform business processes. Basic services are usually defined top-down
by performing analysis on a business domain, specification of business use cases, or business process walkthroughs.

Basic services are best designed by properly establishing the service interface. Some best practices for creating the service
interface include: (1) Interfaces that are easy to consume are as simple as possible, but no simpler (2) Be able to accomplish a
Guidance

business unit of work in a single call (3) Be used across many different contexts (not just the first app that it was built for) (4)
Design

Models business processes rather than lower level functionality (5) The service interface should be easy to version such that they
can be easily extended with the addition of new parameters and doesn’t break service consumers when a new interface is defined
(6) The service interface should promote the concept of loose coupling by insulating the service consumer from changes in the
service implementation, not requiring anything other than the schema and contract to know how to invoke them, and no leaking
internal abstractions outside the service boundary.
© Drexel University Software Engineering Research Group (SERG)
[Link]
51
 Proxy Service
<<Proxy Service>>

Service
Proxy
UML

<<generated>>
Service
Interface

Existing
Application
Component

A proxy service “service-enables” an existing application component by creating a service proxy component that “facades” the
Description

existing component. Proxy services can generally be automatically generated by an IDE, exposing the public interface (or a subset
of the public interface) of the existing application component as a service. A proxy service is often used to integrate with an
application that provides some desired functionality to an SOA application, but this functionality is implemented as a collection of
API’s and not as a service.

One must be careful when creating proxy services, as they are easy to create, but yet are often inefficient from a design perspective
Guidance

when compared to other service types. Problems generally occur with proxy service designs because the underlying component ‘s
Design

public interface is not optimized for an SOA. Designers should generally consider using a wrapper service when the goal is to
integrate with an existing application that offers an API or an integration component.

© Drexel University Software Engineering Research Group (SERG)

[Link]
52
 Wrapper Service
<<Wrapper Service>>

Service
Adapter
<<proxy>>
UML

Service New Adapter

Interface Component

{middleware}

Legacy Application

A wrapper service exposes specific parts of legacy applications through a service interface. This service style essentially creates a
Description

new interface component, called an adapter, that adheres to good design principles of a business service. The adaptor component
uses EAI to interact with a legacy application. The legacy application itself might require modification to support this style as the
desired business logic that is exposed by the adapter component may not be accessible via direct EAI mechanisms. This service
style is a good choice for application integration.

Design the adapter component in a wrapper service style using the same principles that were described in the design guidance for a
Guidance

Business Service. Map the service interface in the adapter to functionality and business rules that exist in the legacy application.
Design

When possible interact with the legacy capability via EAI. In some cases the legacy system itself might require modification to
support the adapter service interface (e.g., the business logic is embedded and not externally accessible)

© Drexel University Software Engineering Research Group (SERG)

[Link]
53
 Controller Service
<<Controller Service>>

Business Process

[service] [service] [service]

UML

Service
Interface

<<service assembly>>

A controller service represents the execution of a high-level business task (or simple business workflow). Services designed using
Description

the controller style create control logic to implement the business task. This control logic is called a service assembly. From an
SOA perspective its important to manage the granularity of the service designs. Services that are too abstract are prone to high
maintenance problems as their interfaces and behaviors are subject to a high degree of change. Aggregate services, such as a
controller service provide additional flexibility to SOA-designs by creating a service that supports a business task, while at the
same time, allowing the underlying services to be used and evolve independently.

Whenever possible deploy the service assembly in the same container as the subordinate services. This enables the service
Guidance

assembly to interact with the other (subordinate) services via a local interface rather than a network interface such as SOAP. Also,
Design

since web service support is still very limited with respect to supporting context and transactions this guidance also allows the
controller to work with the underlying services in a stateful way (i.e., supports ACID transactions).

© Drexel University Software Engineering Research Group (SERG)

[Link]
54
 Coordination Service
<<Coordination Service>>

Business
Transaction Workflow / Business Process

in}
{beg
UML

[service] [service]
Service
Interface

{co
mm [service]
it}
[service]

<<business process with ACID transaction support>>

Description

A coordination service supports executing a workflow to implement a business unit-of-work (BUOW). The BUOW in a coordination
service should be short-running as this service style supports ACID transactions. Unlike a controller service, the workflow in a
coordination service is externalized, defined using a standard markup (i.e., BEPL), and executed by an infrastructure component
that manages the actual workflow process.
Guidance

The transaction-oriented workflow outlined above is the topic of the WS-Transaction specification. With this specification
Design

workflows are defined using the BEPL markup. Given lack of BEPL support in the tools that we are using in class, applications
requiring the characteristics of a coordination service should use a controller service instead an code the business process into the
service assembly.

© Drexel University Software Engineering Research Group (SERG)

[Link]
55
 Workflow Service
<<Coordination/Workflow Service>>

Business
Process Workflow / Business Process

in} Context
{beg Service
UML

[service] [service]

Service Coordination
Interface Service

{com [service]
mit}
Compensation
[service] Service

<<business process with compensated transaction support>>

Description

A workflow service implements a business process. The workflow service does not support ACID transactions because the
business process might be long-running (i.e., several days, require human intervention, etc.). Unlike a controller service, the
workflow in a coordination service is externalized, defined using a standard markup (i.e., BEPL), and executed by an infrastructure
component that manages the actual workflow process. Due to the nature of the workflow service style ACID types of transactions
are not supported, instead, a compensation service is provided in this model to gracefully recover from unexpected problems.

The workflow outlined above is the topic of the WS-Transaction and WS-Coordination specifications. With these specifications,
Guidance
Design

workflows are defined using the BEPL markup. Given lack of BEPL support in the tools that we are using in class, applications
requiring the characteristics of a workflow service should use a controller service instead an code the business process into the
service assembly.

© Drexel University Software Engineering Research Group (SERG)

[Link]
56
Blueprints for SOA Designs

Application/Service integration views

 Shows the application functionally
decomposed (MVC Pattern for thin client)
 Shows the application in context of services
that are consumed
 Defines all application/service integration
points
Service Views
 Defines services in terms of the reference
architecture

© Drexel University Software Engineering Research Group (SERG)

[Link]
57
References
“From Objects to Services: A Journey in Search of Component Reuse Nirvana” by
M. Dodani, Journal of Object Technology vol3, no. 8,
[Link]
“Service-Oriented Architecture : A Field Guide to Integrating XML and Web
Services” by T. Erl, Prentice Hall , ISBN: 0131428985
“What Is An Enterprise Service Bus?”, by M. Gilpin, Forrester Research,
[Link]

© Drexel University Software Engineering Research Group (SERG)

[Link]
58