Simon Laws wrote:
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
Yes, it does. It helps me to see how unlikely it is that this
will ever happen in real life. I think the first point is the
most telling. If the third party interface wasn't designed
with SCA-style conversation semantics in mind, the chances of
successfully applying and exploiting these semantics "after the
fact" are very small.
Simon
