tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Nash <n...@apache.org>
Subject Re: [jira] Commented: (TUSCANY-2445) [Proposal] Support of conversational web service
Date Tue, 01 Jul 2008 21:19:10 GMT
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.


> Regards,
> Yang
> 2008/7/1 Simon Nash <nash@apache.org <mailto: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
>         <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