RE: [hyades-dev] RE: [YOUR ACTION REQUIRED] Discussion points fro m Tues

["Toomey, Joe" <jtoomey@xxxxxxxxxxxx>]

Thanks, Antony.  My comments below:

--Joe

Joe Toomey
Senior Staff Software Engineer
Rational Software
IBM Software Group
tel: (781) 676-7668
fax: (781) 676-7640



-----Original Message-----
From: Antony.Miguel@xxxxxxxxxxxxx [mailto:Antony.Miguel@xxxxxxxxxxxxx] 
Sent: Wednesday, March 26, 2003 8:49 AM
To: hyades-dev@xxxxxxxxxxx
Subject: [hyades-dev] RE: [YOUR ACTION REQUIRED] Discussion points from
Tuesday's Execution Team meeting:


2) "Publishing".  In reviewing the sequence diagram that Kris presented 
for "run and monitor a single test", it became clear that we need to 
provide a way to engage monitoring before the test is actually 
"launched", or else we would have a race condition trying to start up 
the IRemoteHyadesComponent to monitor the test.  It was suggested that 
we should split up the launch() method of IExecutor into two methods, 
one of which "publishes" (instantiates the actual remote components), 
and another that actually invokes the IExecutableObject.  Thoughts?

AM> I may be missing something here but is there some reason we can't 
just call startMonitoring() before we call launch()?

JPT> I guess the real root of the issue is: "when do the actual remote 
components get instantiated?".  All of the objects that are shown in our
use case realizations exist on the workbench's node.  Some or all of
these objects are actually proxies for components that will be running
on the Node on which the test/app under test is running.  It has been
assumed until now that the launch() call was one of the calls that 
actually fired up remote components.  This is a problem for the use case
we reviewed yesterday, though, because we want to start monitoring
before the launch happens, but until the launch happens, there are
no hyades components on the remote machine to attach to.

JPT> There are a few alternatives to this problem.  One would be to 
have an explicit "publish" step that fires up remote components as
they are currently modeled, but does not have the additional behavior
associated with a launch.  Another way to solve this problem would be
to create a new API to register a monitoring component (or any remote 
hyades component) with an IExecutionComponent that could be called 
before launch().  (We'd call it something other than startMonitoring(), 
because it wouldn't actually start monitoring until the remote 
components were instantiated.)  I think I prefer the first method 
because it provides more flexibility.

3) Factory pattern.  While the use of the factory pattern seems 
desirable, it looks rather inelegant that we are creating objects 
with a factory and then adding them as children of a 
IExecutionComponent.  In thinking about this more, I think the 
factory pattern may still be a good approach, because we'll need 
an extensibility point for creating alternative implementations
of IExecutor and IRemoteHyadesComponent.  Registering with a 
factory seems like a reasonable way to accomplish this.  Thoughts?

AM> I think that although the factory seems a little inelegant in the 
simple usecases we have so far it will prove itself in the 
implementation of the design.  I'm happy to keep the factory in.

JPT> I agree.

4) Semantic of IExecutableObject.getChildren().  We agreed that
IExecutableObject.getChildren() would only retrieve the direct 
children of the IExecutableObject on which it was invoked.  We also 
agreed that it may be worthwhile to expose an additional API to walk 
the tree and retrieve all of the children, although a client could 
obviously implement their own traversal.  Thoughts?

AM> As far as I can see, any extra API we expose for the purpose of 
getting all children would be there purely for optimisation (and 
possibly convenience) since getChildren() is capable of giving us all 
the information there is - including heirarchy information.

AM> This optimisation is only useful when the tree structure needs to be 
obtained quickly or frequently.  I imagine that in most cases the client 
would build up a picture of the tree from the getChildren() calls before 
they are launched anyway.

AM> Based on this I would think it would be an optimsation of little use.
I would recommend we leave it as just getChildren() for now.  This also 
saves us deciding on some tree structure to represent the nodes.

JPT> I'm fine with not providing another getChildren implementation for
traversing the tree.  We could, though, provide an implementation that
simply flattened the hierarchy and returned all of the children in a 
simple array or collection.  However, I'm not sure how useful that would
be, so I'm fine with deferring until we see an explicit need.  The most 
important thing is that we agree on the semantic of the getChildren() 
call, and document it appropriately.  (I have added a bit to the javadoc 
to reflect this for our second drop.)

cheers

Antony

_______________________________________________
hyades-dev mailing list
hyades-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/hyades-dev