Hi all:
On Tue, 2007-06-12 at 14:43, Bob Scheifler wrote:
> It would be useful to get opinions from others on whether using constraints
> for SARE seems right or wrong to them.
>
> - Bob
I don't like it. It seems to me that the presence of a heartbeat
message is an application-level requirement that should be indicated by
a particular method call that specifies a desired heartbeat time. The
concept is not applicable to all service types. Where used, the client
has to handle it specifically, so it certainly isn't transparent (as
opposed to constraints on transport-layer integrity, for instance). And
I don't believe that sort of critical failure should be transparently
handled by a framework or application container (that's probably just a
personal style issue; I don't like that kind of magic). To me,
specifying a heartbeat event through constraints and then having a
framework handle the events seems to violate Jini's philosophy of "It's
a network - Deal with it.". As a practical matter, anytime I've tried
to hide the operation of a service's event mechanism behind some kind of
proxy, it's always gotten too complex and I end up just dealing with the
remote events directly.
Having said that, the heartbeat/event supervisor pattern is a common
one, and I could support documenting it in the Distributed Events
specification. At the same time, I've always wanted some clarification
of the intentions surrounding event id's etc (should they be
bit-locations that we can -or- together, for instance? How does the
event id interact with subclasses of the RemoteEvent class, for another
instance). I'm just not comfortable with the constraints mechanism for
requesting it.
Cheers,
Greg.
--
Greg Trasuk, President
StratusCom Manufacturing Systems Inc. - We use information technology to
solve business problems on your plant floor.
http://stratuscom.com
