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.
