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

2. FIRMS-Tutorial2 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. FIRMS-Tutorial3 Part I – Some Observations about WS-* specifications

4. FIRMS-Tutorial4 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. FIRMS-Tutorial5 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. FIRMS-Tutorial6

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

8. FIRMS-Tutorial8 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

9. FIRMS-Tutorial9 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.

10. FIRMS-Tutorial10 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/.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.

11. FIRMS-Tutorial11 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).

12. FIRMS-Tutorial12 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.

13. FIRMS-Tutorial13 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.

14. FIRMS-Tutorial14 PART – II WS-Addressing

15. FIRMS-Tutorial15 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.

16. FIRMS-Tutorial16 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

17. FIRMS-Tutorial17 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.

18. FIRMS-Tutorial18 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.

19. FIRMS-Tutorial19 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.

20. FIRMS-Tutorial20 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.

21. FIRMS-Tutorial21 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.

22. FIRMS-Tutorial22 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.

23. FIRMS-Tutorial23 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();

24. FIRMS-Tutorial24 Creating EPRs A simple EPR reference can be easily created by the code snippet below String address = "http://www.other.example.com/OnStormWarning"; EndpointReferenceType eprType = wsaEprCreator.createEpr(address);

25. FIRMS-Tutorial25 Creating WSA EPRs If one wishes to add ReferenceProperties to the EPR that we just created, the snippet below outlines how it is done. QName qName = new QName("http://www.example.com/warnings", "MySubscription"); wsaEprCreator.addElementToReferenceProperties(eprType, qName, "25");

26. FIRMS-Tutorial26 Part -III Reliable Messaging

27. FIRMS-Tutorial27 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.

28. FIRMS-Tutorial28 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.

29. FIRMS-Tutorial29 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.

30. FIRMS-Tutorial30 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.

31. FIRMS-Tutorial31 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

32. FIRMS-Tutorial32 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.

33. FIRMS-Tutorial33 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)

34. FIRMS-Tutorial34 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.

35. FIRMS-Tutorial35 Part -IV WS-Reliable Messaging

36. FIRMS-Tutorial36 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.

37. FIRMS-Tutorial37 Example Scenario: WSRM Reliable Messaging using WSRM from Endpoint A to Endpoint B

38. FIRMS-Tutorial38 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.

39. FIRMS-Tutorial39 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.

40. FIRMS-Tutorial40 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.

41. FIRMS-Tutorial41 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.

42. FIRMS-Tutorial42 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);

43. FIRMS-Tutorial43 Reliable Messaging Using WSRM – (6) Creation of Source and Sink Processors WsrmSourceNode wsrmSourceNode = new WsrmSourceNode(configInfo); WsrmSinkNode wsrmSinkNode = new WsrmSinkNode(configInfo);

44. FIRMS-Tutorial44 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].

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

46. FIRMS-Tutorial46 Part -V WS-Reliability

47. FIRMS-Tutorial47 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.

48. FIRMS-Tutorial48 Producer Application Consumer Application Source Node Processor Sink Node Processor SubmitDeliver Respond Notify DB

49. FIRMS-Tutorial49 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.

50. FIRMS-Tutorial50 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.

51. FIRMS-Tutorial51 WS-Reliable Messaging Interactions I ( Application ) Source Client Wsr Source Axis WS Wsr Sink Axis WS ( Application ) Wsr Target Service in Axis (5) Payload from Application (4) Message from Sink (2) Message from Source (Poll, Response, Callback) (8) Ack /Fault (Poll, Callback & Reply- Response) (1) Message from Application. (7) Response or Payload from Source (6) Payload from Application DB (9) Poll Response from Sink to Poll Request (3) Poll Request from Wsr Sink If Poll element present. _. _. _ Indicates optional flow of Payload ------ Indicates required flow …….Poll request & response Reply-To?? Web Service

52. FIRMS-Tutorial52 WS-Reliability Messaging Interactions - II When the source receives message from application client, the source initiates messages based on whether it is a ‘response-reply’,‘callback-reply’, and ‘poll-reply’. When the source receives a Payload response form the sink, it will send it to the application. The sink will respond with a ‘response’ for the SOAP message either by sending response, callback or poll reply response. The WSR Sequence monitor will keep track of sent/received messages.

53. FIRMS-Tutorial53 Building WSR based applications The FIRMS software provides a complete implementation of the WS-Reliable Messaging and WS-Reliability specification. All functionality related to the various roles ─ source, sink and application client( Target Service)– have been implemented. Application developers will mostly be focused on the source and sink roles.

54. FIRMS-Tutorial54 Developing the WSR Source Source functionality is accessible through the WsrSourceNode class. Care must be taken to ensure that all incoming and outgoing messages from a node funnel through this class.  Depending on the SOAPMessage and the whether it was received from the application or over the network, this processor deals with exchanges as outlined by the specification.

55. FIRMS-Tutorial55 Capabilities of the WsrSourceNode Manage reliable messages received over the network and application. It can also check this reliable message to see if it is well-formed and conforms to the constraints/rules specified within the WS-Reliability specification.

56. FIRMS-Tutorial56 Developing the WSR Source Development of the application source is a little more involved than on the sink side.  This is because the source is responsible for the generation of several different request types. We however have a class ─ WsrSourceNode ─ which encapsulates the source’s capabilities (as defined in the WS-Reliability specification) and simplifies the generation of requests.  An application source thus need not worry about the generation of well-formed requests since all processing related to this is handled by the SourceNode.

57. FIRMS-Tutorial57 WSR Source: Getting the WsrSourceNode Reference The first step is to get a reference to the WsrSourceNode. The code snippet below outlines how this is done. WsrSourceNode wsrSourceNode = new WsrSourceNode(configInfo);

58. FIRMS-Tutorial58 WSR Source: Summary of Requests Response - Reply : This will send a WS-Reliability SOAP message with the response-reply pattern. Callback-reply : This will send a WS-Reliability SOAP message with the Callback-reply pattern. Poll-reply: This will send a WS-Reliability SOAP message with the Poll request-reply pattern.

59. FIRMS-Tutorial59 WSR Source: Creating a Response–Reply Source EPR: This is the EPR of the source that sink wishes to receive messages from. Sink EPR: This is the EPR of the sink. Response -Reply: The source node will create a SOAP Message with the Response –reply pattern based on whether it is the last message or not.

60. FIRMS-Tutorial60 Code snippet for issuing response reply EndpointReferenceType sourceEpr = wsaEprCreator.createEpr(source); EndpointReferenceType sinkEpr = wsaEprCreator.createEpr(sink); FromDocument from = FromDocument.Factory.newInstance(); from.setFrom(sourceEpr); ActionDocument action = ActionDocument.Factory.newInstance(); action.addNewAction().setStringValue(wsrActions.getProcessRequest()); RelatesToDocument relatesTo = null; EnvelopeDocument envelopeDocument = wsaEnvelopeCreator.createSoapEnvelope(sinkEpr, from, action, relatesTo); if (groupId != null) { QName qName = WsrQNames.getInstance().getGroupId(); boolean added = soapMessageAlteration.addToSoapHeader( envelopeDocument, qName, groupId); } if (replyPattern != null) { QName qName = WsrQNames.getInstance().getRPattern(); boolean added = soapMessageAlteration.addToSoapHeader( envelopeDocument, qName, replyPattern ); } if (replyTo != null) { QName qName = WsrQNames.getInstance().getReplyTo(); boolean added = soapMessageAlteration.addToSoapHeader(envelopeDocument, qName, replyTo); } if (lastMessage != null) { QName qName = WsrQNames.getInstance().getLastMessage(); boolean added = soapMessageAlteration.addToSoapHeader( envelopeDocument, qName, lastMessage); } SOAPMessage soapMessage = null; soapMessage = soapEnvelopeConversion.getSOAPMessage(envelopeDocument);

61. FIRMS-Tutorial61 Example: The Response-reply Request http://docs.oasis-open.org/wsrm/2004/06/ws-reliability- 1.1.xsd/ProcessRequest e94c7a44-4922-467f-bab0-9344652db51a http://156.56.104.46:18080/FIRMS/services/WsrServiceA http://156.56.104.135:18080/FIRMS/services/WsrServiceB 2006-03-01T11:51:53.967-05:00 Response Tracker :1

62. FIRMS-Tutorial62 WSR Source: The Callback-reply Request Source EPR: This is the EPR of the source that sink wishes to receive messages from. Sink EPR: This is the EPR of the sink. Callback -Reply: The source node will create SOAP Message with the Callback–reply pattern with the last message = false or true.

63. FIRMS-Tutorial63 Code snippet for issuing Callback reply EndpointReferenceType sourceEpr = wsaEprCreator.createEpr(source); EndpointReferenceType sinkEpr = wsaEprCreator.createEpr(sink); FromDocument from = FromDocument.Factory.newInstance(); from.setFrom(sourceEpr); ActionDocument action = ActionDocument.Factory.newInstance(); action.addNewAction().setStringValue(wsrActions.getProcessRequest()); RelatesToDocument relatesTo = null; EnvelopeDocument envelopeDocument = wsaEnvelopeCreator.createSoapEnvelope(sinkEpr, from, action, relatesTo); if (groupId != null) { QName qName = WsrQNames.getInstance().getGroupId(); boolean added = soapMessageAlteration.addToSoapHeader( envelopeDocument, qName, groupId); } if (replyPattern != null) { QName qName = WsrQNames.getInstance().getRPattern(); boolean added = soapMessageAlteration.addToSoapHeader( envelopeDocument, qName, replyPattern ); } if (replyTo != null) { QName qName = WsrQNames.getInstance().getReplyTo(); boolean added = soapMessageAlteration.addToSoapHeader(envelopeDocument, qName, replyTo); } if (lastMessage != null) { QName qName = WsrQNames.getInstance().getLastMessage(); boolean added = soapMessageAlteration.addToSoapHeader( envelopeDocument, qName, lastMessage); } SOAPMessage soapMessage = null; soapMessage = soapEnvelopeConversion.getSOAPMessage(envelopeDocument);

64. FIRMS-Tutorial64 Example: The Created Callback-reply Request http://docs.oasis-open.org/wsrm/2004/06/ws-reliability-1.1.xsd/ProcessRequest 8bec45dd-c3f7-49d9-b589-43df954600b9 http://156.56.104.46:18080/FIRMS/services/WsrServiceA http://156.56.104.135:18080/FIRMS/services/WsrServiceB 2006-03-01T12:03:28.150-05:00 Callback Tracker :2

65. FIRMS-Tutorial65 WSR Source: The Poll-reply Request Source EPR: This is the EPR of the source that sink wishes to receive messages from. Sink EPR: This is the EPR of the sink. Poll -Reply: The source node will create a SOAP Message with the Poll –reply pattern with the last message = false or true.

66. FIRMS-Tutorial66 Code snippet for issuing Poll reply EndpointReferenceType sourceEpr = wsaEprCreator.createEpr(source); EndpointReferenceType sinkEpr = wsaEprCreator.createEpr(sink); FromDocument from = FromDocument.Factory.newInstance(); from.setFrom(sourceEpr); ActionDocument action = ActionDocument.Factory.newInstance(); action.addNewAction().setStringValue(wsrActions.getProcessRequest()); RelatesToDocument relatesTo = null; EnvelopeDocument envelopeDocument = wsaEnvelopeCreator.createSoapEnvelope(sinkEpr, from, action, relatesTo); if (groupId != null) { QName qName = WsrQNames.getInstance().getGroupId(); boolean added = soapMessageAlteration.addToSoapHeader( envelopeDocument, qName, groupId); } if (replyPattern != null) { QName qName = WsrQNames.getInstance().getRPattern(); boolean added = soapMessageAlteration.addToSoapHeader( envelopeDocument, qName, replyPattern ); } if (replyTo != null) { QName qName = WsrQNames.getInstance().getReplyTo(); boolean added = soapMessageAlteration.addToSoapHeader(envelopeDocument, qName, replyTo); } if (lastMessage != null) { QName qName = WsrQNames.getInstance().getLastMessage(); boolean added = soapMessageAlteration.addToSoapHeader( envelopeDocument, qName, lastMessage); } SOAPMessage soapMessage = null; soapMessage = soapEnvelopeConversion.getSOAPMessage(envelopeDocument);

67. FIRMS-Tutorial67 Example: The Created Poll-reply Request -I http://docs.oasis-open.org/wsrm/2004/06/ws-reliability-1.1.xsd/ProcessRequest e3b02d0e-3380-4340-8617-e57e764dd05a http://156.56.104.46:18080/FIRMS/services/WsrServiceA http://156.56.104.135:18080/FIRMS/services/WsrServiceB 2006-03-01T12:10:21.596-05:00 Poll Tracker :3

68. FIRMS-Tutorial68 Example: The Created Poll Request -II http://156.56.104.135:18080/FIRMS/services/WsrServiceB http://docs.oasis-open.org/wsrm/2004/06/ws-reliability- 1.1.xsd/ProcessPollRequest 8e95bccf-8431-4947-a08b-585904c1eb64 http://156.56.104.46:18080/FIRMS/services/WsrServiceA dummy

69. FIRMS-Tutorial69 Wsr Source Group Monitor: Message Retransmission This processor processes Groups and determines if (a) Acknowledgements/Retransmissions need to be issued. (b) Checks to see if the Inactivity timeout on a group has expired, if so proceed to terminate the group. The code snippet below depicts the process of issuing a SOAPMessage request. wsrGroupInfoImpl _wsrGroupInfoImpl = wsrGroupInfoStorageOperations.getGroupInfoUsingGroupId(_groupId); boolean messagesAvailable=checkIfMessagesAvailable( _wsrGroupInfoImpl); if (messagesAvailable) { checkToIssueRetransmissions(_wsrGroupInfoImpl); } wsrSourceGroupTerminationImpl.processGroupTermination(_groupId); long[] sequenceNumbersNotAcked = wsrProtocolStorageOperations.getUnacknowledgedSequenceNumbers(groupId); WsrStorageWidgetImpl[] widgetsToRetransmit = wsrProtocolStorageOperations.getStoredElements(groupId, sequenceNumbersNotAcked); EnvelopeDocument retransmitDocument = wsrStorageWidgetImpl.getEnvelope(); enrouteToNetwork(retransmitDocument);

70. FIRMS-Tutorial70 WSR Sink: Development All that a sink needs to do is to ensure that SOAP messages that it generates is funneled through the WsrSinkNode. Depending on the SOAPMessage and whether it was received from the application or over the network, this processor deals with exchanges as outlined by the specification.

71. FIRMS-Tutorial71 WSR Sink: Response Request Once a Sink receives a SOAP Message from the source, it will send the same message to application client (Target Service ) & response back to the Source. If the SOAP Message received from the Source is a poll request, it will send the poll response back to the Source. If the Sink receives a Payload from the Application, it will transmit the same message to the Source.

72. FIRMS-Tutorial72 Example: The created Response Request ……………………………………………………… d7e308ba-d76c-4309-8617-54774f081369 9b3fb76c-feb4-42ac-9d9e-1fbfbdf40fcb http://156.56.104.135:18080/FIRMS/services/WsrmServiceB http://156.56.104.46:18080/FIRMS/services/WsrmServiceA 77d5a23c-ade4-42ab-81f0-be711cdfa051 dummy

73. FIRMS-Tutorial73 WSR Target Service: Payload request Once Target Service (Sink client application) receives a SOAP Message from sink, it may or may not generate a Payload and send it back to the Source. If the Sink receives a Payload from the Application, it will transmit the same message to the Source. EnvelopeDocument envelopeDocument = wsaEnvelopeCreator.createSoapEnvelope(sinkEpr, fromDocument, action, relatesTo); QName qname = new QName("http://www.naradabrokering.org", "Application-Content"); XmlCursor bodyCursor = envelopeDocument.getEnvelope().getBody().newCursor(); tracker++; String value = "PAYLOAD FROM APPLICATION for GroupID:" + groupId + " Sequence Number: "+seqNumber; SOAPMessage soapMessage = soapMessage = soapEnvelopeConversion.getSOAPMessage(envelopeDocument);

74. FIRMS-Tutorial74 Example: The created Payload Request http://docs.oasis-open.org/wsrm/2004/06/ws-reliability- 1.1.xsd/ProcessResponse 24f721f8-7e8e-4509-98a1-3421147c0f71 http://156.56.104.135:18080/FIRMS/services/WsrTS http://156.56.104.46:18080/FIRMS/services/WsrServiceA PAYLOAD FROM APPLICATION for GroupID:7d575f1e-1800-4a28-a1c4- baa501d1751b Sequence Number: 4

75. FIRMS-Tutorial75 Part VI – Deploying FIRMS

76. FIRMS-Tutorial76 FIRMS Deployment within the OMII Container Deploying FIRMS within the OMII container.  Deployment using ant targets.  Deployment using OMII managed programs.  Deployment using WAR file.

77. FIRMS-Tutorial77 Deploy using Ant Targets-Machine 1 Deploy FIRMS on machine one as follows. FIRMS distribution comes with ant build file. Use ant build-all command from stage directory. Ant build-all command will create dist folder. Set the build properties in build.properties file. From dist/server folder, issue >ant deploy-firms command. It will install FIRMS on to OMII container. Deploy WS-RM & WS-R web services using ant.  SoapMonitor: >ant deploy-soapmonitor  Wsrm-ServiceA:>ant deploy-serviceA  Wsr-ServiceA: > ant deploy-wsrserviceA  Wsr-Target Service: >ant deploy-wsrts

78. FIRMS-Tutorial78 Deploy using Ant Targets-Machine2 Deploy FIRMS on Machine two as follows. FIRMS distribution comes with ant build file. Use ant build-all command from stage directory. Ant build-all command will create dist folder. Set the build properties in build.properties file. From dist/server folder, issue >ant deploy-firms command. It will install FIRMS on to OMII container. Deploy WS-RM & WS-R web services using ant.  SoapMonitor: >ant deploy-soapmonitor  Wsrm-ServiceB:>ant deploy-serviceB  Wsr-ServiceB: > ant deploy-wsrserviceB  Wsr-Target Service: >ant deploy-wsrts

79. FIRMS-Tutorial79 Deploy using Ant Targets Deploy SoapMonitor  Deploying soapmonitor using ant script with wsdd file and axis AdminService.

80. FIRMS-Tutorial80 Deploy using Ant Targets Test SoapMonitor  Testing deployed soapmonitor using ant script with wsdd file and axis AdminService.

81. FIRMS-Tutorial81 Deploy using Ant Targets Deploy Wsrm ServiceA  Deploying WS-RM ServiceA using ant script with wsdd file and axis AdminService

82. FIRMS-Tutorial82 Deploy using Ant Targets Deploy Wsr ServiceA  Deploying WS-R ServiceA using ant script with wsdd file and axis AdminService

83. FIRMS-Tutorial83 Deploy using Ant Targets Deploy Wsr Target Service  Deploying WS-R Target Service using ant script with wsdd file and axis AdminService

84. FIRMS-Tutorial84 Deploy using OMII managed programs You have to download the OMII container ( Client and Server from the OMII website). Use ant build-all command from FIRMS staged directory, it will create FIRMS client & server distribution in ‘dist’ folder. Place FIRMS-server.tgz file from the ‘dist’ folder into the OMII server/managed programs folder. Use the OMII stack installer to install the managed programs. It will deploy FIRMS into the OMII container. Place FIRMS-client.zip file into OMII client/manage programs folder. Use OMII managed programs client install to install FIRMS client.

85. FIRMS-Tutorial85 Deploy using OMII managed programs Installing FIRMS Client using managed programs. Place FIRMS-client.zip in the managed program directory. Using OMIImanagedProgrammeClientInstall.sh command from client managed program directory.

86. FIRMS-Tutorial86 Deploy using OMII managed programs Installing FIRMS Server using managed programs. Place FIRMS-server.tgz file in server managed programme folder. Using OMIIstackInstall.pl command from server directory with option 6.

87. FIRMS-Tutorial87 Deploy using FIRMS WAR file Firms WAR file is available in /FIRMS-1.0.0/dist/server/ directory. Use Tomcat manager tool to deploy FIRMS as a separate web application. Tomcat manager is at http://localhost:18080/manager/htmlhttp://localhost:18080/manager/html

88. FIRMS-Tutorial88 Part VII – Running FIRMS within the OMII Container

89. FIRMS-Tutorial89 Running FIRMS within the OMII Container Running FIRMS within the OMII container as follows. 1.Running using Terminal client ANT commands. 2.Running using Frames within the Terminal Output will be displayed in the SOAPMonitor Applet in The web browser.

90. FIRMS-Tutorial90 Deployed FIRMS web services in OMII Deployed FIRMS web services can be viewed at the following URL on Machine one. http:// :18080/axis/servlet/AxisServlet http://<localhost- MachineOne>:18080/axis/servlet/AxisServlet

91. FIRMS-Tutorial91 Deployed FIRMS web services in OMII Deployed FIRMS web services can be viewed at the following URL on Machine two. http:// :18080/axis/servlet/AxisServlet http://<localhost- MachineTwo>:18080/axis/servlet/AxisServlet

92. FIRMS-Tutorial92 Running using Terminal client ant commands-WSRM From FIRMS client within OMII client directory, issue >ant run-sampleclient command.

93. FIRMS-Tutorial93 Running using Terminal client ant commands-WSR From FIRMS client within OMII client directory, issue >ant run-sourceclient command.

94. FIRMS-Tutorial94 Running using Frames within Terminal From FIRMS client within OMII client directory, issue >ant run-sourceclientframe command.

95. FIRMS-Tutorial95 SOAPMonitor Applet All SOAPMessage are exchanged through the SOAPMonitor Applet as follows.

96. FIRMS-Tutorial96 FIRMS Tutorial: Summary Provided an overview of WS-* specification principles Use of FIRMS’ WSRM and WSR for reliable messaging Deployment of FIRMS within the OMII container Running sample FIRMS applications within the OMII Container