[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrf] Scheduled termination, heartbeats and dependent objects
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]