You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@tuscany.apache.org by Nicholas Williams <nw...@ubiquitysoftware.com> on 2007/05/15 17:36:29 UTC
Ambiguity in SCA Common Annotations and APIs specification re. conversations
Hi all,
I would like clarification on what I perceive to be an ambiguity in the SCA Common Annotations and API specification regarding when conversations are started.
Lines [475 - 478] reads:
475 Conversations start on the client side when one of the following occur:
476 * A @Reference to a conversational service is injected
477 * A call is made to CompositeContext.getServiceReference [sidenote: should read ComponentContext]
478 and then a method of the service is called.
Which of the following behaviour would you expect if a client chooses to call ComponentContext.getServiceReference more than once using the same method arguments:
a) each returned ServiceReference will refer to separate conversations.
b) each returned ServiceReference will refer to the same conversation
My interpretation (and preference) would be a). This would allow a client to start multiple conversations to the same reference, which is a common and useful pattern.
**Please could you confirm this is what the spec intends.**
There is however one ugly element to coding a client that wishes to start multiple conversations to the same reference. Consider the following client code:
@Scope("CONVRSATION")
@Service(Client.class)
public class ClientImpl implements Client
{
@Context
protected ComponentContext componentContext;
@Reference(name = "server")
protected Server dummyServer;
public void op(int count)
{
for (int i = 0; i < count; i++)
{
//create a separate conversation for each iteration
final ServiceReference<Server> serviceReference = componentContext.getServiceReference(Server.class, "server");
Server server = serviceReference.getService;
server.setId("id" + i);
server.doStuff();
}
}
}
The ugly bit in the above code is that I've had to declare an @Reference against a dummyServer field, but I have no intention of using the injected service because I am programmatically using the ComponentContext instead. My suggestion would be to allow the @Reference to target a type (it can currently only target field, method, constructor). The code would become:
@Scope("CONVERSATION")
@Service(Client.class)
@Reference(name = "server", type=Server.class)
public class ClientImpl implements Client
{
@Context
protected ComponentContext componentContext;
public void op(int count)
{
for (int i = 0; i < count; i++)
{
//create a separate conversation for each iteration
final ServiceReference<Server> serviceReference = componentContext.getServiceReference(Server.class, "server");
Server server = serviceReference.getService;
server.setId("id" + i);
server.doStuff();
}
}
}
A Type-targetted @Reference annotation would be useful in a number of scenarios:
- the client requires zero to many conversations (as described above)
- the client requires zero or one conversation (why inject a reference if it might not be used)
- the client needs fine control of when the conversation is started (the developer may want lazy reference lookup and won't appreciate the service being injected before the @init method)
What do you think?
Thank you
Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation. All unauthorized use, disclosure or distribution is strictly prohibited. If you are not the addressee, please notify the sender immediately and destroy all copies of this email. Ubiquity Software Corporation plc, a company registered under the laws of England and Wales, Registration 2719723, registered offices at Eastern Business Park, Building 3, Wern Fawr Lane, St. Mellons, Cardiff CF3 5EA, Wales, United Kingdom.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: Ambiguity in SCA Common Annotations and APIs specification re. conversations
Posted by Raymond Feng <en...@gmail.com>.
Hi,
Let me give a try. Please see my comments inline.
Thanks,
Raymond
----- Original Message -----
From: "Nicholas Williams" <nw...@ubiquitysoftware.com>
To: <tu...@ws.apache.org>
Sent: Tuesday, May 15, 2007 8:36 AM
Subject: Ambiguity in SCA Common Annotations and APIs specification re.
conversations
Hi all,
I would like clarification on what I perceive to be an ambiguity in the SCA
Common Annotations and API specification regarding when conversations are
started.
Lines [475 - 478] reads:
475 Conversations start on the client side when one of the following occur:
476 * A @Reference to a conversational service is injected
477 * A call is made to CompositeContext.getServiceReference [sidenote:
should read ComponentContext]
478 and then a method of the service is called.
Which of the following behaviour would you expect if a client chooses to
call ComponentContext.getServiceReference more than once using the same
method arguments:
a) each returned ServiceReference will refer to separate conversations.
b) each returned ServiceReference will refer to the same conversation
<rfeng>
I think it depends. There are two factors:
1) What's the current conversation if any?
2) What's the scope of the target component?
If the getServiceReference() is invoked twice in the same conversation, I
assume it will get ServiceReference instances for the same conversation. If
the getServiceReference() is invoked from two different conversations (or no
conversations), then ServiceReference instances will refer to different
conversations.
</rfeng>
My interpretation (and preference) would be a). This would allow a client
to start multiple conversations to the same reference, which is a common and
useful pattern.
**Please could you confirm this is what the spec intends.**
There is however one ugly element to coding a client that wishes to start
multiple conversations to the same reference. Consider the following client
code:
@Scope("CONVRSATION")
@Service(Client.class)
public class ClientImpl implements Client
{
@Context
protected ComponentContext componentContext;
@Reference(name = "server")
protected Server dummyServer;
public void op(int count)
{
for (int i = 0; i < count; i++)
{
//create a separate conversation for each iteration
final ServiceReference<Server> serviceReference =
componentContext.getServiceReference(Server.class, "server");
Server server = serviceReference.getService;
server.setId("id" + i);
server.doStuff();
}
}
}
The ugly bit in the above code is that I've had to declare an @Reference
against a dummyServer field, but I have no intention of using the injected
service because I am programmatically using the ComponentContext instead.
My suggestion would be to allow the @Reference to target a type (it can
currently only target field, method, constructor). The code would become:
@Scope("CONVERSATION")
@Service(Client.class)
@Reference(name = "server", type=Server.class)
public class ClientImpl implements Client
{
@Context
protected ComponentContext componentContext;
public void op(int count)
{
for (int i = 0; i < count; i++)
{
//create a separate conversation for each iteration
final ServiceReference<Server> serviceReference =
componentContext.getServiceReference(Server.class, "server");
Server server = serviceReference.getService;
server.setId("id" + i);
server.doStuff();
}
}
}
A Type-targetted @Reference annotation would be useful in a number of
scenarios:
- the client requires zero to many conversations (as described above)
- the client requires zero or one conversation (why inject a reference if
it might not be used)
- the client needs fine control of when the conversation is started (the
developer may want lazy reference lookup and won't appreciate the service
being injected before the @init method)
<rfeng>I think what you're asking for is a way to declare references using
annotation without being injected automatically. Another thing is that the
injection of the reference shouldn't trigger the start of the
conversation.</rfeng>
What do you think?
Thank you
Information contained in this e-mail and any attachments are intended for
the use of the addressee only, and may contain confidential information of
Ubiquity Software Corporation. All unauthorized use, disclosure or
distribution is strictly prohibited. If you are not the addressee, please
notify the sender immediately and destroy all copies of this email. Ubiquity
Software Corporation plc, a company registered under the laws of England and
Wales, Registration 2719723, registered offices at Eastern Business Park,
Building 3, Wern Fawr Lane, St. Mellons, Cardiff CF3 5EA, Wales, United
Kingdom.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: Ambiguity in SCA Common Annotations and APIs specification re.
conversations
Posted by Mike Edwards <mi...@gmail.com>.
Nicholas,
As one of the culprits on the Specifications, let me try to give a view
- comments inline.
Yours, Mike.
Nicholas Williams wrote:
> Hi all,
>
> I would like clarification on what I perceive to be an ambiguity in the SCA Common Annotations and API specification regarding when conversations are started.
>
> Lines [475 - 478] reads:
> 475 Conversations start on the client side when one of the following occur:
> 476 * A @Reference to a conversational service is injected
> 477 * A call is made to CompositeContext.getServiceReference [sidenote: should read ComponentContext]
> 478 and then a method of the service is called.
>
> Which of the following behaviour would you expect if a client chooses to call ComponentContext.getServiceReference more than once using the same method arguments:
> a) each returned ServiceReference will refer to separate conversations.
> b) each returned ServiceReference will refer to the same conversation
>
> My interpretation (and preference) would be a). This would allow a client to start multiple conversations to the same reference, which is a common and useful pattern.
>
> **Please could you confirm this is what the spec intends.**
My opinion (and expectation from the spec) is that each ServiceReference
is a separate connection from a client to a provider. Its the same
reference - so the same wire(s) and target(s) are involved.
Logically, for an implementation like Tuscany, I would expect a separate
proxy to be supplied by the runtime to the application.
>
> There is however one ugly element to coding a client that wishes to start multiple conversations to the same reference. Consider the following client code:
>
> @Scope("CONVRSATION")
> @Service(Client.class)
> public class ClientImpl implements Client
> {
>
> @Context
> protected ComponentContext componentContext;
>
> @Reference(name = "server")
> protected Server dummyServer;
>
> public void op(int count)
> {
> for (int i = 0; i < count; i++)
> {
> //create a separate conversation for each iteration
> final ServiceReference<Server> serviceReference = componentContext.getServiceReference(Server.class, "server");
> Server server = serviceReference.getService;
> server.setId("id" + i);
> server.doStuff();
> }
> }
>
> }
>
> The ugly bit in the above code is that I've had to declare an @Reference against a dummyServer field, but I have no intention of using the injected service because I am programmatically using the ComponentContext instead. My suggestion would be to allow the @Reference to target a type (it can currently only target field, method, constructor). The code would become:
>
> @Scope("CONVERSATION")
> @Service(Client.class)
> @Reference(name = "server", type=Server.class)
> public class ClientImpl implements Client
> {
>
> @Context
> protected ComponentContext componentContext;
>
> public void op(int count)
> {
> for (int i = 0; i < count; i++)
> {
> //create a separate conversation for each iteration
> final ServiceReference<Server> serviceReference = componentContext.getServiceReference(Server.class, "server");
> Server server = serviceReference.getService;
> server.setId("id" + i);
> server.doStuff();
> }
> }
>
> }
>
> A Type-targetted @Reference annotation would be useful in a number of scenarios:
> - the client requires zero to many conversations (as described above)
> - the client requires zero or one conversation (why inject a reference if it might not be used)
> - the client needs fine control of when the conversation is started (the developer may want lazy reference lookup and won't appreciate the service being injected before the @init method)
>
There is a distinction (in SCA terms) between getting a reference proxy
for a service that is conversational and the starting of the
conversation itself. The spec quote that you have earlier makes this
clear - there is no conversation in progress until at least one method
of the service interface has been invoked by the client. Merely having
a proxy object in the client code does not constitute the starting of a
conversation.
In principle, it might also be the case that some service operations do
NOT start a conversation. However, the assembly spec does not provide a
way for the service provider to mark the interface in a way that would
make this clear to the client. The safe assumption is that the
invocation of ANY service method involves starting the conversation -
EXCEPT for service methods which are declared to end the conversation
(SCA does provide marking for these methods).
I think that this discussion merits an issue being raised against the
SCA Java C&I specifications to clarify the status of multiple reference
objects obtained via getServiceReference().
The second question you raise of needing to have a way to annotate a
reference WITHOUT getting a reference automatically injected is already
answered in the SCA Java Common Annotations & APIs spec:
Line 1415:
• required (optional) – whether injection of service or services is
required. Defaults to true.
In other words, if you DON'T want a reference injected into a field
annotated with the @reference annotation, say:
@Reference(name="fred" required=false)
> What do you think?
>
> Thank you
>
>
>
>
> Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation. All unauthorized use, disclosure or distribution is strictly prohibited. If you are not the addressee, please notify the sender immediately and destroy all copies of this email. Ubiquity Software Corporation plc, a company registered under the laws of England and Wales, Registration 2719723, registered offices at Eastern Business Park, Building 3, Wern Fawr Lane, St. Mellons, Cardiff CF3 5EA, Wales, United Kingdom.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org