Re: Programmatically dynamic distributed app without a domain manager

["Maloney, Robert A" <bm...@bottomline.com>]

Hello Simon,

Sorry for the delay, as I was out on vacation all last week.

>> Regarding 2281, I assume that also eliminates the need for workers to
be
>> a reference collection, and can go back to being just one reference?

>Not sure I understand this comment. I'm probably missing something in
the
>way that you have your scenario set up.

Sorry, what I meant was: will the change revert the reference
collection:

  @Reference
  protected List<Worker> workers;

back to:

  @Reference
  protected Worker worker;

Based on your response, it will not.  The reason I was asking was in
reference to my other issue of having to add the service name to all the
interface methods.

> If you are passing the names about in method calls it suggests that
> components outside of the scheduler need to know that the workers
exist.
> Are you vending out work references in some way?

Basically, yes.  The Scheduler app is existing non-component code, and
we are currently (due to time constraints) only converting the IPC
interface to Tuscany.  So the access I have to the scheduler component
within the full Scheduler app is the getService() from the SCAClient.
Unfortunately, it again seems that I am currently forcing constrained
usage of Tuscany to a web service interface framework, instead of an
overall architecture.  But this is getting our foot in the door.

I think the main issue is that I have been thinking about the scheduler
component as only part of the Scheduler app, and not that the Scheduler
app is actually contained within the scheduler component.  Time for some
more thinking...

> There is a JIRA for this
(http://issues.apache.org/jira/browse/TUSCANY-
> 2662). It looks like it's been fixed in the 1.x branch and the 1.3.3.
> branch.

Great, thanks.  Any update as to the release of the next version?

Regards,

Bob

Re: Programmatically dynamic distributed app without a domain manager

[Simon Laws <si...@googlemail.com>]

Hi Bob

Comments in line...

Simon

On Mon, Dec 1, 2008 at 6:59 PM, Maloney, Robert A
<bm...@bottomline.com>wrote:

> Hello Simon,
>
> Sorry for the delay, as I was out on vacation all last week.
>
> >> Regarding 2281, I assume that also eliminates the need for workers to
> be
> >> a reference collection, and can go back to being just one reference?
>
> >Not sure I understand this comment. I'm probably missing something in
> the
> >way that you have your scenario set up.
>
> Sorry, what I meant was: will the change revert the reference
> collection:
>
>  @Reference
>  protected List<Worker> workers;
>
> back to:
>
>  @Reference
>  protected Worker worker;
>
> Based on your response, it will not.


Yes, having a reference with multiplicity greater than 1 means that the
reference should be declared as a collection. The 2281 fix added an API to
get a collection of references through the API as an alternative to having
the collection of references injected.

 The reason I was asking was in
> reference to my other issue of having to add the service name to all the
> interface methods.
>
> > If you are passing the names about in method calls it suggests that
> > components outside of the scheduler need to know that the workers
> exist.
> > Are you vending out work references in some way?
>
> Basically, yes.  The Scheduler app is existing non-component code, and
> we are currently (due to time constraints) only converting the IPC
> interface to Tuscany.  So the access I have to the scheduler component
> within the full Scheduler app is the getService() from the SCAClient.
> Unfortunately, it again seems that I am currently forcing constrained
> usage of Tuscany to a web service interface framework, instead of an
> overall architecture.  But this is getting our foot in the door.


OK, I see. So if you do need to distinguish one worker from another you have
to pass its name about. If you didn't care which worker was which, as long
as you had access to them, then I guess you could get by without the worker
name.


>
>
> I think the main issue is that I have been thinking about the scheduler
> component as only part of the Scheduler app, and not that the Scheduler
> app is actually contained within the scheduler component.  Time for some
> more thinking...


SCA doesn't really say anything about work distribution/balancing and so
there are any number of ways the effect can be achieved. We have covered
some in this conversation, e.g. registering composite scoped service
instances with a scheduler component, using a load balancer to spray load
across stateless scoped component instances running in a cluster, etc. It
may even be that some new function, e.g. a new binding which understands
load balancing, is appropriate. Anything we can do to make this kind of
thing easier and more obvious in Tuscany is a good thing so I'm interested
in where your thoughts lead.


>
>
> > There is a JIRA for this
> (http://issues.apache.org/jira/browse/TUSCANY-
> > 2662). It looks like it's been fixed in the 1.x branch and the 1.3.3.
> > branch.
>
> Great, thanks.  Any update as to the release of the next version?


Yep, we're hopefully making a 1.4 release candidate today. Then we all have
to test it and get it out the door. Usually takes a week or so.


>
>
> Regards,
>
> Bob
>