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:[email protected]] Sent: Wednesday, December 08, 2010 10:43 PM To: [email protected] 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:[email protected]] > Sent: Wednesday, December 08, 2010 6:31 PM > To: [email protected] > Subject: Re: Elementary question about Scopes > > On Wed, Dec 8, 2010 at 12:27 AM, Millies, Sebastian > <[email protected]> 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) >
