[seek-dev] EcoGrid Query Service: Instances and Factories
sekar at sdsc.edu
Tue Jan 20 18:04:51 PST 2004
I agree because all our underlying systems are
client-server systems. But at a later stage if we involve
systems that are standalone and are invokable through RPC/system/ssh
calls then the factory will be of use.
So, for the present we can remove the Factory layer as it just adds to
complexity and additional transformation (unneeded) for client-server
On Tue, 20 Jan 2004, Matt Jones wrote:
> EcoGrid team,
> I've been working on the registry issues, and have run into some issues
> with the way Jing and Bing are using the Grid "Factory" pattern. As
> they have implmented it, each wrapped server (like a metacat or srb)
> exposes a "Factory" which has a "createInstance" method. When called, a
> new endpoint is created that exposes the methods in our
> EcoGridQeuryLevelOne interface spec. This endpoint is then queried by
> only that one client. However, this pattern makes it very hard for us
> to discover where the EcoGridQueryLevelOne services reside, because they
> don't exist at the time that the client is querying the registry.
> I don't see what we gain from using the factory pattern here at all
> (given our underlying server systems), so I am proposing we eliminate
> use of Factories and just stick to EcoGridQueryLevelOne instances. I
> think that doing so would substnatially simplify the demands on clients
> in the service discovery pahse while clients are querying the registry.
> The details aof how I arrived at that proposal with Jing are in the
> attached IRC conversation.
> Please review this information and let me know if you think it is a good
> idea to eliminate the use of factories. Thanks,
> PS We're on a tight time schedule, so prompt feedback is appreciated.
More information about the Seek-dev