Re: [Vrs-development] thoughts

[Chris Smith]

On Wednesday 27 March 2002 02:20, Open Source wrote:

> The idea i had was that the mobile agent to be a
> plugin module to any part of VRS including the
> middleware.  The mobile agent uses a published API of
> the middleware to provide a range of services.

The agent will run in the sandbox.  The sandbox runs over
the middleware, so any middleware functionality you want
to allow agents to access needs to be exposed through the
sandbox.

Therefore the functionality of the agents (of the type
we're considering) is limited to the exposed middleware
API.  Which will be limited.

> If we the use the above approach, the mobile agent
> will not be accessing the physical machine but the
> sanbox within which the VRS is running.

I'm not convinced that the middleware should be exposed
at all, because if it were to change in any way, or be
replaced by another middlware altogether, then you'd be
stuffed.  The middleware supports the application built
upon it, in this case the VRS.  It is not there to
support the agents running in the VRS - you're crossing
an abstraction boundary.

This is not to say that we can't do it.  I think it's a
very interesting idea, and one that we should at least
consider!

However, if you were to expose middleware functionality,
then it has to be abstracted, which means development
time and effort and thus a limited set of functionality.
I think anyway.

> The usage of the mobile agent can be further extended
> to handle aysnc control messages used within the
> cluster.

EEK! No!
I may have completely missunderstood you but the whole
point of using a middleware is to provide you (among
other things) with synchronous and asynchronous message
passing and routing!
The VRS control messages are generated by the LDS code 
and are passed down to the middleware layer for routing
and delivery.  The whole VRS is built on the base 
architecture that the middleware provides.
Besides, anything running in the sandbox has no idea that
they're on one machine of a cluster.

I have no argument with agents querying the VRS through a
defined API (say some sort of MIB), but we can't allow
more than that... the fact that there is a middleware 
there at all is irrelevent.

Imagine that we published an Interface Specification for
the LDS/VRS.  Anyone could then write their own implementation.
Agents/services/etc would run on any vendors implementation,
so long as the agent/service adhered to the spec and so did
the vendor.
Exactly how the 'VRS' was implemented internally would be
up to the vendor..... they might even use paper cups and
string as a network.....
Of course this isn't going to happen, 'cos we're developing
Free Software, but it does illustrate the dangers of
assuming implementation details will be visible in one
form or other.

If I'm preaching to the converted, please accept my appology :o)

Lets not throw the agent idea away though - it's a very
interesting idea, and may solve some problems for us...
They're just at the wrong layer....
Perhaps we could start by identifying features to expose through
the API?  BTW, these agents would only run on LDS/VRS's.


Best regards,
Chris


-- 
Chris Smith
  Technical Architect - netFluid Technology Limited.
  "Internet Technologies, Distributed Systems and Tuxedo Consultancy"
  E: address@hidden  W: http://www.nfluid.co.uk