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 <[EMAIL PROTECTED]>: > 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. >>> >>> >> >> >
