Your SlideShare is downloading. ×
Contemporary Architectural and Development Practices in Web ...
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Contemporary Architectural and Development Practices in Web ...

536
views

Published on


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
536
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Architecting Secure, Reliable, and Transacted Service Oriented Architecture using Web Services Dr. Jim Webber http://jim.webber.name [email_address]
  • 2. 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
  • 3. 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
  • 4. 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.
  • 5. 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 bright people still think of Web Services in this way
  • 6. 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.
  • 7. 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.
  • 8. 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.
  • 9. Canonical Web Services-based Application Example: ServiceA sends ServiceB a MessageX . ServiceB responds with a MessageY or a MessageZ depending on the content of the MessageX it received.
  • 10. Architectural Tenets
    • Boundaries are explicit
      • The boundaries of a service are well-defined when they are incorporated into a distributed application. Other services do not see the internal workings, implementation details, or resource representations of a service.
    • Services are autonomous
      • Service implementations are developed and evolve independently from one another.
    • Services share schema and contract, not classes
      • In service-oriented architectures, no single set of abstractions (classes) spans an entire application. Services share schemas (contracts) that define the structure of the information that they exchange, not information about their underlying type systems.
    • Policies determine service compatibility
      • Services interact with one another only after it has been determined – based on policy assertions – that they can meaningfully exchange information.
    • See: D. Box, Service-Oriented Architecture and Programming (SOAP)
    • http://msdn.microsoft.com/msdntv/episode.aspx?xml=episodes/en/20030827SOAPDB/manifest.xml
    • http://msdn.microsoft.com/msdntv/episode.aspx?xml=episodes/en/20030902SOAPDB/manifest.xml
  • 11. 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
  • 12. 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.
  • 13. SOAP + WS-Addressing
  • 14. 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.
  • 15. 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.
    Protocol Contract
  • 16. 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:
      • Facilitates interoperability with other services;
        • Advertises message exchanges, and possibly QoS support/requirements
      • 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
  • 17. 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.
  • 18. 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
  • 19. 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...
  • 20. 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!
  • 21. Today’s SOAP API
    • public class GameServiceStub
    • {
    • public void StartGame() {...}
    • public GridPos Move(GridPos gp)
    • {...}
    • // Other remote methods omitted for brevity
    • }
  • 22. 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
    • }
  • 23. 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!).
  • 24. Implementation: Some Key WS-* Specs
    • Some WS-* specs are designed to be driven by service implementations directly:
      • WS-Eventing
        • multicast
      • WS-Enumeration
        • Streaming/data cursor
      • WS-Transfer
        • CRUD semantics
    • WS-BPEL is an alternative means of implementing services
      • Workflow expressed in terms of Web Services and messages
    • If these make Web Service development easier, use them
      • If not, then ignore them
  • 25. 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.
  • 26. 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
  • 27. 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
  • 28. 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!
    Complex Big $$$ investment Somewhat complex Lower $$$ Easy (if nothing goes wrong) Cheap!
  • 29. 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
  • 30. 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!
  • 31. State Sucks Server Farm Unknown Conversation Multi-Protocol Session-Affinity Aware Router $$$
  • 32. State Still Sucks, but it’s the DBA’s Problem Server Farm Data Tier El-Cheapo Round-Robin Router
  • 33. 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
  • 34. 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
  • 35. Got Questions?

×