Return-Path: Delivered-To: apmail-tuscany-dev-archive@www.apache.org Received: (qmail 66444 invoked from network); 1 Jul 2008 14:13:05 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 1 Jul 2008 14:13:05 -0000 Received: (qmail 60162 invoked by uid 500); 1 Jul 2008 14:13:06 -0000 Delivered-To: apmail-tuscany-dev-archive@tuscany.apache.org Received: (qmail 59854 invoked by uid 500); 1 Jul 2008 14:13:05 -0000 Mailing-List: contact dev-help@tuscany.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@tuscany.apache.org Delivered-To: mailing list dev@tuscany.apache.org Received: (qmail 59845 invoked by uid 99); 1 Jul 2008 14:13:05 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Jul 2008 07:13:05 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of syyzxsyf@gmail.com designates 216.239.58.186 as permitted sender) Received: from [216.239.58.186] (HELO gv-out-0910.google.com) (216.239.58.186) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Jul 2008 14:12:11 +0000 Received: by gv-out-0910.google.com with SMTP id n40so249978gve.35 for ; Tue, 01 Jul 2008 07:12:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=KZcFoh//V/mQqtSK61RUS70Fo+9z7Lk4Az8VFyzj6jk=; b=wl7M+PBHLa/62c5dHX7iTBvEvxw6svzukcrs7CnnN9Gvs/SllhgLEGRZYueRd7ODgd N4a1xOAUEtKoq5rKM49uvMZ7cyOaVsu+wTybMC2uhoE3/4k0DHsQGQ6T+VL1VETz6Itx fV/QBBJGDNLwNtUDyMSZkGYKoghKekHXS6mcQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=WUrWpCRr2Xz62QKP3F9BpIH9wH3EVAYq1WX+aEdocwhM3kueYFDf1dGVSdE8lKbcmE xeq2CXixCAxpX5x/wM4b+x0/jzunALqx/Bu/CzBVkI9iaOqALUhgszrQboB3rHz65juG 25nV5SEUeVxt5z7YJwEwJTLy7+R0jdnh/JPGg= Received: by 10.78.161.4 with SMTP id j4mr1666125hue.74.1214921550254; Tue, 01 Jul 2008 07:12:30 -0700 (PDT) Received: by 10.78.118.17 with HTTP; Tue, 1 Jul 2008 07:12:30 -0700 (PDT) Message-ID: <927483000807010712v2dcbfcd1oa962b7c791ce45a9@mail.gmail.com> Date: Tue, 1 Jul 2008 22:12:30 +0800 From: "Sun Yang" To: dev@tuscany.apache.org Subject: Re: [jira] Commented: (TUSCANY-2445) [Proposal] Support of conversational web service In-Reply-To: <486A1604.10202@apache.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_20764_6630989.1214921550262" References: <882971180.1214903985126.JavaMail.jira@brutus> <486A1604.10202@apache.org> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_20764_6630989.1214921550262 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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. Regards, Yang 2008/7/1 Simon Nash : > 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(); >>> IteratorheaderIterator = >>> 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. >>> >>> >> >> > ------=_Part_20764_6630989.1214921550262 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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.

Regards,
Yang


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.
       



------=_Part_20764_6630989.1214921550262--