2. Agenda
๏ About
WSO2
๏ Of
rela)onships
and
what
not!
๏ Rela)onships
between
services
๏ En)ty
Linking
in
prac)ce
๏ What
SOA
can
learn
from
the
RESTful
pa5erns
๏ RESTful
APIs
๏ HATEOAS
๏ Lightweight
Endpoints
๏ Dynamic
Endpoints
๏ The
API
Façade
๏ Bringing
it
all
together
๏ References
2
3. 3
Mifan
Careem
-‐
BIO
๏ Mifan
Careem,
Director
of
Solu)ons
Architecture
at
WSO2
๏ Mifan
AT
WSO2.com
๏ Works
closely
with
clients
and
WSO2
engineering
and
sales
teams,
in
defining
domain
specific
solu)ons
architectures
4. 4
About
WSO2
๏ Global
enterprise,
founded
in
2005
by
acknowledged
leaders
in
XML,
web
services
technologies,
standards
and
open
source
๏ Provides
only
open
source
plaWorm-‐as-‐a-‐service
for
private,
public
and
hybrid
cloud
deployments
๏ All
WSO2
products
are
100%
open
source
and
released
under
the
Apache
License
Version
2.0.
๏ Is
an
Ac)ve
Member
of
OASIS,
Cloud
Security
Alliance,
OSGi
Alliance,
AMQP
Working
Group,
OpenID
Founda)on
and
W3C.
๏ Driven
by
Innova)on
๏ Launched
first
open
source
API
Management
solu)on
in
2012
๏ Launched
App
Factory
in
2Q
2013
๏ Launched
Enterprise
Store
and
first
open
source
Mobile
solu)on
in
4Q
2013
7. An
Enterprise
Requirement
๏ Build
a
set
of
Business
APIs
in
a
simple,
understandable
manner
based
on
a
complex,
evolving
plaWorm
–
these
APIs
should
stand
the
test
of
)me,
should
be
self-‐
describable
and
should
allow
both
the
plaWorm
and
client
to
evolve
on
their
own.
7
10. A
typical
service
with
rela)onships
10
๏ A
service
chaining
example
below,
where
the
rela)onship
logic
would
be
‘hard-‐coded’
in
the
calling
service
<definitions xmlns="http://ws.apache.org/ns/synapse">
<proxy name="StockQuoteProxy">
<target>
<endpoint>
<address uri="http://localhost:9000/services/
SimpleStockQuoteService"/>
</endpoint>
<outSequence>
<send/>
</outSequence>
</target>
<publishWSDL uri="file:repository/samples/
resources/proxy/sample_proxy_1.wsdl"/>
</proxy>
</definitions>
11. Problems
๏ Service
interfaces
are
‘fixed’
๏ Service
interfaces
are
not
‘meaningful’
or
‘intui)ve’
๏ Rela)onships
cannot
be
dynamic,
and
are
pre-‐defined
in
the
calling
service
๏ Services
cannot
be
interchanged
at
run)me
11
12. REST
–
a
SOA
design
summary
๏ Everything
is
a
resource
–
iden)fy
resources
that
are
exposed
as
services
๏ Model
rela)onships
and
define
resource
friendly
URLs
๏ Map
HTTP
CRUD
to
obtain
and
modify
resources
–
map
GET,
PUT,
POST
and
DELETE
๏ Document
resource
representa)ons
(JSON,
XML,
micro-‐
formats)
๏ Pa5erns
and
an)-‐pa5erns
12
13. Example
๏ PersonInfoService
๏ /person
–
GET,
POST
๏ /person/{id}
–
GET,
PUT,
DELETE
๏ /person/{id}/account–
GET,
POST
๏ /person/{id}/account/id
–
GET,
PUT,
DELETE
๏ POST
to
create
Person
๏ POST
/person
๏ 200
OK
๏ Loca)on:
/person/1423
๏ GET
Person
Account
๏ GET
/person/1423/account
๏ 200
OK
๏ <account>A,
B,
C</account>
๏ <credit
href=“/credit”/>
13
14. REST
and
Associated
Pa5erns
๏ Uniform
Contract
๏ Using
fixed
methods
๏ En)ty
Linking
๏ Discoverable
rela)onships
in
en))es
๏ En)ty
Endpoints
๏ Naming
๏ En)ty
Re-‐direc)on
๏ Load
balancing
๏ Content
Nego)a)on
๏ Mul)ple
clients
๏ Lightweight
Endpoints
๏ Web
API
๏ API
Façade
๏ HATEOAS
๏ Explicity
handle
state
14
17. A
typical
service
with
rela)onships
17
๏ A
service
chaining
example
below,
where
the
rela)onship
logic
would
be
‘hard-‐coded’
in
the
calling
service
<definitions xmlns="http://ws.apache.org/ns/synapse">
<proxy name="StockQuoteProxy">
<target>
<endpoint>
<address uri="http://localhost:9000/services/
SimpleStockQuoteService"/>
</endpoint>
<outSequence>
<send/>
</outSequence>
</target>
<publishWSDL uri="file:repository/samples/
resources/proxy/sample_proxy_1.wsdl"/>
</proxy>
</definitions>
18. En)ty
Linking
Defined
๏ Problem:
Pre-‐defined
rela)onships
๏ Business
en))es
have
natural
rela)onships,
yet
en)ty
services
are
commonly
designed
autonomously
with
no
indica)on
of
these
rela)onships.
๏ Service
consumers
ac)ng
as
composi)on
controllers
are
commonly
required
to
have
en)ty
linking
logic
hard-‐coded
in
order
to
work
with
en)ty
rela)onships.
๏ This
limits
the
composi)on
controller
to
any
addi)onal
links
that
may
become
relevant
and
further
adds
a
governance
burden
to
ensure
that
hard-‐coded
en)ty
linking
logic
is
kept
in
synch
with
the
business.
๏ Solu)on:
En)ty
Linking
๏ Services
inform
their
consumers
about
the
existence
of
related
en))es
as
part
of
the
consumer's
interac)ons
with
the
services.
๏ Applica)on
๏ Links
are
included
in
relevant
response
messages
from
the
service.
๏ Service
consumers
are
able
to
navigate
from
en)ty
to
en)ty
by
following
these
links,
and
accumulate
further
business
knowledge
along
the
way.
๏ This
allows
service
consumers
with
li5le
up-‐front
en)ty
linking
logic
to
correctly
compose
en)ty
services
based
on
their
rela)onships.
18
source: http://SOAPatterns.org
19. En)ty
Linking
in
Prac)ce
๏ Wikipedia
–
the
mother
of
all
rela)onships
๏ Linked
Data
๏ DBPedia
19
20. Example
extended
๏ GET
Person
Account
๏ GET
/person/1423/account
๏ 200
OK
๏ <account>A,
B,
C</account>
๏ <credit
href=“/credit”/>
๏ GET
Account
from
CreditService
๏ GET
/person/1423/account/credit/14
20
22. API
Façade
๏ A
design
pa5ern
where
a
simpler
business
API
interface
is
exposed,
hiding
the
underlying
complex
services
layer
๏ External
clients
communicate
with
the
business
API
layer
–
hence
it
is
important
to
keep
business
APIs
constant
and
re-‐usable
even
when
the
underlying
plaWorm
evolves
22
23. HATEOAS
๏ Hypertext
As
The
Engine
Of
Applica)on
State
๏ It
means
that
hypertext
should
be
used
to
find
your
way
through
the
API
๏ Loose
coupling
between
client
and
server
23
GET /person/1234/account
<account>
<balance>USD 120</balance>
<link rel=“withdraw” href=“/withdraw”/>
<link rel=“deposit” href=“/deposit”/>
<link rel=“close” href=“/close”/>
</account>
<account>
<balance>USD 3</balance>
<link rel=“deposit” href=“/deposit”/>
<link rel=“close” href=“/close”/>
</account>
24. Endpoint
Registry
๏ Endpoints
can
differ
based
on
the
environment,
context,
business
case
๏ A
smart
endpoint
registry
can
pick
up
endpoints
dynamically
at
run)me
24
Source:Asanka Abeysinghe – WSO2 Solutions Architecture Blog
