Soa Primer

Service Oriented Architecture [email_address] VA-12/05

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

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

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

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

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

Process Covers process for building SOA using Web Services VA-12/05 Service Oriented Architecture

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Web Services Framework VA-12/05

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

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

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

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

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

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

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

Service Descriptions Services descriptions are provided using service description documents It is also known as WSDL definition VA-12/05 Service Oriented Architecture

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

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

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

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

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

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

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

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

SOAP Basics A SOAP message is composed of following sections Header Body Fault VA-12/05 Service Oriented Architecture

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

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

WSDL Example 1/3 VA-12/05 Service Oriented Architecture

SOAP Example VA-12/05 Service Oriented Architecture

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

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

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

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

UDDI record example VA-12/05 Service Oriented Architecture

Message Exchange Patterns VA-12/05

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

WS-Coordination example VA-12/05 Service Oriented Architecture

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

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

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

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

WS-BPEL Example VA-12/05 Service Oriented Architecture

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

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

Top level attributes abstractProcess – This attribute specifies whether the process being defined is abstract (rather than executable). The default for this attribute is "no". 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

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

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

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

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

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

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

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 "no-op" instruction into a business process VA-12/05 Service Oriented Architecture

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

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="yes" 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

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

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

Standard attributes and elements Standard-attributes are name="ncname"? suppressJoinFailure="yes|no"? 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

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

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

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

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

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

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 "inclusion" facility that allows a Choreography to be created from parts contained in several different Choreographies VA-12/05 Service Oriented Architecture

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 "transactional" 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

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

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

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

WS-CDL Example VA-12/05 Service Oriented Architecture

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

Addressing Endpoint reference Address ReferenceProperties ReferenceParameters PortType ServiceName and PortName Policy VA-12/05 Service Oriented Architecture

Addressing Message information header MessageID RelatesTo ReplyTo From FaultTo To Action VA-12/05 Service Oriented Architecture

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

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

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

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

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

WS-ReliableMessaging – Nack Element Failure of a message receipt can also be communicated by sending a Nack message VA-12/05 Service Oriented Architecture

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

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

WS-Policy framework WS-Policy framework consists of following three specifications WS-Policy WS-PolicyAssertions WS-PolicyAttachments VA-12/05 Service Oriented Architecture

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

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

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

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

Additional type of assertions WSDL provides UsingPolicy element for additional types of assertions VA-12/05 Service Oriented Architecture

WS-Policy Example VA-12/05 Service Oriented Architecture

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

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

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

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

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

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

WS-MetadataExchange examples VA-12/05 Service Oriented Architecture

Security Core security specifications are WS-Security XML-Signature XML-Encryption Single-Sign On VA-12/05 Service Oriented Architecture

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

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

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

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

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

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

WS-Security Example VA-12/05 Service Oriented Architecture

SAML single sign-on block Example VA-12/05 Service Oriented Architecture

SAML sign-on block Example VA-12/05 Service Oriented Architecture

Notification & Eventing VA-12/05

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

Specifications Two major implementations exist WS-Notification WS-Eventing VA-12/05 Service Oriented Architecture

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

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

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

Notification Message Example VA-12/05 Service Oriented Architecture

Subscription Request Example VA-12/05 Service Oriented Architecture

Subscription Response Example VA-12/05 Service Oriented Architecture

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

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

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

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

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 "Open Systems Interconnection" 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

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

Service Design Guidelines VA-12/05

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

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

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

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

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

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

.NET platform Architectural components ASP.NET Web Forms ASP.NET Web Services Assemblies VA-12/05 Service Oriented Architecture

Soa Primer

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Soa Primer (20)

Recently uploaded (20)

Soa Primer