You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Vamsavardhana Reddy <va...@apache.org> on 2008/05/14 19:05:58 UTC
Conversational semantics using xml in SCDLs
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)
Re: Conversational semantics using xml in SCDLs
Posted by Mike Edwards <mi...@gmail.com>.
Simon Nash wrote:
> 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.
>
Hmm, my experience recently with the BPEL code shows that the handling of interfaces within Tuscany
is not so clean.
I'll continue my investigations and report my findings when I understand it all better.
I agree that different interface elements SHOULD be used. It just doesn't happen in all the cases
that I've experienced.....
Yours, Mike.
Re: Conversational semantics using xml in SCDLs
Posted by Simon Nash <na...@apache.org>.
Vamsavardhana Reddy wrote:
> On Thu, May 15, 2008 at 2:32 PM, Simon Nash <na...@apache.org> 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)
>>>
>>>
>
Re: Conversational semantics using xml in SCDLs
Posted by Vamsavardhana Reddy <c1...@gmail.com>.
On Thu, May 15, 2008 at 2:32 PM, Simon Nash <na...@apache.org> 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)
>>
>>
>
Re: Conversational semantics using xml in SCDLs
Posted by Simon Nash <na...@apache.org>.
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.
> 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.
> 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.
> 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?
> 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.
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).
> 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.
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)
>
Re: Conversational semantics using xml in SCDLs
Posted by Simon Nash <na...@apache.org>.
Simon Laws wrote:
> On Thu, May 15, 2008 at 2:24 PM, Vamsavardhana Reddy <c1...@gmail.com>
> 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 <
>> mike.edwards.inglenook@gmail.com> 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
Re: Conversational semantics using xml in SCDLs
Posted by Simon Laws <si...@googlemail.com>.
On Thu, May 15, 2008 at 2:24 PM, Vamsavardhana Reddy <c1...@gmail.com>
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 <
> mike.edwards.inglenook@gmail.com> 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
Re: Conversational semantics using xml in SCDLs
Posted by Vamsavardhana Reddy <c1...@gmail.com>.
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 <
mike.edwards.inglenook@gmail.com> 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.
>
Re: Conversational semantics using xml in SCDLs
Posted by Mike Edwards <mi...@gmail.com>.
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.