[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
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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
