Re: [wsrf] Scheduled termination, heartbeats and dependent object s

[David Hull <dmh@tibco.com>]

Briefly, the whole point of allowing for multiple means of determining whether resources are still needed is to allow for an appropriately scalable strategy.  Scheduled termination won't work everywhere, nor will heartbeating.  I really don't want to spend a lot of time debating the merits of heartbeating (I'm not even a member of WSRF).  I'm much more interested in the ability to manage a group of resources as a group, as in "if this resource is no longer needed, you can safely delete all these resources as well."  Whatever mechanism you use to tell if the parent is needed will scale better than managing the child resources separately.

Considine, Toby (Facilities Technology Office) wrote:

While heartbeating is important, watch that you don't break some of the
things that drive SOAP as an interface.

I am involved in the oBIX group, striving to get a WS interface to building
control systems.  Building control systems are what is embedded in
everything from HVAC to access control to lighting systems in buildings.
They have a plethora of binary protocols; each and every one of them, of
course, does a lot of heartbeating.

I am working to get to oBIX because all thios heartbeating makes these
systems perform very badly when scaled up to large numbers of systems, with
the non-deterministic network that is the internet in the middle.  Litle
pauses and blurts, student file sharing, or even people bring wireless
routers from home and plugging them in to a jack in their labs all bring the
unreliability of the entiore internet onto one campus.  

This means that I am focused on the barriers to scaleability that drive web
systems.  I am moving to SOAP because I want interactions to be stateless
and connectionless.  I know that this will force the controls manufacturers
to change their systems to be less slaves, and more autonomous systems
orchestrated, rather than controlled from afar.

A siginificant problem with some early implimentations is that they still
require active heartbeating, still have all those assumptions that have
caused me problems for years.  In effect, I have merely traded tight binary
protocols for verbose XML messages, without breaking the underlying
architectual assumptions that cause me pain.

So I guess, at the end, I would caution against reliance on heartbeats, or
define their apropriate use carefully and closely, so we do not get all the
problems of current distributed systems with none of the terseness.

Tc



Toby Considine
University of North Carolina
OASIS oBIX TC



-----Original Message-----
From: Tom Maguire [mailto:tmaguire@us.ibm.com] 
Sent: Wednesday, September 08, 2004 10:41 PM
To: David Hull
Cc: wsrf@lists.oasis-open.org
Subject: Re: [wsrf] Scheduled termination, heartbeats and dependent objects





inlined below


David Hull <dmh@tibco.com> wrote on 09/08/2004 05:47:20 PM:

  

I dithered over this.  We definitely want to be able to use the death 
of a remote process as a signal to destroy resources associated with 
it.
    

I am much less definitive...

  

I believe this is correct, if by "server" you mean "the thing managing 
the resource".  But it reverses the usual meaning of server w.r.t 
heartbeating, where the server is the process sending out heartbeats 
so that clients can tell it's alive.
    

"Server" is a term you used...

  

In any case, I maintain there's something to be captured here.  For my 
money, though, the bigger win is with dependent objects.  You don't 
want either a separate lease or a separate stream of heartbeats for 
each child resource if you can help it.
    

I believe that heartbeating is an important construct however I am unsure if
heartbeating is in scope for the work of WSRF.  I would expect that
heartbeating would more properly be part of a "grouping" semantic of highly
available systems.  Further, I would expect that the heartbeat would be
multicast to other members of the group.  The creation of the group would
involve "voting", "joining" and "leaving".  In this context a strong
requirement of grouping would be reliable and ordered messages.

Tom