tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sun Yang" <syyzx...@gmail.com>
Subject Re: [jira] Commented: (TUSCANY-2445) [Proposal] Support of conversational web service
Date Tue, 01 Jul 2008 14:12:30 GMT
Hi, Simon:

You are right. I have not switch between the WS-Addressing and WS-RM in this

They are two ways to achievement the same goal. The current implementation
  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

I am not sure whether a preference will work here or we should use some
registration mechanism to switch the implementation back and forth.


2008/7/1 Simon Nash <nash@apache.org>:

> 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]
>> 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.

View raw message