Your SlideShare is downloading. ×
Soa Primer
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

Soa Primer

4,791
views

Published on

Published in: Technology

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