Re: Elementary question about Scopes

["Millies, Sebastian" <Se...@ids-scheer.com>]

Hi there,

I am going back to an old discussion we had in December, and
which I've just had occasion to revisit.

I wonder if I'm reading too much into the following statement
of Simon Nash's:

> -----Original Message-----
> From: Simon Nash [mailto:nash@apache.org]
> Sent: Friday, December 10, 2010 10:21 AM
> To: user@tuscany.apache.org
> Subject: Re: Elementary question about Scopes

[snip]
 
>  With COMPOSITE scope, the SCA runtime
> can control the creation and lifetime of the COMPOSITE instance rather
> than being at the mercy of what the JVM does.  If the domain is entrely
> contained within a single JVM, this distinction may not be important.
> For other scenarios such as a server cluster or a distributed domain,
> there will be multiple Java instances of the same SCA COMPOSITE-scoped
> object, with updates coordinated by the SCA runtime. it is essential
> that
> the SCA runtime has the ability to manage this situation and give all
> the JVMs the appearance of a single shared COMPOSITE-scoped object even
> though the actual physical reality might be somewhat different.

Now, I've just finished coding a COMPOSITE scoped component that is
supposed to serve as a sort of global registry for some kinds of
objects (somewhat akin to a server that would coordinate locks on
business objects). This component also contains some rather fine-grained
synchronization on internal data structures for optimized concurrency.

I wonder how the SCA runtime would be able to "coordinate updates" in
view of this. Can I (should I?) ensure that it is really ALWAYS THE
SAME INSTANCE of the component that requests are directed to, even in a
cluster?

I am also not clear about how distributed domains come into the picture.
I had thought the point of a distributed domain was to have several DIFFERENT
composites run in the same domain in different JVMs, even on different servers.
Simon's message makes it sound as if I would distribute the SAME component
over several JVMs.

-- Sebastian

Re: Elementary question about Scopes

[Simon Nash <na...@apache.org>]

Millies, Sebastian wrote:
> Hi there,
> 
> I am going back to an old discussion we had in December, and
> which I've just had occasion to revisit.
> 
> I wonder if I'm reading too much into the following statement
> of Simon Nash's:
> 
>> -----Original Message-----
>> From: Simon Nash [mailto:nash@apache.org]
>> Sent: Friday, December 10, 2010 10:21 AM
>> To: user@tuscany.apache.org
>> Subject: Re: Elementary question about Scopes
> 
> [snip]
>  
>>  With COMPOSITE scope, the SCA runtime
>> can control the creation and lifetime of the COMPOSITE instance rather
>> than being at the mercy of what the JVM does.  If the domain is entrely
>> contained within a single JVM, this distinction may not be important.
>> For other scenarios such as a server cluster or a distributed domain,
>> there will be multiple Java instances of the same SCA COMPOSITE-scoped
>> object, with updates coordinated by the SCA runtime. it is essential
>> that
>> the SCA runtime has the ability to manage this situation and give all
>> the JVMs the appearance of a single shared COMPOSITE-scoped object even
>> though the actual physical reality might be somewhat different.
> 
> Now, I've just finished coding a COMPOSITE scoped component that is
> supposed to serve as a sort of global registry for some kinds of
> objects (somewhat akin to a server that would coordinate locks on
> business objects). This component also contains some rather fine-grained
> synchronization on internal data structures for optimized concurrency.
> 
> I wonder how the SCA runtime would be able to "coordinate updates" in
> view of this. Can I (should I?) ensure that it is really ALWAYS THE
> SAME INSTANCE of the component that requests are directed to, even in a
> cluster?
> 
> I am also not clear about how distributed domains come into the picture.
> I had thought the point of a distributed domain was to have several DIFFERENT
> composites run in the same domain in different JVMs, even on different servers.
> Simon's message makes it sound as if I would distribute the SAME component
> over several JVMs.
> 
> -- Sebastian
> 
> 
According to the SCA-J specification:

  Where an implementation is used by a "domain level component", and the
  implementation is marked "Composite" scope, the SCA runtime MUST ensure
  that all consumers of the component appear to be interacting with a
  single runtime instance of the implementation. [JCA20004]

  Where an implementation is marked "Composite" scope and it is used by a
  component that is nested inside a composite that is used as the implementation
  of a higher level component, the SCA runtime MUST ensure that all consumers of
  the component appear to be interacting with a single runtime instance of the
  implementation. There can be multiple instances of the higher level component,
  each running on different nodes in a distributed SCA runtime. [JCA20008]

  The SCA runtime can exploit shared state technology in combination with other
  well known high availability techniques to provide the appearance of a single
  runtime instance for consumers of composite scoped components.

The key phrases here are "...appear to be interacting with a single runtime
instance..." and "...provide the appearance of a single runtime instance..."

The current Tuscany implementation uses a single runtime instance.  However,
the SCA-J specification permits the use of multiple instances as long as the
appearance of using a single instance is maintained.  This means that you can
safely write code that assumes a single instance, as any SCA implementation
that uses multiple instances would need to fully emulate the appearance of
having a single instance with respect to any code that you have written.

   Simon