You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@tuscany.apache.org by "Millies, Sebastian" <Se...@ids-scheer.com> on 2010/12/08 09:27:26 UTC
Elementary question about Scopes
I've noticed that I have been making some of my services COMPOSITE scope,
others not, without apparent reason. My question regards the difference
between composite and default (request) scope, disregarding conversations.
As I see it, either a service implementation maintains state or it does not.
If it does, it must be made composite scope, so as not to lose the state between
requests, and one must take care of shared access (thread issues) in one's
programming.
If it does not, it wouldn't matter if it were composite scope, as there would
be no shared state to care about how to access anyway. So it could as well be made
composite.
A service being composite scope earns the additional benefit of the init()
method, which can be costly, only being executed once.
So I would decide to make all my services composite scope by default.
Would that be wrong? In other words, is there any particular advantage associated
with default scope services? Any specific runtime properties in Tuscany 1.6 perhaps?
-- Sebastian
Re: Elementary question about Scopes
Posted by Simon Nash <na...@apache.org>.
Millies, Sebastian wrote:
> Yes, I see the point about callbacks.
>
> With regard to the other, cosmetic differences, what you regard as ugly, I
> regard as good programming practice. To me, instance variables represent the
> state of an object, in particular mutable state. If there is no such state,
> I find it much clearer to pass parameters as method arguments rather than
> to store them in instance variables.
>
With STATELESS scope, the object instance == the individual service request.
Therefore it is completely appropriate to store data relating only to the
individual request as instance variables of this object.
Simon
> (In UML, I would represent the dependency of the service class to the argument
> classes as simple dependencies, not as a form of association or aggregation.)
>
> Interesting to hear that your mind works differently.
>
> So I will go and make all my services composite scope, at least as long as
> callbacks do not come into play.
>
> -- Sebastian
>
> -----Original Message-----
> From: Simon Nash [mailto:nash@apache.org]
> Sent: Wednesday, December 08, 2010 10:43 PM
> To: user@tuscany.apache.org
> Subject: Re: Elementary question about Scopes
>
> Millies, Sebastian wrote:
>> Hi Luciano,
>>
>> thanks for the pointer, but I already knew that background.
>>
>> My question is: why not make every service composite scope? (With the
>> arguments in favor of that approach given in my original post.)
>> Perhaps I misunderstood something?
>>
> This is an interesting question. There are differences, though most
> of them seem to be cosmetic rather than fundamental.
>
> The most obvious difference is the need to declare all variables
> as method local instead of as instance variables. This could result
> in significant duplication of declarations when the same variables
> are used by multiple methods.
>
> Also, if one method calls another directly (rather than via SCA), using
> COMPOSITE scope and method local variables means that the variables in
> the first method won't be visible to the second. This can be solved by
> passing the variables as method parameters, though this could make the
> code very ugly.
>
> Taking the previous thought a step further, if an SCA method calls
> non-SCA code and passes "this" as a parameter, any method calls back
> to the same instance will see any request-specific state that was set up
> in instance variables but won't see request-specific state if this
> was set up in method local variables.
>
> There are also differences in when @Init and @Destroy methods are run.
> For STATELESS scope these are run for every request. For COMPOSITE
> scope they are run once only. Again this could be worked around for the
> COMPOSITE scope approach by having every method of a service interface
> explicitly call initialization and termination code, at the cost of yet
> more ugliness.
>
> If you're using callbacks, STATELESS scope is more convenient because
> the callback reference can be injected by the SCA runtime. With
> CONVERSATION scope you need to use API calls to get the callback
> reference out of the request context, which is a bit messy.
>
> There are differences in how property injection works. With STATELESS
> scope, property values are injected as initial values into every
> instance, and these initial values can then be modified by request code
> without affecting other requests. With COMPOSITE scope it would be
> necessary to copy the properties into method local variables before
> modifying them.
>
> Simon
>
>> -- Sebastian
>>
>> -----Original Message-----
>> From: Luciano Resende [mailto:luckbr1975@gmail.com]
>> Sent: Wednesday, December 08, 2010 6:31 PM
>> To: user@tuscany.apache.org
>> Subject: Re: Elementary question about Scopes
>>
>> On Wed, Dec 8, 2010 at 12:27 AM, Millies, Sebastian
>> <Se...@ids-scheer.com> wrote:
>>> I've noticed that I have been making some of my services COMPOSITE scope,
>>> others not, without apparent reason. My question regards the difference
>>> between composite and default (request) scope, disregarding conversations.
>>>
>>> As I see it, either a service implementation maintains state or it does not.
>>> If it does, it must be made composite scope, so as not to lose the state between
>>> requests, and one must take care of shared access (thread issues) in one's
>>> programming.
>>>
>>> If it does not, it wouldn't matter if it were composite scope, as there would
>>> be no shared state to care about how to access anyway. So it could as well be made
>>> composite.
>>>
>>> A service being composite scope earns the additional benefit of the init()
>>> method, which can be costly, only being executed once.
>>>
>>> So I would decide to make all my services composite scope by default.
>>>
>>> Would that be wrong? In other words, is there any particular advantage associated
>>> with default scope services? Any specific runtime properties in Tuscany 1.6 perhaps?
>>>
>>> -- Sebastian
>>>
>> In the 1.x context, here is a good explanation from Mike:
>>
>> http://tuscany.markmail.org/thread/ubfs2ohn67vv5nw2
>>
>> In 2.x, the SCA Specs reduced to only support COMPOSITE and STATELESS (default)
>>
>
RE: Elementary question about Scopes
Posted by "Millies, Sebastian" <Se...@ids-scheer.com>.
Yes, I see the point about callbacks.
With regard to the other, cosmetic differences, what you regard as ugly, I
regard as good programming practice. To me, instance variables represent the
state of an object, in particular mutable state. If there is no such state,
I find it much clearer to pass parameters as method arguments rather than
to store them in instance variables.
(In UML, I would represent the dependency of the service class to the argument
classes as simple dependencies, not as a form of association or aggregation.)
Interesting to hear that your mind works differently.
So I will go and make all my services composite scope, at least as long as
callbacks do not come into play.
-- Sebastian
-----Original Message-----
From: Simon Nash [mailto:nash@apache.org]
Sent: Wednesday, December 08, 2010 10:43 PM
To: user@tuscany.apache.org
Subject: Re: Elementary question about Scopes
Millies, Sebastian wrote:
> Hi Luciano,
>
> thanks for the pointer, but I already knew that background.
>
> My question is: why not make every service composite scope? (With the
> arguments in favor of that approach given in my original post.)
> Perhaps I misunderstood something?
>
This is an interesting question. There are differences, though most
of them seem to be cosmetic rather than fundamental.
The most obvious difference is the need to declare all variables
as method local instead of as instance variables. This could result
in significant duplication of declarations when the same variables
are used by multiple methods.
Also, if one method calls another directly (rather than via SCA), using
COMPOSITE scope and method local variables means that the variables in
the first method won't be visible to the second. This can be solved by
passing the variables as method parameters, though this could make the
code very ugly.
Taking the previous thought a step further, if an SCA method calls
non-SCA code and passes "this" as a parameter, any method calls back
to the same instance will see any request-specific state that was set up
in instance variables but won't see request-specific state if this
was set up in method local variables.
There are also differences in when @Init and @Destroy methods are run.
For STATELESS scope these are run for every request. For COMPOSITE
scope they are run once only. Again this could be worked around for the
COMPOSITE scope approach by having every method of a service interface
explicitly call initialization and termination code, at the cost of yet
more ugliness.
If you're using callbacks, STATELESS scope is more convenient because
the callback reference can be injected by the SCA runtime. With
CONVERSATION scope you need to use API calls to get the callback
reference out of the request context, which is a bit messy.
There are differences in how property injection works. With STATELESS
scope, property values are injected as initial values into every
instance, and these initial values can then be modified by request code
without affecting other requests. With COMPOSITE scope it would be
necessary to copy the properties into method local variables before
modifying them.
Simon
> -- Sebastian
>
> -----Original Message-----
> From: Luciano Resende [mailto:luckbr1975@gmail.com]
> Sent: Wednesday, December 08, 2010 6:31 PM
> To: user@tuscany.apache.org
> Subject: Re: Elementary question about Scopes
>
> On Wed, Dec 8, 2010 at 12:27 AM, Millies, Sebastian
> <Se...@ids-scheer.com> wrote:
>> I've noticed that I have been making some of my services COMPOSITE scope,
>> others not, without apparent reason. My question regards the difference
>> between composite and default (request) scope, disregarding conversations.
>>
>> As I see it, either a service implementation maintains state or it does not.
>> If it does, it must be made composite scope, so as not to lose the state between
>> requests, and one must take care of shared access (thread issues) in one's
>> programming.
>>
>> If it does not, it wouldn't matter if it were composite scope, as there would
>> be no shared state to care about how to access anyway. So it could as well be made
>> composite.
>>
>> A service being composite scope earns the additional benefit of the init()
>> method, which can be costly, only being executed once.
>>
>> So I would decide to make all my services composite scope by default.
>>
>> Would that be wrong? In other words, is there any particular advantage associated
>> with default scope services? Any specific runtime properties in Tuscany 1.6 perhaps?
>>
>> -- Sebastian
>>
>
> In the 1.x context, here is a good explanation from Mike:
>
> http://tuscany.markmail.org/thread/ubfs2ohn67vv5nw2
>
> In 2.x, the SCA Specs reduced to only support COMPOSITE and STATELESS (default)
>
Re: Elementary question about Scopes
Posted by Simon Nash <na...@apache.org>.
Millies, Sebastian wrote:
> Hi Luciano,
>
> thanks for the pointer, but I already knew that background.
>
> My question is: why not make every service composite scope? (With the
> arguments in favor of that approach given in my original post.)
> Perhaps I misunderstood something?
>
This is an interesting question. There are differences, though most
of them seem to be cosmetic rather than fundamental.
The most obvious difference is the need to declare all variables
as method local instead of as instance variables. This could result
in significant duplication of declarations when the same variables
are used by multiple methods.
Also, if one method calls another directly (rather than via SCA), using
COMPOSITE scope and method local variables means that the variables in
the first method won't be visible to the second. This can be solved by
passing the variables as method parameters, though this could make the
code very ugly.
Taking the previous thought a step further, if an SCA method calls
non-SCA code and passes "this" as a parameter, any method calls back
to the same instance will see any request-specific state that was set up
in instance variables but won't see request-specific state if this
was set up in method local variables.
There are also differences in when @Init and @Destroy methods are run.
For STATELESS scope these are run for every request. For COMPOSITE
scope they are run once only. Again this could be worked around for the
COMPOSITE scope approach by having every method of a service interface
explicitly call initialization and termination code, at the cost of yet
more ugliness.
If you're using callbacks, STATELESS scope is more convenient because
the callback reference can be injected by the SCA runtime. With
CONVERSATION scope you need to use API calls to get the callback
reference out of the request context, which is a bit messy.
There are differences in how property injection works. With STATELESS
scope, property values are injected as initial values into every
instance, and these initial values can then be modified by request code
without affecting other requests. With COMPOSITE scope it would be
necessary to copy the properties into method local variables before
modifying them.
Simon
> -- Sebastian
>
> -----Original Message-----
> From: Luciano Resende [mailto:luckbr1975@gmail.com]
> Sent: Wednesday, December 08, 2010 6:31 PM
> To: user@tuscany.apache.org
> Subject: Re: Elementary question about Scopes
>
> On Wed, Dec 8, 2010 at 12:27 AM, Millies, Sebastian
> <Se...@ids-scheer.com> wrote:
>> I've noticed that I have been making some of my services COMPOSITE scope,
>> others not, without apparent reason. My question regards the difference
>> between composite and default (request) scope, disregarding conversations.
>>
>> As I see it, either a service implementation maintains state or it does not.
>> If it does, it must be made composite scope, so as not to lose the state between
>> requests, and one must take care of shared access (thread issues) in one's
>> programming.
>>
>> If it does not, it wouldn't matter if it were composite scope, as there would
>> be no shared state to care about how to access anyway. So it could as well be made
>> composite.
>>
>> A service being composite scope earns the additional benefit of the init()
>> method, which can be costly, only being executed once.
>>
>> So I would decide to make all my services composite scope by default.
>>
>> Would that be wrong? In other words, is there any particular advantage associated
>> with default scope services? Any specific runtime properties in Tuscany 1.6 perhaps?
>>
>> -- Sebastian
>>
>
> In the 1.x context, here is a good explanation from Mike:
>
> http://tuscany.markmail.org/thread/ubfs2ohn67vv5nw2
>
> In 2.x, the SCA Specs reduced to only support COMPOSITE and STATELESS (default)
>
RE: Elementary question about Scopes
Posted by "Millies, Sebastian" <Se...@ids-scheer.com>.
Hi Luciano,
thanks for the pointer, but I already knew that background.
My question is: why not make every service composite scope? (With the
arguments in favor of that approach given in my original post.)
Perhaps I misunderstood something?
-- Sebastian
-----Original Message-----
From: Luciano Resende [mailto:luckbr1975@gmail.com]
Sent: Wednesday, December 08, 2010 6:31 PM
To: user@tuscany.apache.org
Subject: Re: Elementary question about Scopes
On Wed, Dec 8, 2010 at 12:27 AM, Millies, Sebastian
<Se...@ids-scheer.com> wrote:
> I've noticed that I have been making some of my services COMPOSITE scope,
> others not, without apparent reason. My question regards the difference
> between composite and default (request) scope, disregarding conversations.
>
> As I see it, either a service implementation maintains state or it does not.
> If it does, it must be made composite scope, so as not to lose the state between
> requests, and one must take care of shared access (thread issues) in one's
> programming.
>
> If it does not, it wouldn't matter if it were composite scope, as there would
> be no shared state to care about how to access anyway. So it could as well be made
> composite.
>
> A service being composite scope earns the additional benefit of the init()
> method, which can be costly, only being executed once.
>
> So I would decide to make all my services composite scope by default.
>
> Would that be wrong? In other words, is there any particular advantage associated
> with default scope services? Any specific runtime properties in Tuscany 1.6 perhaps?
>
> -- Sebastian
>
In the 1.x context, here is a good explanation from Mike:
http://tuscany.markmail.org/thread/ubfs2ohn67vv5nw2
In 2.x, the SCA Specs reduced to only support COMPOSITE and STATELESS (default)
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: Elementary question about Scopes
Posted by Luciano Resende <lu...@gmail.com>.
On Wed, Dec 8, 2010 at 12:27 AM, Millies, Sebastian
<Se...@ids-scheer.com> wrote:
> I've noticed that I have been making some of my services COMPOSITE scope,
> others not, without apparent reason. My question regards the difference
> between composite and default (request) scope, disregarding conversations.
>
> As I see it, either a service implementation maintains state or it does not.
> If it does, it must be made composite scope, so as not to lose the state between
> requests, and one must take care of shared access (thread issues) in one's
> programming.
>
> If it does not, it wouldn't matter if it were composite scope, as there would
> be no shared state to care about how to access anyway. So it could as well be made
> composite.
>
> A service being composite scope earns the additional benefit of the init()
> method, which can be costly, only being executed once.
>
> So I would decide to make all my services composite scope by default.
>
> Would that be wrong? In other words, is there any particular advantage associated
> with default scope services? Any specific runtime properties in Tuscany 1.6 perhaps?
>
> -- Sebastian
>
In the 1.x context, here is a good explanation from Mike:
http://tuscany.markmail.org/thread/ubfs2ohn67vv5nw2
In 2.x, the SCA Specs reduced to only support COMPOSITE and STATELESS (default)
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/