RE: [hyades-dev] Hyades Base Agent & Collector Interface Specification

["Charles Earl" <earl@xxxxxxxxxxxxxxxxx>]

Andy, 
I would say that the overwhelming majority of agent platforms seem to be
implemented in Java. Larger efforts include the DARPA funded
http://www.cougaar.org/ project (largely BBN), the Lockheed Martin EMAA
project http://www.atl.external.lmco.com/overview/programs/IS/EMAA.html and
the Jade (Java Agent Development Environment) at http://jade.tilab.com/.
We've been attempting to integrate an agent system that we've been
developing for handling distributed job recovery and troubleshooting into
the Hyades framework. This is being developed to support a physics grid
environment at Lawrence Berkeley Lab. We've been talking to EDA tool
developers in hopes of making the system applicable for their grids. We're
looking at the Hyades agent discussion with high interest.
Charles

> -----Original Message-----
> From: hyades-dev-admin@xxxxxxxxxxx [mailto:hyades-dev-admin@xxxxxxxxxxx]
> On Behalf Of Kaylor, Andrew
> Sent: Tuesday, August 10, 2004 8:16 PM
> To: hyades-dev@xxxxxxxxxxx
> Subject: RE: [hyades-dev] Hyades Base Agent & Collector Interface
> Specification
> 
> It's my understanding that JNI actually uses a variant of UTF-8 where
> null characters are represented in a two-byte format, so we may have an
> issue to deal with either way, and we should clearly specify what we
> mean by UTF-8 (standard or JNI interpretation).
> 
> Can anyone tell me roughly what percentage of existing agents are
> implemented in Java?
> 
> -Andy
> 
> -----Original Message-----
> From: hyades-dev-admin@xxxxxxxxxxx [mailto:hyades-dev-admin@xxxxxxxxxxx]
> On Behalf Of Allan K Pratt
> Sent: Monday, August 09, 2004 5:52 PM
> To: hyades-dev@xxxxxxxxxxx
> Subject: Re: [hyades-dev] Hyades Base Agent & Collector Interface
> Specification
> 
> These are some review notes upon reading this document for the first
> time.
> 
> As I read a document like this I try to wear several hats:
>         1. Does this cover everything I might need or want within its
> scope?
>         2. Could I implement an agent based only on this document,
> without
> ambiguity, contradiction, or holes?
>         3. Could I implement a CLIENT of an agent based only on this
> document? Could I reliably drive a generic conforming agent?
> 
> I notice that some strings in this spec say they are UTF-8, and others
> do
> not. If you have a "Conventions" section at the top that says ALL
> strings
> are UTF-8, you won't have to worry about mentioning it in the
> description
> of every command and response that uses strings. If this document is
> based
> on some presumed conventions (at Layer 1 or Layer 0?) then you should
> refer to those explicitly.
> 
> Oh, and are the UTF-8 strings also null-terminated? All strings come
> with
> a length count, but it can also be convenient (especially for native
> C/C++
> code) if they're null terminated. This question applies across the
> board,
> at all levels of the protocol. And then make sure you say whether the
> length count includes the null byte.
> 
> 1.1.1.2.1 Initialize: Is there a requirement that somebody call
> initialize
> before doing anything else with the agent? If so, how can a program
> driving the agent know whether Initialize has already been called or
> not?
> Consider a long-running agent which could survive across multiple client
> 
> (Workbench) sessions. What if I call Initialize again, after it's
> already
> been called -- does the agent reset its state, or ignore the second
> Initialize command, or what? I think we have to remember how loose the
> coupling is between agents and the code that drives them, and not burden
> 
> the clients with preconditions ("Call Init before calling anything else,
> 
> but only call it once").
> 
> 1.1.1.2.2 Deregister: Once an agent is de-registered, it seems like it
> would be impossible to send it any more commands. How is this different
> from Terminate?
> 
> 1.1.1.2.3 Get Agent Name: the text says, "Agent Name is like a class
> name." What does that mean? And why is there a reference to agent
> metadata
> in this section and nowhere else?
> 
> 1.1.1.2.5 Is Attached: does this query make sense for an agent that can
> be
> attached to multiple processes simultaneously? Is there a reason you
> didn't write a query for me to find out WHAT process(es) the agent is
> attached to?
> 
> 1.1.1.2.7 Un-Initialize: What state is the agent in after calling
> Un-Initialize? How is it different from Reset?
> 
> 1.1.1.3.4/5 Set/Add Property: I don't think it's necessary to have "Add
> Property" ... Is it so bad if "Set Property" has the behavior of "Add"
> if
> the property doesn't already exist?
> 
> 1.1.1.3.7 Validate Configuration: The existence of this command implies
> that it's possible to send an invalid property set to the agent without
> the Set Property or Set Property Bag commands returning an error. Is
> that
> wise? What is the behavior of the agent if the configuration is not
> valid?
> 
> 1.1.1.4.3 Get WSDL Definition: Why does this command's description use
> conditional language? The response data is "possibly" in WSDL format?
> What's the alternative? This is a specification; it shouldn't leave
> things
> open-ended like this. If it's like this because the question is
> unresolved, I'd like to see the description say so.
> 
> 1.1.1.4.4 Check Compatibility (with another agent): Besides an
> affirmative
> "yes" and an affirmative "no," another likely response is "I don't know,
> 
> I've never heard of that agent." Or is that one of the error codes
> available to the NOT_COMPATIBLE response? Since this document doesn't
> list
> error codes, I can't tell.
> 
> 1.1.1.5.1 Add Agent Event Listener: Is the mapping of Event IDs to
> events
> known? Or maybe events and their IDs are always agent-defined. In that
> case a generic client couldn't make use of this. Unless the events and
> IDs
> are defined in the WSDL or something else queryable. Also, why do I have
> 
> to send the Server ID in this case? Isn't it implicitly "the same server
> 
> that this command came through"?
> 
> About add/remove agent event listener and also "set property bag": are
> these commands meant to be transactional? That is, if there is an error
> in
> processing ANY PART of the command, you reject and ignore ALL of it?
> Otherwise I can see being *partly* deregistered, or having changed
> *part*
> of the property bag.
> 
> 1.1.1.6 Base Collector Interface: As noted in the text, this interface
> is
> designed for agents which collect observation data locally, and return
> that data to callers on demand. Not all agents work like that; maybe
> there
> should be two subclasses of base agents, for "live data" and "aggregated
> 
> data" types.
> 
> 1.1.1.6.1 Run: I can't make out this command. Is it required to get data
> 
> collection going? I think it suffers from the same problems as Init.
> 
> 1.1.1.6.8 Agent State Machine: This diagram doesn't match the commands
> listed above. The "Run" command doesn't appear in the diagram, and the
> "Configure" command does. "Get Data," too, is on the diagram and not in
> the description. Also, reading the diagram I notice that Cancel is not
> allowed from the Data Waiting state. If I've sent Stop and then decide I
> 
> don't want the data, Cancel should be allowed. Also, Reset seems like it
> 
> should be available from all states. Finally, I can't make out the state
> 
> pattern or usage scenario for "Snapshot" and how it relates to the "Data
> 
> Ready" event and state.
> 
> -- Allan Pratt, apratt@xxxxxxxxxx
> Rational software division of IBM
> 
> _______________________________________________
> hyades-dev mailing list
> hyades-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/hyades-dev
> _______________________________________________
> hyades-dev mailing list
> hyades-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/hyades-dev