Running WSE within the
OMII Container
Community Grids Lab,
This
document provides instructions and results pertaining to the Ws-Eventing
software testing within the OMII1.2 container. We have tested this software using
Red Hat Enterprise Linux (WS) version 4.0.
We now list the
directories relevant to this demo. The variable names here are
self-descriptive.
OMII HOME: /usr/local/OMII OMII TOMCAT HOME: <omii_home>/jakarta-tomcat-5.0.25 OMII AXIS HOME: <omii_home>/axis-1_2beta WSE Base (distribution) Directory: <omii_home>/webservices/wse WSE Client Directory: <omii_home>/webservices/wse/dist/client WSE Server Directory: <omii_home>/webservices/wse/dist/server Step 1: Install Base and extensions,
services and client software available within the OMII1.2 container. There are
excellent instructions related to this within the OMII containers
documentation.
Step 2: We have deployed the Ws-Eventing web services (WseSink, WseSource, WseSM) and SOAPMonitor service within the Tomcat running on port 18080 within the OMII container using our distribution's ant target commands. Here we note that this port number could be any number < 64000 and is under the users control. For information pertaining to the deployment of the aforementioned services please refer to the FINS-Deployment of WSE within OMII file located under the docs/installation folder.
The user
also needs to change the port numbers in the services.properties file
located under the config/wse folder at
both Tomcat and client. This can be achieved by following the instructions
below.
1) Open the services.properties file located under the OMII TOMCAT HOME(/usr/local/OMII/Jakarta-tomcat-5.0.25)/classes/config/wse/ folder and
replace the port numbers with your tomcat port number.
2) Open the services.properties file located
under the WSE Client directory (/usr/local/OMII/webservices/wse/dist/client)/config/wse/
folder and change the port number.
The Figure
1 below depicts the result of this operation on our
machine where we have changed the port number to 18080.
Figure 1 Service.properties file
Step 3: Restart
the Tomcat server.
Step 4: The user then needs to use the cd shell command to
enter the WSE Client Directory (/usr/local/OMII/webservices/wse/dist/client). Next the
user needs to execute the ANT target command ant wseaxis-sink to run the sink client as depicted in Figure 2 below.
Figure 2 Sink Client
Step 5: The user
can then type h to list all the
available options for the sink client as depicted in Figure 3 below
Figure 3 List of Commands at Sink Client
Step 6: The user
can issue a WS-Eventing Subscription request by typing sub t or sub r
or sub x where t, r and x- correspond to
Topics, Regular Expression and XPath Query based subscription formats
respectively.
Users can check the status
of their subscription by typing status
Users can renew their
subscription by typing renew
User can unsubscribe
by typing unsub
In our demo we will
be issuing a topic subscription to the source by typing sub t. When a user does this the Sink Client
creates a well-formed WS-Eventing Subscribe request and sends it to the Sink
Web Service.
Figure 4 Subscription Request sent by Sink Client to Sink Web Service
Form the figure it
can been seen that the WS-Addressing wsa:To element indicates that the
subscription request originated from the Sink and is targeted to the source.
The subscription is topic based ─ /Literature/Shakespere. Any notifications
from the source will go directly to the address encapsulated within the <wsa:notifyTo>
element.
Step 7: The communication between WseSink, WseSource and WseSM web service can be seen in the Catalina.out file available under the (/usr/local/OMII/jakarta-tomcat-5.0.25/logs) folder. Open the file Catalina.out.
This SOAP
message sent by the sink client first goes to the sink web service. Figure 5 depicts the message received by the Sink Web Service
from the Sink Client.
Figure 5 Subscription Request received by Sink Web
Service from Sink Client
Step 8:
Upon
receipt of this subscription request, the source issues a SubscribeResponse
back to the sink. This response contains the subscription identifier generated
by the source to uniquely represent the subscription. This UUID-base
subscription identifier is necessary for all exchanges (renew, status and
unsubscribe) pertaining to the aforementioned subscription. Figure 6 depicts the SubscribeResponse received by the Sink Web Service from the Source Web Service.
The Subscription ID contained within this response is 4953fa05-eba0-4bdf-8679-b8483a3d111b.
Figure 6 Subscription Response received by Sink Web
Service from Source Web Service
Step 9: At the same
time, Source Web Service also sends the Subscription SOAP message to the
Subscription Manager. This message contains both the original subscription
request from the sink along with the response issued by the source. Figure 7 depicts the SOAP message sent by the Source web Service to the Subscription
Manager Service.
Figure 7 Subscription Request and Response received
by Subscription Manager Web Service
Step 10: The user can
check the status of the subscription by typing status
<subscriptionID>.
E.g. status
4953fa05-eba0-4bdf-8679-b8483a3d111b
Figure 8 depicts the status request sent by the Sink Client
Service to the Sink Web Service for subscription ID 4953fa05-eba0-4bdf-8679-b8483a3d111b
Figure 8 Status Request sent by Sink Client Service
to Sink Web Service
Step 11: This status
request is then routed to the Subscription Manager Web Service. Figure 9 depicts the Status Request received by the Subscription
Manager Web Service for SubscriptionID = 4953fa05-eba0-4bdf-8679-b8483a3d111b
Figure 9 Status Request received by Subscription
Manager Web Service
Step 12: The Subscription
Manger the proceeds to generate a status response and sends it back to the sink.
Figure 10 depicts the status response received by the Sink Web
Service from the Subscription Manger Web Service. The status response displays
the time at which the subscription is going to expire.
Figure 10 Status Response Received by Sink Web
Service
Step 13: Users can
renew the subscription by typing renew
<subscriptionID>.
E.g. renew
4953fa05-eba0-4bdf-8679-b8483a3d111b
This renew request
contains new time at which it would like the subscription to expire.
Figure 11 depicts the renew request for subscription ID 4953fa05-eba0-4bdf-8679-b8483a3d111b sent by
the Sink Client Service to the Sink Web
Service.
Figure 11 Renew Request Received by Sink Web Service
from Sink Client Service
Step 14: The renew
request goes directly to the Subscription Manager. Figure 12 depicts the renew request received by the Subscription
Manager Web Service from the Sink Web
Service.
Figure 12 Renew Request received by Subscription
Manager Web Service from Sink Web Service
Step 15: The Subscription
Manger generates a renew response and sends it back to the sink and source. Figure 13 depicts the renew response received by the Sink Web
Service from the Subscription Manager Web Service.
Figure 13 Renew Response received by Sink Web Service
from Subscription Manager Web Service
Step 16: Figure 14 depicts the renew response received by the Source Web
Service from the Subscription Manager Web Service.
Figure 14 Renew Response received by Source Web
Service from Subscription Manager Web Service
Step 17: Next the user
should open a new terminal window and go to the client directory (/usr/local/OMII/webservices/wse/dist/client).
Execute the ant wseaxis-source command
to run the source client and to send notifications back to the sink. Typing h
displays the list of available commands at the Source. Type s to issue a notification.
Figure 15 depicts the
result of this at the Source client.
Figure 15 Source Client
Step 18: Figure 16 shows one of
the notification messages sent by the source Web Service to the Sink that is subscribed
for the topic Literature/Shakespere.
Figure 16 Notification sent by Source Web Service to
Sink Web Service
Step 19: Communication
between sink and source web service can be seen from Catalina.out located under the /usr/local/OMII/jakarata-tomcat-5.0.25/logs folder. Figure
17 depicts the Notification
received by the Sink Web Service from the Source Web Service
Figure 17 Notification received by Sink Web Service
from Source Web Service
Step 20: Users can unsubscribe
the subscription by typing unsub
<subscriptionID>.
E.g. unsub
4953fa05-eba0-4bdf-8679-b8483a3d111b. Figure
18 depicts the unsubscribe request for subscription ID
4953fa05-eba0-4bdf-8679-b8483a3d111b sent by the Sink Client Service to the Sink
Web Service
Figure 18 Unsubscribe Request sent by Sink Client
Service to Sink Web Service
Step 21: The Unsubscribe
request is then routed to the Subscription Manager. Figure 19 depicts the unsubscribe request received by the Subscription
Manager Web Service from the Sink Web Service.
Figure 19 Unsubscribe Request received by
Subscription Manager Web Service from Sink Web Service
Step 22: The Subscription
Manger generates an unsubscribe response and sends it back to the sink and
source. Figure
20 depicts the unsubscribe response received by the Sink
Web Service from the Subscription Manager Web Service.
Figure 20 Unsubscribe Response received by Sink Web
Service from Subscription Manager Web Service
Step 23: Figure 21 depicts the unsubscribe response received by the Source
Web Service from the Subscription Manager Web Service.
Figure 21 Unsubscribe Response received by Source Web
Service from Subscription Manager Web Service