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:03:05 GMT
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 <simonslaws@googlemail.com>:

>
>
> On Mon, Jun 30, 2008 at 6:31 PM, Raymond Feng (JIRA) <
> dev@tuscany.apache.org> 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
>
>

Mime
View raw message