It seems like a fairly simple extension of the SAGA concepts to this. Getting a handle to a service via a service name is exactly what our symphony product provides in terms of API (it's part of defining our "session"). This is worth exploring, for sure. -- Chris On 20/9/06 13:34, "Andre Merzky" <andre@merzky.net> wrote:
Hi Chris,
I pondered a while more about this (as you can imagine ;-). I think the major difference to the GridRPC API package we have is the service definition and specification. And then there is that service management API you also show in your slides. You said that this might not be interesting on API right now - but I actually think it might be interesting, at least at some point.
Consider we'd have that service management API available, with:
enum state { New = 1, Running = 2, Done = 3, Failed = 4 }
class service_description : implements saga::attributes { // that is similar to a job description, but can describe // what a service is supposed to be able to do // _semantically_ }
class service : implements saga::object implements saga::async implements saga::monitorable { CONSTRUCTOR (in service_description sd, out service obj); DESTRUCTOR (in service obj);
get_endpoint (out string url);
// Metrics: // // name: state // desc: fires if the service state changes // mode: Read // unit: 1 // type: Enum // value: "Unknown" // // name: invoked // desc: fires if the service gets invoked by a client // mode: Read // unit: 1 // type: Bool // value: "True" // }
With something like that, the RPC bootstrapping for your purposes could be IMHO modeled as
{ saga::service_description sd;
sd.set_attribute ("ServiceType", "DataBase query");
saga::service s (sd); saga::rpc r (s.get_endpoint ());
r.call ("SELECT * FROM 'mytable'");
// rpc handle goes out of scope - connection closes // service handle goes out of scope - service dies }
The RPC call is pseudo code (it would take a parameter stack as arg, not a string), the rest kind of real. Also, the RPC call can be asynchronous.
So, the service API would basically ensure that the right rpc service is available at that point in time.
Well, just wanted to put that on the list - I am not sure if that is useful for you. I am also not sure if that mechanism should be exposed to an application, or if it should be hidden in the API implementation.
It might, however, be a first step toward a service oriented Grid API, which has been asked for from various sides. We should, however, make a clear distinction between Application oriented work and Service oriented work, at least IMHO.
Cheers, Andre.
Quoting [Christopher Smith] (Sep 19 2006):
I will be going over the last two slides of the deck I showed at GGF17.
http://www.ggf.org/GGF17/materials/325/006_smith.pdf
-- Chris
On 19/9/06 05:07, "Andre Merzky" <andre@merzky.net> wrote:
Hi all,
we scheduled a conference call for tomorrow:
Date: 20 September 2006 Code: 808044 Start: Wed 3:00 PM UCT/GMT Wed 5:00 PM Amsterdam / CEST Wed 8:00 AM Los Angeles Thu 0:00 AM Tokyo Number: 0844.888.8888 (UK) 01805.004.102 (Germany) +44.870.088.5706 (others)
Agenda:
- Agenda Bashing / Not Taker - review of GGF18 - discussion about streaming API - discussion about service management API - AOB
I know that the call time is late for Pascal et.al, but its the earliest time Chris can make (west coast), and the goal of the call is to continue some discussion we started at GGF17/GGF18.
Cheers, Andre.