On Thu, May 15, 2008 at 2:24 PM, Vamsavardhana Reddy <[EMAIL PROTECTED]> wrote:
> Hi Mike, > > Thanks for the heads-up. Let us see whether the Assembly TC does the same > this time too with the proposal to add a top level interface element. > > ++Vamsi > > On Thu, May 15, 2008 at 6:07 PM, Mike Edwards < > [EMAIL PROTECTED]> wrote: > > > Vamsavardhana Reddy wrote: > > <snip> > > > >> For 1, 2, 3 and 5, I think it is a good idea to introduce a new > interface > >> definition as a top level element in SCDLs. This new interface > definition > >> could use any existing interface definition and add additional > semantics. > >> For example, something like > >> <interface.xxx name="myConversationalInterface" > >> interface="myNonConversationalInterface" conversational="true"> > >> <operation name="method1" endsConversation="true"/> > >> </interface.xxx> > >> > >> can yield a conversational interface "myConversationalInterface" from a > >> non-conversational interface "myNonConversationalInterface". This > should > >> work as if there were annotations on the original interface definition. > >> With > >> this new interface definition in place, we may not need "conversational" > >> intent on service or reference and "myConversationalInterface" can be > used > >> whereever "myNonConversationalInterface" were to be used along with a > >> "conversational" intent on the service or reference. > >> > >> Please comment if any of the above does not make sense or suggest any > >> alternative ways to deal with these issues. > >> > >> ++Vamsi > >> > > <snip> > > Vamsi, > > > > Simon has given a good comprehensive response to your main points - I > would > > like to focus on this final suggestion. > > > > You will meet some substantial opposition in the spec group to the idea > of > > creating a new SCDL-based interface definition language. The group has > > rejected such suggestions more than once in the past. > > > > The argument is that there are already very good interface definition > > languages available - and that where SCA extensions are necessary, they > can > > be added as extension annotations to those existing languages. Providing > > yet another parallel interface definition language simply adds to the > > complexity of SCA without a corresponding benefit. I believe that all > the > > issues you raise are already covered by the specs - or there are open > issues > > awaiting resolution. > > > > You are welcome to make suggestions to the SCA specification group, of > > course, but I thought it useful to give you a heads-up on the likely > > reaction. > > > > > > Yours, Mike. > > > I think we need to be clear about our expectations of adding a "conversational" intent to the SCDL. From reading the notes here let me try and articulate when it could be useful. A 3rd party interface is provided which knows nothing of SCA and doesn't specific @Conversational A user builds a component implementation that inherits direction from this 3rd party interface This component implementation is conversational in that it either - stores instance based conversational data - uses the SCA conversation ID (via the @ConversationId annotation for example) to locate conversation data The user writes a SCDL component to exploit this implementation and has to add the intent "conversational" to tell SCA to treat this as a conversational service An SCA client service can now hold a conversation with this service BUT it must end the conversation using the conversation.end() call rather than relying on an annotated method at the service. Hence the only thing that appears in the SCDL is the "conversational" intent. This seems to put some constraints on the client. I.e. it must know that it has to do special conversation processing. It is holding a conversation over a reference whose interface is not annotated as being conversational. The writer has to be be aware of this. Does this help? Simon
