1 / 96

FIRMS TUTORIAL Leveraging WSRM and WSR

FIRMS TUTORIAL Leveraging WSRM and WSR. Community Grids Lab, Indiana University. FIRMS Tutorial: Outline. Some Observations about WS-* specifications WS-Addressing Reliable Messaging Overview WS-Reliable Messaging WS-Reliability Deploying FIRMS Running FIRMS within the OMII Container.

fifi
Download Presentation

FIRMS TUTORIAL Leveraging WSRM and WSR

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. FIRMS TUTORIALLeveraging WSRM and WSR Community Grids Lab, Indiana University

  2. FIRMS Tutorial: Outline • Some Observations about WS-* specifications • WS-Addressing • Reliable Messaging Overview • WS-Reliable Messaging • WS-Reliability • Deploying FIRMS • Running FIRMS within the OMII Container

  3. Part I – Some Observations about WS-* specifications

  4. Some quick observations about WS-* • Typically addresses core areas or those where the demand is substantial enough to eschew proprietary ad hoc solutions. • In some cases common issues across various WS-* specifications mandate additional WS-* specifications. • Exemplars include WS-Addressing, WS-Policy. • Various specifications are intended to incrementally augment capabilities at an endpoint. • For e.g. if you need reliable messaging capabilities simply plug in a WSRM or WSR module. If you need notification capability plug in WS-Eventing or WS-Notification.

  5. Some quick observations about WS-* • Functionality of specifications encapsulated within stand-alone SOAP messages. • They typically also include a WSDL definitions of operations, but all functionality is encapsulated in SOAP messages. • Primary interaction model is one-way, asynchronous SOAP messaging. • Lot of these specifications are also intended to be stackable.

  6. Typical implementation strategy • Develop strategy for processing the XML Schema associated with the specification. • This would allow you to process the XML messages from Java (or language of choice). • XML generated over the wire should be conformant to the relevant schemas. • This allows one to interact with other implementations. • Develop Processor to enforce rules and processing associated with the specification. • This would include performing actions, issuing requests/responses and faults. • Ensure that rules and processing related to leveraged specifications are enforced.

  7. Processing XML Schemas • We were looking for a solution that allowed us to process XML from within the Java domain. • There are 4 choices • Develop Java classes ourselves • Use wsdl2java to do this • Use the JAXB Data Binding Framework • Use a schema compiler such as Castor or XMLBeans

  8. Writing one’s own classes • Approach used by Apache’s Sandesha project. • Implementation of WSRM • Error prone and quite difficult • Increasingly the developer has to deal with several other specifications. • Another approach is to just process messages based on DOM. • Quite difficult to do. No examples that we are currently aware of.

  9. WSDL2Java Problems • Issues (in version 1.2) related to this tool’s support for schemas have been documented in http://www-106.ibm.com/developerworks/webservices/library/ws-castor/ . • Specifically, the problems relate to insufficient (and in some cases incorrect) support for complex schema types, XML validation and serialization issues.

  10. JAXB Issues • JAXB is a specification from Sun to deal with XML and Java data-bindings. • JAXB though better than what is generated using Axis’ wsdl2java still does not provide complete support for the XML Schema. • You may run into situations where you may find an inaccessible data inside your schema. • We looked at both the JAXB reference implementation from Sun and JaxMe from Apache (which is an open source implementation of the JAXB Framework).

  11. Rationale for the choice of XMLBeans • We settled on XMLBeans because of two reasons. • It is an open source effort. Originally developed by BEA it was contributed by BEA to the Apache Software Foundation. • In our opinion, it provides the best and most complete support for the XML schema of all the tools currently available. • XMLBeans allows us to validate instance documents and also facilitates simple but sophisticated navigation through XML documents. • The XML generated by the corresponding Java classes is true XML which conforms to (and can be validated against) the original schema.

  12. Developing WS-* Processors • In some cases there would be more than one role associated with a specification. Ensure that processing related to each role is done. • E.g. WSRM, WSR and WSE. • Processing the SOAP Messages • Direction of the message is important. • Messages processed differently depending on whether it was received over the network or from application. • When problems are encountered the processor needs to throw exceptions and/or issue faults. • Faults need to conform to rules outlined in both SOAP and WS-Addressing.

  13. PART – IIWS-Addressing

  14. WS-Addressing • Web Services Addressing (WSA) provides transport-neutral mechanisms to address Web services and messages. • WSA provides two very important constructs: • endpoint references (EPR) and • message information headers (MIH) • WSA is leveraged by several WS-* specifications • WS-ReliableMessaging, WS-Reliability and WS-Notification.

  15. Endpoint References (EPR) • Endpoint references are a transport neutral way to identify and describe service instances and endpoints. • A typical scenario would involve a node sitting at the edge of an organization, directing traffic to the right instance based on the information maintained in the EPR. • EPRs are constructed and specified in the SOAP message by the entity that is initiating the communications

  16. EPRs – Structure • An address element which is a URI • A reference properties element which is a set of properties required to identify a resource • A reference parameters element which is a set of parameters associated with the endpoint that is necessary for facilitating specific interactions.

  17. Message Information Headers (MIH) • The MIH enables the identification and location of endpoints pertaining to an interaction. • The interactions include Request, Reply/Response, and Faults.

  18. Message Information Headers - II • To (mandatory element): This specifies the intended receiver of message. • From: This identifies the originator of a message. • ReplyTo: Specifies where replies to a message will be sent to. • FaultTo: Specifies where faults, as a result of processing the message, should be sent to.

  19. Message Information Headers III • Action: This is a URI that identifies the semantics associated with the message. WSA also specifies rules on the generation of Action elements from the WSDL definition of a service. • In the WSDL case this is generally a combination of [target namespace]/[port type name]/[input/output name] . For e.g. http://schemas.xmlsoap.org/ws/2004/08/eventing/Subscribe is a valid action element. • MessageId: This is typically a UUID which uniquely identifies a message. This is sometimes also used correlate responses with previously issued requests. • RelatesTo: This identifies how a message relates to a previous message. This field typically contains the messageId of a previously issued message.

  20. WSA Rules • Identifies how the EPR elements should be added to the Header of the SOAP Message while targeting an endpoint. • Has rules pertaining to the generation of responses and faults. • Contents of the wsa:RelatesTo and/or the wsa:Action field.

  21. WSA Rules • WSA also outlines the rules related to targeting of replies and faults. • In the case of faults, it also outlines the content of the wsa:Action element. • It outlines rules related to the generation of the wsa:RelatesTo element.

  22. Creating EPRs – (1) • We have simplified the creation of endpoint references. The complexity of the generation of the appropriate EPR is managed by the cgl.narada.wsinfra.wsa.WsaEprCreator class. To get a reference to this class please see the code snippet below. WsaEprCreator wsaEprCreator = WsaEprCreator.getInstance();

  23. Creating EPRs • A simple EPR reference can be easily created by the code snippet below

  24. Creating WSA EPRs • If one wishes to add ReferenceProperties to the EPR that we just created, the snippet below outlines how it is done.

  25. Part -III Reliable Messaging

  26. Why reliable messaging? • TCP is not enough • Provides per-hop guarantees. • No scheme to recover from failures. • Applications can sometimes require strong reliability guarantees. • Transactions need to be assured to be processed exactly-once. • May delegate complexity of guarantees to the protocol implementation.

  27. Reliable Messaging: General Requirements • Must be transport independent. • Underlying link may be lossy, may possibly garble order and generate multiple copies of same message. • Support a variety of delivery assurances, each of which may be leveraged by different applications. • Must support recovery from failures. • Must lend itself to incremental addition of capabilities such as security and notifications.

  28. Application layer reliability • XML-based collaborative application: RosettaNet/BizTalk framework; provides business-level reliability scheme. • ebXML with its ebXML Message Service(ebMS) : First reliability scheme binding with XML messages and the antecedent of the WS-Reliability specification. • Typical exchange involves the ebMS Message Service Handler (MSH) responding to a message with an Acknowledgement message • WS-Reliability from Fujitsu and SUN extended and modified the basic ebMS scheme for Web services. • WS-ReliableMessaging from IBM, and Microsoft, provides reliable messaging architecture within the Web services domain.

  29. A note on Acknowledgements • Sender initiated protocols: ACKs (+ve acknowledgements) • Confirms the receipt of a specific event • Sender identifies holes in the delivery sequences, based on Acks, and initiate retransmissions to remedy this error. • Receiver-initiated protocols: NAKs (-ve acknowledgements) • Detect the error in the received sequences and send the negative acknowledgements to plug these gaps in the delivered sequences • ACK-based scheme can exist by themselves, but NAK-based scheme cannot. • A NAK-only scheme will require a source to keep messages forever, since there is no way to know if the message was received.

  30. General Reliable Messaging Assurances • At-Least-Once: Guaranteed message delivery • At-Most-Once: Guaranteed message duplicate elimination • Exactly-Once: Guaranteed message delivery and duplicate elimination • Guaranteed Message Ordering within a group of the messages

  31. WS-Reliable Messaging • Specification from IBM, and Microsoft • Leverages the WS-Addressing and WS-Policy specifications. • Provides support for both positive and negative acknowledgements. • Provides operations for explicit creation and termination of sequences. • Delivery assurance modes supported include at-least-once, at-most-once, exactly-once, and ordered delivery.

  32. WS-Reliability • Specification from Fujitsu, Oracle, and Sun • Provides support for positive acknowledgements. • Provides support for a variety of message-exchange patterns. • Request/Response, One-way, Polling • Delivery assurance mode supported • Unreliable, at-least-once, ordered-and-exactly-once • Is currently an OASIS standard. • (Note WS-Security is also an OASIS standard)

  33. WSRM & WSR Similarities • Messages are part of a sequence/group of messages. • Addresses issues pertaining to ordering and duplicate detection. • Quality of service constraints are applied to groups of messages. • Recommends message-level security, specifically WS-Security, for secure delivery of messages. • Provides framework for reporting faults/errors in processing between endpoints involved in reliable delivery • Provide support for acknowledging multiple range of messages received within a group/sequence.

  34. Part -IV WS-Reliable Messaging

  35. Enabling reliable messaging using WSRM • All an entity needs to do is to ensure that the message flows through the appropriate processors. • There are two distinct roles within the WSRM – the source and the sink. • The WSRM specification facilitates the reliable delivery of messages from the source to the sink.

  36. Example Scenario: WSRM Reliable Messaging using WSRM from Endpoint A to Endpoint B

  37. Reliable Messaging Using WSRM – (1) • Let us now look closely at communications between endpoints A and B. • Furthermore, for the purposes of this discussion let us assume that we are interested in reliable messaging for messages issued from A to B. • Configure a source-processor at endpoint A and a sink-processor at endpoint B. • All messages issued by the application at endpoint A are funneled through the source-processor. • All messages received from the network are funneled through the sink processor at endpoint B.

  38. Reliable Messaging Using WSRM – (2) • When endpoint A is ready to send a message to endpoint B, it creates a SOAP Message with the appropriate WS-Addressing element [wsa:To] indicate the endpoint to which the message is targeted. • Since all messages are funneled through the source processor, the source-processor at endpoint A receives this message.

  39. Reliable Messaging Using WSRM – (3)Operations at the Source • The source-processor at A checks to see if a Sequence (essentially a group of messages identified by a UUID) has been established for messages originating at A and targeted to B. • If a Sequence has not been established, the source-processor at endpoint A initiates a CreateSequence control message to initiate the creation of sequence. • Upon receipt of this CreateSequence request, the sink-processor at the target endpoint B generates a CreateSequenceResponse.. • If a Sequence exists (or if one was established as outlined in item a), the source-processor at the originator endpoint A will associate this Sequence with the message. • Additionally, for every Sequence a source-processor also keeps track of the number of messages that were sent by the source endpoint A to the target sink-endpoint B. • For every unique application message (retransmissions, control messages etc are not within the purview of this numbering scheme) sent from A to B the source-processor at A increments the message number by 1. This message number is also included along with the Sequence information.

  40. Reliable Messaging Using WSRM – (4)Operations at the Sink • Upon receipt of such a message at the sink endpoint B, the sink-processor checks to see if there were any losses in messages that were sent prior to this message (the numbering information reveals such losses). • If there were no losses and the message order is correct, the sink-processor releases the message to the application at B. • The message is stored onto stable storage and an acknowledgment is issued based on the acknowledgement interval. • If there are problems with the received message, such as unknown Sequence Information or if the Sequence was terminated an error message is returned to the source. • If a message loss has been detected, the sink will initiate retransmissions by issuing a negative acknowledgement to the source endpoint A. • This negative acknowledgement will include the message numbers and the Sequence information about the messages that were not received.

  41. Reliable Messaging Using WSRM – (5) • A source endpoint can also identify a message as being the last message of a Sequence. • This must be specified within the application layer and the source-processor will initiate appropriate actions associated with such a message. QName qName = WsrmQNames.getInstance().getLastMessageNBX(); String value = "true"; boolean added = soapMessageAlteration.addToSoapHeader(envelopeDocument, qName, value);

  42. Reliable Messaging Using WSRM – (6)Creation of Source and Sink Processors

  43. Reliable Messaging Using WSRM – (6) • All actions related to ensuring reliable communications are handled by the source and sink processors at the endpoints. The functions performed by the processors include: • Initiating the creation of a Sequence. [Source] • Responding to a CreateSequence request and the creation of a Sequence. [Sink] • Tagging Sequence and Numbering information to a message. [Source] • Issuing acknowledgements (both positive and negative). [Sink] • Processing Acknowledgements and performing retransmissions. [Source].

  44. Application Source Client Application Sink Client Wsrm Source Axis WS Wsrm Sink Axis WS DB DB (1) Create Sequence / Reliable Message (2) Sequence Response/ Acknowledgment WS-Reliable Messaging Interactions I

  45. Part -V WS-Reliability

  46. Overview of Reliability • End points communicate through the exchange of reliable messages. • A message is to be delivered reliably between distributed applications in the presence of software component, system, or network failures. • Reliability based systems are an instance of messaging-based systems where entities have two distinct roles viz. source and sink.

  47. Producer Application Consumer Application Notify Submit Deliver Respond Source Node Processor Sink Node Processor DB DB

  48. Routing WS-Reliability Message from Source • A source will issue SOAPMessage based on the application client request and initiates reliable message transfer. • The sink node will pass the message to the application client, in this implementation this is the target service. • The sink node wait for payload from application and will responds with response. • The source will send a poll request if the application request is poll and send it to the Sink.

  49. WS-Reliability • WS-Reliability is an instance of a tightly-coupled messaging system. • There is no intermediary between the source and the sink. • The source is responsible for the routing of SOAP Message Reliably to the Sink.

More Related