A Reference Architecture for Service Oriented Architecture ...bmitchell/course/cs575/... · “Service Oriented Architecture (SOA) is an approach to the development of loosely coupled,

1© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu

A Reference Architecture forService Oriented Architecture (SOA)


Motivation

Why do we need SOARedundancyImplementation inconsistencyLack of inter-operability“Wrapper”-HappyLack of Modularity

Misconception: SOA is about design and not technology (i.e., WebServices)


What is SOA? ---- Randy Heffner, Forrester Research

http://orchestrationpatterns.com/?q=node/13

"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)”


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 Web Services sets…”And so on…

Source: http://orchestrationpatterns.com/?q=node/13


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 Web Services sets…”And so on…

Source: http://orchestrationpatterns.com/?q=node/13

It’s a bit confusing… is SOAabout:

1. Web Services

2. Business Architecture

3. Services

4. “Loose Coupling”

5. Integration

6. All of the above?

7. Or something else…


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 publishedand available for invocation on a Service Bus. Adopting SOA is essential to delivering the business agility and IT flexibility promised by Web Services…”

Source: http://msdn.microsoft.com/architecture/soa/default.aspx

Microsoft uses a Metropolisanalogy 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


IBM & SOA….

Source: http://www-306.ibm.com/software/solutions/webservices/

IBM’s Website on SOA (linked here fromdeveloperworks.com)is clearly targeted atselling IBM tools andprofessional services…


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…


SOA Buzz…… you however will be well equipped to play“buzzword bingo” at the meeting where somebodytries to explain SOA…


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 beconstructed to govern common aspects of all applications built in accordancewith this style…


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 addressableServices are language and platform independentServices have flexible instantiation capabilitiesServices are statelessMessages are formally defined by a service contract…


The “Actors” in an SOA – Service Consumers, Service Providers & Messages

Service Consumer

Service Provider

Message

Inte

rmed

iary

Serv

ice

ConcreteService

Service

ConsumedService

Interface

Application

ProvidedService

Interface


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 ProgramsThird party tools: Siebel

Services are designed to have flexible interfaces and are evolved easilyServices separate the concerns of the service consumer from the service provider

Services can be instantiated in a variety of different waysLocal components, Web Services, Sync-/Asynchronous Messages

Services are lifecycle managed by an application server container of some sort

CICS, .Net Framework, J2EE (WebSphere, Axis)


The Architectural Connectors -Messages

Services interoperate with each other using “messages” capable of verifying and certifying their own syntax and semanticsArchitecture Requirements for Messages

Messages do not assume any sort of delivery technologyMessages support intermediaries and can be transformed between the service consumer and the service provider without either party being aware of the transformation processMessages can be secured end-to-endMessages can be deserialized into language-specific componentsLanguage specific components can serialize themselves into a valid message that adheres to both the syntactic and semantic requirements of the message


Messages and XML

In a SOA, messages are generally encoded as XML documentsCharacter-based encoding is the lowest-common denominator for almost every computing and message-transport platformResearch into XML parsing has produced parsers that can produce and digest XML documents very fastThe valid structure of messages encoded as XML can be specified using a standard description language – XML SchemaXML Namespaces support the flexible extension of service interfacesXML is governed by a wide verity of standards

SecurityTransformationIndustry-specific business transactionsVendor-specific schemas


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 amaximum degree of backward-compatibilityInterface specifies the semantics used by the service provider

Loosen the coupling between an application and the databaseAllows current data sources to be aggregated behind a service interfaceAllows 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


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 supportsService contracts define “subject areas” that support the various business events supported by the service

Service contract can be used by a service invocation frameworkExamples: WSDL for Web Services


Best Practices for Interface and Message Design in SOA

Service interfaces should be build around the specification and execution of useful application/business eventsThe service interface should define a collection of “subject areas” that are relevant to the application/business events supported by the service

<ServiceRequestMessage><MessageHeader>

<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.


Some Misconceptions about Services

Services are not Database API’sUse 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 SOAReuse of a service is nice if you can find a requirement for it

A service is best thought of as an authoritative access point toexecute application/business events around a particular businesssubject areaA service is a great place to get a business context aware “viewof the truth”


We will see later that services come in different styles

Service StylesBasic ServicesIntegration ServicesComposite Services


Anti-Best Practice for Creating Services: The “Right-Click” method…


.Net is no better for directly promotinga 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 class that is public and decorated with “[WebMethod]” becomes part of the service interface

<%@ WebService Class="ClassName_Goes_Here" %>


Design Service Like Mini-Applications

PersistedStructures

Request-Tier

WebServer

MessageValidation

Service InterfaceTier

ServiceImplementation

DomainObjectBuilder

MessageSerialization

Objects

Services should usetype-safe objects thatserialize/deserialize

to XML in accordancewith the service

contract

Domain ObjectTier

DomainObjects

DataAccessObjects

Business EventAction Factory

Actions(Events)

The domain tierrepresents thebusiness domainand is unaware of how the businessobjects are persisted.Business logic goeshere.

Data-AccessTier

Data accessobjects areaware of howto persistdomain

objects in a database.

DatabaseTier

StoredProcedures

MainframeTransactions

Other…(Messaging)

Databases

The domain layer is bound to the data access layer by action objects thatmanage business event transactions

Business EventChange Publisher

MessageQueue

LocalObjects


Outline

Objects and ComponentsService Oriented Reference Architecture

SOA Functional ViewSOA Architectural ViewSOA MessagingSOA Interfaces (provided & required)ESB


Objects and Components (again)

Services are the main entities in applications constructed using SOA principlesServices are constructed using components, which in turn, are created using objects

Reviewing principles of objects and components is helpful in understanding how to design servicesServices can then be placed in context of a reference architecture for SOA


Principles of OO

AbstractionAn object is known by its data type and behavior, providing a stable interface for communicating with and using the object.

EncapsulationImplementation decisions are hidden inside of classes and were protected by variables (properties) and methods that were explicitly made public to the outsideAllows for the separation of interface from implementation

PolymorphismThe ability for an class to take on different behavior-based on the runtime binding to object types


Principles of OO

InheritanceThe 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.

IdentityA class is a template for objects and objects are instances of classesAll objects can be uniquely defined, have their own unique identity, and manage their unique state


Design Principles for OO

Program to interface not implementationTo 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 propagateMaximize cohesion within an object


Design Principles for OO

Good interface design is essentialIt does not expose the underlying attributes (class level) or the underlying classes (subsystem/component level)Does not expose the underlying implementationDoes a logical unit of workA change to the system should not require a change to the interface (property of good abstraction)


Problems with OOThe design principles of OO scale to design principles for services in an SOAOO 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 changesDistribution was handled manually using low level network protocolsInterface design had to be “perfect”, but this was difficult to do in practiceAll types must be binary compatibleType conversion and object serialization/deserialization was a manual process


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 interfaceComponents are only able to provide a single interface to their clientsDesigns using components are “chatty”, often requiring many components to perform a “useful” operation – this makes scalability difficult

Component frameworks are proprietaryCOM, DCOM, CORBA, J2EE/EJB


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., Microsoft.Net, J2EE)

Standardizes resource allocation and sharing that is tightly integrated into component modelAble 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”


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 componentSupport asynchronous programming modelsSupport common architecture styles (e.g., Pub-Sub)Support severs implemented in a different technology from the requestorSupport applications with high-reliability requirementsSupport external routing information



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 queueQueues 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



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 formatThe asynchronous programming model is more difficult for programmers to deal with than a synchronous programming modelDeployment of applications using messaging infrastructure is fragmented


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 principlesContainers 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 seamlesslyStandardize the format and define semantics for the messaging payloadsSupports external definition of routing and QoS of related to the delivery of messages


SOA Revisited

SOARepresents every application or resources as a service with a standardized interfaceIs 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


Service revisited

A service is :A component that does something useful on behalf of an applicationExposes its functionality and hides the implementation detailsNot 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 anotherDependencies between services should be defined in terms of an application process


An SOA Reference Architecture


SOA Reference Model 101

Requestor

Provider

Message

Message TypeDelivery MethodDelivery Channel

Transport ProtocolPayload Format

Encoding SemanticsExtensions

Inte

rmed

iary

Serv

ice

FunctionalService

Service

ServiceInterface

Application


Components of the SOA Reference Architecture

ServiceFunctional

Type

ServiceStyle

ServiceMessaging

Models

Service Interface

Quality of Service (QoS)

Characteristics

App

licat

ion

Spec

ific

Com

pone

nts

Serv

ice

Inte

grat

ion

Ada

pter

s

Application Service Integration


Establishing the Functional Aspect of the Service in an SOA

Service Types

Component ServiceSimple services potentially acting on single enterprise resource (e.g., database, code, etc) and are created by aggregating and/or encapsulating one or more application-specific component interface(s)

Business ServiceComponent services composed of combinations of component services and rules.

Data ServiceServices providing data querying, combination and transformation for multiple data sources.

Business Process ServiceLong lived business processes coordinating other services with external interactions.

Tran

spor

t

HTTP

/HT

TPS

Mess

age

Brok

erW

S-Re

liabl

eMe

ssag

ing

Serv

ice C

onsu

mer

s

Porta

lW

eb App

Othe

rSe

rvice

sAp

plica

tion

Code

Partn

ers

Core Services

Security ServicePolicies

ServiceManager

TCP/

IPRP

C

Serv

ice R

esou

rces

Othe

rSe

rvice

sAp

plica

tion

Code

Lega

cyPa

rtner

sDa

taba

se

Service Requestor Message Service Provider

(or Service Intermediary)

Lega

cy

Files

3rdPa

rtyAp

plica

tions

Event-Driven ServiceServices that react, publish or implement enterprise business events.


The Enterprise Architecture Reference Model for SOA

Services

Utilit

ySe

rvice

Wor

kflo

wR

ules

XML Processing

Serv

ice

Rep

osito

ry

SOA

Patte

rns

ESB

Infra

stru

ctur

eB

usin

ess

Proc

ess

Met

adat

aC

ompo

sitio

nR

outin

gC

achi

ng

Inte

grat

ion

Qua

lity

of S

ervi

ceTr

ansf

orm

atio

nC

oord

inat

ion

Data Transformation

Controller Service (Simple Business

Process Composition)

Wrapper Service

Coordination Service(ACID Transaction)

Workflow Service(Business Process,

Business Transaction)

Proxy Service

Basic Service

Functional Services

Ser

vice

Arc

hite

ctur

al S

tyle

s

Application

Presentation

ApplicationComponents

Application Framework

Components

Design & Architectural

Patterns

SOA DesignMessaging

Inte

r-, In

tra-,

and

Extra

net G

atew

ays

QoS

-Clu

ster

ing/

Load

Bala

ncin

g

Core

Infra

stru

ctur

eIn

frast

ruct

ure

Com

pone

nts

StorageWarehouseODS BOR Data Mart

ETL

3rd Party Integration

PurchasedApplications

PartnerApplications

Messaging / Transactions / EAI

WebSphereJ2EE

Microsoft.Net CICS

Containers

Legacy

LegacyApplication

LegacyApplication

LegacyApplication

Process/PM

SDLC MethodologyManagement

Components

Mes

sagi

ng /

Tra

nsac

tions

/ E

AI

Mes

sagi

ng /

Tra

nsac

tions

/ E

AIMessaging / Transactions / EAI

Database

InternalApplications

Policy Enforcement

Reporting / Information Management

OperationalReporting

ReportingApplications

Analytical Reporting

Secu

rity

Via Data Service

DataApplication

DomainEnterprise

Architecture DomainCorporate

Domain InfrastructureLegend: MessagingInterface


Messaging Taxonomy SOA Transport Models for Messages Supported by the Reference Architecture

Protocol Payload Format Extensions Delivery

MethodDeliveryPattern

TCP/IP

HTTP/HTTPS

RMI

IIOP

.Net Remote

MQ

WS-Reliable Messaging

XML

Binary

SOAP

XML-RPC

CORBA

Custom/ Proprietary

Serialized Object

Attachments

Message Metadata (Security, Session, Context, etc.)

Message Schema

Marshalling and DatatypeSpecifications

Synchronous

Asynchronous

Delivery QoSAt Least Once

At Most Once

Exactly Once

One-WayCommandEvent

Request/Reply

Point-to-PointOne-to-Many

Publish/Subscribe

EncodingSemantics

RPCThe payload contains attributes that directly bind to service parameters

Document-Centric

The payload is encoded as a structured document

Endpoint Addressing


Service Specification

Step 1:Select Service

Type

Step 2:Select Service

Style

Each designed service should be classified by its service type

Once a service type is defined, a service style should be selected based on the desired architectural characteristics of the service, its required resources, and potential consumers

Step 4:Define

SupportedMessaging

Models

A service may be integrated into multiple applications under different contexts, therefore, the service design should also consider the messaging models that will be supported by the service

Step 3:Specify Service

Interface

Each service should provide a well-designed interface encapsulating the desired service behavior

Step 5:Define Quality of

Service (QoS) Characteristics

A service should also specify its required and provided QoSattributes such as security, transactions, performance, etc.


The Service Styles are Related

Basic Services Integration Services Composite Services

BasicService

UtilityService

[is a special type of]

ProxyService

WrapperService

[is a specialization of]

ControllerService

WorkflowService

CoordinationService

[adds externalizedworkflow capabilities to]

[adds ACID transactionsupport to]


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 SOAAn ESB

Facilitates effective service communicationFacilitates effective service integrationFacilitates effective service interaction


ESB Interfaces

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.

Control

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.

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.

Description

Change

Connection

ESB Interface


ESB Features

Support for mapping of data formats of message payloads in cases where the service requestor and provider have different interface formats

Transformation and Mapping

The ESB may implement microprocesses that aggregate smaller services into larger services, which may also require transaction management.

Service Aggregation

The ESB provides support for compensated transactions, working with other TP monitors to handle ACID transactions

Transaction Management

Support for subject-, content-, and itinerary-based routing. The ESB transparently routes requests to the correct version of the service interface, as well as managing the version instances.

Supports the ESB messaging requirements (protocol, style, sync, async, etc.)

Description

Request Routing and Versioning

Communication

ESB Features

When maintaining a name space (service discovery), the ESB may extend the service metadata this requires (such as WSDL), to enable services to be classified to ease searching for reuse.

Service Registry and Metadata Management

The ESB automate management as much as possible, it will also be necessary to enable humans to investigate problems, find root causes, and take action to correct the issues that are discovered.

Monitoring and Management

A special case of semantic mapping, enrichment enables database or table lookups to be merged into a message stream so that messages emerge from the bus richer with data than when they arrived.

Extensibility for Message Enrichment

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 otherwise unreliable networks and services can be made to provide the quality of service required by the requester.

The ESB supports security policies regarding service usage

Description

Quality of Service

Security

ESB Features


Utility Service<<Utility Service>>

<<component>> <<component>>


ServiceInterface

<<reusable business logic>>

Des

crip

tion

Des

ign

Gui

danc

eU

ML

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.

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


Basic Service

Des

crip

tion

Des

ign

Gui

danc

eU

ML

A basic service encapsulates the functionality implemented in one or more business components by specifying a well-defined 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 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)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.

<<Basic Service>>



ServiceInterface

<<business logic>>


Proxy Service<<Proxy Service>>

ServiceProxy

<<generated>>

ExistingApplicationComponent

ServiceInterface

Des

crip

tion

Des

ign

Gui

danc

eU

ML

A proxy service “service-enables” an existing application component by creating a service proxy component that “facades” the 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 anapplication 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 when compared to other service types. Problems generally occur with proxy service designs because the underlying component ‘s 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.


Wrapper Service<<Wrapper Service>>

ServiceAdapter

<<proxy>>

New AdapterComponent

ServiceInterface

Legacy Application

{middleware}

Des

crip

tion

Des

ign

Gui

danc

eU

ML

A wrapper service exposes specific parts of legacy applications through a service interface. This service style essentially creates a new interface component, called an adapter, that adheres to good design principles of a business service. The adaptor componentuses 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 Business Service. Map the service interface in the adapter to functionality and business rules that exist in the legacy application. When possible interact with the legacy capability via EAI. In some cases the legacy system itself might require modification tosupport the adapter service interface (e.g., the business logic is embedded and not externally accessible)


Controller Service

Des

crip

tion

Des

ign

Gui

danc

eU

ML

A controller service represents the execution of a high-level business task (or simple business workflow). Services designed using 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 assembly to interact with the other (subordinate) services via a local interface rather than a network interface such as SOAP. Also, 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).

<<Controller Service>>

ServiceInterface

Business Process

[service] [service] [service]

<<service assembly>>


Coordination Service<<Coordination Service>>

ServiceInterface

Workflow / Business Process

[service]

[service]

[service]

<<business process with ACID transaction support>>

[service]

BusinessTransaction

{begin}

{commit}

Des

crip

tion

Des

ign

Gui

danc

eU

ML

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.

The transaction-oriented workflow outlined above is the topic of the WS-Transaction specification. With this specification 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.


The workflow outlined above is the topic of the WS-Transaction and WS-Coordination specifications. With these specifications, 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.

Workflow Service

Des

crip

tion

UM

L

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.

<<Coordination/Workflow Service>>

ServiceInterface

Workflow / Business Process

[service]

[service]

[service]

<<business process with compensated transaction support>>

ContextService

CoordinationService

CompensationService[service]

BusinessProcess

{begin}

{commit}

Des

ign

Gui

danc

e


Blueprints for SOA Designs

Application/Service integration viewsShows the application functionally decomposed (MVC Pattern for thin client)Shows the application in context of services that are consumedDefines all application/service integration points

Service ViewsDefines services in terms of the reference architecture


References

“From Objects to Services: A Journey in Search of Component Reuse Nirvana” by M. Dodani, Journal of Object Technology vol3, no. 8, http://www.jot.fm/issues/issue_2004_09/column5. “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, http://www.forrester.com/go?docid=35193.

Documents

A Reference Architecture for Service Oriented Architecture ...bmitchell/course/cs575/... · “Service Oriented Architecture (SOA) is an approach to the development of loosely coupled,