Hi Xinjun,
Please see my comments below.
Thanks,
-jaliya
----- Original Message -----
From: Xinjun Chen
To: Jaliya Ekanayake
Sent: Monday, January 21, 2008 11:21 AM
Subject: Re: Is WS-RM required in these scenarios
Hi Jaliya,
Thanks for your reply.
I have some follow-up questions regarding your reply.
1) You mentioned that "if a web service requests needs to go through several
transport connections and several software components, before it reaches its
ultimate recipient then the transport level protocol can itself cannot
guarantee the reliable delivery.". When you mention "it may go through
several transport connections", I can think of two examples: a) The request
is going through a proxy before reach the destination. b) The request is
going through some SOAP intermediary. Can you give some example of "several
software components"?
To further extend this question, if there is only one hop between the client
and the web service and the transport is reliable, does it mean WS-RM is not
required? (Assuming message persistence is out of question).
That is exactly what I mentioned. SOAP intermediary or Proxy or a Message
BUS (ESB, Apache Synapse) are all such examples.
Please forgive me if you feel my questions are offensive. I know, as a
Sandesha or Sandesha2 developer, you try to promote or expect others to
promote the use of WS-RM. I am just trying to find the correct usage of
WS-RM. Try to use WS-RM only when it is really necessary.
You are right, we should not use technology just because they exist in this
world. You don't need to add support to all the WS* implementation to get a
web service >solution to work. However, most of the WS* specs have a very
good intended usages. So on those circumstances, they perform well and make
the life of a programmer >easy.
2) In your answer to Q1, the database persistence increases the possibility
of request recovery from client system crash, but it does not alleviate the
problem. RM layer will have no way to recover the request if the client
system crashes even before the request is persisted to database.
If you see the outcome of this situation, it has no effect. You have not
invoked the service, so no need to rollout any transaction. Since the
client itself has crashed, the
person or the system that uses that client will be fully aware of the
situation. What RM stand for is to guarantee the delivery of messages once
it is pass to the RM layer.
Does WS-RM also perform database persistence for the response? What if a
response reaches the RM source, RM source sends acknowledgment of response
to RM destination but then client system crash before the response is
consumed by Application source? Is this possible to happen?
I am not exactly sure about the implementation now, but it should be able
to configure so that the response is also persisted at the client side.
The problem you have mentioned can happen, a common analogy is: you use
FedEX to transfer a package, they deliver it to someone in your house, but
that person >simply through it away, now who is responsible for the loss of
the package? FedEX or the people in your house?
If you don't trust the people in your house(client system) you can build
your own program with RM so that the client can simply query the database
to retrieve the received >messages before it crash.
3) I am not so sure about your answer to Q2. The challenge posed in Q2 is
that the second request must uses some information contained in the first
response. Every invocation must be a blocking call. I think a normal
ServiceClient.sendReceive() will be used. But I am not sure whether three
ServiceClient.sendReceive() should be invoked in one WS-RM sequence.
Use of sequence is an optimization mechanism. If the messages are related
you can use an RM sequence for all of them. You can select the optimum way
to use RM >according to the way you invoke your web service or program the
client.
4) In your answer to Q3, you refer me to Sandesha2 userguide. Axis2 Async
Callback and Sandesha2 together really solve the problem gracefully. Thanks
Axis2 and Sandesha2.
:)
In my situation, I face another issue. My partner is hosting the web service
which may not be in Axis2. I can adopt the Axis2 Callback when doing WS
call, but I cannot force my partner to use Axis2. Will this be OK? Does the
Axis2 Callback introduce certain coupling between the web service
implementation and the client implementation?
ASFIK, There is no implementation dependency in the Callback mechanism in
Axis2. It is completely client side programming model and have nothing to
do with the >server implementation. However, if you need to have a dual
channel request/response type web service invocations then the server
should also support that kind of >message exchange pattern.
Regards,
Andrew
On Jan 21, 2008 3:26 PM, Jaliya Ekanayake <[EMAIL PROTECTED]> wrote:
Hi Chen,
Main difference in TCP and WS-RM is the layer in which these protocols
operates in the communication stack. TCP is a transport layer protocol while
the WS-RM is a message level protocol. TCP guarantees you the delivery of
messages in a single TCP connection. However, if a web service requests
needs to go through several transport connections and several software
components, before it reaches its ultimate recipient then the transport
level protocol can itself cannot guarantee the reliable delivery. Software
components in between can fail and the message may not get delivered to the
ultimate recipient. That is the main reason for incorporating a message
level reliable delivery protocol for web service stack.
Q1:
WS-RM is almost not required in this case. However, WS-RM has a guaranteed
delivery mechanism with the help of persistent database. So if the
communication channel has any problems or the web service is not and
running when you call it, still the RM layer will relay your messages when
they are up and running.
Q2:
You don't need to define a custom messaging protocol when you can use WS-RM,
if you use it, then you can assume all three messages are going to be
delivered in order. If there is a failure, then you will be notified at
which point you can start your logic on rolling back transactions.
Q3: You can still use WS-RM to support message level reliable delivery of
messages. Please see
http://ws.apache.org/sandesha/sandesha2/userGuide.html#request_reply
for how to use Sandesha for request/reply web service invocation over
multiple channel communication.
HTH,
-jaliya
----- Original Message -----
From: Xinjun Chen
To: [email protected]
Sent: Sunday, January 20, 2008 9:42 PM
Subject: Is WS-RM required in these scenarios
Dear Sandesha developers,
Thanks for making Sandesha2 a reality and providing WS-RM and WS-RX
implementations for the WS community.
This is my first post in the sandesha mail list.
I have a question regarding the usage of WS-RM.
To me, WS-RM is amazingly similar to TCP protocol in TCP/IP model. But the
difference is that the WS-RM (RM layer) is a sub-layer below Application
layer in TCP/IP model. TCP itself is a transport layer protocol. TCP
protocol ensures that all the data packets which belongs to the same
application message are transmitted to the destination with the insurance
that the delivery is in-order, once-and-only-once. The WS-RM ensures that
all SOAP requests which belongs to the same sequence are sent to the WS
destination with the insurance that the delivery is once-and-only-once and
optionally in-order.
I have three scenarios:
1) My WS client invokes the WS using HTTP/SOAP, and the underlying transport
is TCP. Every invocation is independent of each other. In this case, do I
still need WS-RM?
From my understanding, WS-RM is totally unnecessary in this scenario because
the TCP itself is reliable, so the single invocation (SOAP request) can be
reliably sent to the destination. Is my understanding correct?
2) Again, in this scenario, the transport is TCP. In one session (or one
sequence), there are three request-response message exchanges. The second
request will not be sent out if the first response has not arrived. If the
first request succeeds but the second request fails, there is no transaction
issue (rollback) required. The application has the choice to either retry
the second request or just abort the response of the first request. The web
service provider will not know whether the client will retry the second web
service. In this scenario, is WS-RM still necessary? If we use WS-RM, will
the three message exchanges in one sequence?
From my understanding, we are not able to apply WS-RM in this
request-response message exchanges. The messages in a sequence should be
asynchronous request message, or non-blocking invocation.
3) Again, in this scenario, the transport is TCP. In this scenario, both
application source and application destination may be web service provider
and consumer.
In the first message exchange, the application source sends one request to
the destination, only requiring an acknowledgment of receipt of the request.
The actual business response is generated after the destination processes
the request. The business response is sent back to the application source
through another WS invocation. The application source exposes one web
service to receives response from application destination. The processing
time incurred at the application destination may be quite long, say 5
minutes.
In this scenario, do I need to use WS-RM? How can I use WS-RM?
Thanks for reading my long questions. I hope I have made my questions clear.
Regards,
Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
