Transcript FIRMS TUTORIAL Leveraging WSRM and WSR Community Grids Lab, Indiana University FIRMS Tutorial: Outline  Some Observations about WS-* specifications  WS-Addressing  Reliable Messaging Overview 

FIRMS TUTORIAL
Leveraging WSRM and WSR
Community Grids Lab,
Indiana University
1
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
FIRMS-Tutorial
2
Part I – Some Observations
about WS-* specifications
FIRMS-Tutorial
3
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
4
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
5
XML Schema
WS-*
SOAP Rules
WS-Eventing
WS-Addressing
WS-RM
WS-Policy
WS-Security
FIRMS-Tutorial
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.
FIRMS-Tutorial
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
FIRMS-Tutorial
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.
FIRMS-Tutorial
9
WSDL2Java Problems
 Issues (in version 1.2) related to this tool’s support
for schemas have been documented in http://www106.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
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).
FIRMS-Tutorial
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.
FIRMS-Tutorial
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.
FIRMS-Tutorial
13
PART – II
WS-Addressing
FIRMS-Tutorial
14
WS-Addressing
 Web Services Addressing (WSA) provides transportneutral 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.
FIRMS-Tutorial
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
FIRMS-Tutorial
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.
FIRMS-Tutorial
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.
FIRMS-Tutorial
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.
FIRMS-Tutorial
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.
FIRMS-Tutorial
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.
FIRMS-Tutorial
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.
FIRMS-Tutorial
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();
FIRMS-Tutorial
23
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);
FIRMS-Tutorial
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.
QName qName =
new QName("http://www.example.com/warnings",
"MySubscription");
wsaEprCreator.addElementToReferenceProperties(eprType, qName,
"25");
FIRMS-Tutorial
25
Part -III
Reliable Messaging
FIRMS-Tutorial
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 exactlyonce.
May delegate complexity of guarantees to the protocol
implementation.
FIRMS-Tutorial
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.
FIRMS-Tutorial
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.
FIRMS-Tutorial
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.
FIRMS-Tutorial
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
FIRMS-Tutorial
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-leastonce, at-most-once, exactly-once, and ordered
delivery.
FIRMS-Tutorial
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)
FIRMS-Tutorial
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 WSSecurity, 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
34
Part -IV
WS-Reliable Messaging
FIRMS-Tutorial
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.
FIRMS-Tutorial
36
Example Scenario: WSRM
Endpoints
hosted within a
container
Endpoint A
Endpoint B
Application
Application
WSRM Source
Processor
WSRM Sink
Processor
Reliable Communications from
Endpoint A to Endpoint B
Reliable Messaging using WSRM from Endpoint A to Endpoint B
FIRMS-Tutorial
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 sinkprocessor 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
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.
FIRMS-Tutorial
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 sinkendpoint 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 sourceprocessor at A increments the message number by 1. This message number is
also included along with the Sequence information.
FIRMS-Tutorial
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 sinkprocessor 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
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);
FIRMS-Tutorial
42
Reliable Messaging Using WSRM – (6)
Creation of Source and Sink Processors
WsrmSourceNode wsrmSourceNode = new WsrmSourceNode(configInfo);
WsrmSinkNode wsrmSinkNode = new WsrmSinkNode(configInfo);
FIRMS-Tutorial
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].
FIRMS-Tutorial
44
WS-Reliable Messaging Interactions I
Application
Source Client
DB
Wsrm
Source Axis
WS
Application
Sink Client
Wsrm Sink
Axis WS
DB
(1) Create Sequence /
Reliable Message
(2) Sequence Response/
Acknowledgment
FIRMS-Tutorial
45
Part -V
WS-Reliability
FIRMS-Tutorial
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.
FIRMS-Tutorial
47
Producer
Application
Consumer
Application
Notify
Submit
Deliver
Respond
DB
FIRMS-Tutorial
Source Node
Processor
Sink Node
Processor
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.
FIRMS-Tutorial
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.
FIRMS-Tutorial
50
WS-Reliable Messaging Interactions I
( Application )
Wsr Target Service
in Axis
( Application )
Source Client
(1) Message from
Application.
(7) Response or
Payload
from
Source
(5) Payload from
Application
(4) Message from Sink
(6) Payload from Application
DB
Wsr Source Axis
WS
(8) Ack /Fault (Poll, Callback & ReplyResponse)
Wsr Sink Axis
WS
(2) Message from Source
(Poll, Response, Callback)
(9) Poll Response from Sink to
Poll Request
(3) Poll Request from Wsr Sink
If Poll element present.
FIRMS-Tutorial
DB
Reply-To??
Web Service
_ . _ . _ Indicates optional flow of
Payload
------ Indicates required flow
…….Poll request & response
51
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.
FIRMS-Tutorial
52
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.
FIRMS-Tutorial
53
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.
FIRMS-Tutorial
54
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
55
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
56
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);
FIRMS-Tutorial
57
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
58
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
59
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
60
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.oasisopen.org/wsrm/2004/06/ws-reliability-1.1.xsd/wsrext" xmlns:ws="http://docs.oasisopen.org/wsrm/2004/06/ws-reliability-1.1.xsd">
<Header> <add:Action>http://docs.oasis-open.org/wsrm/2004/06/ws-reliability1.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-wsswssecurity-utility-1.0.xsd"> <nar:Application-Content>Tracker :1</nar:Application-Content>
</Body></Envelope>
FIRMS-Tutorial
61
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.
FIRMS-Tutorial
62
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
63
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/wsreliability-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-wsswssecurity-utility-1.0.xsd">
<nar:Application-Content>Tracker :2</nar:Application-Content>
</Body>
</Envelope>
FIRMS-Tutorial
64
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.
FIRMS-Tutorial
65
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
66
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/wsreliability-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-wsswssecurity-utility-1.0.xsd"> <nar:Application-Content>Tracker :3</nar:Application-Content>
</Body>
</Envelope>
FIRMS-Tutorial
67
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.oasisopen.org/wsrm/2004/06/ws-reliability1.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-reliability1.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
68
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
69
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.
FIRMS-Tutorial
70
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.
FIRMS-Tutorial
71
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-200401wss-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-wsswssecurity-utility-1.0.xsd"><nar:dummy
xmlns:nar="http://www.naradabrokering.org">dummy</nar:dummy></Body>
</Envelope>
FIRMS-Tutorial
72
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);
FIRMS-Tutorial
73
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-reliability1.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-wsswssecurity-utility-1.0.xsd">
<nar:Application-Content> PAYLOAD FROM APPLICATION for GroupID:7d575f1e-1800-4a28-a1c4baa501d1751b Sequence Number: 4</nar:Application-Content>
</Body>
</Envelope>
FIRMS-Tutorial
74
Part VI – Deploying FIRMS
FIRMS-Tutorial
75
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.
FIRMS-Tutorial
76
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:
Wsrm-ServiceA:
Wsr-ServiceA:
Wsr-Target Service:
FIRMS-Tutorial
>ant deploy-soapmonitor
>ant deploy-serviceA
> ant deploy-wsrserviceA
>ant deploy-wsrts
77
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:
Wsrm-ServiceB:
Wsr-ServiceB:
Wsr-Target Service:
FIRMS-Tutorial
>ant deploy-soapmonitor
>ant deploy-serviceB
> ant deploy-wsrserviceB
>ant deploy-wsrts
78
Deploy using Ant Targets
 Deploy SoapMonitor
Deploying soapmonitor using ant script with wsdd file and
axis AdminService.
FIRMS-Tutorial
79
Deploy using Ant Targets
 Test SoapMonitor
Testing deployed soapmonitor using ant script with wsdd
file and axis AdminService.
FIRMS-Tutorial
80
Deploy using Ant Targets
 Deploy Wsrm ServiceA
Deploying WS-RM ServiceA using ant script with wsdd file
and axis AdminService
FIRMS-Tutorial
81
Deploy using Ant Targets
 Deploy Wsr ServiceA
Deploying WS-R ServiceA using ant script with wsdd file
and axis AdminService
FIRMS-Tutorial
82
Deploy using Ant Targets
 Deploy Wsr Target Service
Deploying WS-R Target Service using ant script with wsdd
file and axis AdminService
FIRMS-Tutorial
83
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
84
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
85
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
86
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
87
Part VII – Running FIRMS
within the OMII Container
FIRMS-Tutorial
88
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
89
Deployed FIRMS web services in OMII
 Deployed FIRMS web services can be viewed at the
following URL on Machine one. http://<localhostMachineOne>:18080/axis/servlet/AxisServlet
FIRMS-Tutorial
90
Deployed FIRMS web services in OMII
 Deployed FIRMS web services can be viewed at the
following URL on Machine two. http://<localhostMachineTwo>:18080/axis/servlet/AxisServlet
FIRMS-Tutorial
91
Running using Terminal client ant
commands-WSRM
 From FIRMS client within OMII client directory,
issue >ant run-sampleclient command.
FIRMS-Tutorial
92
Running using Terminal client ant
commands-WSR
 From FIRMS client within OMII client directory,
issue >ant run-sourceclient command.
FIRMS-Tutorial
93
Running using Frames within Terminal
 From FIRMS client within OMII client directory,
issue >ant run-sourceclientframe command.
FIRMS-Tutorial
94
SOAPMonitor Applet
 All SOAPMessage are exchanged through the
SOAPMonitor Applet as follows.
FIRMS-Tutorial
95
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
FIRMS-Tutorial
96