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. 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". 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. 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. 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. 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? 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 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)
