Hi, Simon: That is my concern. I believe a warning message will help users a lot. But from the concept perspective, I am thinking the service side should decide the conversation state. I am not sure whether or not the confliction situation brings confusion to the end user.
Regards, Yang Sun 2008/7/1 Simon Laws <[EMAIL PROTECTED]>: > > > On Mon, Jun 30, 2008 at 6:31 PM, Raymond Feng (JIRA) < > [email protected]> wrote: > >> >> [ >> https://issues.apache.org/jira/browse/TUSCANY-2445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12609297#action_12609297] >> >> Raymond Feng commented on TUSCANY-2445: >> --------------------------------------- >> >> Thanks Yang for the contribution! >> >> A few comments on top of Simon's: >> >> 1. The parsing part is done by Luciano and the changes are in the code >> base already. >> >> 2. AS we can support the exchange of the conversation states using >> different protocols such as WS-Addressing and WS-RM, we probably need to >> define an extension point here to allow the pluggability. >> >> > [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. >> > >> >> -- >> This message is automatically generated by JIRA. >> - >> You can reply to this email to add a comment to the issue online. >> >> > I also have a question about the conversation end processing and fix that > is described.Are you suggesting that we should deal with cases where the > reference and service are marked inconsistently with respect to > conversational annotations? Looking at the interface contract mapper code it > doesn't look like we check conversational annotations for compatibility. I > agree that the least we should do is raise a warning in this case. I > wouldn't go as far as saying that we need to copy annotations from reference > to service though. > > Simon > >
