1 firms tutorial leveraging wsrm and wsr community grids lab, indiana university
TRANSCRIPT
1
FIRMS TUTORIALLeveraging WSRM and WSR
Community Grids Lab,Indiana University
FIRMS-Tutorial 2
FIRMS Tutorial: OutlineSome Observations about WS-*
specifications WS-AddressingReliable Messaging OverviewWS-Reliable MessagingWS-ReliabilityDeploying FIRMS Running FIRMS within the OMII
Container
FIRMS-Tutorial 3
Part I – Some Observations about WS-* specifications
FIRMS-Tutorial 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.
FIRMS-Tutorial 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.
FIRMS-Tutorial 6
WS-*
WS-Eventing
WS-RM
WS-Security
SOAP Rules
WS-Addressing
WS-Policy
XML Schema
FIRMS-Tutorial 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.
FIRMS-Tutorial 8
Processing XML Schemas We were looking for a solution that
allowed us to process XML from within the Java domain.
There are 4 choicesDevelop Java classes ourselvesUse wsdl2java to do thisUse the JAXB Data Binding FrameworkUse a schema compiler such as Castor or
XMLBeans
FIRMS-Tutorial 9
Writing one’s own classesApproach used by Apache’s Sandesha
project.Implementation of WSRM
Error prone and quite difficultIncreasingly 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.
FIRMS-Tutorial 10
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.
FIRMS-Tutorial 11
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).
FIRMS-Tutorial 12
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.
FIRMS-Tutorial 13
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 MessagesDirection 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.
FIRMS-Tutorial 14
PART – IIWS-Addressing
FIRMS-Tutorial 15
WS-AddressingWeb 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-* specificationsWS-ReliableMessaging, WS-Reliability and
WS-Notification.
FIRMS-Tutorial 16
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
FIRMS-Tutorial 17
EPRs – StructureAn address element which is a URIA 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.
FIRMS-Tutorial 18
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.
FIRMS-Tutorial 19
Message Information Headers - IITo (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.
FIRMS-Tutorial 20
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.
FIRMS-Tutorial 21
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.
FIRMS-Tutorial 22
WSA RulesWSA 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.
FIRMS-Tutorial 23
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();
FIRMS-Tutorial 24
Creating EPRsA 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);
FIRMS-Tutorial 25
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");
FIRMS-Tutorial 26
Part -III Reliable Messaging
FIRMS-Tutorial 27
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.
FIRMS-Tutorial 28
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.
FIRMS-Tutorial 29
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.
FIRMS-Tutorial 30
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.
FIRMS-Tutorial 31
General Reliable Messaging AssurancesAt-Least-Once: Guaranteed message
deliveryAt-Most-Once: Guaranteed message
duplicate elimination Exactly-Once: Guaranteed message
delivery and duplicate eliminationGuaranteed Message Ordering within a
group of the messages
FIRMS-Tutorial 32
WS-Reliable MessagingSpecification from IBM, and MicrosoftLeverages 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.
FIRMS-Tutorial 33
WS-ReliabilitySpecification from Fujitsu, Oracle, and SunProvides support for positive
acknowledgements.Provides support for a variety of message-
exchange patterns.Request/Response, One-way, Polling
Delivery assurance mode supportedUnreliable, at-least-once, ordered-and-exactly-
once Is currently an OASIS standard.
(Note WS-Security is also an OASIS standard)
FIRMS-Tutorial 34
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.
FIRMS-Tutorial 35
Part -IV WS-Reliable Messaging
FIRMS-Tutorial 36
Enabling reliable messaging using WSRMAll 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.
FIRMS-Tutorial 37
Example Scenario: WSRM
Endpoint A
Application
WSRM Source Processor
Endpoint B
Application
WSRM Sink Processor
Endpoints hosted within a container
Reliable Communications fromEndpoint A to Endpoint B
Reliable Messaging using WSRM from Endpoint A to Endpoint B
FIRMS-Tutorial 38
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.
FIRMS-Tutorial 39
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.
FIRMS-Tutorial 40
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.
FIRMS-Tutorial 41
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.
FIRMS-Tutorial 42
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);
FIRMS-Tutorial 43
Reliable Messaging Using WSRM – (6)Creation of Source and Sink Processors
WsrmSourceNode wsrmSourceNode = new WsrmSourceNode(configInfo);
WsrmSinkNode wsrmSinkNode = new WsrmSinkNode(configInfo);
FIRMS-Tutorial 44
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].
FIRMS-Tutorial 45
WS-Reliable Messaging Interactions I
Application Source Client
Wsrm Source Axis
WS
Wsrm Sink Axis WS
(1) Create Sequence / Reliable Message
DBDB
(2) Sequence Response/ Acknowledgment
Application Sink Client
FIRMS-Tutorial 46
Part -V WS-Reliability
FIRMS-Tutorial 47
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.
FIRMS-Tutorial 48
Producer Application
Consumer Application
Source Node Processor
Sink Node Processor
Submit DeliverRespond
Notify
DB DB
FIRMS-Tutorial 49
Routing WS-Reliability Message from SourceA 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.
FIRMS-Tutorial 50
WS-ReliabilityWS-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.
FIRMS-Tutorial 51
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
DBDB
(9) Poll Response from Sink to Poll Request
(3) Poll Request from Wsr SinkIf Poll element present.
_ . _ . _ Indicates optional flow of Payload
------ Indicates required flow…….Poll request & response
Reply-To??Web Service
FIRMS-Tutorial 52
WS-Reliability Messaging Interactions - IIWhen 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.
FIRMS-Tutorial 53
Building WSR based applicationsThe 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.
FIRMS-Tutorial 54
Developing the WSR SourceSource 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.
FIRMS-Tutorial 55
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.
FIRMS-Tutorial 56
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.
FIRMS-Tutorial 57
WSR Source: Getting the WsrSourceNode ReferenceThe first step is to get a reference to the
WsrSourceNode. The code snippet below outlines how this is done.
WsrSourceNode wsrSourceNode = new WsrSourceNode(configInfo);
FIRMS-Tutorial 58
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.
FIRMS-Tutorial 59
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.
FIRMS-Tutorial 60
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);
FIRMS-Tutorial 61
Example: The Response-reply Request<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:add="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:nar="http://www.naradabrokering.org" xmlns:wsr="http://docs.oasis-open.org/wsrm/2004/06/ws-reliability-1.1.xsd/wsrext" xmlns:ws="http://docs.oasis-open.org/wsrm/2004/06/ws-reliability-1.1.xsd"> <Header> <add:Action>http://docs.oasis-open.org/wsrm/2004/06/ws-reliability-1.1.xsd/ProcessRequest</add:Action> <add:MessageID>e94c7a44-4922-467f-bab0-9344652db51a</add:MessageID> <add:From> <add:Address>http://156.56.104.46:18080/FIRMS/services/WsrServiceA</add:Address> </add:From> <add:To>http://156.56.104.135:18080/FIRMS/services/WsrServiceB</add:To> <ws:Request> <ws:MessageId groupId="7d575f1e-1800-4a28-a1c4-baa501d1751b"> <ws:SequenceNum last="false" number="0" groupExpiryTime="2006-04-01T11:51:53.965-05:00"/> </ws:MessageId> <ws:ExpiryTime>2006-03-01T11:51:53.967-05:00</ws:ExpiryTime> <ws:ReplyPattern> <ws:Value>Response</ws:Value> </ws:ReplyPattern> <ws:AckRequested/> <ws:DuplicateElimination/> <ws:MessageOrder/> </ws:Request> </Header> <Body wsu:Id="id-29656818" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"> <nar:Application-Content>Tracker :1</nar:Application-Content> </Body></Envelope>
FIRMS-Tutorial 62
WSR Source: The Callback-reply RequestSource 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.
FIRMS-Tutorial 63
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);
FIRMS-Tutorial 64
Example: The Created Callback-reply Request
<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/" xmlns:add="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:nar="http://www.naradabrokering.org" xmlns:wsr="http://docs.oasis-open.org/wsrm/2004/06/ws-reliability-1.1.xsd/wsrext" xmlns:ws="http://docs.oasis-open.org/wsrm/2004/06/ws-reliability-1.1.xsd"> <Header> <add:Action>http://docs.oasis-open.org/wsrm/2004/06/ws-reliability-1.1.xsd/ProcessRequest</add:Action> <add:MessageID>8bec45dd-c3f7-49d9-b589-43df954600b9</add:MessageID> <add:From> <add:Address>http://156.56.104.46:18080/FIRMS/services/WsrServiceA</add:Address> </add:From> <add:To>http://156.56.104.135:18080/FIRMS/services/WsrServiceB</add:To> <ws:Request> <ws:MessageId groupId="7d575f1e-1800-4a28-a1c4-baa501d1751b"> <ws:SequenceNum last="false" number="1" groupExpiryTime="2006-04-01T11:51:53.107-05:00"/> </ws:MessageId> <ws:ExpiryTime>2006-03-01T12:03:28.150-05:00</ws:ExpiryTime> <ws:ReplyPattern> <ws:Value>Callback</ws:Value> <ws:ReplyTo reference-scheme="http://156.56.104.46:18080/FIRMS/services/WsrServiceA"/> </ws:ReplyPattern> <ws:AckRequested/> <ws:DuplicateElimination/> <ws:MessageOrder/> </ws:Request> </Header> <Body wsu:Id="id-26873835" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"> <nar:Application-Content>Tracker :2</nar:Application-Content> </Body></Envelope>
FIRMS-Tutorial 65
WSR Source: The Poll-reply RequestSource 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.
FIRMS-Tutorial 66
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);
FIRMS-Tutorial 67
Example: The Created Poll-reply Request -I
<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/" xmlns:add="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:nar="http://www.naradabrokering.org" xmlns:wsr="http://docs.oasis-open.org/wsrm/2004/06/ws-reliability-1.1.xsd/wsrext" xmlns:ws="http://docs.oasis-open.org/wsrm/2004/06/ws-reliability-1.1.xsd"> <Header> <add:Action>http://docs.oasis-open.org/wsrm/2004/06/ws-reliability-1.1.xsd/ProcessRequest</add:Action> <add:MessageID>e3b02d0e-3380-4340-8617-e57e764dd05a</add:MessageID> <add:From> <add:Address>http://156.56.104.46:18080/FIRMS/services/WsrServiceA</add:Address> </add:From> <add:To>http://156.56.104.135:18080/FIRMS/services/WsrServiceB</add:To> <ws:Request> <ws:MessageId groupId="7d575f1e-1800-4a28-a1c4-baa501d1751b"> <ws:SequenceNum last="false" number="2" groupExpiryTime="2006-04-01T11:51:53.595-05:00"/> </ws:MessageId> <ws:ExpiryTime>2006-03-01T12:10:21.596-05:00</ws:ExpiryTime> <ws:ReplyPattern> <ws:Value>Poll</ws:Value> </ws:ReplyPattern> <ws:AckRequested/> <ws:DuplicateElimination/> <ws:MessageOrder/> </ws:Request> </Header> <Body wsu:Id="id-12617107" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"> <nar:Application-Content>Tracker :3</nar:Application-Content> </Body></Envelope>
FIRMS-Tutorial 68
Example: The Created Poll Request -II
<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/" xmlns:add="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:ws="http://docs.oasis-open.org/wsrm/2004/06/ws-reliability-1.1.xsd"> <Header> <add:To xmlns="http://schemas.xmlsoap.org/soap/envelope/" xmlns:nar="http://www.naradabrokering.org" xmlns:wsr="http://docs.oasis-open.org/wsrm/2004/06/ws-reliability-1.1.xsd/wsrext">http://156.56.104.135:18080/FIRMS/services/WsrServiceB</add:To> <add:Action>http://docs.oasis-open.org/wsrm/2004/06/ws-reliability-1.1.xsd/ProcessPollRequest</add:Action> <add:MessageID>8e95bccf-8431-4947-a08b-585904c1eb64</add:MessageID> <add:From> <add:Address>http://156.56.104.46:18080/FIRMS/services/WsrServiceA</add:Address> </add:From> <ws:PollRequest> <ws:RefToMessageIds groupId="7d575f1e-1800-4a28-a1c4-baa501d1751b"> <ws:SequenceNumRange from="2" to="2"/> </ws:RefToMessageIds> <ws:ReplyTo reference-cheme="http://156.56.104.46:18080/FIRMS/services/WsrServiceA"/> </ws:PollRequest> </Header><Body><nar:dummy xmlns:nar="http://www.naradabrokering.org">dummy</nar:dummy></Body></Envelope>
FIRMS-Tutorial 69
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);
FIRMS-Tutorial 70
WSR Sink: DevelopmentAll 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.
FIRMS-Tutorial 71
WSR Sink: Response RequestOnce 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.
FIRMS-Tutorial 72
Example: The created Response Request<?xml version="1.0" encoding="UTF-8"?><Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/" xmlns:add="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:rm="http://schemas.xmlsoap.org/ws/2004/03/rm" xmlns:util="http://schemas.xmlsoap.org/ws/2002/07/utility"> <Header><wsse:Security mustUnderstand="1“ xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">………………………………………………………</wsse:Security> <add:RelatesTo>d7e308ba-d76c-4309-8617-54774f081369</add:RelatesTo> <add:MessageID>9b3fb76c-feb4-42ac-9d9e-1fbfbdf40fcb</add:MessageID> <add:From> <add:Address>http://156.56.104.135:18080/FIRMS/services/WsrmServiceB</add:Address> </add:From> <add:To>http://156.56.104.46:18080/FIRMS/services/WsrmServiceA</add:To> <rm:SequenceAcknowledgement> <util:Identifier>77d5a23c-ade4-42ab-81f0-be711cdfa051</util:Identifier> <rm:AcknowledgementRange Lower="1" Upper="1"/> </rm:SequenceAcknowledgement> </Header> <Body wsu:Id="id-17126955" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"><nar:dummy xmlns:nar="http://www.naradabrokering.org">dummy</nar:dummy></Body></Envelope>
FIRMS-Tutorial 73
WSR Target Service: Payload requestOnce 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);
FIRMS-Tutorial 74
Example: The created Payload Request <Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/" xmlns:add="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:nar="http://www.naradabrokering.org"> <Header> <add:Action>http://docs.oasis-open.org/wsrm/2004/06/ws-reliability-1.1.xsd/ProcessResponse</add:Action> <add:MessageID>24f721f8-7e8e-4509-98a1-3421147c0f71</add:MessageID> <add:From> <add:Address>http://156.56.104.135:18080/FIRMS/services/WsrTS</add:Address> </add:From> <add:To>http://156.56.104.46:18080/FIRMS/services/WsrServiceA</add:To> </Header> <Body wsu:Id="id-1797462" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"> <nar:Application-Content> PAYLOAD FROM APPLICATION for GroupID:7d575f1e-1800-4a28-a1c4-baa501d1751b Sequence Number: 4</nar:Application-Content> </Body></Envelope>
FIRMS-Tutorial 75
Part VI – Deploying FIRMS
FIRMS-Tutorial 76
FIRMS Deployment within the OMII ContainerDeploying FIRMS within the OMII
container.Deployment using ant targets.Deployment using OMII managed programs.Deployment using WAR file.
FIRMS-Tutorial 77
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
FIRMS-Tutorial 78
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
FIRMS-Tutorial 79
Deploy using Ant TargetsDeploy SoapMonitor
Deploying soapmonitor using ant script with wsdd file and axis AdminService.
FIRMS-Tutorial 80
Deploy using Ant TargetsTest SoapMonitor
Testing deployed soapmonitor using ant script with wsdd file and axis AdminService.
FIRMS-Tutorial 81
Deploy using Ant TargetsDeploy Wsrm ServiceA
Deploying WS-RM ServiceA using ant script with wsdd file and axis AdminService
FIRMS-Tutorial 82
Deploy using Ant TargetsDeploy Wsr ServiceA
Deploying WS-R ServiceA using ant script with wsdd file and axis AdminService
FIRMS-Tutorial 83
Deploy using Ant TargetsDeploy Wsr Target Service
Deploying WS-R Target Service using ant script with wsdd file and axis AdminService
FIRMS-Tutorial 84
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.
FIRMS-Tutorial 85
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.
FIRMS-Tutorial 86
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.
FIRMS-Tutorial 87
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/html
FIRMS-Tutorial 88
Part VII – Running FIRMS within the OMII Container
FIRMS-Tutorial 89
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.
FIRMS-Tutorial 90
Deployed FIRMS web services in OMIIDeployed FIRMS web services can be
viewed at the following URL on Machine one. http://<localhost-MachineOne>:18080/axis/servlet/AxisServlet
FIRMS-Tutorial 91
Deployed FIRMS web services in OMIIDeployed FIRMS web services can be
viewed at the following URL on Machine two. http://<localhost-MachineTwo>:18080/axis/servlet/AxisServlet
FIRMS-Tutorial 92
Running using Terminal client ant commands-WSRMFrom FIRMS client within OMII client
directory, issue >ant run-sampleclient command.
FIRMS-Tutorial 93
Running using Terminal client ant commands-WSRFrom FIRMS client within OMII client
directory, issue >ant run-sourceclient command.
FIRMS-Tutorial 94
Running using Frames within TerminalFrom FIRMS client within OMII client
directory, issue >ant run-sourceclientframe command.
FIRMS-Tutorial 95
SOAPMonitor AppletAll SOAPMessage are exchanged
through the SOAPMonitor Applet as follows.
FIRMS-Tutorial 96
FIRMS Tutorial: SummaryProvided an overview of WS-*
specification principlesUse of FIRMS’ WSRM and WSR for
reliable messagingDeployment of FIRMS within the OMII
containerRunning sample FIRMS applications
within the OMII Container