Service-oriented modeling and architecture

How to identify, specify, and realize services

for your SOA
Level: Intermediate
Ali Arsanjani, Ph.D. (arsanjan@us.ibm.com), Chief
Architect, !A and "eb services Center of #$cellence,
I%&
'( )ov *''+
,his article discusses the hi-hli-hts of service.oriented modelin- and
architecture/ the 0e1 activities that 1ou need for the anal1sis and desi-n
re2uired to build a ervice.!riented Architecture (!A). ,he author stresses
the im3ortance of addressin- the techni2ues re2uired for the identification,
s3ecification and reali4ation of services, their flows and composition, as 5ell
as the enter3rise.scale components needed to reali4e and ensure the 2ualit1
of services re2uired of a !A.
Introduction
,here has been a lot of bu44 and h13e .. some factual, some not so 5ell.
founded .. surroundin- the o33ortunities 3resented b1 ervice.oriented
Architectures (SOA) and its implementation as Web services. Anal1sts
have 3redicted, 3undits have 3rofessed, 3rofessors have lectured, com3anies
have scurried to sell 5hat the1 had, as !A 3roducts .. often missin- the
3oint that !A is not a 3roduct. It6s about brid-in- the -a3 bet5een business
and I, throu-h a set of business.ali-ned I, services usin- a set of desi-n
3rinci3les, 3atterns, and techni2ues.
7D)et recentl1 said, 89artner 3redicts that b1 *'':, more than ;' 3ercent of
enter3rises 5ill use !A as a 8-uidin- 3rinci3le8 5hen creatin- mission.
critical a33lications and 3rocesses.8
A hu-e demand e$ists for the develo3ment and im3lementation of !As. o
if !A is not just about the 3roducts and standards that hel3 reali4e it, for
e$am3le throu-h "eb services, then 5hat additional elements do 1ou need
to reali4e a !A< Service-oriented modeling re2uires additional activities and
artifacts that are not found in traditional object-oriented analysis and
desin (OOA!)" ,he article =#lements of ervice.oriented Anal1sis and
Desi-n8 describes an initial set of reasons 5h1 1ou need more than !!AD. It
also describes ho5 business 3rocess mana-ement or enter3rise architecture
(#A) and !!AD are inade2uate means of conductin- anal1sis and desi-n.
Also, in the I%& >edboo0 entitled =Patterns: ervice.!riented Architecture
and "eb ervices8, I illustrate the major activities of this service.oriented
modelin- a33roach.
?o5ever, additional im3ortant considerations e$ist that 1ou need to ta0e into
account. @or one thin-, current !!AD methods do not address the three 0e1
elements of a !A: services, flows, and components reali4in- services. Aou
also need to be able to e$3licitl1 address the techni2ues and 3rocesses
re2uired for the identification, s3ecification and reali4ation of services, their
Document o3tions
flo5s and com3osition, as 5ell as the enter3rise.scale com3onents needed to
reali4e and ensure the 2ualit1 of services re2uired.
econd, a 3aradi-m shift needs to occur, in order to a33reciate the distinct
re2uirements of the two #ey roles in a SOA$ t%e service provider and
service consumer" ,hird, a33lications assumed to be built for one
enter3rise or line of business must no5 as3ire to be used in a su33l1 chain
and be e$3osed to business 3artners 5ho mi-ht com3ose, combine, and
enca3sulate them into ne5 a33lications. ,his is the notion of the service
ecos1stem or service value.net.
,his is a sli-ht ste3 u3 from just 8distributed objects8. It6s about the value
created throu-h the net5or0 effect: for e$am3le, 5hen 3arties levera-e a
combination of Ama4on.com 5ith 9oo-le6s search services and combine them
5ith e%a1 services to build their o5n h1brid solutions. !r 5hen a travel
a-enc1 reaches dee3 into an airline reservation s1stem and coordinates it
5ith a rental car a-enc1 and hotel chain, u3datin- their records and sendin-
the itinerar1 to 1our electronic or-ani4er. "hatever the a33lication, 1ou need
much more than just -ood tools and standards to successfull1 create a !A.
Aou need some 3rescri3tive ste3s to su33ort 1our !A life c1cle/ techni2ues
for the anal1sis, desi-n, and reali4ation of services, flo5s, and com3onents.
,herefore, for an1one interested in enter3rise a33lication develo3ment, it6s
crucial to understand the detailed ste3s involved in service.oriented modelin-
and architecture.
%efore I describe these ste3s in detail, let6s first understand 5hat 1ou are
aimin- to 3roduce: what is a SOA, and what does it look like? After definin-
the notion and conce3ts behind a !A, I6ll describe the la1ers of a !A and
ho5 1ou need to record 0e1 architectural decisions about each of those la1ers
that hel3 1ou in buildin- a blue3rint for the !A that is ri-ht for 1our 3roject,
line of business, enter3rise.5ide effort, or value.chain that 1ou are tr1in- to
inte-rate and come u3 5ith a set of services, flo5s, and com3onents that
im3lement the !A.
Service-
Oriented
Architecture: A
conceptual
model
,his conce3t is
based on an
architectural
st1le that
defines an
interaction
model
bet5een three
&ac# to top
3rimar1
3arties: the
service
3rovider, 5ho
3ublishes a
service
descri3tion
and 3rovides
the
im3lementatio
n for the
service, a
service
consumer,
5ho can either
use the
uniform
resource
identifier
(B>I) for the
service
descri3tion
directl1 or can
find the
service
descri3tion in
a service
re-istr1 and
bind and
invo0e the
service. ,he
service bro0er
3rovides and
maintains the
service
re-istr1,
althou-h
no5ada1s
3ublic
re-istries are
not in vo-ue.
A meta.model
sho5in- these
relationshi3s
is de3icted in
@i-ure C
belo5.
'iure ($
)onceptual
model of a
SOA
arc%itectural
style
The
architectural
style and
principles
,he
architecture
st1le definin-
a !A
describes a
set of 3atterns
and -uidelines
for creatin-
loosely
coupled,
business-
aligned
services that,
because of the
separation of
concerns
between
description,
implementat
ion, and
bindin,
&ac# to top
3rovide
un3recedente
d fle$ibilit1 in
res3onsivenes
s to ne5
business
threats and
o33ortunities.
A !A is an
enter3rise.
scale I,
architecture
for lin0in-
resources on
demand. In a
!A,
resources are
made
available to
3artici3ants in
a value net,
enter3rise,
line of
business
(t13icall1
s3annin-
multi3le
a33lications
5ithin an
enter3rise or
across
multi3le
enter3rises).
It consists of a
set of
business.
ali-ned I,
services that
collectivel1
fulfill an
or-ani4ation6s
business
3rocesses and
-oals. Aou can
choreo-ra3h
these services
into com3osite
a33lications
and invo0e
them throu-h
standard
3rotocols, as
sho5n in
@i-ure *
belo5.
A service is a
soft5are
resource
(discoverable)
5ith an
e*ternalized
service
description"
,his service
descri3tion is
available for
searchin-,
bindin-, and
invocation b1
a service
consumer. ,he
service
3rovider
reali4es the
service
descri3tion
im3lementatio
n and also
delivers the
2ualit1 of
service
re2uirements
to the service
consumer.
ervices
should ideall1
be -overned
b1 declarative
3olicies and
thus su33ort a
d1namicall1
re.
confi-urable
architectural
st1le.
'iure +$
Attributes of
a SOA
%usiness
a-ilit1 is
-ained b1 I,
s1stems that
are fle$ible,
3rimaril1 b1
se3aration of
interface,
im3lementatio
n, and bindin-
(3rotocols)
offered b1 a
!A, allo5in-
the deferral of
the choice of
which service
3rovider to
opt for at a
-iven 3oint in
time based on
new business
requirements,
(functional
and non.
functional (for
e$am3le,
3erformance,
securit1,
scalabilit1, and
so forth)
re2uirements)
.
Aou can reuse
the services
across internal
business units
or across the
value chains
amon-
business
3artners in a
fractal
realization
pattern.
@ractal
reali4ation
refers to the
abilit1 of an
architectural
st1le to a33l1
its 3atterns
and the roles
associated
5ith the
3artici3ants in
its interaction
model in a
com3osite
manner. Aou
can a33l1 it to
one tier in an
architecture
and to
multi3le tiers
across the
enter3rise
architecture.
Amon-
3rojects, it
can be
bet5een
business units
and business
3artners
5ithin a value
chain in a
uniform and
conce3tuall1
scalable
manner.
&ac# to top
Context
In this article,
I introduce
the hi-h.level
activities of
identification,
s3ecification
and
reali4ation,
and some
artifacts of
service.
oriented
modelin-.
ervice.
oriented
modelin- is a
service.
oriented
anal1sis and
desi-n
(!AD)
3rocess for
modelin-,
anal14in-,
desi-nin-, and
3roducin- a
!A that
ali-ns 5ith
business
anal1sis,
3rocesses,
and -oals.
I6ll first ta0e a
loo0 at 5hat
1ou intend to
build, namel1
a !A and its
la1ers. ,hen
I6ll describe
ho5 to build
the !A b1
discussin- the
main activities
and
techni2ues
that 1ou need
to create a
!A.
As an
e$am3le, let6s
assume that
1ou are
5or0in- on a
3roject and
the objective
is to mi-rate a
3ortion of the
ban0in- line of
business,
5hich has a
self.service
accountin-
s1stem, to a
!A.
In order to
mi-rate to a
!A, 1ou
need some
additional
elements that
-o be1ond
service
modelin-.
,hese include:
Ado3tio
n and
maturit
1
models.
"here
is 1our
enter3ri
se at in
the
relative
scale of
maturit
1 in the
ado3tio
n of
!A
and
"eb
ervice
s<
#ver1
differen
t level
of
ado3tio
n has
its o5n
uni2ue
needs.
Assess
ments.
Do 1ou
have
some
3ilots<
?ave
1ou
dabbled
into
"eb
services
< ?o5
-ood is
1our
resultin
-
architec
ture<
hould
1ou
0ee3
-oin- in
the
same
directio
n< "ill
this
scale to
an
enter3ri
se !A<
?ave
1ou
conside
red
ever1thi
n- 1ou
need to
conside
r<
trate-
1 and
3lannin
-
activitie
s. ?o5
do 1ou
3lan to
mi-rate
to a
!A<
"hat
are the
ste3s,
tools,
method
s,
technol
o-ies,
standar
ds, and
trainin-
1ou
need to
ta0e
into
account
< "hat
is 1our
roadma
3 and
vision,
and
ho5 do
1ou -et
there<
"hat6s
the
3lan<
9overn
ance.
hould
e$istin-
API or
ca3abili
t1
become
a
service<
If not,
5hich
ones
are
eli-ible<
#ver1
service
should
be
created
5ith the
intent
to brin-
value to
the
busines
s in
some
5a1.
?o5 do
1ou
mana-e
this
3rocess
5ithout
-ettin-
in the
5a1<
Im3lem
entation
of best.
3ractice
s. "hat
are
some
tried
and
tested
5a1s of
im3lem
entin-
securit1
,
ensurin
-
3erform
ance,
com3lia
nce
5ith
standar
ds for
intero3e
rabilit1,
desi-nin
- for
chan-e<
In addition to
identification,
s3ecification,
and reali4ation
described in
this article,
the service.
oriented
modelin-
a33roach
includes the
techni2ues
re2uired for
de3lo1ment,
monitorin-,
mana-ement,
and
-overnance
re2uired to
su33ort the
full !A life
c1cle.
,he above
discussions on
mi-ration to
!A and the
additional
activities after
reali4ation
deserve an
article of their
o5n, 5hich I
5ill -et to in a
subse2uent
column in this
series. @or
no5, let6s
assume that
1ou sco3ed
the 3roject
and decided
5here to focus
on: a focal
3oint for
transformation
of e$istin-
s1stems or
services to a
ne5 set of
s1stems and
services has
been defined.
Aou can no5
start service.
oriented
modelin- to
build 1our
service.
oriented
architecture.
An
architectural
template for a
SOA
An abstract
vie5 of !A
de3icts it as a
3artiall1
la1ered
architecture of
com3osite
services that
ali-n 5ith
business
3rocesses.
@i-ure D
de3icts a
re3resentation
&ac# to top
of this t13e of
architecture.
,he
relationshi3
bet5een
services and
com3onents is
that
enter3rise.
scale
com3onents
(lar-e.-rained
enter3rise or
business line
com3onents)
reali4e the
services and
are
res3onsible for
3rovidin- their
functionalit1
and
maintainin-
their 2ualit1 of
service.
%usiness
3rocess flo5s
can be
su33orted b1
a
choreo-ra3h1
of these
e$3osed
services into
com3osite
a33lications.
An inte-ration
architecture
su33orts the
routin-,
mediation,
and
translation of
these
services,
com3onents,
and flo5s
usin- an
#nter3rise
ervice %us
(#%). ,he
de3lo1ed
services must
be monitored
and mana-ed
for 2ualit1 of
service and
adherence to
non.functional
re2uirements.
'iure ,$ -%e
layers of a
SOA
@or each of
these la1ers,
1ou must
ma0e desi-n
and
architectural
decisions.
,herefore, to
hel3
document
1our !A, 1ou
mi-ht 5ant to
create a
document
consistin- of
sections that
corres3ond to
each of the
la1ers.
?ere is a
tem3late for
1our !A
architecture
document:
C. co3e
E5hat
area of
the
enter3ri
se is
this
architec
ture
for<F
*. !3erati
onal
s1stems
la1er
C. P
a
c
0
a
-
e
d
a
3
3l
ic
a
ti
o
n
s
*. C
u
s
t
o
m

a
3
3l
ic
a
ti
o
n
s
D. A
r
c
h
it
e
c
t
u
r
al
d
e
ci
si
o
n
s
D. #nter3ri
se
com3on
ents
la1er
C. @
u
n
c
ti
o
n
al
a
r
e
a
s
s
u
3
3
o
rt
e
d
b
1
t
h
is
e
n
t
e
r
3
ri
s
e
c
o
m
3
o
n
e
n
t
s
*. E
"
h
a
t
b
u
si
n
e
s
s
d
o
m
ai
n
s,
-
o
al
s
a
n
d
3
r
o
c
e
s
s
e
s
a
r
e
s
u
3
3
o
rt
e
d
b
1
t
h
is
e
n
t
e
r
3
ri
s
e
c
o
m
3
o
n
e
n
t
s
F
D. D
e
ci
si
o
n
s
r
e
-
a
r
di
n
-
-
o
v
e
r
n
a
n
c
e
C.
E
+. A
r
c
h
it
e
c
t
u
r
al
d
e
ci
si
o
n
s
+. ervice
s la1er
C. C
a
t
e
-
o
ri
4
e
d
3
o
rt
f
ol
io
o
f
s
e
r
vi
c
e
s
*. A
r
c
h
it
e
c
t
u
r
al
d
e
ci
si
o
n
s
G. %usines
s
3rocess
and
com3osi
tion
la1er
C. %
u
si
n
e
s
s
3
r
o
c
e
s
s
e
s
t
o
b
e
r
e
3
r
e
s
e
n
t
e
d
a
s
c
h
o
r
e
o
-
r
a
3
h
ie
s
*. A
r
c
h
it
e
c
t
u
r
al
d
e
ci
si
o
n
s
C.
E
;. Access
or
3resent
ation
la1er
C. E
D
o
c
u
m
e
n
t
i
m
3l
ic
a
ti
o
n
s
o
f
"
e
b
s
e
r
vi
c
e
s
a
n
d

!
A
o
n
t
h
is
la
1
e
r/
if
a
n
1.
@
o
r
e
$
a
m
3l
e
,
u
s
e
o
f
3
o
rt
le
t
s
t
h
a
t
in
v
o
0
e
"
e
b
s
e
r
vi
c
e
s
a
t
t
h
e
u
s
e
r
i
n
t
e
rf
a
c
e
le
v
el
a
n
d
t
h
e
i
m
3l
ic
a
ti
o
n
s
o
n
t
h
e
f
u
n
c
ti
o
n
i
n
-
o
f
t
h
a
t
la
1
e
r
F
H. Inte-rat
ion
la1er
C. E
I
n
cl
u
d
e
c
o
n
si
d
e
r
a
ti
o
n
s
o
f
a
n
#

%
F
*. E
?
o
5
a
r
e
5
e
-
oi
n
-
t
o
e
n
s
u
r
e
t
h
e
s
e
r
vi
c
e
.
le
v
el
a
-
r
e
e
m
e
n
t
s
(

L
A
s
)
a
n
d
2
u
al
it
1
o
f
s
e
r
vi
c
e
(
I
o

)
r
e
2
u
ir
e
d
b
1
cl
ie
n
t
s
o
f
t
h
e
s
e
r
vi
c
e
s
3
r
o
vi
d
e
d
<
F
D.
e
c
u
ri
t
1
is
s
u
e
s
a
n
d
d
e
ci
si
o
n
s
+. P
e
rf
o
r
m
a
n
c
e
is
s
u
e
s
a
n
d
d
e
ci
si
o
n
s
G. ,
e
c
h
n
ol
o
-
1
a
n
d
s
t
a
n
d
a
r
d
s
li
m
it
a
ti
o
n
s
a
n
d
d
e
ci
si
o
n
s
;. &
o
n
it
o
ri
n
-
a
n
d
m
a
n
a
-
e
m
e
n
t
o
f
s
e
r
vi
c
e
s
C.
D
)o5, letJs
describe each
la1er in
-reater detail
and discuss
the
com3osition of
each of these
la1ers.
.ayer ($
Operational
systems
layer" ,his
consists of
e$istin-
custom built
a33lications,
other5ise
called legacy
s1stems,
includin-
e$istin- C>&
and #>P
3ac0a-ed
a33lications,
and older
object.
oriented
s1stem
im3lementatio
ns, as 5ell as
business
intelli-ence
a33lications.
,he com3osite
la1ered
architecture of
an !A can
levera-e
e$istin-
s1stems and
inte-rate
them usin-
service.
oriented
inte-ration
techni2ues.
.ayer +$
/nterprise
components
layer" ,his is
the la1er of
enter3rise
com3onents
that are
res3onsible for
reali4in-
functionalit1
and
maintainin-
the Io of the
e$3osed
services.
,hese s3ecial
com3onents
are a
mana-ed,
-overned set
of enter3rise
assets that
are funded at
the enter3rise
or the
business unit
level. As
enter3rise.
scale assets,
the1 are
res3onsible for
ensurin-
conformance
to LAs
throu-h the
a33lication of
architectural
best 3ractices.
,his la1er
t13icall1 uses
container.
based
technolo-ies
such as
a33lication
servers to
im3lement the
com3onents,
5or0load
mana-ement,
hi-h.
availabilit1,
and load
balancin-.
.ayer ,$
Services
layer" ,he
services the
business
chooses to
fund and
e$3ose reside
in this la1er.
,he1 can be
discovered or
be staticall1
bound and
then invo0ed,
or 3ossibl1,
choreo-ra3he
d into a
com3osite
service. ,his
service
e$3osure la1er
also 3rovides
for the
mechanism to
ta0e
enter3rise
scale
com3onents,
business unit
s3ecific
com3onents,
and in some
cases, 3roject.
s3ecific
com3onents,
and
e$ternali4es a
subset of their
interfaces in
the form of
service
descri3tions.
,hus, the
enter3rise
com3onents
3rovide
service
reali4ation at
runtime usin-
the
functionalit1
3rovided b1
their
interfaces.
,he interfaces
-et e$3orted
out as service
descri3tions in
this la1er,
5here the1
are e$3osed
for use. ,he1
can e$ist in
isolation or as
a com3osite
service.
.evel 0$
&usiness
process
composition
or
c%oreorap%
y layer"
Com3ositions
and
choreo-ra3hie
s of services
e$3osed in
La1er D are
defined in this
la1er. ervices
are bundled
into a flo5
throu-h
orchestration
or
choreo-ra3h1,
and thus act
to-ether as a
sin-le
a33lication.
,hese
a33lications
su33ort
s3ecific use
cases and
business
3rocesses.
?ere, visual
flo5
com3osition
tools, such as
I%&K
"eb3hereK
%usiness
Inte-ration
&odeler or
"ebs3here
A33lication
Develo3er
Inte-ration
#dition, can
be used for
the desi-n of
a33lication
flo5.
.ayer 1$
Access or
presentation
layer"
Althou-h this
la1er is
usuall1 out of
sco3e for
discussions
around a !A,
it is -raduall1
becomin-
more relevant.
I de3ict it here
because there
is an
increasin-
conver-ence
of standards,
such as "eb
ervices for
>emote
Portlets
Lersion *.'
and other
technolo-ies,
that see0 to
levera-e "eb
services at the
a33lication
interface or
3resentation
level. Aou can
thin0 of it as a
future la1er
that 1ou need
to ta0e into
account for
future
solutions. It is
also im3ortant
to note that
!A
decou3les the
user interface
from the
com3onents,
and that 1ou
ultimatel1
need to
3rovide an
end.to.end
solution from
an access
channel to a
service or
com3osition of
services.
.evel 2$
3nteration
(/S&)" ,his
la1er enables
the inte-ration
of services
throu-h the
introduction of
a reliable set
of ca3abilities,
such as
intelli-ent
routin-,
3rotocol
mediation,
and other
transformation
mechanisms,
often
described as
the #% (see
>esources).
"eb ervices
Descri3tion
Lan-ua-e
("DL)
s3ecifies a
bindin-, 5hich
im3lies a
location 5here
the service is
3rovided. !n
the other
hand, an #%
3rovides a
location
inde3endent
mechanism
for
inte-ration.
.evel 4$ 5oS"
,his la1er
3rovides the
ca3abilities
re2uired to
monitor,
mana-e, and
maintain Io
such as
securit1,
3erformance,
and
availabilit1.
,his is a
bac0-round
3rocess
throu-h
sense.and.
res3ond
mechanisms
and tools that
monitor the
health of !A
a33lications,
includin- the
all im3ortant
standards
im3lementatio
ns of ".
&ana-ement
and other
relevant
3rotocols and
standards that
im3lement
2ualit1 of
service for a
!A.
How to
approach
service-
oriented
modeling and
architecture
,his section
describes ho5
to combine a
to3.do5n,
business.
driven
a33roach 5ith
a bottom.u3
a33roach,
levera-in-
le-ac1
investments.
ervice.
oriented
modelin-
a33roach
3rovides
modelin-,
anal1sis,
desi-n
&ac# to top
techni2ues,
and activities
to define the
foundations of
a !A. It
hel3s b1
definin- the
elements in
each of the
!A la1ers
and ma0in-
critical
architectural
decisions at
each level. It
does so usin-
a combination
of a to3.do5n,
business.
driven manner
of service
identification
cou3led 5ith a
stream of
5or0 that
conducts
service
identification
throu-h
levera-in-
le-ac1 assets
and s1stems.
In this 5a1,
hi-h.level
business
3rocess
functionalit1 is
e$ternali4ed
for lar-e.
-rained
services.
maller.
-rained
services ..
those that
hel3 reali4e
the hi-her
level of
services .. are
identified b1
e$aminin- the
e$istin-
le-ac1
functionalit1
and decidin-
ho5 to create
ada3tors and
5ra33ers, or
com3onenti4in
- the le-ac1
to e$ternali4e
the desired
functionalit1
often loc0ed
5ithin the
s1stem.
@inall1, usin-
-oal.service
modelin-, 1ou
use a cross-
sectional
a33roach to
cut do5n the
sheer number
of candidate
services that
mi-ht alread1
be identified.
A more
judicious
a33roach
5ould be to
first do to3.
do5n, then
-oal.service
modelin-, and
finall1 bottom.
u3 le-ac1
anal1sis of
e$istin-
assets. ,he
messa-e is:
the faster 1ou
sco3e the
3roject do5n
to a
mana-eable
and realistic
set, the
sooner 1ou
can reali4e
value b1
focusin- on
0e1 services
to e$3ose 5ith
service
descri3tions
that form the
cornerstone of
the !A.
,his
combination of
functional
business
as3irations
and levera-in-
of e$istin-
investments in
le-ac1
s1stems
3rovide a
3otent
solution to
or-ani4ations
that 5ant to
have 2uic0
5ins and
mi-rate their
enter3rise to a
modern !A.
Consolidation
of soft5are
a33lications
throu-h
service.
oriented
inte-ration
thus becomes
3ossible.
ervice.
oriented
inte-ration is
an evolution
of #nter3rise
A33lication
Inte-ration
(#AI) in 5hich
3ro3rietar1
connections
are re3laced
5ith
standards.
based
connections
over an #%
notion that is
location
trans3arent
and 3rovides a
fle$ible set of
routin-,
mediation,
and
transformation
ca3abilities.
Service-
oriented
modeling: The
analysis and
design of
services
o far, I have
set the sta-e
b1 describin-
a !A. I have
also sho5n
that to build a
!A, 1ou
need to ma0e
0e1
architectural
decisions
about each
la1er in 1our
!A, and that
1our desi-n
must reflect a
&ac# to top
set of
business.
ali-ned
services and
decisions
about ho5
the1 5ill be
com3osed into
a33lications
usin-
choreo-ra3h1.
Bnli0e 1our
comfortable
5orld of
objects, 1ou
need to ta0e
into account
t5o
3ers3ectives
in a !A/ that
of the service
consumer and
service
3rovider. ,he
service bro0er
is currentl1
not
mainstream
and 5ill be
covered in a
later venue.
,he desi-n
strate-1 for a
!A does not
start from the
=bottom.u38
as is often the
case 5ith a
"eb services.
based
a33roach. Aou
must
remember
that !A is
more strate-ic
and business.
ali-ned. "eb
services are a
tactical
im3lementatio
n of !A. A
number of
im3ortant
activities and
decisions e$ist
that influence
not just
inte-ration
architecture
but enter3rise
and
a33lication
architectures
as 5ell. ,he1
include the
activities from
the t5o 0e1
vie5s of the
consumer and
3rovider
described in
@i-ure +
belo5.
'iure 0$
Activities of
service-
oriented
modelin
@i-ure +
sho5s the
activities that
are t13icall1
conducted b1
each of the
roles of
3rovider and
consumer.
)ote that the
3rovider6s
activities are a
su3erset of
the
consumer6s
activities (for
e$am3le, the
3rovider
5ould also be
concerned
5ith service
identification,
cate-ori4ation,
and so forth).
In man1
cases, the
differentiation
of the roles
comes from
the fact that
the consumers
s3ecif1 the
services the1
5ant, often
search for it,
and once the1
are convinced
of the match
bet5een the
s3ecification
of the service
the1 are
loo0in- for,
and that
3rovided b1 a
service
3rovider, the1
bind and
invo0e the
service as
needed. ,he
3rovider, in
turn, needs to
3ublish the
services the1
are 5illin- to
su33ort/ both
in terms of
functionalit1
and most
im3ortantl1 in
terms of the
Io that
consumers 5ill
re2uire. ,his
im3licit
contract
bet5een
consumer and
3rovider mi-ht
mature into
an e$3licit
contract in
terms of
LAs/
ne-otiated
either
electronicall1
or throu-h
business and
le-al venues.
,he activities
described
above can be
de3icted to
flo5 5ithin the
service.
oriented
modelin- and
architecture
method, as
sho5n in
@i-ure G
belo5.
'iure 1$ -%e
service-
oriented
modelin
and
arc%itecture
met%od
,he 3rocess of
service.
oriented
modelin- and
architecture
consists of
three -eneral
ste3s:
identification,
s3ecification
and reali4ation
of services,
com3onents
and flo5s
(t13icall1,
choreo-ra3h1
of services).
Service
identification
,his 3rocess
consists of a
combination of
to3.do5n,
bottom.u3,
and middle.
out techni2ues
of domain
decom3osition
, e$istin-
asset anal1sis,
and -oal.
service
modelin-. In
the top-down
view, a
blue3rint of
business use
cases 3rovides
the
s3ecification
for business
services. ,his
to3.do5n
3rocess is
often referred
to as domain
decomposition
, 5hich
consists of the
decom3osition
of the
business
domain into
its functional
areas and
subs1stems,
includin- its
flo5 or
3rocess
decom3osition
into
3rocesses,
sub.
3rocesses,
and hi-h.level
business use
cases. ,hese
use cases
often are ver1
-ood
candidates for
business
services
e$3osed at
the ed-e of
the enter3rise,
or for those
used 5ithin
the
boundaries of
the enter3rise
across lines of
business.
In the
bottom-up
portion of the
3rocess or
eisting
system
analysis,
e$istin-
s1stems are
anal14ed and
selected as
viable
candidates for
3rovidin-
lo5er cost
solutions to
the
im3lementatio
n of
underl1in-
service
functionalit1
that su33orts
the business
3rocess. In
this 3rocess,
1ou anal14e
and levera-e
API6s,
transactions,
and modules
from le-ac1
and 3ac0a-ed
a33lications.
In some
cases,
com3onenti4at
ion of the
le-ac1
s1stems is
needed to re.
modulari4e
the e$istin-
assets for
su33ortin-
service
functionalit1.
!he middle-
out view
consists of
goal-service
modeling to
validate and
unearth other
services not
ca3tured b1
either to3.
do5n or
bottom.u3
service
identification
a33roaches. It
ties services
to -oals and
sub.-oals, 0e1
3erformance
indicators, and
metrics.
Service
classification
or
categoriation
,his activit1 is
started 5hen
services have
been
identified. It is
im3ortant to
start service
classification
into a service
hierarch1,
reflectin- the
com3osite or
fractal nature
of services:
services can
and should be
com3osed of
finer.-rained
com3onents
and services.
Classification
hel3s
determine
com3osition
and la1erin-,
as 5ell as
coordinates
buildin- of
interde3enden
t services
based on the
hierarch1.
Also, it hel3s
alleviate the
service
3roliferation
s1ndrome in
5hich an
increasin-
number of
small.-rained
services -et
defined,
desi-ned, and
de3lo1ed 5ith
ver1 little
-overnance,
resultin- in
major
3erformance,
scalabilit1, and
mana-ement
issues. &ore
im3ortantl1,
service
3roliferation
fails to
3rovide
services,
5hich are
useful to the
business, that
allo5 for the
economies of
scale to be
achieved.
Su!system
analysis
,his activit1
ta0es the
subs1stems
found above
durin- domain
decom3osition
and s3ecifies
the
interde3enden
cies and flo5
bet5een the
subs1stems. It
also 3uts the
use cases
identified
durin- domain
decom3osition
as e$3osed
services on
the subs1stem
interface. ,he
anal1sis of the
subs1stem
consists of
creatin-
object models
to re3resent
the internal
5or0in-s and
desi-ns of the
containin-
subs1stems
that 5ill
e$3ose the
services and
reali4e them.
,he desi-n
construct of
=subs1stem8
5ill then be
reali4ed as an
im3lementatio
n construct of
a lar-e.
-rained
com3onent
reali4in- the
services in the
follo5in-
activit1.
Component
specification
In the ne$t
major activit1,
the details of
the
com3onent
that
im3lement the
services are
s3ecified:
Data
>ules
ervice
s
Confi-u
rable
3rofile
Lariatio
ns
&essa-in- and
events
s3ecifications
and
mana-ement
definition
occur at this
ste3.
Service
allocation
ervice
allocation
consists of
assi-nin-
services to the
subs1stems
that have
been identified
so far. ,hese
subs1stems
have
enter3rise
com3onents
that reali4e
their
3ublished
functionalit1.
!ften 1ou
ma0e the
sim3lif1in-
assum3tion
that the
subs1stem
has a one.to.
one
corres3ondenc
e 5ith the
enter3rise
com3onents.
Structuring
components
occurs 5hen
1ou use
3atterns to
construct
enter3rise
com3onents
5ith a
combination
of:
&ediato
rs
@aMade
>ule
objects
Confi-u
rable
3rofiles
@actorie
s
ervice
allocation also
consists of
assi-nin- the
services and
the
com3onents
that reali4e
them to the
la1ers in 1our
!A.
Allocation of
com3onents
and services
to la1ers in
the !A is a
0e1 tas0 that
re2uire the
documentatio
n and
resolution of
0e1
architectural
decisions that
relate not onl1
to the
a33lication
architecture
but to the
technical
o3erational
architecture
desi-ned and
used to
su33ort the
!A
reali4ation at
runtime.
Service
realiation
,his ste3
reco-ni4es
that the
soft5are that
reali4es a
-iven service
must be
selected or
custom built.
!ther o3tions
that are
available
include
inte-ration,
transformation
, subscri3tion
and
outsourcin- of
3arts of the
functionalit1
usin- "eb
services. In
this ste3 1ou
ma0e the
decision as to
5hich le-ac1
s1stem
module 5ill be
used to reali4e
a -iven
service and
5hich services
5ill be built
from the
=-round.u38.
!ther
reali4ation
decisions for
services other
than business
functionalit1
include:
securit1,
mana-ement
and
monitorin- of
services.
In realit1,
3rojects tend
to ca3itali4e
on an1
amount of
3arallel efforts
to meet
closin-
5indo5s of
o33ortunit1.
,herefore, I
recommend
conductin-
three streams
in 3arallel.
,o3.do5n
domain
decom3osition
(3rocess
modelin- and
decom3osition
, variation.
oriented
anal1sis,
3olic1 and
business rules
anal1sis, and
domain
s3ecific
behavior
modelin-
(usin-
-rammars and
dia-rams) ) is
conducted in
3arallel 5ith a
bottom.u3
anal1sis of
e$istin-
le-ac1 assets
that are
candidates for
com3onenti4at
ion
(modulari4atio
n) and service
e$3osure. ,o
catch the
business
intent behind
the 3roject
and to ali-n
services 5ith
this business
intent, -oal.
service
modelin- is
conducted.
Conclusion
In this article,
I started 5ith
the
fundamentals
of a service.
oriented
&ac# to top
architecture,
its la1ers, and
the associated
t13es of
architectural
decisions.
,hen, I
described the
activities in a
method for
service.
oriented
modelin- and
the
im3ortance of
activities from
the service
consumer and
3rovider
3ers3ectives
(service
bro0er 5ill be
dealt 5ith in a
later article).
,his method
3rovides
s3ecific
-uidance on
the anal1sis
and desi-n
activities for
determinin-
the three
fundamental
as3ects of a
service.
oriented
architecture:
services,
flo5s, and
com3onents
that reali4e
the services. I
also described
a tem3late
1ou can use
for 1our
architectural
decisions in
each of the
la1ers of the
!A.
I noted that
for service
identification,
it is im3ortant
to combine
the three
a33roaches of
to3.do5n,
bottom.u3,
and cross.
sectional,
-oal.model
anal1sis. I
then loo0ed at
the main
activities of
s3ecification
and reali4ation
of services.
In the ne$t
column in this
series, I 5ill
a33l1 the
method to the
ban0in-
domain of
account
mana-ement
and describe
each ste3 5ith
an e$am3le.
In addition to
identification,
s3ecification,
and
reali4ation, I
5ill also
discuss the
remainin-
activities of
the service.
oriented
modelin-
a33roach that
includes
de3lo1ment,
monitorin-,
mana-ement,
and
-overnance
re2uired to
su33ort the
full !A life
c1cle.
Ac"nowledgme
nts
,he author
5ould li0e to
ac0no5led-e
the valued
in3ut and
feedbac0 of
the follo5in-
esteemed
collea-ues
and friends
(no 3articular
order): Luba
Cherba0ov,
Nerrie ?olle1,
9eor-e
9alambos,
u-andh
&ehta, David
Oanson,
han0ar
Nal1ana, #d
Calun4ins0i,
Abdul Allam,
Peter ?olm,
Nrishnan
>amachandra
n, Oenn1 An-,
Oonathan
Adams, unil
Dube, >al3h
"iest, !laf
7immerman,
#mil1 Plach1,
Nath1
A-lesias.
>eece, and
David &ott.
#esources
>ead
the
article
=#lemen
ts of
ervice.
oriented
Anal1sis
and
Desi-n8
,
(develo
3er"or
0s, Oune
*''+)
for
more
informa
tion on
this
interdis
ci3linar
1
modelin
-
a33roac
h for
!A
3rojects
.
>ead
about
8Pattern
s:
ervice.
oriented
Architec
ture
and
"eb
ervice
s8
>edboo
0,
9*+.
;D'D.
'',
A3ril
*''+,
#ndrei
&., et
al.
Lisit
"eber
vices.!r
-P for
more
informa
tion on
the
"oal-
oriente
d
approac
h to
enterpri
se
compon
ent
identific
ation
and
specific
ation,
Commu
nication
s of the
AC&,
!ct
*''*,
N. Levi,
A.
Arsanja
ni.
9et the
#terna
lizing
$ompo
nent
%anner
s to
Achieve
"reater
%aintai
nability
through
a
&ighly
'e-
$onfigu
rable
Architec
tural
Style
article
b1 Ali
Arsanja
ni,
Oames
O.
Al3i-ini,
and
?ussein
7edan.
Proceed
in-s of
the
IC&:
;*:..
I###
Press
*''*.
9o to
Ali
Arsanja
niJs
Patterns
and
%est.
3ractice
s "eb
site for
more
informa
tion on
,he
#nter3ri
se
Com3on
ent
Pattern,
3roceed
in-s of
3attern
lan-ua-
es of
3ro-ra
mmin-
*'''.
Chec0
out the
8Pattern
s:
Im3lem
entin-
an !A
5ith the
#nter3ri
se
ervice
%us8
>edboo
0,
9*+.
;D+;.
'',
Au-ust
*''+,
&artin
Neen,
usan
%isho3,
Alan
?o30ins
, ven
&ilins0i,
Chris
)ott,
>ic0
>obinso
n,
Oonatha
n
Adams,
Paul
Lerschu
eren.
Access
"eb
services
0no5led
-e,
tools,
and
s0ills
5ith
3eed.
start
"eb
services
, 5hich
offers
the
latest
Oava.
based
soft5ar
e
develo3
ment
tools
and
middle5
are
from
I%&
(trial
editions
), 3lus
online
tutorials
and
articles,
and an
online
technica
l forum.
9et
involved
in the
develo3
er"or0s
commu
nit1 b1
3artici3
atin- in
develo3
er"or0s
blo-s.
%ro5se
for
boo0s
on
these
and
other
technica
l to3ics.
"ant
more<
,he
develo3
er"or0s
!A
and
"eb
services
4one
hosts
hundred
s of
informa
tive
articles
and
introduc
tor1,
interme
diate,
and
advance
d
tutorials
on ho5
to
develo3
"eb
services
a33licat
ions.
A!out the
author
Dr. Ali Arsanjani is a enior ,echnical taff &ember 5ho is Chief Architect of
the !A and "eb ervices Center of #$cellence in I%& 9lobal ervices. ?e
has *C 1ears e$3erience in the I, industr1, desi-nin- and deliverin-
distributed soft5are architectures for lar-er s1stems. ?is research interests
and 3ublications include soft5are desi-n 3atterns, soft5are architecture,
com3onent.based and service.oriented architectures, and -rammar.oriented
object desi-n. ?e s3eciali4es in buildin- d1namicall1 reconfi-urable soft5are
s1stems. Aou can contact him at