Soa Primer


Published on

Published in: Technology
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Soa Primer

  1. 1. Service Oriented Architecture [email_address] VA-12/05
  2. 2. Agenda <ul><li>What is SOA </li></ul><ul><li>Web Services Framework </li></ul><ul><ul><li>WSDL </li></ul></ul><ul><ul><li>SOAP </li></ul></ul><ul><li>Message Exchange Patterns </li></ul><ul><li>Coordination </li></ul><ul><li>Orchestration </li></ul><ul><li>Choreography </li></ul><ul><li>Addressing </li></ul><ul><li>Reliable Messaging </li></ul><ul><li>Policy </li></ul><ul><li>Metadata Exchange </li></ul><ul><li>Security </li></ul><ul><li>Notification & Eventing </li></ul><ul><li>WS-I Profiles </li></ul><ul><li>Service Design Guidelines </li></ul><ul><li>SOA platforms </li></ul>VA-12/05 Service Oriented Architecture
  3. 3. What is SOA VA-12/05
  4. 4. What SOA is not <ul><li>SOA is not web services </li></ul><ul><li>SOA can not be achieved by investing in a WS platform </li></ul>VA-12/05 Service Oriented Architecture
  5. 5. SOA – An ideal scenario <ul><li>It is an ideal vision of the system with </li></ul><ul><ul><li>Cleanly partitioned resources </li></ul></ul><ul><ul><li>Consistent representation </li></ul></ul><ul><li>Business and automation logic conforms to the vision of system </li></ul><ul><li>Support by diverse vendors and platforms </li></ul>VA-12/05 Service Oriented Architecture
  6. 6. SOA – The reality <ul><li>Organizations need to undergo an transformation </li></ul><ul><ul><li>Changes may be required in business logic and automation logic </li></ul></ul><ul><li>Real SOA requires </li></ul><ul><ul><li>Real Change </li></ul></ul><ul><ul><li>Real Foresight </li></ul></ul><ul><ul><li>Real commitment </li></ul></ul><ul><ul><li>Guidance </li></ul></ul><ul><ul><ul><li>Technology can only provide this one </li></ul></ul></ul>VA-12/05 Service Oriented Architecture
  7. 7. SOA Confusion <ul><li>Service Oriented Architecture is a Software Architect’s Vision of the system </li></ul><ul><li>Developer would insist that he is building an Object Oriented System </li></ul><ul><li>Business Analyst may be looking at Business Oriented Architecture </li></ul>VA-12/05 Service Oriented Architecture
  8. 8. Process <ul><li>Covers process for building SOA using Web Services </li></ul>VA-12/05 Service Oriented Architecture
  9. 9. SOA for dummies <ul><li>A business community consists of multiple businesses each of which performs specific services </li></ul><ul><ul><li>We do not want a single outlet that provides all the services </li></ul></ul><ul><li>Distributing business an automation logic into separate units is not new </li></ul><ul><ul><li>Then what makes services orientation so different </li></ul></ul>VA-12/05 Service Oriented Architecture
  10. 10. SOA for dummies <ul><li>Even in a business community, we want businesses to interact with each other </li></ul><ul><ul><li>but do not want them to become overly dependent on each other </li></ul></ul><ul><ul><li>For example if a shop can automatically charge your visa account for purchases </li></ul></ul><ul><ul><ul><li>We do not want such a tight integration that it becomes impossible to shop without visa </li></ul></ul></ul><ul><ul><ul><li>We still want people to be able to pay using cash </li></ul></ul></ul>VA-12/05 Service Oriented Architecture
  11. 11. Composition of services <ul><li>Services can be composed of other services </li></ul><ul><li>Services can be composed by using other services in a business logic </li></ul>VA-12/05 Service Oriented Architecture
  12. 12. Composition of services VA-12/05 Service Oriented Architecture Select Music for Download Create total bill Prompt user for credit card details Credit Card Approved Process credit card approval Allow Download Validate credit car details Successful Process transaction Valid Card Transaction Successful Transaction Failed Yes Yes No No
  13. 13. How Services Relate <ul><li>Services must be aware of each other’s existence for them to work together </li></ul><ul><li>Services share “Service Descriptions” with each other </li></ul><ul><ul><li>Service Description at least establishes the name of the service, data expected and data returned </li></ul></ul>VA-12/05 Service Oriented Architecture
  14. 14. How services relate <ul><li>For services to interact and achieve something meaningful </li></ul><ul><ul><li>Services must exchange information </li></ul></ul><ul><li>A communication framework is needed that can </li></ul><ul><ul><li>Enable exchange of information </li></ul></ul><ul><ul><li>Keep the loosely coupled relationship </li></ul></ul>VA-12/05 Service Oriented Architecture
  15. 15. Service communication <ul><li>Services communicate by sending messages across to each other </li></ul><ul><li>Messages exist as independent units of communication </li></ul><ul><ul><li>Messages should be autonomous </li></ul></ul><ul><ul><li>Messages are outfitted with enough intelligence to self-govern their parts of the processing logic </li></ul></ul>VA-12/05 Service Oriented Architecture
  16. 16. SOA approach <ul><li>Service orientation requires </li></ul><ul><ul><li>Services </li></ul></ul><ul><ul><li>Service descriptions </li></ul></ul><ul><ul><li>Communicate via messages </li></ul></ul><ul><ul><li>Along with separation of interface from processing logic </li></ul></ul><ul><li>This looks very similar to other distributed computing architectures </li></ul>VA-12/05 Service Oriented Architecture
  17. 17. SOA approach <ul><li>A service oriented approach is different then conventional approach in following manner </li></ul><ul><ul><li>Loose coupling – Services maintain a relationship that minimizes dependencies and only requires them to be aware of each other </li></ul></ul><ul><ul><li>Service contract – Services adhere to a communications agreement which is defined collectively by service descriptions </li></ul></ul>VA-12/05 Service Oriented Architecture
  18. 18. SOA approach <ul><ul><li>Autonomy – Services retain control over logic that they encapsulate </li></ul></ul><ul><ul><li>Abstraction – Services hide everything from real world that is not described in service contract </li></ul></ul><ul><ul><li>Composability – Services provide mechanisms for coordination and assembly </li></ul></ul><ul><ul><li>Statelessness – Service minimize retaining information specific to an activity </li></ul></ul><ul><ul><li>Discoverability – Services are designed to be outwardly descriptive so that they can be found and assessed via discovery mechanisms </li></ul></ul>VA-12/05 Service Oriented Architecture
  19. 19. Misconceptions about SOA <ul><li>An application that uses Web-Services is SOA </li></ul><ul><li>SOA is just marketing – rebranding of web services and distributed computing </li></ul><ul><li>SOA simplifies distributed computing </li></ul><ul><li>One you SOA, everything becomes interoperable </li></ul>VA-12/05 Service Oriented Architecture
  20. 20. SOA Generations <ul><li>First generation SOA consisted of </li></ul><ul><ul><li>WSDL – For describing the service </li></ul></ul><ul><ul><li>SOAP – messaging formats used by service and its requestor </li></ul></ul><ul><ul><li>UDDI – standardized service registry format (Universal Description, Discovery, and integration) </li></ul></ul><ul><ul><ul><li>Never really took off, still is an optional feature </li></ul></ul></ul><ul><li>Second Generation </li></ul><ul><ul><li>Also known as WS-* specifications </li></ul></ul><ul><ul><li>Extensions address specific areas of functionality </li></ul></ul>VA-12/05 Service Oriented Architecture
  21. 21. Evolution of SOA <ul><li>Standards </li></ul><ul><ul><li>Accepted industry standard </li></ul></ul><ul><ul><li>First generation web services specifications and a number of XML specifications </li></ul></ul><ul><li>Specifications </li></ul><ul><ul><li>A proposed or accepted standard </li></ul></ul><ul><ul><ul><li>Standards as defined above and all WS-* extensions </li></ul></ul></ul><ul><li>Extensions </li></ul><ul><ul><li>A WS-* specification or a feature provided by WS-* specification </li></ul></ul>VA-12/05 Service Oriented Architecture
  22. 22. Standard bodies <ul><li>W3C </li></ul><ul><li>OASIS – Organization for the advancement of structured information standards </li></ul><ul><li>WS-I – Web Services Interoperability Organization </li></ul><ul><li>Major vendors </li></ul>VA-12/05 Service Oriented Architecture
  23. 23. Common pitfalls <ul><li>Building service oriented architectures like traditional distributed architectures </li></ul><ul><ul><li>Proliferation of RPC style service descriptions </li></ul></ul><ul><ul><li>Improper partitioning of functional boundaries in the system </li></ul></ul><ul><ul><li>Creation of non-composable services </li></ul></ul><ul><ul><li>Non-standardized services </li></ul></ul><ul><li>Under-estimating SOA performance requirements </li></ul><ul><li>Web Services security </li></ul>VA-12/05 Service Oriented Architecture
  24. 24. SOA vs. Client Server Architecture VA-12/05 Service Oriented Architecture SOA Client Server Architecture Presentation layer is detached from services themselves Application logic resides in client software. Client needs to control user experience, back-end resources Highly distributed processing, services themselves may be distributed over many servers Client is responsible for most of the processing, 80/20 rule was used as a rule of thumb Complex security model but provides flexibility For simple scenario, implements a very easy security model Also has high maintenance costs and requires powerful administration tools Very high maintenance costs of maintaining client server applications
  25. 25. SOA vs. Distributed Internet Architecture VA-12/05 Service Oriented Architecture SOA Distributed Internet Architecture Standardized interfaces, Self sufficient messages All the logic exists in server side. Some very insignificant logic may exist in client. Proprietary interfaces in place Message based communication, promotes creation of autonomous services Can support stateful and stateless components, data exchange is primarily synchronous Messages contain header blocks where security logic can be stored Exclusive connection maintains context. In non-exclusive connections, user credentials have to be sent across each request Higher administration costs Simple to maintain, HTTP server needs to be built for scalability
  26. 26. Web Services Framework VA-12/05
  27. 27. Web Services Framework <ul><li>Framework is characterized by </li></ul><ul><ul><li>An abstract, vendor-neutral existence defined by standards organizations and implemented by technology platforms </li></ul></ul><ul><ul><li>Core building blocks include Web Services, Service Descriptions, messages </li></ul></ul><ul><ul><li>Communication agreement centered around service descriptions based on WSDL </li></ul></ul><ul><ul><li>Messaging framework comprised of SOAP technology and concepts </li></ul></ul><ul><ul><li>Service description registration and discovery architecture </li></ul></ul><ul><ul><li>Architecture that supports messaging patterns and compositions </li></ul></ul><ul><ul><li>Second generation of web services extensions (WS-*) </li></ul></ul>VA-12/05 Service Oriented Architecture
  28. 28. Service Roles <ul><li>Service Provider </li></ul><ul><ul><li>Invocation of web services via an external source </li></ul></ul><ul><ul><li>Provides a published service description offering information about its features and behavior </li></ul></ul><ul><li>Service Requestor </li></ul><ul><ul><li>Web services invokes a service provider by sending a message </li></ul></ul><ul><ul><li>Web services searches for and assesses the most suitable service provider by studying available service descriptions </li></ul></ul>VA-12/05 Service Oriented Architecture
  29. 29. Service Roles <ul><li>Intermediaries </li></ul><ul><ul><li>Passive intermediaries – responsible for routing messages to a subsequent location </li></ul></ul><ul><ul><ul><li>Does not modify the message </li></ul></ul></ul><ul><ul><li>Active intermediaries – Route the message but would process the message and may need to alter it </li></ul></ul><ul><li>Initial Senders </li></ul><ul><ul><li>These are service requestor entities that initiate the transmission of a message </li></ul></ul><ul><li>Ultimate receiver </li></ul><ul><ul><li>These are service providers that finally receive the message </li></ul></ul>VA-12/05 Service Oriented Architecture
  30. 30. Service Roles <ul><li>Service compositions </li></ul><ul><ul><li>These are compositions of multiple service to provide a service </li></ul></ul><ul><ul><ul><li>Each service that participates in service composition becomes service composition member </li></ul></ul></ul><ul><ul><li>Service compositions are typically governed by extensions defined in WS-* composition extensions e.g. WS-BPEL </li></ul></ul>VA-12/05 Service Oriented Architecture
  31. 31. Service Models <ul><li>Business Service Model </li></ul><ul><ul><li>Most fundamental building block </li></ul></ul><ul><ul><li>Represents corporate entity or information set </li></ul></ul><ul><ul><li>Represents business process logic </li></ul></ul><ul><ul><li>Act as service composition members </li></ul></ul><ul><ul><li>Could correspond to Business service layer </li></ul></ul>VA-12/05 Service Oriented Architecture
  32. 32. Service Models <ul><li>Utility Service Model </li></ul><ul><ul><li>Any web services that is designed for potential reuse can be classified a utility service </li></ul></ul><ul><ul><li>These are used as </li></ul></ul><ul><ul><ul><li>Solution agnostic intermediary </li></ul></ul></ul><ul><ul><ul><li>Service that promotes intrinsic interoperability </li></ul></ul></ul><ul><ul><ul><li>Service with highest degree of autonomy </li></ul></ul></ul>VA-12/05 Service Oriented Architecture
  33. 33. Service Models <ul><li>Controller Service Model </li></ul><ul><ul><li>These services perform the task of assembly and coordination of service compositions </li></ul></ul><ul><ul><li>These are used to </li></ul></ul><ul><ul><ul><li>Support autonomy in services </li></ul></ul></ul><ul><ul><ul><li>Leverage reuse opportunity </li></ul></ul></ul><ul><ul><ul><li>Support and implement principle of composability </li></ul></ul></ul>VA-12/05 Service Oriented Architecture
  34. 34. Service Descriptions <ul><li>Services descriptions are provided using service description documents </li></ul><ul><li>It is also known as WSDL definition </li></ul>VA-12/05 Service Oriented Architecture
  35. 35. Service endpoints <ul><li>A WSDL describes the point of contact for service provider </li></ul><ul><ul><li>Also known as service endpoint </li></ul></ul><ul><ul><li>Establishes </li></ul></ul><ul><ul><ul><li>Structure of request messages </li></ul></ul></ul><ul><ul><ul><li>Physical location of service </li></ul></ul></ul>VA-12/05 Service Oriented Architecture
  36. 36. Abstract Descriptions <ul><li>portType </li></ul><ul><ul><li>High level view of service interface </li></ul></ul><ul><ul><li>WSDL 2.0 is renaming this to interface </li></ul></ul><ul><li>Operation </li></ul><ul><ul><li>Specific action performed by service </li></ul></ul><ul><ul><li>Comparable to a public method with input and output parameters </li></ul></ul><ul><li>message </li></ul><ul><ul><li>A set of input and output messages are used with every operation </li></ul></ul>VA-12/05 Service Oriented Architecture
  37. 37. Concrete Description <ul><li>Concrete description in WSDL file is used to connect abstract interface to physical transport protocol </li></ul><ul><li>Binding </li></ul><ul><ul><li>Represents one possible transport technology that service can use to communicate – SOAP </li></ul></ul><ul><li>Port </li></ul><ul><ul><li>Physical address at which a service can be accessed with a specific protocol </li></ul></ul><ul><ul><li>Being renamed to endpoint in WSDL 2.0 </li></ul></ul><ul><li>Service </li></ul><ul><ul><li>Group of related endpoints </li></ul></ul>VA-12/05 Service Oriented Architecture
  38. 38. WSDL Basics <ul><li>The definitions element </li></ul><ul><ul><li>Root or parent element of every WSDL document </li></ul></ul><ul><ul><li>Houses all parts of service definitions </li></ul></ul><ul><ul><li>Also establishes namespaces being used </li></ul></ul><ul><li>The types element </li></ul><ul><ul><li>This is where XSD schema is placed </li></ul></ul><ul><ul><li>Contains embedded and imported types </li></ul></ul><ul><ul><li>XSD complexType element is used to establish embedded types </li></ul></ul>VA-12/05 Service Oriented Architecture
  39. 39. WSDL Basics <ul><li>The message and part elements </li></ul><ul><ul><li>For every message that a service is designed to receive or transmit, a message construct must be addded </li></ul></ul><ul><ul><li>The message contains one or more part child elements that are assigned a type </li></ul></ul><ul><li>If all messages in a WSDL definition are assigned XSD(simple) types, a types element is not needed </li></ul>VA-12/05 Service Oriented Architecture
  40. 40. WSDL Basics <ul><li>The portType, interface and operation element </li></ul><ul><ul><li>portType defines a collection of operations </li></ul></ul><ul><ul><li>Individual operations are defined using operation element </li></ul></ul><ul><ul><li>portType element is being renamed to interface in WSDL 2.0 </li></ul></ul><ul><li>The input and output elements </li></ul><ul><ul><li>Input and output elements are part of operation elements </li></ul></ul><ul><ul><li>These are analogous to parameter passing in function calls </li></ul></ul>VA-12/05 Service Oriented Architecture
  41. 41. WSDL Basics <ul><li>The binding element </li></ul><ul><ul><li>This is the first element for the concrete portion of service definition </li></ul></ul><ul><ul><li>This element is used to bind the operations and portType defined with actual SOAP bindings </li></ul></ul><ul><li>The input and output element </li></ul><ul><ul><li>These elements are analogous to elements in abstract portion but establish protocol details to be used </li></ul></ul>VA-12/05 Service Oriented Architecture
  42. 42. WSDL Basics <ul><li>The service, port and endpoint elements </li></ul><ul><ul><li>The service element provides a physical address at which the service can be accessed </li></ul></ul><ul><ul><li>It hosts the port elements that contains location information </li></ul></ul><ul><ul><li>Port element is replaced with endpoint element in WSDL 2.0 </li></ul></ul><ul><li>The import element </li></ul><ul><ul><li>WSDL definitions support a similar form of modularity as XSD schemas </li></ul></ul><ul><ul><ul><li>The import element can be used to import parts of WSDL definitions as well as XSD schemas </li></ul></ul></ul>VA-12/05 Service Oriented Architecture
  43. 43. SOAP Basics <ul><li>A SOAP message is composed of following sections </li></ul><ul><ul><li>Header </li></ul></ul><ul><ul><li>Body </li></ul></ul><ul><ul><li>Fault </li></ul></ul>VA-12/05 Service Oriented Architecture
  44. 44. SOAP Basics <ul><li>The Envelope element </li></ul><ul><ul><li>Envelope element represents the root of SOAP message structures </li></ul></ul><ul><ul><li>It contains a mandatory body element and an optional header construct </li></ul></ul><ul><li>The Header element </li></ul><ul><ul><li>The header element is a key enabler of WS-* specification. </li></ul></ul><ul><ul><li>Most of these specifications have added new header blocks </li></ul></ul><ul><ul><ul><li>Header also has a mustUnderstand attribute that indicates that the receiver needs to process header before understanding body </li></ul></ul></ul>VA-12/05 Service Oriented Architecture
  45. 45. SOAP Basics <ul><li>The Body element </li></ul><ul><ul><li>The structure and naming used to define this part of SOAP message relates to the style and use attributes in WSDL binding element </li></ul></ul><ul><ul><li>Intermediaries, in general would use header information without touching body. In exceptional cases, if allowed they may read the body contents </li></ul></ul><ul><li>The Fault Element </li></ul><ul><ul><li>Fault construct provides a readymade error response that is added inside the body construct </li></ul></ul><ul><ul><ul><li>Contains FaultCode, FaultString and detail elements </li></ul></ul></ul>VA-12/05 Service Oriented Architecture
  46. 46. WSDL Example 1/3 VA-12/05 Service Oriented Architecture
  47. 47. WSDL Example 2/3 VA-12/05 Service Oriented Architecture
  48. 48. WSDL Example 3/3 VA-12/05 Service Oriented Architecture
  49. 49. SOAP Example VA-12/05 Service Oriented Architecture
  50. 50. Metadata and Service contracts <ul><li>Apart from WSDL definition two additional document are used </li></ul><ul><ul><li>XSD Schema </li></ul></ul><ul><ul><li>Policy </li></ul></ul><ul><li>Together these three documents form the service metadata </li></ul><ul><li>Service contract also include additional documents not expressed by service descriptions like SLA </li></ul>VA-12/05 Service Oriented Architecture
  51. 51. Semantic Descriptions <ul><li>Most challenging part of providing description of web service is communicating its semantic qualities </li></ul><ul><li>For example </li></ul><ul><ul><li>How would a service behave in certain conditions </li></ul></ul><ul><ul><li>How would a service respond to specific condition </li></ul></ul><ul><ul><li>What tasks the service is most suited for </li></ul></ul><ul><li>Most of the time these activities are done by humans </li></ul><ul><li>Some preliminary work is being done by W3C towards this </li></ul>VA-12/05 Service Oriented Architecture
  52. 52. Service description advertisement and discovery <ul><li>Central directories and repositories are required to advertise services </li></ul><ul><li>These repositories would allow </li></ul><ul><ul><li>Location of latest version of known service descriptor </li></ul></ul><ul><ul><li>Discover new web services based on a known criteria </li></ul></ul><ul><li>Initial specification incorporated UDDI to provide this functionality </li></ul>VA-12/05 Service Oriented Architecture
  53. 53. Private and public registries <ul><li>Public registries accept registrations from any organizations </li></ul><ul><li>Private registries can be implemented within enterprises to provide a central repository of service that the organization develops, leases or purchases </li></ul><ul><li>Parts of UDDI record </li></ul><ul><ul><li>Business entities and business services – profile information </li></ul></ul><ul><ul><li>Binding templates or tModels – pointers to actual service descriptions </li></ul></ul>VA-12/05 Service Oriented Architecture
  54. 54. UDDI record example VA-12/05 Service Oriented Architecture
  55. 55. Message Exchange Patterns VA-12/05
  56. 56. Message Exchange Patterns <ul><li>Almost all the tasks in web services context require transmission of multiple messages </li></ul><ul><li>Message Exchange Patterns (MEPs) have been developed to provide a set of templates that provide a group of mapped out sequences for exchange of messages </li></ul>VA-12/05 Service Oriented Architecture
  57. 57. Primitive MEPs <ul><li>Request Response – Synchronous communication </li></ul><ul><ul><li>Establishes a simple exchange in which a message is first transmitted from source to a destination </li></ul></ul><ul><ul><li>Upon receiving the message, the destination responds with a message back to source </li></ul></ul><ul><li>Fire and Forget – Based on unidirectional transmission of messages from source to one or more destinations without expecting a response </li></ul><ul><ul><li>Single destination </li></ul></ul><ul><ul><li>Multicast </li></ul></ul><ul><ul><li>Broadcast </li></ul></ul>VA-12/05 Service Oriented Architecture
  58. 58. Complex MEPs <ul><li>Publish and Subscribe model – services involved with message exchange become publishers and subscribers </li></ul><ul><ul><li>WS-* specifications that incorporate this model are </li></ul></ul><ul><ul><ul><li>WS-BaseNotification </li></ul></ul></ul><ul><ul><ul><li>WS-BrokeredNotification </li></ul></ul></ul><ul><ul><ul><li>WS-Topics </li></ul></ul></ul><ul><ul><ul><li>WS-Eventing </li></ul></ul></ul>VA-12/05 Service Oriented Architecture
  59. 59. MEPs and WSDL <ul><li>WSDL 1.1 provides four message exchange patterns </li></ul><ul><ul><li>Request Response operation – Upon receiving the message, the service must respond with a standard or fault message </li></ul></ul><ul><ul><li>Solicit response operation – Upon submitting a message to a service requestor, service expects a standard response or fault message </li></ul></ul><ul><ul><li>One way operation – The service expects a single message and is not obligated to respond </li></ul></ul><ul><ul><li>Notification Operation – The service sends a message a expects no response </li></ul></ul>VA-12/05 Service Oriented Architecture
  60. 60. MEPs and WSDL <ul><li>WSDL 2.0 extends MEP to support eight patterns </li></ul><ul><ul><li>In-out pattern </li></ul></ul><ul><ul><li>Out-in pattern </li></ul></ul><ul><ul><li>In-only pattern </li></ul></ul><ul><ul><li>Out-only pattern </li></ul></ul><ul><ul><li>Robust in-only and out-only pattern </li></ul></ul><ul><ul><ul><li>Same as in out with fault message because of transmission or processing error </li></ul></ul></ul><ul><ul><li>In-optional-out and out-optional-in pattern – delivery of one of the messages becomes optional </li></ul></ul>VA-12/05 Service Oriented Architecture
  61. 61. Service Activity <ul><li>Service Oriented Architectures define </li></ul><ul><ul><li>Tasks are comprised of processing logic that executes to fulfill a number of business requirements </li></ul></ul><ul><ul><li>Interaction of a group of services working together to complete a task is referred to as Service Activity </li></ul></ul>VA-12/05 Service Oriented Architecture
  62. 62. Primitive and complex service activities <ul><li>Simple or primitive service activity is typified by synchronous communication and often consists of two services exchanging information using standard request-response MEP </li></ul><ul><li>Complex activities can involve many services that collaborate to complete multiple process steps over a long period of time </li></ul>VA-12/05 Service Oriented Architecture
  63. 63. Coordination VA-12/05
  64. 64. Coordination <ul><li>Coordination establishes a framework to provide a means for context information in complex activities </li></ul><ul><ul><li>to be managed </li></ul></ul><ul><ul><li>preserved </li></ul></ul><ul><ul><li>and/or updated </li></ul></ul><ul><ul><li>And distributed to activity participants </li></ul></ul><ul><li>Context is defined as </li></ul><ul><ul><li>Something that is happening or executing has meaning during its lifetime and description of its meaning </li></ul></ul>VA-12/05 Service Oriented Architecture
  65. 65. Coordinator composition <ul><li>WS-Coordination establishes a generic service based on coordinator service model </li></ul><ul><li>This service controls composition of three other services that each play a specific part in the management of context data </li></ul><ul><ul><li>Activation service – responsible for creation of new context and associating this to an activity </li></ul></ul><ul><ul><li>Registration service – allows use of context information received from activation service </li></ul></ul><ul><ul><li>Protocol-specific service – protocols supported </li></ul></ul><ul><ul><li>Coordinator – controller service of composition </li></ul></ul>VA-12/05 Service Oriented Architecture
  66. 66. Activation and registration service <ul><li>Coordination service composition is instantiated when an application service contacts the activation service via CreateCoordinationContext request message </li></ul><ul><ul><li>The context data is created and passed back with ReturnContext message </li></ul></ul><ul><ul><li>Application service can invite other services to participate in coordination using context data </li></ul></ul><ul><li>Any Web Service in possession of this context information can issue a registration request to registration service </li></ul><ul><ul><li>Registration allows service to enlist in a coordination based on a protocol </li></ul></ul>VA-12/05 Service Oriented Architecture
  67. 67. Completion process <ul><li>The application service can request a coordination to be completed by issuing a completion request message to coordination service </li></ul><ul><li>The coordinator then issues its own completion message to all coordination participants </li></ul><ul><ul><li>Each participant responds with a completion acknowledgement message </li></ul></ul>VA-12/05 Service Oriented Architecture
  68. 68. Coordination <ul><li>WS-Coordination provides a coordinator based context management framework </li></ul><ul><ul><li>Introduces a layer of composition control to SOA </li></ul></ul><ul><ul><li>Standardizes the management and interchange of context information within a variety of key business protocols </li></ul></ul><ul><li>Coordination also alleviates the need for services to retain state </li></ul>VA-12/05 Service Oriented Architecture
  69. 69. Atomic Transactions <ul><li>Atomic transactions implement the familiar commit and rollback features to enable cross-service transaction support </li></ul><ul><li>Acronym ACID is used to represent traditional transaction </li></ul><ul><ul><li>Atomic – Either all changes or no changes suceed </li></ul></ul><ul><ul><li>Consistent – Valid data models </li></ul></ul><ul><ul><li>Isolated – Multiple transaction don’t interfere </li></ul></ul><ul><ul><li>Durable – Changes made as part of transaction survive subsequent failures </li></ul></ul>VA-12/05 Service Oriented Architecture
  70. 70. Atomic transaction protocols <ul><li>WS-AtomicTransaction is a coordination type </li></ul><ul><ul><li>Extension created for use with WS-Coordination context management framework </li></ul></ul><ul><ul><ul><li>To participate in an atomic transaction, a service first receives a coordination context from activation service </li></ul></ul></ul><ul><ul><ul><ul><li>It subsequently registers for available atomic transaction protocols </li></ul></ul></ul></ul>VA-12/05 Service Oriented Architecture
  71. 71. Atomic transaction protocols <ul><li>Following transaction protocols are provided </li></ul><ul><ul><li>Completion protocol – used to initiate commit or abort states of transaction </li></ul></ul><ul><ul><li>Durable 2PC protocol – Services representing permanent data repositories should register for this </li></ul></ul><ul><ul><li>Volatile 2PC protocol – Service managing non persistent data should register for this </li></ul></ul>VA-12/05 Service Oriented Architecture
  72. 72. Atomic Transaction process <ul><li>Atomic transaction coordinator is tasked with the responsibility of deciding the outcome of a transaction </li></ul><ul><ul><li>It bases this decision on feedback it receives from all the transaction participants </li></ul></ul><ul><ul><li>Two phase process is used </li></ul></ul><ul><ul><ul><li>During prepare phase, all participants are notified by the coordinator to prepare and issue a vote </li></ul></ul></ul><ul><ul><ul><ul><li>The vote consists of commit or abort request </li></ul></ul></ul></ul><ul><ul><ul><li>In second phase the coordinator enters a commit phase </li></ul></ul></ul><ul><ul><ul><ul><li>If all votes are commit then a commit is issued </li></ul></ul></ul></ul><ul><ul><ul><ul><li>If any of the vote requests an abort then the transaction is aborted and changes are rolled back </li></ul></ul></ul></ul>VA-12/05 Service Oriented Architecture
  73. 73. Business activities <ul><li>Business activities govern long running complex service activities </li></ul><ul><ul><li>The activity may take hours, days or weeks and during this period the activity may perform numerous tasks involving many participants </li></ul></ul><ul><li>Business activities differ from protocol based atomic transactions in the way they deal with exceptions and nature of constraints introduced by protocol rules </li></ul>VA-12/05 Service Oriented Architecture
  74. 74. Business activities <ul><li>Business activity protocols do not offer rollback capabilities </li></ul><ul><ul><li>Business activities provide an optional compensation process that can be invoked when exception conditions occur </li></ul></ul><ul><li>WS-BusinessActivity is a coordination type designed to leverage WS-Coordination context management framework </li></ul><ul><ul><li>BusinessAgreementWithParticipantCompletion </li></ul></ul><ul><ul><ul><li>Allows participant to decide completion </li></ul></ul></ul><ul><ul><li>BusinessAgreementWithCoordinatorCompletion </li></ul></ul><ul><ul><ul><li>Allows coordinator to decide completion </li></ul></ul></ul>VA-12/05 Service Oriented Architecture
  75. 75. Business activity states <ul><li>Business activity coordinator and participants transition through series of states </li></ul><ul><li>Points of transitions identified by passing of special notification messages </li></ul>VA-12/05 Service Oriented Architecture
  76. 76. Business activity states <ul><li>Completion </li></ul><ul><ul><li>A participant could indicate that it has completed the processing by issuing Completed notification </li></ul></ul><ul><ul><ul><li>Participant moves from active to completed state </li></ul></ul></ul><ul><ul><ul><li>Coordinator may respond with a close message to let the participant know that business activity is successfully completed </li></ul></ul></ul><ul><li>Compensation </li></ul><ul><ul><li>If things do not go as planned, participants could enter compensation state where they attempt to perform some kind of exception handling </li></ul></ul>VA-12/05 Service Oriented Architecture
  77. 77. Business activity states <ul><li>Cancelled </li></ul><ul><ul><li>A cancelled stated could be entered which results in termination of any further processing except distribution of cancellation notifications </li></ul></ul><ul><li>Exit </li></ul><ul><ul><li>Participants can enter exit state by issuing an exit notification message </li></ul></ul>VA-12/05 Service Oriented Architecture
  78. 78. Business activity states <ul><li>One of the main differences between business activities and atomic transactions is the fact that participating services are not required to remain participants for the duration of the activity </li></ul><ul><li>Participants may leave an activity after their contribution is performed </li></ul>VA-12/05 Service Oriented Architecture
  79. 79. WS-Coordination example VA-12/05 Service Oriented Architecture
  80. 80. WS-Coordination example VA-12/05 Service Oriented Architecture
  81. 81. Orchestration VA-12/05
  82. 82. Orchestration <ul><li>Orchestration facilitates connecting of different processes without having to redevelop the solutions that originally automated the processes individually </li></ul><ul><li>Orchestration introduces workflow logic which is abstracted and more easily maintained </li></ul><ul><li>In SOA orchestrations themselves exist as services </li></ul><ul><li>A key industry specification that standardizes orchestration is web services business process execution language or WS-BPEL </li></ul>VA-12/05 Service Oriented Architecture
  83. 83. Basic and structured activities <ul><li>WS-BPEL breaks down workflow logic into a series of predefined primitive activities </li></ul><ul><ul><li>Basic Activities </li></ul></ul><ul><ul><ul><li>Invoke </li></ul></ul></ul><ul><ul><ul><li>Receive </li></ul></ul></ul><ul><ul><ul><li>Reply </li></ul></ul></ul><ul><ul><ul><li>Throw </li></ul></ul></ul><ul><ul><ul><li>Wait </li></ul></ul></ul><ul><ul><li>Structured activities are created by assembling other activities using logics </li></ul></ul><ul><ul><ul><li>Sequence </li></ul></ul></ul><ul><ul><ul><li>Switch </li></ul></ul></ul><ul><ul><ul><li>While </li></ul></ul></ul><ul><ul><ul><li>Flow </li></ul></ul></ul><ul><ul><ul><li>Pick </li></ul></ul></ul>VA-12/05 Service Oriented Architecture
  84. 84. Sequences, flows and links <ul><li>Sequence aligns a group of related activities in a list that determines sequential execution order </li></ul><ul><li>Flow also contains group of related activities but activities can be executed concurrently </li></ul><ul><ul><li>The flow does not finish till the time all the activities are completed </li></ul></ul><ul><li>Links are used to establish formal dependencies between activities that are part of a flow </li></ul><ul><ul><li>Links are also knows as synchronization dependencies. </li></ul></ul>VA-12/05 Service Oriented Architecture
  85. 85. Orchestration and Coordination <ul><li>WS-BPEL and fully utilize WS-Coordination context management framework by incorporating the WS-BusinessActivity coordination type </li></ul>VA-12/05 Service Oriented Architecture
  86. 86. WS-BPEL Example VA-12/05 Service Oriented Architecture
  87. 87. WS-BPEL Example VA-12/05 Service Oriented Architecture
  88. 88. WS-BPEL Example VA-12/05 Service Oriented Architecture
  89. 89. Top level attributes <ul><li>abstractProcessProfile – This mandatory attribute provides the URI that identifies the profile of an abstract process. </li></ul><ul><li>queryLanguage – This attribute specifies the default XML query language used for selection of nodes in assignment, property definition, and other uses. The default value for this attribute is: &quot;urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0&quot;, which represents the usage of XPath 1.0 within WS-BPEL 2.0. The URI of the corresponding XPath 1.0 specification is: </li></ul><ul><li>expressionLanguage – This attribute specifies the expression language used in the process. The default value for this attribute is: &quot;urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0&quot;, which represents the usage of XPath 1.0 within WS-BPEL 2.0. The URI of the corresponding XPath 1.0 specification is: . </li></ul>VA-12/05 Service Oriented Architecture
  90. 90. Top level attributes <ul><li>suppressJoinFailure – This attribute determines whether the joinFailure fault will be suppressed for all activities in the process. The effect of the attribute at the process level can be overridden by an activity using a different value for the attribute. The default for this attribute is &quot;no&quot; at the process level. When this attribute is not specified for an activity, it inherits its value from its closest enclosing activity or from the process if no enclosing activity specifies this attribute. </li></ul><ul><li>exitOnStandardFault – This attribute specifies if the process must exit if a WS-BPEL standard fault other than bpws:joinFailure is encountered[1]. If the value of this attribute is set to “yes”, then the process MUST exit immediately as if an <exit> activity has been reached, when a WS-BPEL standard fault other than bpws:joinFailure is enountered. If the value of this attribute is set to “no”, then the process can handle a standard fault using a fault handler. The default value for this attribute is “no”. When this attribute is not specified on a <scope> it inherits its value from its enclosing <scope> or <process>. </li></ul><ul><ul><li>If the value of exitOnStandardFault of a <scope> or <process> is set to “yes”, then a fault handler that explicitly targets the WS-BPEL standard faults MUST NOT be used in that scope. A process definition that violates this condition MUST be detected and rejected by static analysis. </li></ul></ul>VA-12/05 Service Oriented Architecture
  91. 91. Top level attributes <ul><li>abstractProcess – This attribute specifies whether the process being defined is abstract (rather than executable). The default for this attribute is &quot;no&quot;. </li></ul><ul><li>The value of the queryLanguage and expressionLanguage attributes on the <process> element are global defaults and can be overridden on specific activities like <assign> using the mechanisms defined later in this specification. In addition the queryLanguage attribute is also available for use in defining BPEL property aliases in WSDL. </li></ul><ul><li><documentation> construct may be added to virtually all WS-BPEL constructs as the formal way to annotate processes definition with human documentation. Examples of <documentation> construct can be found in previous section. </li></ul>VA-12/05 Service Oriented Architecture
  92. 92. Activity <ul><li>Token activity can have one of the following values </li></ul><ul><ul><li><receive> </li></ul></ul><ul><ul><li><reply> </li></ul></ul><ul><ul><li><invoke> </li></ul></ul><ul><ul><li><assign> </li></ul></ul><ul><ul><li><throw> </li></ul></ul><ul><ul><li><exit> </li></ul></ul><ul><ul><li><wait> </li></ul></ul><ul><ul><li><empty> </li></ul></ul><ul><ul><li><sequence> </li></ul></ul><ul><ul><li><if> </li></ul></ul><ul><ul><li><while> </li></ul></ul><ul><ul><li><repeatUntil> </li></ul></ul><ul><ul><li><forEach> </li></ul></ul><ul><ul><li><pick> </li></ul></ul><ul><ul><li><flow> </li></ul></ul><ul><ul><li><scope> </li></ul></ul><ul><ul><li><compensate> </li></ul></ul><ul><ul><li><rethrow> </li></ul></ul><ul><ul><li><validate> </li></ul></ul><ul><ul><li><extensionActivity> </li></ul></ul>VA-12/05 Service Oriented Architecture
  93. 93. Receive <ul><li>Receive allows the process to do a blocking wait </li></ul><ul><ul><li>The portType attribute on the <receive> activity is optional </li></ul></ul><ul><ul><li>If the portType attribute is included for readability, the value of the portType attribute MUST match the portType value implied by the combination of the specified partnerLink and the role implicitly specified by the activity </li></ul></ul>VA-12/05 Service Oriented Architecture
  94. 94. Reply <ul><li>The <reply> construct allows the business process to send a message in reply to a message that was received through a <receive> </li></ul><ul><ul><li>The combination of a <receive> and a <reply> forms a request-response operation on the WSDL portType for the process </li></ul></ul><ul><ul><li>The portType attribute on the <reply> activity is optional </li></ul></ul><ul><ul><li>If the portType attribute is included for readability, the value of the portType attribute MUST match the portType value implied by the combination of the specified partnerLink and the role implicitly specified by the activity </li></ul></ul>VA-12/05 Service Oriented Architecture
  95. 95. Invoke <ul><li>The <invoke> construct allows the business process to invoke a one-way or requestresponse operation on a portType offered by a partner </li></ul><ul><ul><li>The portType attribute on the <invoke> activity is optional. </li></ul></ul><ul><ul><li>If the portType attribute is included for readability, the value of the portType attribute MUST match the portType value implied by the combination of the specified partnerLink and the role implicitly specified by the activity </li></ul></ul>VA-12/05 Service Oriented Architecture
  96. 96. Assign <ul><li>The <assign> construct can be used to update the values of variables with new data </li></ul><ul><ul><li>An <assign> construct can contain any number of elementary assignments, including <copy> assign elements or data update operations defined as extension under other namespaces. </li></ul></ul>VA-12/05 Service Oriented Architecture
  97. 97. Extension activity and sequence <ul><li>New activities can be introduced for use in BPEL by placing them inside of the extensionActivity element. The contents of an extensionActivity element MUST be a single element that MUST make available BPEL's standard-attributes and standard-elements. </li></ul><ul><li>The <sequence> construct allows you to define a collection of activities to be performed sequentially in lexical order. </li></ul>VA-12/05 Service Oriented Architecture
  98. 98. Validate, throw and wait <ul><li>The <validate> construct can be used to validate the values of variables against their associated XML and WSDL data definition. </li></ul><ul><ul><li>The construct has a attribute, which points to the variables being validated. </li></ul></ul><ul><li>The <throw> construct generates a fault from inside the business process. </li></ul><ul><li>The <wait> construct allows you to wait for a given time period or until a certain time has passed. </li></ul><ul><ul><li>Exactly one of the expiration criteria must be specified. </li></ul></ul><ul><li>The <empty> construct allows you to insert a &quot;no-op&quot; instruction into a business process </li></ul>VA-12/05 Service Oriented Architecture
  99. 99. If and While <ul><li>The <if> construct allows you to select exactly one branch of activity from a set of potential choices. </li></ul><ul><li>The <while> construct allows you to indicate that an activity is to be repeated as long as a certain success criteria has been met. </li></ul>VA-12/05 Service Oriented Architecture
  100. 100. RepeatUntil and forEach <ul><li>The <repeatUntil> constructs allows you to indicate the repeated performance of a specified iterative activity. </li></ul><ul><ul><li>The iterative activity will continue to be performed so long as after it executes the given Boolean <repeatUntil> condition holds true. </li></ul></ul><ul><li>The <forEach> construct is an iterator that will repeat its contained scope activity exactly N+1 times where N equals the <finalCounterValue> minus the <startCounterValue>. </li></ul><ul><ul><li>If parallel=&quot;yes&quot; then this is a parallel foreach where the N+1 instances of the enclosed scope activity will occur in parallel. </li></ul></ul><ul><ul><li>In essence an implicit flow is dynamically created with N+1 copies of the foreach's scope activity as children. </li></ul></ul><ul><ul><li>If <completionCondition> is specified within the <forEach> construct, the forEach activity MAY be completed without executing or finishing all the branches specified. </li></ul></ul><ul><ul><li>The details of the early completion condition is specified within the <branches> construct. </li></ul></ul>VA-12/05 Service Oriented Architecture
  101. 101. Pick and Flow <ul><li>The <pick> construct allows you to block and wait for a suitable message to arrive or for a time-out alarm to go off. </li></ul><ul><ul><li>When one of these triggers occurs, the associated activity is performed and the pick completes. </li></ul></ul><ul><ul><ul><li>The portType attribute on the <onMessage> activity is optional. </li></ul></ul></ul><ul><ul><ul><li>If the portType attribute is included for readability, the value of the portType attribute MUST match the portType value implied by the combination of the specified partnerLink and the role implicitly specified by the activity </li></ul></ul></ul><ul><ul><ul><li>The optional messageExchange attribute is used to associate a <reply> activity with a <onMessage> activity </li></ul></ul></ul><ul><li>The <flow> construct allows you to specify one or more activities to be performed concurrently. </li></ul><ul><ul><li>Links can be used within concurrent activities to define arbitrary control structures. </li></ul></ul>VA-12/05 Service Oriented Architecture
  102. 102. Scope and compensate <ul><li>The <scope> construct allows you to define a nested activity with its own associated variables, fault handlers, and compensation handler. </li></ul><ul><li>The <compensate> construct is used to invoke compensation on an inner scope that has already completed normally. </li></ul><ul><ul><li>This construct can be invoked only from within a fault handler or another compensation handler. </li></ul></ul>VA-12/05 Service Oriented Architecture
  103. 103. Standard attributes and elements <ul><li>Standard-attributes are </li></ul><ul><ul><li>name=&quot;ncname&quot;? suppressJoinFailure=&quot;yes|no&quot;? </li></ul></ul><ul><ul><ul><li>default values are </li></ul></ul></ul><ul><ul><ul><ul><li>name: No default value (that is, the default is unnamed) </li></ul></ul></ul></ul><ul><ul><ul><ul><li>suppressJoinFailure: When this attribute is not specified for an activity, it inherits its value from its closest enclosing activity or from the process if no enclosing activity specifies this attribute. </li></ul></ul></ul></ul><ul><li>Standard elements </li></ul>VA-12/05 Service Oriented Architecture
  104. 104. Choreography VA-12/05
  105. 105. Choreography <ul><li>When multiple services from different organizations need to work together to achieve a common goal interoperation requirements extend into realm of collaboration </li></ul><ul><li>WS-CDL (Choreography Description Language) is one of the several specifications that attempts to organize information exchange between multiple organizations with an emphasis on public collaboration </li></ul>VA-12/05 Service Oriented Architecture
  106. 106. Choreography <ul><li>Within a given choreography, a web services assumes one of the number of predefined roles </li></ul><ul><ul><li>This establishes what the service does and what the service can do within the context of a particular business task </li></ul></ul><ul><li>Roles can be bound to WSDL definitions and are grouped accordingly </li></ul>VA-12/05 Service Oriented Architecture
  107. 107. Relationships and Channels <ul><li>Every action within a choreography can be broken down into a series of message exchanges between two services </li></ul><ul><li>Each potential exchange between two roles in a choreography is defined as a relationship </li></ul><ul><li>Channels are used to define characteristics of messages exchange between two roles </li></ul><ul><ul><li>Channel information can be passed around in a message </li></ul></ul><ul><ul><li>This fosters dynamic discovery and increases the number of potential participants within large-scale collaborative tasks </li></ul></ul>VA-12/05 Service Oriented Architecture
  108. 108. Interactions and work units <ul><li>Logic behind the message exchange in encapsulated within an interaction </li></ul><ul><li>Work units are related to interactions and impose rules and constraints that must be adhered to </li></ul>VA-12/05 Service Oriented Architecture
  109. 109. Orchestrations and Choreographies <ul><li>An orchestration expresses organization specific business workflow </li></ul><ul><ul><li>An organization controls the logic behind an orchestration even if it involves external businesses </li></ul></ul><ul><li>A choreography is not owned by a single entity, it acts as a community interchange pattern used for collaborative purposes by services from different provider entities </li></ul>VA-12/05 Service Oriented Architecture
  110. 110. WS-CDL Goals <ul><li>Reusability -- Choreography definition is usable by different parties operating in different contexts (industry, locale, etc.) with different software (e.g. application software) </li></ul><ul><li>Cooperation – Choreographies define the sequence of exchanging messages between two (or more) independent parties or processes by describing how they should cooperate </li></ul><ul><li>Multi-Party Collaboration. Choreographies can be defined involving any number of parties or processes </li></ul><ul><li>Semantics -- Choreographies can include human-readable documentation and semantics for all the components in the Choreography </li></ul><ul><li>Composability -- Existing Choreographies can be combined to form new Choreographies that may be reused in different contexts </li></ul><ul><li>Modularity -- Choreographies can be defined using an &quot;inclusion&quot; facility that allows a Choreography to be created from parts contained in several different Choreographies </li></ul>VA-12/05 Service Oriented Architecture
  111. 111. WS-CDL Goals <ul><li>Information Driven Collaboration -- Choreographies describe how parties make progress within a collaboration, through the recording of exchanged information and changes to observable information that cause ordering constraints to be fulfilled and progress to be made </li></ul><ul><li>Information Alignment – Choreographies allow the parties that take part in Choreographies to communicate and synchronize their observable information </li></ul><ul><li>Exception Handling – Choreographies can define how exceptional or unusual conditions that occur while the Choreography is performed are handled </li></ul><ul><li>Transactionality -- The processes or parties that take part in a Choreography can work in a &quot;transactional&quot; way with the ability to coordinate the outcome of the long-lived collaborations, which include multiple participants, each with their own, non-observable business rules and goals </li></ul><ul><li>Specification Composability -- This specification will work alongside and complement other specifications such as the WS-Reliability [WSRM], WS-Composite Application Framework (WS-CAF) [WSCAF], WS-Security [WSS], Business Process Execution Language for WS (WS-BPEL) [WSBPEL], etc. </li></ul>VA-12/05 Service Oriented Architecture
  112. 112. WS-CDL Model <ul><li>The WS-CDL model consists of the following entities: </li></ul><ul><ul><li>Participant Types, Role Types and Relationship Types </li></ul></ul><ul><ul><ul><li>Within a Choreography, information is always exchanged between parties within or across trust boundaries. </li></ul></ul></ul><ul><ul><ul><li>A Role Type enumerates the observable behavior a party exhibits in order to collaborate with other parties. </li></ul></ul></ul><ul><ul><ul><li>A Relationship Type identifies the mutual commitments that must be made between two parties for them to collaborate successfully. </li></ul></ul></ul><ul><ul><ul><li>A Participant Type is grouping together those parts of the observable behavior that must be implemented by the same logical entity or organization </li></ul></ul></ul><ul><ul><li>Information Types, Variables and Tokens </li></ul></ul><ul><ul><ul><li>Variables contain information about commonly observable objects in a collaboration, such as the information exchanged or the observable information of the Roles involved. </li></ul></ul></ul><ul><ul><ul><li>Tokens are aliases that can be used to reference parts of a Variable. </li></ul></ul></ul><ul><ul><ul><li>Both Variables and Tokens have Types that define the structure of what the Variable contains or the Token references </li></ul></ul></ul>VA-12/05 Service Oriented Architecture
  113. 113. WS-CDL Model <ul><ul><li>Choreographies - Choreographies define collaborations between interacting parties: </li></ul></ul><ul><ul><ul><li>Choreography Life-line – expresses the progression of a collaboration </li></ul></ul></ul><ul><ul><ul><ul><li>Initially, the collaboration is established between parties, </li></ul></ul></ul></ul><ul><ul><ul><ul><li>then work is performed within it </li></ul></ul></ul></ul><ul><ul><ul><ul><li>finally it completes either normally or abnormally </li></ul></ul></ul></ul><ul><ul><ul><li>Choreography Exception Blocks -- specifies what additional interactions should occur when a Choreography behaves in an abnormal way </li></ul></ul></ul><ul><ul><ul><li>Choreography Finalizer Blocks -- describes how to specify additional interactions that should occur to modify the effect of an earlier successfully completed Choreography </li></ul></ul></ul><ul><ul><ul><ul><li>for example to confirm or undo the effect </li></ul></ul></ul></ul>VA-12/05 Service Oriented Architecture
  114. 114. WS-CDL Model <ul><ul><li>Channels - A Channel realizes a point of collaboration between parties by specifying where and how information is exchanged </li></ul></ul><ul><ul><li>Work Units - A Work Unit prescribes the constraints that must be fulfilled for making progress and thus performing actual work within a Choreography </li></ul></ul><ul><ul><li>Activities and Ordering Structures - Activities are the lowest level components of the Choreography that perform the actual work. </li></ul></ul><ul><ul><ul><li>Ordering Structures combine activities with other Ordering Structures in a nested structure to express the ordering conditions in which information within the Choreography is exchanged </li></ul></ul></ul><ul><ul><li>Interaction Activity - An Interaction is the basic building block of a Choreography, which results in an exchange of information between parties and possible synchronization of their observable information changes and the actual values of the exchanged information </li></ul></ul><ul><ul><li>Semantics - Semantics allow the creation of descriptions that can record the semantic definitions of every component in the model </li></ul></ul>VA-12/05 Service Oriented Architecture
  115. 115. WS-CDL Example VA-12/05 Service Oriented Architecture
  116. 116. WS-CDL Example VA-12/05 Service Oriented Architecture
  117. 117. WS-CDL Example VA-12/05 Service Oriented Architecture
  118. 118. WS-CDL Example VA-12/05 Service Oriented Architecture
  119. 119. WS-CDL Example VA-12/05 Service Oriented Architecture
  120. 120. WS-CDL Example VA-12/05 Service Oriented Architecture
  121. 121. WS-CDL Example VA-12/05 Service Oriented Architecture
  122. 122. Addressing VA-12/05
  123. 123. Addressing <ul><li>In the context of SOAP message addressing enables everybody to know </li></ul><ul><ul><li>Where a message is coming from </li></ul></ul><ul><ul><li>The address where it is supposed to go </li></ul></ul><ul><ul><li>The specific address where it is supposed to be delivered </li></ul></ul><ul><ul><li>Exception – where it should go if it can’t be delivered </li></ul></ul><ul><li>WS-Addressing implements addressing features by providing two types of SOAP headers </li></ul><ul><ul><li>EndpointReference </li></ul></ul><ul><ul><li>Message information header elements </li></ul></ul>VA-12/05 Service Oriented Architecture
  124. 124. Addressing <ul><li>Endpoint reference </li></ul><ul><ul><li>Address </li></ul></ul><ul><ul><li>ReferenceProperties </li></ul></ul><ul><ul><li>ReferenceParameters </li></ul></ul><ul><ul><li>PortType </li></ul></ul><ul><ul><li>ServiceName and PortName </li></ul></ul><ul><ul><li>Policy </li></ul></ul>VA-12/05 Service Oriented Architecture
  125. 125. Addressing <ul><li>Message information header </li></ul><ul><ul><li>MessageID </li></ul></ul><ul><ul><li>RelatesTo </li></ul></ul><ul><ul><li>ReplyTo </li></ul></ul><ul><ul><li>From </li></ul></ul><ul><ul><li>FaultTo </li></ul></ul><ul><ul><li>To </li></ul></ul><ul><ul><li>Action </li></ul></ul>VA-12/05 Service Oriented Architecture
  126. 126. Reliable Messaging VA-12/05
  127. 127. Reliable Messaging <ul><li>Reliable Messaging address the concerns of non-delivery and delivery out of sequence </li></ul><ul><ul><li>Establishes a measure of quality assurance that can be applied to other activity management frameworks </li></ul></ul><ul><li>Provides a framework that guarantees </li></ul><ul><ul><li>Notification of success and failure of message </li></ul></ul><ul><ul><li>Message sent with specific sequence related rules will arrive as intended </li></ul></ul><ul><ul><ul><li>In case of out of sequence message delivery, failure condition would be generated </li></ul></ul></ul>VA-12/05 Service Oriented Architecture
  128. 128. WS-ReliableMessaging <ul><li>Introduces critical quality of service features for the guaranteed delivery and failure notification of SOAP message </li></ul><ul><li>Key elements </li></ul><ul><ul><li>Sequence </li></ul></ul><ul><ul><li>MessageNumber </li></ul></ul><ul><ul><li>LastMessage </li></ul></ul><ul><ul><li>SequenceAcknowledgement </li></ul></ul><ul><ul><li>AcknowledgementRange </li></ul></ul><ul><ul><li>Nack </li></ul></ul><ul><ul><li>AckRequested </li></ul></ul>VA-12/05 Service Oriented Architecture
  129. 129. WS-ReliableMessaging – Terms <ul><li>Sequence – establishes the order in which the messages should be delivered </li></ul><ul><li>Acknowledgements – Messages that are sent to acknowledge the receipt of the message </li></ul><ul><ul><li>Negative acknowledgements are also allowed </li></ul></ul><ul><li>Delivery Assurances – predefined message delivery patterns </li></ul><ul><ul><li>AtMostOnce </li></ul></ul><ul><ul><li>AtLeastOnce </li></ul></ul><ul><ul><li>ExactlyOnce </li></ul></ul><ul><ul><li>InOrder </li></ul></ul>VA-12/05 Service Oriented Architecture
  130. 130. WS-ReliableMessaging – Sequence <ul><li>Sequence element uses a set of child elements to represent the location of current message in overall sequence of SOAP messages </li></ul><ul><ul><li>Identifier – associates an identifier with the sequence </li></ul></ul><ul><ul><li>MessageNumber – associates a number with the message </li></ul></ul><ul><ul><li>LastMessage can be added to denote that this is the last message in sequence </li></ul></ul>VA-12/05 Service Oriented Architecture
  131. 131. WS-ReliableMessaging – Sequence <ul><li>Sequence element uses a set of child elements to represent the location of current message in overall sequence of SOAP messages </li></ul><ul><ul><li>Identifier – associates an identifier with the sequence </li></ul></ul><ul><ul><li>MessageNumber – associates a number with the message </li></ul></ul><ul><ul><li>LastMessage can be added to denote that this is the last message in sequence </li></ul></ul>VA-12/05 Service Oriented Architecture
  132. 132. WS-ReliableMessaging – SequenceAcknowledgement and AcknowledgementRange <ul><li>SequenceAcknowledgement message is sent as an acknowledgement for a message received </li></ul><ul><ul><li>AcknowledgementRange child element is added to specific range of messages that were received and acknowledgement as part of the SequenceAcknowledgement that is being sent </li></ul></ul>VA-12/05 Service Oriented Architecture
  133. 133. WS-ReliableMessaging – Nack Element <ul><li>Failure of a message receipt can also be communicated by sending a Nack message </li></ul>VA-12/05 Service Oriented Architecture
  134. 134. WS-ReliableMessaging – AckRequested <ul><li>Receiver of a message may issue Ack messages at periodic intervals </li></ul><ul><li>Sender may request the receiver to issue an Ack on demand using AckRequested message </li></ul>VA-12/05 Service Oriented Architecture
  135. 135. Policy VA-12/05
  136. 136. Policy Assertions and alternatives <ul><li>Service properties are expressed individually by policy assertions </li></ul><ul><ul><li>Each assertion could be required or optional </li></ul></ul><ul><li>Policy assertions can be grouped into policy alternatives </li></ul><ul><li>Policies are used in coordination to restrict sharing of context data </li></ul><ul><li>Policies can be applied to any subject in orchestration and choreography </li></ul><ul><li>Policies are used in reliable messaging to implement fundamental features like delivery assurances </li></ul>VA-12/05 Service Oriented Architecture
  137. 137. WS-Policy framework <ul><li>WS-Policy framework consists of following three specifications </li></ul><ul><ul><li>WS-Policy </li></ul></ul><ul><ul><li>WS-PolicyAssertions </li></ul></ul><ul><ul><li>WS-PolicyAttachments </li></ul></ul>VA-12/05 Service Oriented Architecture
  138. 138. WS-Policy framework <ul><li>These collectively provide </li></ul><ul><ul><li>Policy </li></ul></ul><ul><ul><li>TextEncoding, Language, SpecVersion, MessagePredicate assertions </li></ul></ul><ul><ul><li>ExactlyOne element </li></ul></ul><ul><ul><li>All element </li></ul></ul><ul><ul><li>Usage and Preference attributes </li></ul></ul><ul><ul><li>PolicyReference element </li></ul></ul><ul><ul><li>PolicyURIs attribute </li></ul></ul><ul><ul><li>PolicyAttachment element </li></ul></ul>VA-12/05 Service Oriented Architecture
  139. 139. Policy element <ul><li>Root construct of the policy </li></ul><ul><li>Contains policy assertions </li></ul><ul><ul><li>WS-PolicyAssertions specification provide common, predefined assertion elements </li></ul></ul><ul><ul><ul><li>TextEncoding </li></ul></ul></ul><ul><ul><ul><li>Language </li></ul></ul></ul><ul><ul><ul><li>SpecVersion </li></ul></ul></ul><ul><ul><ul><li>MessagePredicate – indicates message processing rules expressed using XPath </li></ul></ul></ul>VA-12/05 Service Oriented Architecture
  140. 140. ExactlyOne, All, and Preference element <ul><li>ExactlyOne </li></ul><ul><ul><li>This construct surrounds multiple assertions with a choice between them </li></ul></ul><ul><ul><li>Exactly one must be chosen </li></ul></ul><ul><li>All </li></ul><ul><ul><li>This construct surrounds multiple assertions </li></ul></ul><ul><ul><li>Indicates that all must be met </li></ul></ul><ul><li>Preference </li></ul><ul><ul><li>Provides a mechanism to rank assertions as per order of preference </li></ul></ul><ul><ul><ul><li>An integer value is assigned </li></ul></ul></ul>VA-12/05 Service Oriented Architecture
  141. 141. PolicyReference & PolicyURI element <ul><li>PolicyReference </li></ul><ul><ul><li>It is used to link an element with one or more policies </li></ul></ul><ul><ul><li>PolicyReference element contains a URI that points to the policy document </li></ul></ul><ul><ul><ul><li>ID attribute is referenced via the value after # in URL </li></ul></ul></ul><ul><li>PolicyURI </li></ul><ul><ul><li>PolicyURI can be used to link one or more policy documents </li></ul></ul><ul><ul><ul><li>These policies are merged at run time </li></ul></ul></ul>VA-12/05 Service Oriented Architecture
  142. 142. Additional type of assertions <ul><li>WSDL provides UsingPolicy element for additional types of assertions </li></ul>VA-12/05 Service Oriented Architecture
  143. 143. WS-Policy Example VA-12/05 Service Oriented Architecture
  144. 144. Metadata Exchange VA-12/05
  145. 145. Metadata Exchange <ul><li>Metadata exchange provides information regarding services that a service provider provides </li></ul><ul><li>WS-MetadataExchange specification allows for a service requestor to issue a standardized request message that asks for some or all of the meta information related to an endpoint address </li></ul><ul><ul><li>If a service requestor knows where a service is located, it can query it to find information about services that are located </li></ul></ul>VA-12/05 Service Oriented Architecture
  146. 146. WS-MetadataExchange <ul><li>Originally specification provides three types of messages </li></ul><ul><ul><li>Get WSDL </li></ul></ul><ul><ul><li>Get Schema </li></ul></ul><ul><ul><li>Get Policy </li></ul></ul><ul><li>These messages were later merged into a single message </li></ul><ul><ul><li>Get Metadata </li></ul></ul><ul><li>To retrieve actual contents Get request message is used </li></ul>VA-12/05 Service Oriented Architecture
  147. 147. WS-MetadataExchange <ul><li>Service requestor sends a GetMetaData request </li></ul><ul><li>Upon receiving request message service endpoint generates a response message with metadata documents </li></ul>VA-12/05 Service Oriented Architecture
  148. 148. WS-MetadataExchange – GetMetadata element <ul><li>GetMetadata element is placed in body element of SOAP message </li></ul><ul><li>Dialect </li></ul><ul><ul><li>Specifies type and version of metadata requested </li></ul></ul><ul><li>Identifier </li></ul><ul><ul><li>Specifies types of metadata requested </li></ul></ul>VA-12/05 Service Oriented Architecture
  149. 149. WS-MetadataExchange <ul><li>Metadata element </li></ul><ul><ul><li>Parent element for metadata </li></ul></ul><ul><li>MetadataSection element </li></ul><ul><ul><li>Contents of documents are placed in this section </li></ul></ul><ul><li>MetadataReference element </li></ul><ul><ul><li>If only pointer to the document is sent, this section is used </li></ul></ul>VA-12/05 Service Oriented Architecture
  150. 150. Get message <ul><li>If response to GetMetadata request contains MetadataReference then service requestor can use Get message to get actual contents of the documents </li></ul>VA-12/05 Service Oriented Architecture
  151. 151. WS-MetadataExchange examples VA-12/05 Service Oriented Architecture
  152. 152. Security VA-12/05
  153. 153. Security <ul><li>Core security specifications are </li></ul><ul><ul><li>WS-Security </li></ul></ul><ul><ul><li>XML-Signature </li></ul></ul><ul><ul><li>XML-Encryption </li></ul></ul><ul><ul><li>Single-Sign On </li></ul></ul>VA-12/05 Service Oriented Architecture
  154. 154. Identification, Authentication, and Authorization <ul><li>Identity is a claim regarding origin of a message </li></ul><ul><li>Authentication means that identity is established </li></ul><ul><li>Authorization provides the extent of access that authentication grants </li></ul>VA-12/05 Service Oriented Architecture
  155. 155. Single Sign-on <ul><li>Propagating the authentication and authorization to multiple service providers is a challenge </li></ul><ul><li>Single Sign-on address this issue </li></ul><ul><li>Three primary extensions that support SSO </li></ul><ul><ul><li>SAML – Security Assertion Markup Language </li></ul></ul><ul><ul><li>.NET Passport </li></ul></ul><ul><ul><li>XACML – XML Access Control Markup Language </li></ul></ul>VA-12/05 Service Oriented Architecture
  156. 156. Confidentiality and Integrity <ul><li>Confidentiality is concerned with protecting the privacy of message contents </li></ul><ul><ul><li>A message is considered to have remained confidential if no service or agent in its message path not authorized to do so viewed its contents </li></ul></ul><ul><li>Integrity ensures that the message is not altered since its departure from the original sender </li></ul><ul><ul><li>This guarantees that the state of the message has remained same since original transmission </li></ul></ul>VA-12/05 Service Oriented Architecture
  157. 157. Transport Level security and message level security <ul><li>SSL provider transport level security </li></ul><ul><li>A service intermediary taking possession of this message may still have capability to alter the message </li></ul><ul><ul><li>In SOA message level security is a must </li></ul></ul><ul><li>Encryption and digital signatures </li></ul><ul><ul><li>Encryption provides features so that encryption can be applied to whole message or parts of it </li></ul></ul><ul><ul><li>Signatures provide non-repudiation which can prove that the message was sent by a specific requestor and delivered to specific provider </li></ul></ul><ul><ul><ul><li>Is also legally binding </li></ul></ul></ul>VA-12/05 Service Oriented Architecture
  158. 158. WS-Security <ul><li>Security element </li></ul><ul><ul><li>Could also contain XML-Encryption and XML-Signature </li></ul></ul><ul><ul><li>UsernameToken </li></ul></ul><ul><ul><ul><li>Username </li></ul></ul></ul><ul><ul><ul><li>Password </li></ul></ul></ul><ul><ul><li>SecurityTokenReference – provides pointer to a token that exists outside the SOAP message </li></ul></ul><ul><ul><li>BinarySecurityToken </li></ul></ul><ul><ul><ul><li>Tokens stored as binary data e.g. certificates </li></ul></ul></ul>VA-12/05 Service Oriented Architecture
  159. 159. Composing security element <ul><li>Security element is the standardized container for security related elements </li></ul><ul><ul><li>SAML block could also be located in Security element </li></ul></ul>VA-12/05 Service Oriented Architecture
  160. 160. WS-Security Example VA-12/05 Service Oriented Architecture
  161. 161. SAML single sign-on block Example VA-12/05 Service Oriented Architecture
  162. 162. SAML sign-on block Example VA-12/05 Service Oriented Architecture
  163. 163. Notification & Eventing VA-12/05
  164. 164. Notification & Eventing <ul><li>Notification and Eventing are used to implement a push delivery pattern </li></ul><ul><li>Involves a publisher service </li></ul><ul><ul><li>Makes information categorized by different topics available </li></ul></ul><ul><li>Subscribers register for receiving this information </li></ul><ul><ul><li>Subscriber can chose to register for topics by directly interacting with publisher or some kind of broker </li></ul></ul><ul><li>When any new information is available regarding any topic, it is broadcast to all the subscribers that are interested in that topic </li></ul>VA-12/05 Service Oriented Architecture
  165. 165. Specifications <ul><li>Two major implementations exist </li></ul><ul><ul><li>WS-Notification </li></ul></ul><ul><ul><li>WS-Eventing </li></ul></ul>VA-12/05 Service Oriented Architecture
  166. 166. WS-Notification <ul><li>Sponsored by IBM for its grid computing platform </li></ul><ul><ul><li>WS-BaseNotification – establishes the standardized interfaces used by services involved on either end of information exchange </li></ul></ul><ul><ul><li>WS-Topics – governs the structure and categorization of topics </li></ul></ul><ul><ul><li>WS-BrokeredNotification – standardizes the broker intermediary used to send and receive messages </li></ul></ul>VA-12/05 Service Oriented Architecture
  167. 167. WS-Eventing <ul><li>Sponsored by microsoft </li></ul><ul><li>Designed for system administration </li></ul><ul><li>Concepts </li></ul><ul><ul><li>Event sources </li></ul></ul><ul><ul><li>Event sinks and subscribers </li></ul></ul><ul><ul><li>Subscription managers </li></ul></ul><ul><ul><li>Notification messages </li></ul></ul><ul><ul><li>Subscription end messages </li></ul></ul><ul><ul><li>Subscription messages </li></ul></ul><ul><ul><ul><li>Subscribe </li></ul></ul></ul><ul><ul><ul><li>Unsubscribe </li></ul></ul></ul><ul><ul><ul><li>Renew </li></ul></ul></ul><ul><ul><ul><li>GetStatus </li></ul></ul></ul><ul><ul><li>Subscription filters </li></ul></ul>VA-12/05 Service Oriented Architecture
  168. 168. WS-Notification and WS-Eventing <ul><li>Huge overlaps between two standards primarily due to interests of sponsor vendors </li></ul><ul><li>Efforts re underway to have a common specification or interoperability established </li></ul>VA-12/05 Service Oriented Architecture
  169. 169. Notification Message Example VA-12/05 Service Oriented Architecture
  170. 170. Subscription Request Example VA-12/05 Service Oriented Architecture
  171. 171. Subscription Response Example VA-12/05 Service Oriented Architecture
  172. 172. WS-I Profiles VA-12/05
  173. 173. WS-I Profiles <ul><li>A Profile is a named group of Web services specifications at specific version levels, along with </li></ul><ul><li>conventions about how they work together. </li></ul><ul><ul><li>WS-I will develop a core collection of profiles that support interoperability for general purpose Web services functionality. </li></ul></ul><ul><li>Profiles make it easier to discuss Web services interoperability at an appropriate level of granularityThere is already strong industry consensus on what constitutes the most basic Web services profile. </li></ul><ul><ul><li>More advanced Profiles will therefore likely include this basic Profile as a foundation. </li></ul></ul><ul><li>Vertical industries will build on the WS-I Profiles by adding industry specific standards. </li></ul>VA-12/05 Service Oriented Architecture
  174. 174. WS-I Profiles <ul><li>Basic Profile 1.0 consists of </li></ul><ul><ul><li>XML Schema 1.0 </li></ul></ul><ul><ul><li>SOAP 1.1 </li></ul></ul><ul><ul><li>WSDL 1.1 </li></ul></ul><ul><ul><li>UDDI 2.0. </li></ul></ul><ul><li>Basic Profile 1.1 </li></ul><ul><ul><li>SOAP 1.1 </li></ul></ul><ul><ul><li>HTTP/1.1 </li></ul></ul><ul><ul><li>XML 1.0 (Second Edition) </li></ul></ul><ul><ul><li>XML Schema Part 1: Structures </li></ul></ul><ul><ul><li>XML Schema Part 2: Datatypes </li></ul></ul><ul><ul><li>WSDL 1.1 </li></ul></ul><ul><ul><li>UDDI Version 2.04 API Specification </li></ul></ul><ul><ul><li>UDDI Version 2.03 Data Structure Reference </li></ul></ul><ul><ul><li>UDDI Version 2 XML Schema </li></ul></ul><ul><ul><li>RFC2818: HTTP Over TLS </li></ul></ul><ul><ul><li>RFC2246: The TLS Protocol Version 1.0 </li></ul></ul><ul><ul><li>The SSL Protocol Version 3.0 </li></ul></ul><ul><ul><li>RFC2459: Internet X.509 PKI Certificate and CRL Profile </li></ul></ul>VA-12/05 Service Oriented Architecture
  175. 175. WS-I Profiles <ul><li>Attachment profile 1.0 </li></ul><ul><ul><li>SOAP Messages with Attachments </li></ul></ul><ul><ul><li>XML 1.0 (Second Edition) </li></ul></ul><ul><ul><li>Namespaces in XML 1.0 </li></ul></ul><ul><ul><li>RFC2557 MIME Encapsulation of Aggregate Documents, such as HTML (MHTML) </li></ul></ul><ul><ul><li>RFC2045 Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies </li></ul></ul><ul><ul><li>RFC2046 Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types </li></ul></ul><ul><ul><li>RFC2392 Content-ID and Message-ID Uniform Resource Locators </li></ul></ul><ul><ul><li>WSDL 1.1, Section 5.0 </li></ul></ul>VA-12/05 Service Oriented Architecture
  176. 176. WS-I Profiles <ul><li>Simple SOAP Binding profile </li></ul><ul><ul><li>Simple Object Access Protocol (SOAP) 1.1 </li></ul></ul><ul><ul><li>Extensible Markup Language (XML) 1.0 (Second Edition) </li></ul></ul><ul><ul><li>Namespaces in XML 1.0 </li></ul></ul><ul><ul><li>RFC2616: Hypertext Transfer Protocol -- HTTP/1.1 </li></ul></ul><ul><ul><li>WSDL 1.1, Section 3 </li></ul></ul>VA-12/05 Service Oriented Architecture
  177. 177. WS-I Profiles <ul><li>Basic Security Profile </li></ul><ul><ul><li>HTTP over TLS </li></ul></ul><ul><ul><li>The TLS Protocol Version 1.0 </li></ul></ul><ul><ul><li>The SSL Protocol Version 3.0 </li></ul></ul><ul><ul><li>Web Services Security: SOAP Message Security 1.0 (WS-Security 2004) OASIS Standard 200401, March 2004 </li></ul></ul><ul><ul><li>Web Services Security: SOAP Message Security 1.0 (WS-Security 2004) Errata 1.0 Committee Draft 200401, October 2004 </li></ul></ul><ul><ul><li>Web Services Security UsernameToken Profile 1.0 OASIS Standard 200401, March 2004 </li></ul></ul><ul><ul><li>Web Services Security: UsernameToken Profile 1.0 Errata 1.0 Committee Draft 200401, September 2004 </li></ul></ul><ul><ul><li>Web Services Security X.509 Certificate Token Profile OASIS Standard 200401, March 2004 </li></ul></ul><ul><ul><li>Web Services Security: X.509 Token Profile 1.0 Errata 1.0 Committee Draft 200401, October 2004 </li></ul></ul><ul><ul><li>RFC2459: Internet X.509 Public Key Infrastructure Certificate and CRL Profile </li></ul></ul><ul><ul><li>Information technology &quot;Open Systems Interconnection&quot; The Directory: Public-key and attribute certificate frameworks Technical Corrigendum 1 </li></ul></ul><ul><ul><li>XML-Signature Syntax and Processing </li></ul></ul><ul><ul><li>Web Services Security: SOAP Message Security Section 9 </li></ul></ul><ul><ul><li>XML Encryption Syntax and Processing </li></ul></ul><ul><ul><li>Basic Profile Version 1.0 (BP1.0) </li></ul></ul><ul><ul><li>Basic Profile Version 1.0 Errata </li></ul></ul><ul><ul><li>Basic Profile Version 1.1 (BP1.1) </li></ul></ul><ul><ul><li>Simple SOAP Binding Profile Version 1.0 (SSBP1.0) </li></ul></ul><ul><ul><li>Attachments Profile Version 1.0 (AP1.0) </li></ul></ul><ul><ul><li>Web Services Security: SOAP Messages with Attachments (SwA) Profile 1.0 </li></ul></ul>VA-12/05 Service Oriented Architecture
  178. 178. WS-I Profiles <ul><li>Kerberos Token Profile </li></ul><ul><ul><li>Web Services Security: Kerberos Token Profile </li></ul></ul><ul><li>Rights Expression Lannguage (REL) Token Profile </li></ul><ul><ul><li>Web Services Security: REL Token Profile </li></ul></ul><ul><li>SAML Token Profile </li></ul><ul><ul><li>Web Services Security: SAML Token Profile </li></ul></ul>VA-12/05 Service Oriented Architecture
  179. 179. Service Design Guidelines VA-12/05
  180. 180. Guidelines <ul><li>Apply naming standards </li></ul><ul><ul><li>Create naming standards and apply them to </li></ul></ul><ul><ul><ul><li>Service endpoint names </li></ul></ul></ul><ul><ul><ul><li>Service operation names </li></ul></ul></ul><ul><ul><ul><li>Message value </li></ul></ul></ul><ul><li>Naming standards are organization specific </li></ul>VA-12/05 Service Oriented Architecture
  181. 181. Suggestions for naming <ul><li>Service candidates with high reuse potential should be stripped of any business process related naming characteristics </li></ul><ul><li>Entity centric business services need to remain representative of their corresponding entity models </li></ul><ul><li>Service operations for entity centric business service should be verb based and should not repeat service names </li></ul><ul><li>Names should clearly communicate the nature of their individual functionality </li></ul>VA-12/05 Service Oriented Architecture
  182. 182. Suitable interface granularity <ul><li>XML based processing generally has performance challenges hence service design should be of optimum granularity </li></ul><ul><li>Use alternatives like binary encoding extensions if needed </li></ul><ul><li>Have alternative WSDL definitions for same services </li></ul><ul><li>Ave coarse grained interfaces to services designated as solution endpoints </li></ul>VA-12/05 Service Oriented Architecture
  183. 183. SOA platforms VA-12/05
  184. 184. J2EE Platform VA-12/05 Service Oriented Architecture Different Operating Systems Java Runtime J2EE class library JAX-RPC Runtime Service oriented solution Web Container EJB Container Servlets EJB
  185. 185. J2EE Platform <ul><li>Relevant specifications </li></ul><ul><ul><li>Java 2 Platform Enterprise Edition Specification </li></ul></ul><ul><ul><li>Java API for XML based RPC </li></ul></ul><ul><ul><li>Web Services for J2EE </li></ul></ul><ul><ul><li>Architectural components </li></ul></ul><ul><ul><ul><li>JSP </li></ul></ul></ul><ul><ul><ul><li>Struts </li></ul></ul></ul><ul><ul><ul><li>Servlets </li></ul></ul></ul><ul><ul><ul><li>EJBs </li></ul></ul></ul><ul><ul><li>Runtime </li></ul></ul><ul><ul><ul><li>EJB container </li></ul></ul></ul><ul><ul><ul><li>Web container </li></ul></ul></ul>VA-12/05 Service Oriented Architecture
  186. 186. .NET Platform VA-12/05 Service Oriented Architecture Windows Operating Systems Common Language Runtime .NET class library Assemblies Service oriented solution ASP.NET Web Services Enhancements(WSE)
  187. 187. .NET platform <ul><li>Architectural components </li></ul><ul><ul><li>ASP.NET Web Forms </li></ul></ul><ul><ul><li>ASP.NET Web Services </li></ul></ul><ul><ul><li>Assemblies </li></ul></ul>VA-12/05 Service Oriented Architecture
  188. 188. [email_address] VA-12/05