Architecting Secure, Reliable, and Transacted Service Oriented by vev19514


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

                                           Dr. Jim Webber
                     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

 • Historical Perspective
      • What is a Web Service?
      • Evolution of Web Service
 • Message-Orientation
      • Architecture
      • Protocol
      • Implementation
 • Enterprise Issues
      • Scalability
      • Dependability
      • Consistency
 • Summary
 • Q&A
                          What is a Web Service?

 • A service is piece of
   application logic exposing
   message-oriented interface.
      • Any scale from inter-process to
 • 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

      • 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
   WS stack.
                                   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
                                Client application
                 Some  otherwise bright
                               objects and proxies                Server objects and
                    people still think
               of Web Services in this way

                                 Remote object method

                          RPC with Documents

 • The community learned that SOAP RPC was pretty awful
   for interoperability
      • Different implementations interpreted the encoding rules
 • 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
 • It is not the future of Web Services, just a point on the
   learning curve.
                        The RESTifarian Jihad

 • Seeing that the Web was good and that RPC was bad,
   the RESTifarians waged war on the Web Services
 • 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
 • But the notion of exchanging messages is correct.
                   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
      • 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
      • 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.
                        Canonical Web Services-based Application

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

                   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.

 •   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








                                                          <types />        Not validated

                                                       WSDL contract
                          Architecture: Key WS-* Specs

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

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

                         http                       tcp                        jms
            transport                                                                 transport

                                  intermediate               intermediate

 • 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
      • 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.
                                 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
            • No type information in Web Services, only

 • Derive contract by examining SOAP

 • WSDL contract describes messages


   and message exchanges that the                                               <wsdl:binding>

   service will participate in.                                                 <wsdl:service>
                               Contract and Policy

 • Contracts are binding and immutable
      • The associated service cannot violate the terms it sets out in the
      • 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
                   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
       • 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.
                                                   Protocol: Key WS-* Specs

 • In addition to the architecture specs:
      • Metadata

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

      • Security


                                                               Reliable messaging

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


      • Reliable Messaging
              (WSDL, Policy)

            • WS-ReliableMessaging

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

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


 • The internal architecture of a                                         Devices

   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


                                                  SOAP messages

                                                                   TCP, UDP, HTTP, SMTP, JMS, etc.
                             Message Processing Layer

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

                                                                                                                                       service logic
                                                                message                                     message
                                                                 object                                      object

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

                                                                                                                                       message processing

 • Presents a truthful picture of                                         Client application

                                                                                                                             Server objects and

   the underlying message
                                                                         objects and proxies

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



                                                SOAP Envelope

                                                                                            SOAP Envelope
                                                                  <interface>                                 <interface>
                                                                    …                                           …

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

        messaging infrastructure                                <wsdl>                                      <wsdl>           Network


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

                                                                </wsdl>                                     </wsdl>

 • Messages are the abstraction
   that the service logic binds to,
   not other services
      • Loose coupling!
                   Today’s SOAP API

 public class GameServiceStub
   public void StartGame()
   public GridPos Move(GridPos gp)

     // Other remote methods omitted for brevity
                   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

     // Other messaging events omitted for brevity
                              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!).
                             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
 • Need to understand how the WS-* specs can help
      • And how then cannot help.
                                  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

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

 • In theory, reliable messaging is transparent to the
 • 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
                   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
        Big $$$
      messaging investment
 • Should all processes should be idempotent?
 • Dependability characteristics of the Web Service
           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!
                     Enterprise Issues: Scalability

 • Stateless services scale easily.                    Data Tier

 • Add more hardware, deploy
                                                      Server Farm
 • Leave state management to
   underlying enterprise-grade
      • DB guys know how to manage
        state in a dependable manner
                   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!
                             State Sucks

                                                      Server Farm

                                             Unknown Conversation

 $$$               Multi-Protocol Session-Affinity Aware Router
                   State Still Sucks, but it’s the DBA’s Problem
                                                               Data Tier

                                                         Server Farm

                                El-Cheapo Round-Robin Router
                    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

 • 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

To top