Vamsavardhana Reddy wrote:
On Thu, May 15, 2008 at 2:32 PM, Simon Nash <[EMAIL PROTECTED]> wrote:
Vamsavardhana Reddy wrote:
Right now all the conversation related things we have in Tuscany seem to
use
annotations in Java code. The assembly schema does not seem to be good
enough to specify the equivalents through SCDLs. Here are some of the
issues, taking the java annotations as a reference point, that are coming
in
the way of conversational semantics using SCDLs. I would like to hear
from
others before I take up these with OASIS SCA Assembly TC. So, please
provide your input and also suggest any aspects that I may be missing to
see.
1. Designating an interface as conversational:
JAVA: The @Conversational annotation used to designate a Java interface as
conversational. Wherever the interface is used, it is seen as
conversational interface consistently.
ASSEMBLY: I do not see a way to designate an interface (just the interface
definition) as conversational through SCDLs.
This was resolved by http://www.osoa.org/jira/browse/ASSEMBLY-47.
Either the interface can be annotated as conversational, or the service
or reference using the interface can be annotated as converational.
By "designating just the interface as conversational", I meant it should be
considered as conversational wherever it appears in the SCDLs without having
to specify anything additional. I think with ASSEMBLY-47 only the service
or reference under which the interface element appears will be considered as
conversational and it does not affect the other occurrences of the same
interface elsewhere in the composite. For example in:
<component name="c1">
...
<service name="Service1">
<interface.java interface="MyService" requires="conversational">
<operation name="method1" endsConversation="true"/>
</interface.java>
</service>
</component>
<component name="c2">
...
<service name="Service1">
<interface.java interface="MyService"/>
</service>
</component>
The MyService interface is conversational only in component c1 but not in
c2.
Yes, this can happen, and I don't think it's a problem.
2. Designating a method in a conversational interface as "ends
conversation".
JAVA: The @EndsConversation annotation on a method designates the method
as
ends conversation.
ASSEMBLY: Right now there is no way to do this through SCDLs.
http://www.osoa.org/jira/browse/ASSEMBLY-47 seem to talk about a similar
issue but in the context of interfaces defined in WSDLs.
Problem: Even if an operation element is introduced under interface
element,
it is not possible to guarantee consistency across all the occurrences of
the interface in the SCDLs. For example, the interface used under a
service
element in component1 may designate method1 as "ends conversation" where
as
a different component using the same interface need not necessarily
designate method1 as "ends conversation".
If the two components involved are being wired together using this
interface, but have inconsistent definitions for which methods are
"ends conversation", this is an error in the SCDL assembly and
should be detected by the SCA runtime.
It is not necessary that both the components are wired together. The two
components could be using the interface element under service element.
How does this cause a problem? Can you give more specific details
of the problem scenario?
3. Designating a service is a conversational service:
JAVA: A service whose interface is decorated with @Conversational
annotation
is a conversational service.
ASSEMBLY: A "conversational" intent can be specified on the component
service whose java interface is not decorated with @Conversational.
Problem: We can not guarantee that all components that provide a service
with a particular interface use the "conversational" intent on the service
consistently. For e.g, component1 may use "conversational" intent on the
service1, whereas component2 that provides a service2 with the same
interface as service1 need not use "conversational" intent.
Why is this a problem? From SCA's perspective, the conversational
and non-conversational forms would be different interfaces. Unless
they are wired together, this does not cause any problems.
Tuscany seems to use the same interface object wherever an interface
features. Perhaps it should clone the interface object so that additional
intents can be set as required without affecting all occurrences of the
interface.
I am surprised to hear that. I would expect a different interface
object to be created for each different interface element appearing
in the SCDL.
4. Specifying Conversation attributes:
JAVA: The @ConversationAttributes annotation used on the implementation
class enables specifying conversation attributes applicable to the
conversational interfaces of services and references of the class.
ASSEMBLY: Right now there is no way to specify conversation attributes
through SCDLs. http://www.osoa.org/jira/browse/JAVA-14 seems to refer to
the same problem.
Yes it does, so this issue can be used to discuss and create a proposal.
5. Specifying a callback interface for a service interface.
JAVA: The @Callback annotation on a service interface specifies the
callback
interface.
ASSEMBLY: Optional callbackInterface attribute on the interface element
can
be used to specify the callback interface. But this does not necessarily
tag the interface and its callback interface as the @Callback annotation
would.
I don't see any problem here, as long as specifying this in the SCDL
and omitting the @Callback annotation is allowed. Section 6.7 of the
JavaCAA spec is not very clear on this point. Does this work in
Tuscany?
I have not checked how it works in Tuscany. I guess @Callback is used on
the java interface, the interface object should be carrying the information
on the callback.
The question is what happens if @Callback is not specified on the
Java interface, but is only specified in SCDL. I think this should work.
6. conversational intent on a service or a reference element.
The conversational intent specified on a service or a reference element
seems to be inherited by the child callback element. But, it is not
necessary that the callback interface of a conversational service is
always
conversational. Should the callback element "not inherit" the intents and
specify its own intents?
Does it say in the spec that the conversational intent specified
on a service or reference element is inherited by the child callback
element? Or is this just what Tuscany is currently doing? I agree
that this would not be correct.
In Tuscany the callback element is inheriting the intents specified on the
parent service or reference element. I guess all the intents on the parent
element are inherited by child elements in general.
This sounds like a Tuscany bug, unless it is stated somewhere in
the spec (in which case it would be a spec issue).
The child callback element is currently only used to provide binding
information. Extending it to carry intents would require an
Assembly issue.
My current proposal for JAVA-25 would not allow callbacks to be
conversational. So depending on the resolution to this issue,
it may not be necessary to add this extension to the child callback
element (at least from the perspective of the OASIS specs).
That should definitely ease a lot of things.
>
Yes, I hope we will be able to agree on this in the spec group.
There is still a bit of disagreement over this proposal.
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.
See above. I think the issues can be resolved without the need to
introduce a new top-level element. However, I can see some value
in what you are proposing. It would be worth raising an Assembly
issue proposing this new top-level element so that this can be
considered by the Assembly TC.
I will raise an issue with Assembly TC.
Simon
++Vamsi
PS: I seem to attempt to eliminate the conversational intent altogether,
but
that has nothing to do with the '007' in my mail id. :o)
