Hello Mike
Yes your explanations helped me really to have a better understanding of the
scope annotation.
Thank you very much.
Best regards
Fahim
2008/11/24 Mike Edwards <[EMAIL PROTECTED]>
> Fahim,
>
> I hope that the explanation is quite straightforward, so I'll try to do
> that inline...
>
> fahim salim wrote:
>
>> Hello All
>>
>> I have seen some samples using @Scope annotation.
>> I have read the SCA Java Common Annotation spec which explains this but
>> it's not very clear.
>> Are there some scenarios explaining for example the following cases:
>> 1/ @Scope("COMPOSITE")
>>
> This scope should be used for services which have some initialization which
> takes a long time - an example might be an in-memory database component.
>
> In this case, there is effectively a singleton for the implementation -
> only one instance object of the implementation class will exist in the
> system and all service invocations go to the same instance.
>
> The challenge for such implementations is that they must be prepared to be
> multi-threaded. All invocations of service methods from all clients go to
> the same instance - and multiple threads can be running multiple invocations
> in parallel at the same time. It is up to the writer of the implementation
> code to provide appropriate serialization.
>
>>
>> 2/ @Scope("CONVERSATION")
>>
> This scope should be used for stateful services, where some state data is
> remembered between invocations of sucessive service methods.
>
> In this case, the conversation starts usually with a given client invoking
> any of the methods on the service interface. An instance of the service
> implementation class is "new" at the start of the conversation. Subsequent
> invocations methods of that service from the same client are then directed
> to the same Java implementation object - so that the implementation class
> can store state information in its member fields (for example) and have that
> information available for those later calls.
>
> The conversation ends when a method marked @EndsConversation is called (or
> when the implementation code calls the ServiceReference.endConversation API
> to end the conversation). Once such a method has been called, the
> implementation instance is discarded (ie the state is thrown away).
>
>
>> 3/ @Scope("STATELESS")
>>
> This should be the default for the implementation of most services -
> stateless services.
>
> In this case, you have a standard Java POJO class. It is stateless in the
> sense that the invocation of every service method is independent any any
> other service method invocations. It is as if the Java object instance for
> the service implementation is "new" for each method invocation.
>
> In reality, the SCA runtime may choose to optimise this, eg by keeping the
> object instances for the class in a pool of object, which it reuses, so as
> to reduce the object allocation overhead. However, the behviour is still as
> if the object is new for each method call.
>
> Note that since each invocation is dispatched to a separate instance, there
> is strictly no need to provide serialization in the implementation code of
> stateless service implementations.
>
>
>> ?
>>
>> Thanks
>> Fahim
>>
>
> I hope that this helps - but please ask more questions if things are still
> not clear.
>
>
> Yours, Mike.
>
