contemporary architectural and development practices in web
Post on 10-Jun-2015
551 Views
Preview:
TRANSCRIPT
www.neresc.ac.ukwww.neresc.ac.uk
Architecting Secure, Reliable, and Transacted Service Oriented Architecture using Web Services
Architecting Secure, Reliable, and Transacted Service Oriented Architecture using Web Services
Dr. Jim Webberhttp://jim.webber.name
Jim@Webber.name
Dr. Jim Webberhttp://jim.webber.name
Jim@Webber.name
www.neresc.ac.ukwww.neresc.ac.uk
UK E-Science Programme
‘e-Science is about global collaboration in key areas of science and the next generation of infrastructure that will enable it.’
• £250 (~AU$600) million, 5 year programme• Split between application areas and infrastructure
• Bioinformatics, astronomy,etc• “Grid” computing, Internet-scale computing, etc
• My involvement: Web Services standards, architecture, and development
www.neresc.ac.ukwww.neresc.ac.uk
Roadmap
• Historical Perspective• What is a Web Service?• Evolution of Web Service
• Message-Orientation• Architecture• Protocol• Implementation
• Enterprise Issues• Scalability• Dependability• Consistency
• Summary• Q&A
www.neresc.ac.ukwww.neresc.ac.uk
What is a Web Service?
• A service is piece of application logic exposing message-oriented interface.• Any scale from inter-process
to Internet
• A Web Service is a system which exposes a message oriented-interface whose messages are in SOAP format.
• SOAP is the critical differentiator.• It is what differentiates a Web
Service from other kinds of services (e.g. OS services).
• SOAP is the lowest point in the WS stack.
SOAP Messages
Network
SOAP message processor
Application
www.neresc.ac.ukwww.neresc.ac.uk
Remote object method invocations
Network
Client Application
Client application objects and proxies Server objects and
stubs
Serverapplication
In the Beginning...
• In the old days we used SOAP-RPC• RPC style SOAP plus encoding rules for serialising and deserialising
application-level objects into messages.• A kind of XML RPC• Similar to RMI etc but without all the good stuff like garbage
collection, security, and performance.
Some otherwise brightpeople still think
of Web Services in this way
www.neresc.ac.ukwww.neresc.ac.uk
RPC with Documents
• The community learned that SOAP RPC was pretty awful for interoperability• Different implementations interpreted the encoding rules
differently.
• Document-oriented SOAP (doc/literal) solved (or at least moved) interoperability problems.• But left the inappropriate object-like model in place.
• RPC with documents is the mainstream of Web Services today.
• It is not the future of Web Services, just a point on the learning curve.
www.neresc.ac.ukwww.neresc.ac.uk
The RESTifarian Jihad
• Seeing that the Web was good and that RPC was bad, the RESTifarians waged war on the Web Services community.
• REST-ful services have a uniform API and exchange messages using that API.
• The API is HTTP-like and allows messages to be sent (POST) and responses to be solicited (GET)• Along with PUT and DELETE etc.
• Unfortunately RESTful semantics aren’t always mappable onto protocols other than HTTP.• What’s SMTP GET?
• Imposing an API – even a uniform API – is too constraining.
• But the notion of exchanging messages is correct.
www.neresc.ac.ukwww.neresc.ac.uk
A Message-Oriented Architectural Style
• Today’s Web Services architecture is based on the notion of:• Services, which exchange• SOAP Messages, which are constrained in form and exchange
pattern by• WSDL, which may also advertise• Quality of Service Protocols, defined by the• WS-* specifications
• The action taken in response to receiving a message is up to the recipient• At the highest architectural level, a message exchange is simply a
transfer of information from sender to receiver.• The business semantics of a message exchange are service-specific.
• Transfer of messages is transport protocol independent• The means of transporting a message carries no semantics
• I.e. POSTing or GETting does not change the semantics of a message.
www.neresc.ac.ukwww.neresc.ac.uk
Canonical Web Services-based Application
Message requests (and perhaps responses) that do not relate to a specific object
SOAP message processor
Purchase ordersystem Purchase order
application
SOAP message processor
Purchase order
service
WSDL
Contract about
the form
at of
messages that
c
an be exchanged
Example: ServiceA sends ServiceB a MessageX. ServiceB responds with a MessageY or a MessageZ depending on the content of the MessageX it received.
www.neresc.ac.ukwww.neresc.ac.uk
Architecture
• Standard enterprise architecture• Tool support: Whiteboard, PowerPoint, and coffee
• Identify functional and non-functional requirements• Identify existing Web Services as candidates for inclusion in the system
• Those that satisfy the functional and non-functional requirements• Identify what functionality you need to deploy yourself.• Identify the interactions between Web Services
Service
Ad
min
istr
ativ
e
do
ma
in
Service
Service
Service
Administrative domain
Service
Service Ad
min
istrative
d
om
ain
<wsdl> <types /> <definitions> ... </definitions> <interface> … </interface></wsdl>
Not validated
WSDL contract
www.neresc.ac.ukwww.neresc.ac.uk
Architecture: Key WS-* Specs
• SOAP• The lowest part of the Web Services stack.• Consider messages in terms of:
• Content for functional requirements;• Content for non-functional requirements.
• SOAP provides a transfer mechanism that combines both:• SOAP body for transferring information pertinent to the functional
requirements;• SOAP headers for transferring out-of-band information to address non-
functional requirements.
• WS-Addressing• Remember - SOAP is the lowest part of the WS stack!• It is the transfer mechanism for Web Services
• Everything else is transport.
• WS-Addressing allows SOAP messages to be routed round a system irrespective of the underlying transport.
www.neresc.ac.ukwww.neresc.ac.uk
SOAP + WS-Addressing
http tcp jms
logical point-to-point SOAP message transfer
intermediate intermediate
Web Service
transport
Web Service
transport
www.neresc.ac.ukwww.neresc.ac.uk
Protocol
• Each Web Service we develop has to deal with message exchanges• Those that it requires to expose its own functionality;• Those that the Web Services it uses to interact with other
Web Services;• Message exchanges pertaining to the QoS protocols it
supports.
• Protocol demolishes the idea of Web Services as entities which are “invoked.”• If you insist on having an operation to invoke, then “invoke”
the ProcessMessage operation.
• ProcessMessage is abstract, semantics:• A transfer of a message from sender to receiver; and• A request to process the received message.
www.neresc.ac.ukwww.neresc.ac.uk
Deriving Contracts
• Protocol is supported by contracts• Form and pattern of messages
exchanged by a Web Service• Note: contracts rather than interfaces
• Interface is an overloaded term that implies type information
• No type information in Web Services, only schema
• Derive contract by examining SOAP messages
• WSDL contract describes messages and message exchanges that the service will participate in.
<wsdl:definitions> <wsdl:types> ... </wsdl: types> <wsdl: interfaces> ... </wsdl: interfaces> <wsdl:binding> ... </wsdl:binding> <wsdl:service> ... </wsdl:service></wsdl:definitions>
Pro
toco
lC
ontr
act
www.neresc.ac.ukwww.neresc.ac.uk
Contract and Policy
• Contracts are binding and immutable• The associated service cannot violate the terms it sets out in
the contract.• Consumers’ only information about the service is its contract.
• Serves two purposes:1. Facilitates interoperability with other services;
• Advertises message exchanges, and possibly QoS support/requirements
2. Decouples service implementation from consumers.• Hides the implementation of a service behind a message-oriented façade.
• Policy declarations determine the QoS protocols used for an interaction.• Policies can be determined statically or dynamically• Static policies can be attached to the service contract• Dynamically created policies communicated to service
consumers during interactions with the service
www.neresc.ac.ukwww.neresc.ac.uk
WSDL Contracts are not Object IDL
• WSDL contracts should not “leak” information about their services.
Anything in declared a WSDL contract must be preserved until the associated Web Service is retired.• Remember WSDL is immutable
• Service implementations are not• They will be subject to maintenance, bug fixes etc
• Use WSDL to shield your service implementation from its consumers.• Expose only messages and message exchanges.
• WSDL isn’t Object IDL.• A WSDL contract betrays no type information and must not
expose the type system of the underlying implementation.
www.neresc.ac.ukwww.neresc.ac.uk
Protocol: Key WS-* Specs
• In addition to the architecture specs:• Metadata
• WSDL, WS-Policy, WS-MetadataExchange
• Security• WS-Security, WS-Trust, WS-SecureConversation
• Reliable Messaging• WS-ReliableMessaging
• Transactions• WS-AT/BA or WS-TransactionManagement
Mes
sagi
ngQ
ualit
y of
ser
vice
Tra
nsfe
r
Addressing, notification, enumeration, etc.(WS-Addressing, WS-MessageDelivery, WS-Eventing, WS-
Notification, WS-Enumeration)
Met
adat
a(W
SD
L, P
olic
y)
Sec
urity
(WS
-Sec
urity
, WS
-Tru
st, W
S-
Sec
ureC
onve
rsat
ion
)
Rel
iabl
e m
essa
ging
(WS
-Rel
iabl
eMes
sagi
ng)
Tra
nsac
tions
(WS
-AT
/BA
, WS
-T
rans
actio
nMan
agem
ent)
SOAP
www.neresc.ac.ukwww.neresc.ac.uk
Implementation
• The internal architecture of a service is relatively mundane.
• The layering of messaging, logic, and state is similar to the classic N-tiered architecture.
• The message processing layer is interesting though... B
PE
L, J
ava,
.NE
T
serv
ice
logi
c
Databases
Humans
ProgramsComputational resources
Devices
reso
urce
s
<env:Envelope> <env:Header> ... </env:header> <env:Body> ... </env:Body></env:Envelope>
mes
sage
pro
cess
ing
SO
AP
, WS
DL,
and
ot
her
WS
-* p
roto
cols
pr
oces
sing
tran
spor
t
SOAP messages
TCP, UDP, HTTP, SMTP, JMS, etc.
www.neresc.ac.ukwww.neresc.ac.uk
Message Processing Layer
• Deals with the conversion of messages on the wire (in SOAP format) to programmatic abstractions.
• Does not try to abstract message exchanges into RPC
• Presents a truthful picture of the underlying message exchanges to the service logic• Allows the service logic to be
tolerant of the underlying messaging infrastructure
• Latent, lossy, asynchronous etc
• Messages are the abstraction that the service logic binds to, not other services• Loose coupling!
mes
sage
pro
cess
ing
tran
spor
tbody
head
er
SO
AP
Env
elop
e <wsdl> <interface> … </interface></wsdl>
<wsdl> <interface> … </interface></wsdl> bo
dyhe
ader
SO
AP
Env
elop
e <wsdl> <interface> … </interface></wsdl>
<wsdl> <interface> … </interface></wsdl>
incoming SOAP message
outgoing SOAP message
serv
ice
logi
c
messageobject
messageobject
Network
Client Application
Client application objects and proxies Server objects and
stubs
Serverapplication
WSDL
www.neresc.ac.ukwww.neresc.ac.uk
Today’s SOAP API
public class GameServiceStub
{
public void StartGame(){...}
public GridPos Move(GridPos gp)
{...}
// Other remote methods omitted for brevity
}
www.neresc.ac.ukwww.neresc.ac.uk
Typical Message-Oriented API
public interface IMessage{...}
public class StartGameMessage : IMessage{...}
// Other messages omitted for brevity
public class GameMessagingLayer{
/* Outbound messages */public void SendMessage(IMessage){...}
/* Inbound messages */
public event MoveMessageReceivedDelegate MoveMessageArrived;public event StartGameMessageReceivedDelegate StartGameMessageArrived;
// Other messaging events omitted for brevity}
www.neresc.ac.ukwww.neresc.ac.uk
Service Logic
• The arrival of a message at a service causes some processing to occur• From the ProcessMessage architectural style
• Service implementation is stateless• All the information it needs to perform a specific task is
contained with the message that initiates that task, is computed, or is contained in the persistent data storage tier.
• c.f. architecture of the web.
• Non-functional requirements (e.g. security, message integrity) are out of scope for service implementation• They are administrative tasks (mostly!).
www.neresc.ac.ukwww.neresc.ac.uk
Enterprise Issues
• Web Services are not an enterprise platform in the traditional sense• Though an individual Web Service will usually be deployed
onto such a platform (J2EE app server, .Net)
• Just a collection of specs and implementations• messages, message exchange patterns, and semantics
• Cannot rely on the infrastructure to manage dependability characteristics• Security, reliable message transfer, transactionality,
scalability etc
• Need to understand how the WS-* specs can help• And how then cannot help.
www.neresc.ac.ukwww.neresc.ac.uk
Enterprise Issues: Security
• WS-Security does not make your Web Services secure!
• It can help with message-level security• Privacy• Integrity• Non-repudiation
• HTTPS is not sufficient• Messages traverse arbitrary
networks• Point to point mechanisms are
difficult to scale• WS-Security elements are
embedded within the message• And easily traverse arbitrary
networks
http tcp jms
logical point-to-point SOAP message transfer
resources
message processing
Web Service logic
transport
resources
message processing
Web Service logic
transport
intermediate intermediate
www.neresc.ac.ukwww.neresc.ac.uk
Enterprise Issues: Reliable Messaging
• In theory, reliable messaging is transparent to the architecture
• Reliable messaging gives us at most once/exactly once notification of delivery of messages• No indication whatsoever of whether a message was
processed
• Messages can go missing or be duplicated, the protocol will detect that• Not in a catastrophic failure case
• Can rely on the underlying protocol to smooth out the lumps in a large-scale Web Service networks• No such thing as a free lunch• The lumps will always be there, RM can only reduce their
frequency and size
www.neresc.ac.ukwww.neresc.ac.uk
Enterprise Issues: Reliable Messaging
• The underlying protocols still have to be exposed to our Web Service implementations• Implementations have to be architected to deal with failures
in messaging
• Should all processes should be idempotent?• Dependability characteristics of the Web Service
• Mission critical – every operation has to be idempotent.• At some point RM will fail. Without idempotent operations you are in a
world of pain
• Somewhat critical – take a chance?• Make common or particularly important routines idempotent
• Uncritical• Leave it to the underlying RM protocol!
ComplexBig $$$
investmentSomewhat complex
Lower $$$Easy (if nothing goes wrong)
Cheap!
www.neresc.ac.ukwww.neresc.ac.uk
Enterprise Issues: Scalability
• Stateless services scale easily.
• Add more hardware, deploy services.
• Leave state management to underlying enterprise-grade Database.• DB guys know how to
manage state in a dependable manner
Server Farm
Data Tier
www.neresc.ac.ukwww.neresc.ac.uk
Enterprise Issues: Dependability
• Statelessness makes failover fault tolerance trivial• Well mostly...
• If it can be detected that a Web Service or a host server has crashed, simply route messages to live Web Services on live hosts• Standard systems management stuff for the hardware• WS-Management may help for Web Services
• Stateful services will cause you pain• Do you really want to have to build state migration
capabilities into your WS code?• Avoid WS-RF!
www.neresc.ac.ukwww.neresc.ac.uk
Server Farm
State Sucks
Unknown Conversation
Multi-Protocol Session-Affinity Aware Router$$$
www.neresc.ac.ukwww.neresc.ac.uk
Server Farm
State Still Sucks, but it’s the DBA’s Problem
Data Tier
El-Cheapo Round-Robin Router
www.neresc.ac.ukwww.neresc.ac.uk
Enterprise Issues: Consistency
• Never expose lockable resources outside your administrative domain• Denial of service attacks possible otherwise
• Cannot have consistent data all the time.• Have to be satisfied with snapshots of data• Only the administrative domain that owns the data has the
most up-to-date information
• Web Services transactions don’t help• They just keep logical processing of messages in sync.
• Design applications with the understanding of the “age” of the data in mind• See: Pat Helland’s “Data on the Inside vs. Data on the
Outside” for in-depth analysis• http://msdn.microsoft.com/architecture/overview/
default.aspx?pull=/library/en-us/dnbda/html/dataoutsideinside.asp
www.neresc.ac.ukwww.neresc.ac.uk
Summary
• Web Services are about document exchanges, not APIs or interfaces
• Messages are the source of truth, use them to decouple your service from its consumers
• Be careful what you advertise in WSDL, you’ll have to carry it forever
• Three architectural views:• Global architecture (Service-Oriented)• Protocol (Message-Oriented)• Implementation (Event driven)
• Web Service interactions are stateless• WS-* can only get you so far
www.neresc.ac.ukwww.neresc.ac.uk
Got Question
s?
Got Question
s?
top related