Hi Gilbert,
Responses with "=>"
Thanks,
Jaliya
----- Original Message -----
From: "Gilbert Pilz" <[EMAIL PROTECTED]>
To: "Jaliya Ekanayake" <[EMAIL PROTECTED]>; <[email protected]>
Sent: Wednesday, September 06, 2006 1:05 AM
Subject: RE: Sandesha 1.0; SandeshaContext.endSequence() and active, offered
sequences
Responses with "gp>" . .
-----Original Message-----
From: Jaliya Ekanayake [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 05, 2006 6:52 PM
To: Gilbert Pilz; [email protected]
Subject: Re: Sandesha 1.0; SandeshaContext.endSequence() and
active, offered sequences
Hi Gilbert,
Please see my comments below.
Thanks,
-Jaliya
----- Original Message -----
From: "Gilbert Pilz" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, September 05, 2006 4:01 PM
Subject: Sandesha 1.0; SandeshaContext.endSequence() and
active, offered sequences
Hello Sandesha-istas!
I was working on some interop testing between Sandesha 1.0
and WebLogic Server 9.2 in which a Sandesha 1.0 client
engages in a request-response exchange with a WLS 9.2 server.
Everything works fine up until the point that the client
calls SandeshaContext.endSequence(). At this point the client
has terminated the outbound sequence via a
wsrm:TerminateSequence message but the inbound sequence
(established via an offer during the initial
CreateSequence/CreateSequenceResponse handshake) is still
active. The Sandesha 1.0 client blocks in endSequence() until
the inactivity timeout for that sequence is reached and an
exception is thrown.
>>
The exception is thrown only when the inbound sequence is not
completed within the InactivityTimeout right?
gp> Correct, but imagine if the InactivityTimeout were set for
gp> 48 hours or some such. From the standpoint of a user the
gp> client would "never" exit . .
Although I can understand that there may be reasons that the
client would want to block until the offered sequence is
terminated, I don't think it is reasonable to expect that
terminating an outbound sequence will necessarily result in
the server automatically terminating the inbound sequence.
>>
When the client offer a sequence then it knows that there are
some responses that it is expecting from the server. So,
terminating outbound sequence does not mean that the inbound
sequence will also terminate. However for the client to
terminate gracefully (after getting all the responses) the
inbound sequence should also terminate with the proper
TerminateSequence. At least it should get the required number
of responses.
gp> In the test I am running the client has received the "proper"
gp> number of responses (1)
=>the inbound sequence (or offered sequence is for the responses).
=>so if the sending party (server) knows that it sends x number of messages
then why not send the terminate sequence as well.
=>That is, when it comes to request/response type web service invocation
both RMClient and RMServer should act in the same manner
=>where they both can accept sequence requests and also should send sequence
termination as well.
=>Sandesha currently assumes the number of response messages be equal to the
number of request messages in the normal case and if any other type is
required then the user has to
=>implement sandesha client with a listener that can wait for any number of
responses. In anycase the response sequence should also has a Terminate
Sequence for it to complete =>and to comply with the WS-RM specification. We
can implement the suggestions that you have mentioned but it is mainly
because the server is not sending the Terminate sequence =>message at the
correct place.
=>When we know the operation that we need to invoke we need to know whether
it is in-out or in-out-out ... out so we know the number of out messages
(say n) that we need to =>send. Unfortunately we don't have support in axis
to do the latter unless the service itself start sending the responses. So
after n messages the server should send the Terminate =>Sequence for it to
comply with the Specification.
and it has gracefully terminated
gp> the outbound sequence. It is blocking on a TerminateSequence
gp> for the inbound sequence which it will never get because,
gp> unlike the Sandesha server, WebLogic does not treat termination
gp> of the inbound (from its perspective) sequence as a signal
gp> to terminate the corresponding offered, outbound sequence.
I agree with you that if the InactivityTimeout is a large
value then may be we need a way to inform Sandesha client
only to wait X number of milliseconds (where
X<InactivityTimeout), but in order for client to complete it
has to wait till it receive the required number of responses.
gp> I'm not sure how the Sandesha layer can be expected to
gp> know, a priori, what the "required" number of responses
gp> is. To stretch a point, I could define an asynchronous
gp> in-out-out-out service in which a single request message
gp> was followed by N response messages. How would the client
gp> know when the server was done sending responses? Obviously
gp> it could wait until the InactivityTimeout period has lapsed
gp> but we've already covered why this isn't always workable . .
The other possibility to completely de-couple the client and
the client side listener that is waiting for the inbound
messages(responses) is to host the client itself in a
container (e.g. client itself can be a servlet or jsp) then
we can have a separate servlet or jsp which handle the repose
part of the client's requests and use that servlet or jsp's
url as the replyTo url.
gp> This is, in essence, what WebLogic does but I think the core
gp> problem still remains, however; what do you do when the thing
gp> that "contains" an RMD for an active sequence needs to clean
gp> up (stop, exit, shutdown) but is unwilling to block for the
gp> InactivityTimeout? I think sending a SequenceTerminated
gp> fault to the RMS should at least be an option.
I couldn't find any language in the 200502 specs that
mandates such a linkage between the inbound and outbound sequences.
>>
This is because these two sequences are considered completely
independent and only the client need to relate them find the
responses.
gp> That was my understanding as well.
I think the application should be allowed to select from
three possible behaviors for endSequence():
1) block waiting for all active inbound sequences to be
terminated (current behavior)
2) send a SequenceTerminated fault to all active inbound sequences
3) simply clean up the sequence
What do people think?
>>
Since the suggestions are an extensions to the current
implementation it would be great if you could submit a patch.
Then we can get this functionality in Sandesha.
I'll give this a shot and post my patch to this list.
--
Gilbert Pilz
Sr. Principal Technologist
Office of the CTO
BEA Systems, Inc.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
