SOA

A Reference Architecture for Service Oriented Architecture (SOA)
Drexel University Software Engineering Research Group (SERG) http://serg cs !rexel e!u
Motivation
Why do we need SOA

Redundancy Implementation inconsistency ac! of inter"opera#ility $Wrapper%"&appy ac! of Modularity
Misconception' SOA is a#out desi(n and not technolo(y (i)e)* We#Services)

What is SOA, """" Randy &effner* -orrester 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 !uality of service (!oS) characteristics (security, transactions, performance, etc") are e#plicitly identified at design time Software infrastructure takes active responsibility for managing !oS and enforcing policy for service access and e#ecution Services and their metadata are cataloged in a repository $rotocols and structures within the architecture are, optionally, based on industry standards (e"g", the emerging S%A$ stack of standards)&
http'..orchestrationpatterns)com.,/0node.1+
What is SOA, """" More definitions

2he orchestration patterns we#site outlines 12 additional definitions of SOA from industry e3perts4 2he diversity in definitions is interestin(4

$Service Oriented Architecture (SOA) is an approach to the development of loosely coupled* protocol"independent distri#uted applications4% $SOA is a form of technolo(y architecture that adheres to the principles of service orientation4$ 5Service"oriented architecture is an architectural discipline4% $SOA is a style of desi(n that strives to ena#le easy inte(ration and fle3i#le applications4$ 5A service oriented architecture is an approach to desi(n and inte(rate software in a modular method where each module is precisely a 6loosely coupled service6 ***% $Service Oriented Architecture is nothin( #ut #usiness oriented architecture4% $SOA is a framewor! ena#lin( application functionality to #e provided* discovered and consumed as re"usa#le We# Services sets4% Source: http:''orchestrationpatterns"com'()*node'+, And so on4
What is SOA, """" More definitions

2he orchestration patterns we#site outlines 12 additional -t.s a bit confusing/ is S%A definitions of SOA from industry e3perts4 2he diversity in about: definitions is interestin(4

Services $Service Oriented Architecture (SOA)+" is 0eb an approach to the development of loosely coupled* protocol"independent distri#uted applications4% 1" 2usiness $SOA is a form of technolo(y architecture that adheres to the principles of service Architecture orientation4$ 5Service"oriented architecture is an architectural ," Services discipline4% $SOA is a style of desi(n that strives to ena#le easy inte(ration and fle3i#le 3" 45oose 6oupling& applications4$ 5A service oriented architecture is an7" approach to desi(n and inte(rate software -ntegration in a modular method where each module is precisely a 6loosely coupled 8" All of the above( service6 ***% $Service Oriented Architecture is nothin( #usiness else/ oriented architecture4% 9" %r#ut something $SOA is a framewor! ena#lin( application functionality to #e provided* discovered and consumed as re"usa#le We# Services sets4% Source: http:''orchestrationpatterns"com'()*node'+, And so on4
7
Microsoft and SOA4

" #icrosoft $iew on S%": $2he (oal for Service Oriented Architecture (SOA) is a world"wide mesh of colla#oratin( services that are pu#lished and availa#le for invocation on a Service 9us) Adoptin( SOA is essential to deliverin( the #usiness a(ility and I2 fle3i#ility promised #y We# Services4%
:icrosoft uses a :etropolis analogy to e#plain S%A/ ;he idea being that cities, like an S%A, re)uire services (police, manufacturing, shopping, etc") and a transportation (bus, railroad, etc") system to thrive
Source: http:''msdn"microsoft"com'architecture'soa'default"asp#
I9M ; SOA4)
-2:.s 0ebsite on S%A (linked here from developerworks"com) is clearly targeted at selling -2: tools and professional services/
Source: http:''www ,<8"ibm"com'software'solutions'webservices'

SOA
=ou may either feel educated or sleepy by now, but you probably know little more than when you arrived at this class about S%A/
<
SOA 9u>>4
/ you however will be well e)uipped to play 4buzzword bingo& at the meeting where somebody tries to e#plain S%A/
Service Oriented Architecture is an @3ample of an Architectural Style

An "rchitectural Style defines a family of systems in terms of a pattern of structural or(ani>ation)

2ecause S%A is an Architectural Style a >eference Architecture can be constructed to govern common aspects of all applications built in accordance with this style/
What are the architectural components, What are the architectural connectors, What patterns (uide the desi(n of the components and connectors, &ow are faults and une3pected events handled, Alear definition of the set of constraints on the architectural components and the relationships that are allowed #etween them
1?
Service Oriented Architecture is an @3ample of an Architectural Style

SOA as an Architectural Style'
What are the architectural components,

Services
What are the architectural connectors,

Messa(es
What patterns (overn the desi(n of the components and connectors,

Bata Services* 9usiness Services* Aomposite Services
&ow are faults and une3pected events handled,
an(ua(e specific e3ception handlin( mapped to service faults
Alear definition of the set of constraints on the architectural components and the relationships that are allowed #etween them
Services are networ! addressa#le Services are lan(ua(e and platform independent Services have fle3i#le instantiation capa#ilities Services are stateless Messa(es are formally defined #y a service contract 4
11
2he $Actors% in an SOA C Service Aonsumers* Service Droviders ; Messa(es

Service $rovider Service 6onsumer
:essage
Service
Consumed Service Interface Provided Service Interface
&nter'e!ia ry Service
"pplicat ion
(oncret e Service
12
2he Architectural Aomponents " Services

Services are a conceptual !esign co'ponent* and can #e implemented usin( a variety of different technolo(ies

Eava 9eans* (@nterprise Eava 9eans) )Fet Alass -iles (ASMG) AO9O Dro(rams 2hird party tools' Sie#el
Services are desi(ned to have fle3i#le interfaces and are evolved easily
Services separate the concerns of the service consumer from the service provider ocal components* We# Services* Sync".Asynchronous Messa(es
Services can #e instantiated in a variety of different ways
Services are lifecycle mana(ed #y an application server container of some sort
AIAS* )Fet -ramewor!* E2@@ (We#Sphere* A3is)

1+
2he Architectural Aonnectors " Messa(es

Services interoperate with each other usin( $messa(es% capa#le of verifyin( and certifyin( their own synta3 and semantics Architecture Re/uirements for Messa(es

Messa(es do not assume any sort of delivery technolo(y Messa(es support intermediaries and can #e transformed #etween the service consumer and the service provider without either party #ein( aware of the transformation process Messa(es can #e secured end"to"end Messa(es can #e deseriali>ed into lan(ua(e"specific components an(ua(e specific components can seriali>e themselves into a valid messa(e that adheres to #oth the syntactic and semantic re/uirements of the messa(e
11
Messa(es and GM
In a SOA* messa(es are (enerally encoded as GM documents
Aharacter"#ased encodin( is the lowest"common denominator for almost every computin( and messa(e"transport platform Research into GM parsin( has produced parsers that can produce and di(est GM documents very fast 2he valid structure of messa(es encoded as GM can #e specified usin( a standard description lan(ua(e C GM Schema GM Famespaces support the fle3i#le e3tension of service interfaces GM is (overned #y a wide verity of standards
Security 2ransformation Industry"specific #usiness transactions Hendor"specific schemas
17
9enefits of the SOA Architectural Style

Its all a#out the interface4
oosen the couplin( #etween a service component and the re/uestin( application
Support easy and rapid evolution of the service interface with a ma3imum
de(ree of #ac!ward"compati#ility Interface specifies the semantics used #y the service provider
oosen the couplin( #etween an application and the data#ase

Allows current data sources to #e a((re(ated #ehind a service interface Allows the underlyin( data sources to evolve as authoritative data sources
are created
Messa(es define the types used #y the interfaces of the service consumer and the service provider
18
9est Dractices for Service Besi(n in an SOA

Services for an SOA should #e #uilt usin( the $Besi(n #y Aontract% approach
Service contract developed first usin( a standard description lan(ua(e* typically GM Schema
2he service contract defines the service interface* encodes the messa(e
structure* and defines the messa(e semantics
Services interfaces define the interface types* as such service pro(rammers should not #e wor!in( at the GM level
O#Iects should #e (enerated for the service interface from the service
contract (i)e)* GSBO#IectJen for )Fet* EAG9 for Eava)
Service contracts should #e desi(ned for e3tension* and or(ani>ed around #usiness events that the service supports Service contracts define $su#Iect areas% that support the various #usiness events supported #y the service @3amples' WSB for We# Services
Service contract can #e used #y a service invocation framewor!
1:
9est Dractices for Interface and Messa(e Besi(n in SOA

Service interfaces should #e #uild around the specification and e3ecution of useful application.#usiness events 2he service interface should define a collection of $su#Iect areas% that are relevant to the application.#usiness events supported #y the service
<ServiceRequestMessage> <MessageHeader>  <BusinessEvent> <! Enumeration of supported usiness events goes here --> <!BusinessEvent> <!MessageHeader> <MessageBod"> <Su #ect$rea%>&&&<!Su #ect$rea%> <Su #ect$rea'>&&&<!Su #ect$rea'> <Su #ect$rea(>&&&<!Su #ect$rea(> <!MessageBod"> <!ServiceRequestMessage>
;he application'business event coupled with the provided sub?ect areas dictates what a service will do on behalf of the consumer, this model fits in naturally to business processes where the 4current view of the truth& might be dependant on the state of the business process"
1<
Some Misconceptions a#out Services

Services are not Bata#ase ADIKs
Lse stored procedures for $#lac! #o3% operations on data
A service can #e implemented as a We# Service* #ut a We# Service is not necessarily a service in an SOA Reuse of a service is nice if you can find a re/uirement for it
A service is #est thou(ht of as an authoritative access point to e3ecute application.#usiness events around a particular #usiness su#Iect area A service is a (reat place to (et a #usiness conte3t aware $view of the truth%
1=
We will see later that services come in different styles Service Styles

9asic Services Inte(ration Services Aomposite Services
2?
Anti"9est Dractice for Areatin( Services' 2he $Ri(ht"Alic!% method4
21
)Fet is no #etter for directly promotin( a component to a service4

Becorate a component interface with $[WebMethod]% Areate a file with an $)a3m3% e3tension with a sin(le line'
Any method the components class that is pu#lic and decorated <)* +e in Service ,lass-.,lass(ame/0oes/Here. )> with $[WebMethod]% #ecomes part of the service interface
22
Besi(n Service i!e Mini" Applications

>e)uest ;ier
0eb Server :essage !ueue
Service -nterface ;ier

Service -mplementation
Aomain %b?ect ;ier

Aomain %b?ects
Aata Access ;ier

Aata Access %b?ects
Aatabase ;ier
:essage Serialization %b?ects Aomain %b?ect 2uilder
2usiness Cvent 6hange $ublisher ;he domain layer is bound to the data access layer by action ob?ects that manage business event transactions 2usiness Cvent Action Dactory
$ersisted Structures Stored $rocedures Aatabases :ainframe ;ransactions %ther/ (:essaging)
:essage @alidation
5ocal %b?ects
Services should use type safe ob?ects that serialize'deserialize to B:5 in accordance with the service contract
;he domain tier Aata access represents the Actions ob?ects are business domain (Cvents) aware of how and is unaware to persist of how the business domain ob?ects are persisted" ob?ects in a 2usiness logic goes database" here"
2+
Outline
O#Iects and Aomponents Service Oriented Reference Architecture

SOA SOA SOA SOA @S9
-unctional Hiew Architectural Hiew Messa(in( Interfaces (provided ; re/uired)
21
O#Iects and Aomponents (a(ain)

Services are the main entities in applications constructed usin( SOA principles Services are constructed usin( components* which in turn* are created usin( o#Iects
Reviewin( principles of o#Iects and components is helpful in understandin( how to desi(n services Services can then #e placed in conte3t of a reference architecture for SOA
27
Drinciples of OO
A#straction
An o#Iect is !nown #y its data type and #ehavior* providin( a sta#le interface for communicatin( with and usin( the o#Iect) Implementation decisions are hidden inside of classes and were protected #y varia#les (properties) and methods that were e3plicitly made pu#lic to the outside Allows for the separation of interface from implementation 2he a#ility for an class to ta!e on different #ehavior"#ased on the runtime #indin( to o#Iect types
@ncapsulation
Dolymorphism
28
Drinciples of OO
Inheritance
2he a#ility of one o#Iect to inherit the representation and #ehavior from another o#Iect) 2his inherited #ehavior and representation can #e selectively used $as is%* e3tended* or replaced) A class is a template for o#Iects and o#Iects are instances of classes All o#Iects can #e uni/uely defined* have their own uni/ue identity* and mana(e their uni/ue state
2:
Identity

Besi(n Drinciples for OO

Dro(ram to interface not implementation 2o e3tend #ehavior* favor o#Iect composition over inheritance C e3tended #ehavior and ori(inal #ehavior are preserved
2his prevents a chan(e to the ori(inal #ehavior from impactin( inherited #ehavior
Minimi>e couplin( #etween o#Iects to ensure that chan(es are locali>ed and do not propa(ate Ma3imi>e cohesion within an o#Iect
2<
Besi(n Drinciples for OO

Jood interface desi(n is essential
It does not e3pose the underlyin( attri#utes (class level) or the underlyin( classes (su#system.component level) Boes not e3pose the underlyin( implementation Boes a lo(ical unit of wor! A chan(e to the system should not re/uire a chan(e to the interface (property of (ood a#straction)
2=
Dro#lems with OO
2he desi(n principles of OO scale to desi(n principles for services in an SOA OO has scala#ility and comple3ity limitations
Alasses have to have compile or lin! time visi#ility to all other classes C this implies repac!a(in(.deployin( an entire application unit when a class chan(es Bistri#ution was handled manually usin( low level networ! protocols Interface desi(n had to #e $perfect%* #ut this was difficult to do in practice All types must #e #inary compati#le 2ype conversion and o#Iect seriali>ation.deseriali>ation was a manual process
+?
Aomponents
Aomponents a((re(ate classes and focus on pac!a(in( and distri#ution
OO desi(n principles directly map to component desi(n principles
Met component approaches to software desi(n have their pro#lems'

Aomponents must still provide a sta#le interface Aomponents are only a#le to provide a sin(le interface to their clients Besi(ns usin( components are $chatty%* often re/uirin( many components to perform a $useful% operation C this ma!es scala#ility difficult AOM* BAOM* AOR9A* E2@@.@E9
+1
Aomponent framewor!s are proprietary

Step 1' Aontainers to the rescue4

Aontainers (a)!)a application servers) are li!e application"aware operatin( systems that sit on top of the native operatin( system (e)()* Microsoft)Fet* E2@@)

Standardi>es resource allocation and sharin( that is ti(htly inte(rated into component model A#le to introduce component"aware semantics
@)()* Secuirty attri#utes #ased on R9AA " #eyond read*
write* read"write* allow* deny
Aontainers a#stract many of the $hard% thin(s'
-indin( thin(s (directories)* mana(in( networ! resources* relia#ility* availa#ility* data#ase connections* security* $on demand%"stuff
Aode runnin( in a container is often called $mana(ed code%

+2
Step 2' Messa(in( infrastructure to the rescue4

2raditional distri#uted inter"opera#ility is (enerally achieved #y sendin( a #inary"encoded messa(e over a synchronous networ! connection (e)()* soc!et) 2his approach ma!es it hard to'

Drovide multiple interfaces for a component Support asynchronous pro(rammin( models Support common architecture styles (e)()* Du#"Su#) Support severs implemented in a different technolo(y from the re/uestor Support applications with hi(h"relia#ility re/uirements Support e3ternal routin( information
++

Messa(in( infrastructures are traditionally implemented as /ueues where messa(es* metadata and routin( information are placed into a /ueue and the messa(in( infrastructure routes the messa(e to from a source /ueue to a destination /ueue Nueues may have properties such as tri((ers so that when a messa(e of a certain type arrives it automatically invo!es a component to process the messa(e
+1

Messa(in( infrastructures also have their pro#lems'
2he format for the encoded messa(e is left to the user C meanin( the re/uestor and server must a(ree on the format 2he asynchronous pro(rammin( model is more difficult for pro(rammers to deal with than a synchronous pro(rammin( model Beployment of applications usin( messa(in( infrastructure is fra(mented
+7
Step +' Standards to the rescue C finally ena#lement of SOA is possi#le

SOA ta!es the #est from OO* Aomponents* Aontainers* and messa(in( infrastructures

OO and Aomponents provide the desi(n principles Aontainers and messa(in( infrastructures provide the runtime environment
Fow standards such as the WS"O set ena#le containers to support distri#uted components that'

Aan interoperate usin( messa(in( or synchronous messa(es seamlessly Standardi>e the format and define semantics for the messa(in( payloads Supports e3ternal definition of routin( and NoS of related to the delivery of messa(es
+8
SOA Revisited
SOA
Represents every application or resources as a service with a standardi>ed interface Is #ased on havin( services e3chan(e structured information (as opposed to an RDA call) Drovides facilities via a container to coordinate and mediate #etween the services so that they can #e invo!ed* used and chan(ed effectively
+:
Service revisited
A service is '

A component that does somethin( useful on #ehalf of an application @3poses its functionality and hides the implementation details Fot dependant on the conte3t or state of other services
A service either provides information or facilitates the processin( of an application feature ensurin( that the application state is chan(ed from one valid and consistent state to another Bependencies #etween services should #e defined in terms of an application process
+<
An SOA Reference Architecture
+=
SOA Reference Model 1?1

Message Type Delivery Method Delivery Channel Transport Protocol Payload Format Encoding Semantics Extensions
$rovider
>e)uestor
Message
Service
Service Interface
&nter'e!ia ry Service
"pplicat ion
)unctio nal Service
1?
Aomponents of the SOA Reference Architecture

Application Specific 6omponents
Service Dunctional ;ype
Service Style
Service -nterface
Service :essaging :odels
!uality of Service (!oS) 6haracteristics
Application
Service
Inte(ration
11
Service -ntegration Adapters
@sta#lishin( the -unctional Aspect of the Service in an SOA

Service >e)uestor :essage Service $rovider (or Service -ntermediary)
(o'ponent Service
Simple services potentially actin( on sin(le enterprise resource (e)()* data#ase* code* etc) and are created #y a((re(atin( and.or encapsulatin( one or more application"specific component interface(s)
Service (onsu'ers "pplicat %ther 2egac ion Services y (o!e
*usiness Service
,ransport /S0 Relia1le #essaging
Aomponent services composed of com#inations of component services and rules)
Data Service
Services providin( data /ueryin(* com#ination and transformation for multiple data sources)
Service Resources
#essag e *ro.er
Event0Driven Service
Services that react* pu#lish or implement enterprise #usiness events)
+artne rs %ther Services
/e1 "pp
-,,+/ -,,+S
*usiness +rocess Service

on( lived #usiness processes coordinatin( other services with e3ternal interactions)
Servic (ore Services Servic Securi e e #ana ty +olicie Drexel University Software Engineering Research Group (SERG) ger s http://serg cs !rexel e!u
+ort al
)iles
Data1as 2egac e y 3r! +arty "pplicatio ns
,(+/&+
"pplicat ion (o!e
+artn ers
Service ;ypes
R+(
12
2he @nterprise Architecture Reference Model for SOA

(ontainers /e1Sph #icros ere oft 78EE 9et +rocess/+# (&(S Data1a se SD2( #anage 'ent #etho!ology 3r! +arty &ntegration *asic Service
6oordination
Messa(in( . 2ransactions . @AI
&nfrastructu re Securi (o'ponent ty s
"pplication +resentati on "pplicatio n (o'ponen ts S%" Design Design 5 "rchitectu ral +atterns "pplicatio n )ra'ewor . (o'ponen ts
Services
)unctional Services
!uality of Service
Service Repository
Utility Service
;ransformation
+urchase! "pplication s
+roxy Service /rapper Service (ontroller Service (Si'ple *usiness (oor!ination +rocess Service (o'position) ("(&D /or.flow ,ransaction) Service (*usiness +rocess4 *usiness GM Drocessin( Dolicy @nforcement ,ransaction)
Service Architectural Styles
Hia Bata Service
-ntegration
&nternal "pplication s +artner "pplication s (o'ponent s
(ore &nfrastructure 6oS 0 &nter04 &ntra04 (lustering/ an! Extranet 2oa! Gateways *alancing
2usiness $rocess :etadata 6omposition
Messa(in (
ES* &nfrastructure
S%" +atterns
6aching
>outing
Rules
Wor!flow
Bata 2ransformation
2egacy 2egacy 2egacy "pplicatio 2egacy "pplicatio n "pplicatio n n
Reporting / &nfor'ation #anage'ent %peration Reporting "nalytical al "pplication Reporting Reporting s Enterprise
Storage
%DS
*%R
/arehou se
@2
Data #art
5egend:
"pplication Drexel University Software Engineering Research Group (SERG) (orporate "rchitecture &nfrastructure Data Do'ain Do'ain http://serg cs !rexel e!u Do'ain
#essaging &nterface
1+
Messa(in( 2a3onomy
S%A ;ransport :odels for :essages Supported by the >eference Architecture
$rotocol
$ayload Dormat
Cncoding Semantics
C#tensions
Aelivery :ethod
Aelivery $attern
;6$'-$
E;;$'E;;$S >:--%$ "Fet :! 0S
B:5 2inary S%A$ B:5 >$6 6%>2A 6ustom' $roprietary Serialized %b?ect
>$6
;he
Attachments :essage :etadata (Security, Session, 6onte#t, etc") :essage Schema :arshalling and Aatatype Specifications
Synchronous Asynchronous Aelivery !oS

At At
payload contains attributes that directly bind to service parameters
%ne 0ay
6ommand Cvent
5east %nce :ost %nce %nce
>e)uest' >eply
$oint %ne
>emote
Aocument 6entric
;he
to $oint to :any
C#actly
>eliable :essaging
payload is encoded as a structured document
$ublish' Subscribe
Cndpoint Addressing
11
Service Specification
Step +: Select Service ;ype Step 1: Select Service Style Step ,: Specify Service -nterface Step 3: Aefine Supported :essaging :odels Step 7: Aefine !uality of Service (!oS) 6haracteristics
Cach designed service should be classified by its service type
%nce a service type is defined, a service style should be selected based on the desired architectural characteristics of the service, its re)uired resources, and potential consumers
Cach service should provide a well designed interface encapsulating the desired service behavior
A service may be integrated into multiple applications under different conte#ts, therefore, the service design should also consider the messaging models that will be supported by the service
A service should also specify its re)uired and provided !oS attributes such as security, transactions, performance, etc"
17
2he Service Styles are Related

Basic Services
*asic Service Gis a special type ofH Utility Service
Integration Services
Composite Services
(ontroller Service Gadds e#ternalized workflow capabilities toH /or.flow Service Gadds A6-A transaction support toH (oor!inati on Service
+roxy Service Gis a specialization ofH /rapper Service
18
@S9
Where a container layered over the OS to facilitate the mana(ed code model* an @S9 lives within a container to provide function to services in an SOA An @S9

-acilitates effective service communication -acilitates effective service inte(ration -acilitates effective service interaction
1:
@S9 Interfaces
CS2 -nterface 6onnection
Aescription The ESB connection interface should fully support the synchronous and asynchronous e! service stac"s as ell as message#oriented middle are $M% Series&' (TTP)(TTPS' Microsoft *+ET Serviced Components' ,ava -emote Method Invocation $-MI&' *+ET -emoting' CICS host transactions* -ather than changing code in a service interface' the ESB is configured ith metadata to handle managing the service catalog' interface versioning' routing' .uality of service $%oS&' orchestration' security' !usiness rules' and other volatile duties* The control interface provides enterprise management capa!ilities that are outside the scope of the individual services managed !y the ESB* The control interface integrates ith standard infrastructure management facilities' handles service provisioning to maintain %oS commitments' and provides reports)logs on the health and operation of the ESB infrastructure*
6hange
6ontrol
1<
@S9 -eatures
CS2 Deatures Security !uality of Service Aescription The ESB supports security policies regarding service usage 2he @S9 can persist re/uests to messa(e /ueues and retry service operations when failures occur* implement failover to alternate servers* and other steps to ensure that otherwise unrelia#le networ!s and services can #e made to provide the /uality of service re/uired #y the re/uester)
CS2 Deatures 6ommunication
Aescription Supports the ESB messaging re.uirements $protocol' style' sync' async' etc*&
>e)uest >outing and Support for su!/ect#' content#' and itinerary#!ased @ersioning routing* The ESB transparently routes re.uests to the correct version of the service interface' as ell as managing the version instances* ;ransformation and :apping Service Aggregation Support for mapping of data formats of message payloads in cases here the service re.uestor and provider have different interface formats 2he @S9 may implement microprocesses that a((re(ate smaller services into lar(er services* which may also re/uire transaction mana(ement) The ESB provides support for compensated transactions' or"ing ith other TP monitors to handle 0CID transactions
Service >egistry and When maintainin( a name space (service :etadata :anagement discovery)* the @S9 may e3tend the service metadata this re/uires (such as WSB )* to ena#le services to #e classified to ease searchin( for reuse) C#tensibility for :essage Cnrichment A special case of semantic mappin(* enrichment ena#les data#ase or ta#le loo!ups to #e mer(ed into a messa(e stream so that messa(es emer(e from the #us richer with data than when they arrived) 2he @S9 automate mana(ement as much as possi#le* it will also #e necessary to ena#le humans to investi(ate pro#lems* find root causes* and ta!e action to correct the issues that are discovered)
;ransaction :anagement
:onitoring and :anagement
1=
Ltility Service
IIJtility ServiceKK IIcomponentKK IIcomponentKK
J:5
Service -nterface
IIcomponentKK
IIcomponentKK
11reusa!le !usiness logic22
Aescription
A utility service encapsulates generic functionality intended to be reused within and across different S%A applications" -n S%A, 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 S%A as it is intended to be reused across (and not integrated into) multiple applications" Jtility services are physically created by aggregating the desired public interfaces of one or more application components into the utility service interface"
Aesign Luidance
Jtility services are conceptually similar to library or framework components in traditional application architectures"
7?
9asic Service
II2asic ServiceKK IIcomponentKK IIcomponentKK
J:5
Service -nterface
IIcomponentKK
IIcomponentKK
11!usiness logic22
Aescription
A basic service encapsulates the functionality implemented in one or more business components by specifying a well defined service interface that e#poses a desired business capability" Cach interface point in a basic service should be defined with a granularity in terms of performing a useful business unit of work (2J%0)" A basic service must perform a discrete 2J%0" 2asic services can be orchestrated with other service styles to perform business processes" 2asic services are usually defined top down by performing analysis on a business domain, specification of business use cases, or business process walkthroughs" 2asic services are best designed by properly establishing the service interface" Some best practices for creating the service interface include: (+) -nterfaces that are easy to consume are as simple as possible, but no simpler (1) 2e able to accomplish a business unit of work in a single call (,) 2e used across many different conte#ts (not ?ust the first app that it was built for) (3) :odels business processes rather than lower level functionality (7) ;he service interface should be easy to version such that they can be easily e#tended with the addition of new parameters and doesn.t break service consumers when a new interface is defined (8) ;he service interface should promote the concept of loose coupling by insulating the service consumer from changes in the service implementation, not re)uiring anything other than the schema and contract to know how to invoke them, and no leaking internal abstractions outside the service boundary"
Aesign Luidance
71
Dro3y Service
II$ro#y ServiceKK
J:5
Service -nterface
Service $ro#y IIgeneratedKK
C#isting Application 6omponent
Aescription
A pro#y service 4service enables& an e#isting application component by creating a service pro#y component that 4facades& the e#isting component" $ro#y services can generally be automatically generated by an -AC, e#posing the public interface (or a subset of the public interface) of the e#isting application component as a service" A pro#y service is often used to integrate with an application that provides some desired functionality to an S%A application, but this functionality is implemented as a collection of A$-.s and not as a service"
Aesign Luidance
%ne must be careful when creating pro#y services, as they are easy to create, but yet are often inefficient from a design perspective when compared to other service types" $roblems generally occur with pro#y service designs because the underlying component Ms public interface is not optimized for an S%A" Aesigners should generally consider using a wrapper service when the goal is to integrate with an e#isting application that offers an A$- or an integration component"
72
Wrapper Service
II0rapper ServiceKK Service Adapter IIpro#yKK
J:5
Service -nterface
Few Adapter 6omponent
3middle are4
5egacy Application
Aescription
A wrapper service e#poses specific parts of legacy applications through a service interface" ;his service style essentially creates a new interface component, called an adapter, that adheres to good design principles of a business service" ;he adaptor component uses CA- to interact with a legacy application" ;he legacy application itself might re)uire modification to support this style as the desired business logic that is e#posed by the adapter component may not be accessible via direct CA- mechanisms" ;his service style is a good choice for application integration"
Aesign Luidance
Aesign the adapter component in a wrapper service style using the same principles that were described in the design guidance for a 2usiness Service" :ap the service interface in the adapter to functionality and business rules that e#ist in the legacy application" 0hen possible interact with the legacy capability via CA-" -n some cases the legacy system itself might re)uire modification to support the adapter service interface (e"g", the business logic is embedded and not e#ternally accessible)
7+
Aontroller Service
II6ontroller ServiceKK 2usiness $rocess
J:5
5service6 Service -nterface
5service6
5service6
11service assem!ly22 A controller service represents the e#ecution of a high level business task (or simple business workflow)" Services designed using the controller style create control logic to implement the business task" ;his control logic is called a service assembly" Drom an S%A 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 sub?ect to a high degree of change" Aggregate services, such as a controller service provide additional fle#ibility to S%A 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" 0henever possible deploy the service assembly in the same container as the subordinate services" ;his enables the service assembly to interact with the other (subordinate) services via a local interface rather than a network interface such as S%A$" Also, since web service support is still very limited with respect to supporting conte#t and transactions this guidance also allows the controller to work with the underlying services in a stateful way (i"e", supports A6-A transactions)"
Aesign Luidance
Aescription
71
Aoordination Service
II6oordination ServiceKK 2usiness ;ransaction 0orkflow ' 2usiness $rocess
J:5
in4 3!eg
5service6 Service -nterface 5service6
3co mm it4
5service6 5service6
11!usiness process ith 0CID transaction support22
Aescription
A coordination service supports e#ecuting a workflow to implement a business unit of work (2J%0)" ;he 2J%0 in a coordination service should be short running as this service style supports A6-A transactions" Jnlike a controller service, the workflow in a coordination service is e#ternalized, defined using a standard markup (i"e", 2C$5), and e#ecuted by an infrastructure component that manages the actual workflow process"
Aesign Luidance
;he transaction oriented workflow outlined above is the topic of the 0S ;ransaction specification" 0ith this specification workflows are defined using the 2C$5 markup" Liven lack of 2C$5 support in the tools that we are using in class, applications re)uiring the characteristics of a coordination service should use a controller service instead an code the business process into the service assembly"
77
Wor!flow Service
II6oordination'0orkflow ServiceKK 2usiness $rocess 0orkflow ' 2usiness $rocess 6onte#t Service 5service6 Service -nterface 5service6 6oordination Service
in4 3!eg
J:5
3com mit4
5service6 5service6 6ompensation Service
11!usiness process ith compensated transaction support22
Aescription
A workflow service implements a business process" ;he workflow service does not support A6-A transactions because the business process might be long running (i"e", several days, re)uire human intervention, etc")" Jnlike a controller service, the workflow in a coordination service is e#ternalized, defined using a standard markup (i"e", 2C$5), and e#ecuted by an infrastructure component that manages the actual workflow process" Aue to the nature of the workflow service style A6-A types of transactions are not supported, instead, a compensation service is provided in this model to gracefully recover from une#pected problems"
Aesign Luidance
;he workflow outlined above is the topic of the 0S ;ransaction and 0S 6oordination specifications" 0ith these specifications, workflows are defined using the 2C$5 markup" Liven lack of 2C$5 support in the tools that we are using in class, applications re)uiring the characteristics of a workflow service should use a controller service instead an code the business process into the service assembly"
78
9lueprints for SOA Besi(ns

Application.Service inte(ration views
Shows the application functionally decomposed (MHA Dattern for thin client) Shows the application in conte3t of services that are consumed Befines all application.service inte(ration points Befines services in terms of the reference architecture
7:
Service Hiews
References
$-rom O#Iects to Services' A Eourney in Search of Aomponent Reuse Firvana% #y M) Bodani* Eournal of O#Iect 2echnolo(y vol+* no) <* http'..www)Iot)fm.issues.issueP2??1P?=.column7) $Service"Oriented Architecture ' A -ield Juide to Inte(ratin( GM and We# Services% #y 2) @rl* Drentice &all * IS9F' ?1+112<=<7 $What Is An @nterprise Service 9us,%* #y M) Jilpin* -orrester Research* http'..www)forrester)com.(o,docid0+71=+)
7<

SOA

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

SOA

Cargado por

Copyright:

Formatos disponibles

A Reference Architecture for Service Oriented Architecture (SOA)

Redundancy Implementation inconsistency ac! of inter"opera#ility $Wrapper%"&appy ac! of Modularity

Misconception' SOA is a#out desi(n and not technolo(y (i)e)* We#Services)

What is SOA, """" Randy &effner* -orrester Research

What is SOA, """" More definitions

What is SOA, """" More definitions

Microsoft and SOA4

Source: http:''www ,<8"ibm"com'software'solutions'webservices'

Service Oriented Architecture is an @3ample of an Architectural Style

Service Oriented Architecture is an @3ample of an Architectural Style

What are the architectural components,

What are the architectural connectors,

What patterns (overn the desi(n of the components and connectors,

&ow are faults and une3pected events handled,

an(ua(e specific e3ception handlin( mapped to service faults

2he $Actors% in an SOA C Service Aonsumers* Service Droviders ; Messa(es

2he Architectural Aomponents " Services

Services can #e instantiated in a variety of different ways

Services are lifecycle mana(ed #y an application server container of some sort

AIAS* )Fet -ramewor!* E2@@ (We#Sphere* A3is)

2he Architectural Aonnectors " Messa(es

9enefits of the SOA Architectural Style

oosen the couplin( #etween an application and the data#ase

9est Dractices for Service Besi(n in an SOA

structure* and defines the messa(e semantics

contract (i)e)* GSBO#IectJen for )Fet* EAG9 for Eava)

Service contract can #e used #y a service invocation framewor!

9est Dractices for Interface and Messa(e Besi(n in SOA

Some Misconceptions a#out Services

Lse stored procedures for $#lac! #o3% operations on data

9asic Services Inte(ration Services Aomposite Services

Anti"9est Dractice for Areatin( Services' 2he $Ri(ht"Alic!% method4

)Fet is no #etter for directly promotin( a component to a service4

Besi(n Service i!e Mini" Applications

Service -nterface ;ier

Aomain %b?ect ;ier

Aata Access ;ier

:essage Serialization %b?ects Aomain %b?ect 2uilder

$ersisted Structures Stored $rocedures Aatabases :ainframe ;ransactions %ther/ (:essaging)

SOA SOA SOA SOA @S9

-unctional Hiew Architectural Hiew Messa(in( Interfaces (provided ; re/uired)

O#Iects and Aomponents (a(ain)

Besi(n Drinciples for OO

Besi(n Drinciples for OO

OO desi(n principles directly map to component desi(n principles

Met component approaches to software desi(n have their pro#lems'

Aomponent framewor!s are proprietary

Step 1' Aontainers to the rescue4

write* read"write* allow* deny

Aontainers a#stract many of the $hard% thin(s'

Aode runnin( in a container is often called $mana(ed code%

Step 2' Messa(in( infrastructure to the rescue4

Step 2' Messa(in( infrastructure to the rescue4

Step 2' Messa(in( infrastructure to the rescue4

Step +' Standards to the rescue C finally ena#lement of SOA is possi#le

An SOA Reference Architecture

SOA Reference Model 1?1

)unctio nal Service

Aomponents of the SOA Reference Architecture

Service :essaging :odels

!uality of Service (!oS) 6haracteristics

Service -ntegration Adapters

@sta#lishin( the -unctional Aspect of the Service in an SOA

Service (onsu'ers "pplicat %ther 2egac ion Services y (o!e