Architecting Secure, Reliable, and Transacted Service Oriented by vev19514

VIEWS: 8 PAGES: 33

									      Architecting Secure, Reliable, and Transacted Service
            Oriented Architecture using Web Services




                                           Dr. Jim Webber
                                      http://jim.webber.name
                                        Jim@Webber.name




www.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.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.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                          Application
   which exposes a message
   oriented-interface whose
   messages are in SOAP format.                     SOAP message
 • SOAP is the critical                               processor

   differentiator.
      • It is what differentiates a Web            SOAP Messages
        Service from other kinds of
        services (e.g. OS services).
 • SOAP is the lowest point in the
                                                              Network
   WS stack.

www.neresc.ac.uk
                                   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.


                                 Client Application
                                                                       Server
                                                                     application
                                Client application
                 Some  otherwise bright
                               objects and proxies                Server objects and
                                                                        stubs
                    people still think
               of Web Services in this way



                                 Remote object method
                                     invocations

                                                                  Network


www.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.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.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.uk
                        Canonical Web Services-based Application


                           Purchase order
                               system                                  Purchase order
                                                                                                             Pu
                                                                         application                           rch
                                                                                                                    a
                                                                                                                se se o
                                                                                                                   rvi   r
                                                                                                                      ce der
                                                                                                     ut
                                                                                                  bo
                                                                                               t a of      t     d              DL
                                                                                            rac rmat s tha ange
                                                                                          nt fo                              WS
                                                                                        Co e           e xch
                                                                                                    ag
                                                                                          th ess be e
                                                                                              m an
                                                                                                  c




                   SOAP message                                  SOAP message
                     processor                                     processor




                    Message requests (and perhaps responses)
                       that do not relate to a specific object




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

                                                      Administrative
                                                        domain


                                                         Service


                                         Service
                        Administrative




                                                                                       Service




                                                                                                 Administrative
                          domain




                                                                                                   domain
                                         Service


                                                                                       Service
                                         Service

                                                        <wsdl>
                                                          <types />        Not validated
                                                          <definitions>
                                                            ...
                                                          </definitions>
                                                          <interface>
                                                            …
                                                          </interface>
                                                        </wsdl>



                                                       WSDL contract

www.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.uk
                         SOAP + WS-Addressing




           Web Service          logical point-to-point SOAP message transfer         Web Service




                         http                       tcp                        jms
            transport                                                                 transport

                                  intermediate               intermediate




www.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.uk
                                 Deriving Contracts

 • Protocol is supported by contracts
      • Form and pattern of messages exchanged
        by a Web Service




                                                                  Protocol
      • 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:definitions>
                                                                                <wsdl:types>
                                                                                 ...
                                                                                 </wsdl:types>

 • WSDL contract describes messages




                                                                    Contract
                                                                                <wsdl:interfaces>
                                                                                 ...
                                                                                 </wsdl:interfaces>

   and message exchanges that the                                               <wsdl:binding>
                                                                                 ...
                                                                                 </wsdl:binding>

   service will participate in.                                                 <wsdl:service>
                                                                                 ...
                                                                                 </wsdl:service>
                                                                               </wsdl:definitions>




www.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.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.uk
                                                   Protocol: Key WS-* Specs

 • In addition to the architecture specs:
      • Metadata



                               (WS-Security, WS-Trust, WS-
            • WSDL, WS-Policy, WS-MetadataExchange




                                                                                      TransactionManagement)
                                                             (WS-ReliableMessaging)
      • Security

                                  SecureConversation)




                                                               Reliable messaging




                                                                                                               Quality of service
                                                                                          (WS-AT/BA, WS-
            • WS-Security, WS-Trust, WS-SecureConversation




                                                                                            Transactions
                                        Security

      • Reliable Messaging
              (WSDL, Policy)




            • WS-ReliableMessaging
                Metadata




      • Transactions
            • WS-AT/BA or WS-TransactionManagement




                                                                                                               Messaging
                                          Addressing, notification, enumeration, etc.
                                   (WS-Addressing, WS-MessageDelivery, WS-Eventing, WS-
                                               Notification, WS-Enumeration)




                                                                                                               Transfer
                                                                           SOAP




www.neresc.ac.uk
                             Implementation

 • The internal architecture of a                                         Devices




                                                                                                              resources
   service is relatively mundane.                                                                    Humans


 • The layering of messaging,                                                         Programs
   logic, and state is similar to the                         Databases         Computational resources


   classic N-tiered architecture.




                                           BPEL, Java, .NET




                                                                                                              service logic
 • The message processing layer
   is interesting though...




                                        other WS-* protocols




                                                                                                              message processing
                                         SOAP, WSDL, and
                                                                               <env:Envelope>
                                                                                 <env:Header>




                                             processing
                                                                                    ...
                                                                                 </env:header>
                                                                                 <env:Body>
                                                                                    ...
                                                                                 </env:Body>
                                                                               </env:Envelope>



                                                  SOAP messages




                                                                                                              transport
                                                                   TCP, UDP, HTTP, SMTP, JMS, etc.

www.neresc.ac.uk
                             Message Processing Layer

 • Deals with the conversion of
   messages on the wire (in SOAP
   format) to programmatic




                                                                                                                                       service logic
   abstractions.
                                                                message                                     message
                                                                 object                                      object

 • Does not try to abstract
   message exchanges into RPC                                          Client Application
                                                                                              outgoing SOAP message




                                                                                                                                       message processing
                                                                                                                                  Server

 • Presents a truthful picture of                                         Client application
                                                                                                                                application

                                                                                                                             Server objects and

   the underlying message
                                                                         objects and proxies
                                                                                                                                   stubs

                                                incoming SOAP message
   exchanges to the service logic
      • Allows the service logic to be
                                                                <wsdl>                                      <wsdl>




                                                       header




                                                                                                   header
                                                                                 WSDL




                                                SOAP Envelope




                                                                                            SOAP Envelope
                                                                  <interface>                                 <interface>
                                                                    …                                           …


        tolerant of the underlying
                                                                  </interface>                                </interface>
                                                                </wsdl>                                     </wsdl>




        messaging infrastructure                                <wsdl>                                      <wsdl>           Network




                                                 body




                                                                                             body
                                                                  <interface>                                 <interface>
                                                                    …                                           …
                                                                  </interface>                                </interface>
            • Latent, lossy, asynchronous etc




                                                                                                                                       transport
                                                                </wsdl>                                     </wsdl>




 • Messages are the abstraction
   that the service logic binds to,
   not other services
      • Loose coupling!
www.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.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.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.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.uk
                                  Enterprise Issues: Security

 • WS-Security does not make your                                      • HTTPS is not sufficient
   Web Services secure!                                                         • Messages traverse arbitrary
 • It can help with message-level                                                 networks
   security                                                                     • Point to point mechanisms are
      • Privacy                                                                   difficult to scale
      • Integrity                                                      • WS-Security elements are
      • Non-repudiation                                                  embedded within the message
                                                                                • And easily traverse arbitrary
                                                                                  networks


                   resources                                                                        resources




              Web Service logic                                                                  Web Service logic




             message processing            logical point-to-point SOAP message transfer         message processing




                                    http                       tcp                        jms
                   transport                                                                         transport
                                             intermediate               intermediate



www.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.uk
                   Enterprise Issues: Reliable Messaging

 • The underlying protocols still have to be exposed to our
   Web Service implementations
               Complex
    • Implementations have to be architected to deal with failures in
        Big $$$
      messaging investment
 • Should all processes should be idempotent?
              Somewhat
 • Dependability characteristics of the Web Service
               complex
           Easy (if nothing
              critical $$$
    • Mission Lower – every operation has to be idempotent.
             goes wrong)
       • At some point RM will fail. Without idempotent operations you are in a world
         of painCheap!
      • Somewhat critical – take a chance?
            • Make common or particularly important routines idempotent
      • Uncritical
            • Leave it to the underlying RM protocol!




www.neresc.ac.uk
                     Enterprise Issues: Scalability

 • Stateless services scale easily.                    Data Tier

 • Add more hardware, deploy
   services.
                                                      Server Farm
 • Leave state management to
   underlying enterprise-grade
   Database.
      • DB guys know how to manage
        state in a dependable manner




www.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.uk
                             State Sucks

                                                      Server Farm




                                             Unknown Conversation


 $$$               Multi-Protocol Session-Affinity Aware Router




www.neresc.ac.uk
                   State Still Sucks, but it’s the DBA’s Problem
                                                               Data Tier




                                                         Server Farm




                                El-Cheapo Round-Robin Router




www.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.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.uk
                      Got
                   Questions?



www.neresc.ac.uk

								
To top