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