Sun Yang wrote:
Hi, Simon:
You are right. I have not switch between the WS-Addressing and WS-RM in
this prototype.
They are two ways to achievement the same goal. The current
implementation is:
If WS-RM conversation is used, it will overwrite the conversationID of
WS-Addressing conversation.
If WS-RM conversation is not used, WS-Addresssing conversation will
take effect.
I am not sure whether a preference will work here or we should use some
registration mechanism to switch the implementation back and forth.
I'm sorry if I am missing something obvious, but I still don't understand
how the decision is made about whether or not to use WS-RM conversation.
If the current patch is applied, would WS-RM conversation be used
unconditionally? I don't think that would be acceptable.
Simon
Regards,
Yang
2008/7/1 Simon Nash <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>:
ant elder (JIRA) wrote:
[
https://issues.apache.org/jira/browse/TUSCANY-2445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12609501#action_12609501
<https://issues.apache.org/jira/browse/TUSCANY-2445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12609501#action_12609501>
]
ant elder commented on TUSCANY-2445:
------------------------------------
This looks like a great addition to me, its useful new function
, well written, and doesn't break any existing functionality. Is
there any reason to not apply the patch now and iteratively work
on the improvements being discussed? (I'll apply it soon unless
anyone shouts)
How does the patch decide whether to call WS-RM or use the existing
WS-Addressing support for conversational calls over Web services?
I looked at the code, but I couldn't see where this was being done.
Simon
Yang, I'm not sure what to do with the
HelloWorldConversational.zip what do you think about making a
new itest out of it so it can be run as part of the build, would
you submit another patch for that?
[Proposal] Support of conversational web service
------------------------------------------------
Key: TUSCANY-2445
URL:
https://issues.apache.org/jira/browse/TUSCANY-2445
Project: Tuscany
Issue Type: Improvement
Reporter: Yang Sun
Priority: Minor
Attachments: HelloWorldConversational.zip, rm-patch.patch
Original Estimate: 168h
Remaining Estimate: 168h
I want to improve Tuscany by supporting the conversational
behavior in web service client side binding. The following
is my proposal and I also have a prototype to demonstrate my
idea. Please give me some feedback.
Improvement Background:
-----------------------------------
Sometimes, the client wants to keep some session-like
variables between the calls to the server. Eg, 1. Login to
the server side by providing the security credential;
2. Get the invoice data from the Tuscany domain by web service;
3. Update the invoice data by calling Tuscany web service
interface;
4. Do other business related tasks;
5. Logoff from the server side.
Currently, Tuscany web service don't support this kind of
conversational feature.
SCA Related Spec:
--------------------------
In SCA assembly spec, it clarifies the external behavior of
conversational service and the use of wsdl to declare the
conversational behavior of its binding web service.
To support the conversational feature, the WSDL should
support the declaration of the following attributes:
1. sca:requires=conversational -- Declares at the porttype
level to make the functions in port type conversational.
2. sca:endConversation=true/false -- Declares at the
function level to give the function a special meaning (end
the conversation).
And the spec said SCA should use webservice reliable
messaging as the communication protocol. My Proposal:
------------------
Fortunately, Luciano provides a new parser mechanism which
support the parsing of sca:requires and sca:endConversation
and etc. So the things left me to do is simple (if I am not
wrong). I list my major changes.
1. Integrating Axis addressing and sandesha2 modules to the
packages.(Sandesha module implements ws-rm and ws-rm relys
on addressing, so we need addressing module as well) -- by
copying addressing-1.3.mar, sandesha2-1.3.mar to
\src\main\resources\org\apache\tuscany\sca\binding\ws\axis2\engine\config
in tuscany-binding-ws-axis2 module;
2. Engaging addressing and sandesha2 modules if the port
type is conversational. -- Modifications to
TuscanyAxisConfigurator; 3. Extract the identifier header
in SOAP header and make it as the conversationID. A code
snippet in my prototype is as below. (in
Axis2ServiceProvider.invokeTarget() method).
if (isConversational()) {
SOAPHeader soapHeader =
inMC.getEnvelope().getHeader();
Iterator<OMElement>headerIterator =
soapHeader.getChildren();
while (headerIterator.hasNext()) {
OMElement currentEle= headerIterator.next();
}
OMElement sequenceHeader =
soapHeader.getFirstChildWithName(new
QName("http://schemas.xmlsoap.org/ws/2005/02/rm";, "Sequence"));
OMElement identifierHeader =
sequenceHeader.getFirstChildWithName(new
QName("http://schemas.xmlsoap.org/ws/2005/02/rm";,
"Identifier"));
conversationID = identifierHeader.getText();
}
After the changes, the basic functions of conversational web
service works.
Test for the prototype:
-----------------------------
1. I wrote a demo client to check the working of
conversational web service. It is a enhancement to a echo
string. (attach the files as well)
It can trace the calls to the service from a WS-RM client
and give different feedbacks based on the call frequencies.
It also supports the method which marked as
endConversational.
2. Run all the test cases in tuscany-binding-ws-axis2.
Qustions need to be discussed:
-------------------------------------------
I have a confusion on the handling of endConversation in the
prototype and I have some thoughts on its implementation.
But I am not sure whether I am on the right track. In the
prototype, I have not made any further processing. But I am
thinking I can make some improvements here to better support
the conversational. Pls help me review it. The following is
my idea.
As we know, we can achieve endConversation effect in two ways:
1. end the underlying WS-RM conversation -- by sending
endSequence command
2. end the conversation at the Tuscany side by calling the
method marked as endConversation
For the situation 1, if I don't do anything, the external
behavior is correct since the identifier is re-created after
the conversation end and the conversation manager will use
the new conversationId to get the conversation variables.
But it will left the variables for the ended conversation in
the ConversationManager. It is a memory leak till the
timeout of ConversationManager. And it will affect the
scalability of SCA domains.
My improvement idea: write a axis handler at RMPhase and
listen to endConversation command. If we got that command,
the handler will find the ConversationManager and call its
method to clear the variables according to its ending
identifier.
For the situation 2, if I don't do anything, the behavior
can still be right. But we must have a constraint here: the
corresponding java interface must marked with
@endConversation. If not, the conversation sequence will be
lost (from CONVERSATION_END to CONVERSATON_CONTINUE) and the
conversation cannot be ended. My improvement idea: from my
understanding, the invocation source should decide the
conversation sequence. So whether or not the invocation
target marked with endConversation, the conversation
sequence should be CONVERSATION_END if the invocation source
is marked as CONVERSATION_END. A quick fix here is to copy
the conversation sequence from the invocation source to
invocation target when tuscany looks up the InvocationChain.
Or at least, we should make some check at the interface
compatible logic and give the user a warning message when
the conversation sequence is not compatible.
Thanks for reading so long and pls provide me your feedback.
