[SAGA-RG] Phone Call Tomorrow

[Andre Merzky]

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 at 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.
> 



-- 
"So much time, so little to do..."  -- Garfield