[
https://issues.apache.org/jira/browse/TUSCANY-2445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Sun updated TUSCANY-2445:
------------------------------
Attachment: rm-patch.patch
A prototype implementation of ws-rm support. It is a patch file which should be
applied to the head.
In additional to apply the patch file, pls copy addressing.mar and
sandesha2.mar to
\src\main\resources\org\apache\tuscany\sca\binding\ws\axis2\engine\config in
tuscany-binding-ws-axis2 module.
> [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: 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.
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
