[news.eclipse.tools.hyades] Re: Execution Environment Control / Mgmt

[jptoomey@xxxxxxxxxx]

Execution Environment Control Group Meeting, Feb 27, 2003

Group Members:
Kent Siefkes, Joe Toomey, Kris Kobylinski, Ian Hunter, Clay Williams, 
Neil Sanderson

Attending this meeting:
Kent Siefkes, Joe Toomey, Kris Kobylinski, Neil Sanderson, Mike Norman

Proposed Agenda:

1.  Mike will address a concern Kris raised last week with regards 
    to near term focus for our group in context with what is expected 
    for an initial Hyades release vs. what should be scoped for later 
    iterations.

2.  Discuss next week's meeting agenda.  Kent will be unavailable for 
    next week's meeting, at an IBM managers training in McLean, VA, so 
        he won't be able to present anything on TM execution environment, 
        as originally discussed.  Joe will run the meeting and send out 
        meeting notes in Kent's absence.

Actions/Results:

Mike gave a presentation in order to facilitate discussion on execution
requirements.  The generated discussion was very productive, and we 
agreed on the following base execution requirements.  We have not yet
asserted which of these requirements need to be met by the first drop
of Hyades, but it's clear that it will be a subset.

1.  Deployment (see ** below).  This is decomposed into three parts
  a. Deployment of execution framework
  b. Deployment of the test(s)
  c. Deployment of the SUT
2.  Execute a remote process
3.  Report test status during run (if the test/framework is capable)
    (aka Monitoring)
4.  Control of test execution

** Kris raised concern that deployment is specifically out-of-scope for
project per Hyades slidepack.  The team agreed that we would prefer to 
use an alternate Eclipse deployment mechanism if one existed.  Mike 
took the action to ensure that the requirement for a Deployment activity
within Eclipse is raised via the Tools PMC Lead at the Eclipse board 
meeting next week. Depending on feedback we will need to take a view on
some interim activity we need within the project.

Joe raised concern about the view that vendor specific execution 
capability will likely precede a generic Hyades execution capability.
Asked "Does the first drop of Hyades need to actually do anything, 
or could it simply be an SDK / set of enabling components for 
vendors to adopt and utilize?"  Mike's answer was that the first 
version does not necessarily need to do anything without additional
vendor supplied componentry.  I think it's clear that the first drop
of Hyades will provide usable features for Profiling, while testing
is of concern because we don't want to bless the Test model before we
are able to adapt it to UML 2.0.  Outside the scope of this group.

Someone asked a question about the default Hyades reference 
implementation that we will eventually provide - should it be generic 
or can it be specific(e.g. http) - we haven't determined this, but a 
specific implementation may be sufficient.

Agreed that the point of vendor interoperability is the model (we are
not expecting vendor X's execution engines to be able to run code 
generated by any arbitrary vendor Y's code generator.)

Agreed that we want our agents to expose the same API to both 
the test control (workbench) and other agents.  However, also agreed 
that we will not mandate the use of Hyades interfaces (cf. TCI
[TTCN-3 Control Interface])

Agreed on the need for the following interfaces to support Test:

  1. Install execution engine
  2. Instantiate execution engine

  3. [from Allan's exchange with Mike after the meeting] configure 
     execution environment
  - We may satisfy this with a documented collection of name/value 
    pairs using #6 below

  4. Deploy test to execution engine (send program to execution engine)
  5. Invoke test through execution engine

  6. Send control events to execution engine
  - May define specific events, or may rely on use of name/value pairs.
    Either way, we will need name/value pairs for extensibility 
    purposes.
  - Probably will support two methods of returning data based on control
    events: a direct response via the control channel and an 
        asynchronous flow of data back through the trace model.

Similar set of requirements needed for Trace operations, but without 
need for 4 & 5 (we think.)

Discussion of RAC deferred until Richard provides API, however Mike 
mentioned the possibility that we may not want to use the RAC.  This was 
a surprising comment, and needs further discussion soon.

Mike proposed the following "Thoughts for progress"

* Concentrate on interfaces
* Start with the API inside the workbench that fires up Agents/Engines
* Start with a minimal set of functions
* Work out how to build that API on top of the RAC
* Then consider the remote end of that interface
* (omitted from slides) consider what extensibility points need to be
  provided and where they should exist

Joe took action item to propose a set of APIs.

Joe will run next week's meeting in Kent's absence.