Hi Greg,
Greg Trasuk wrote:
Hi all:
I've been watching this discussion for a while, and I'm afraid I'm
unclear on what Mark is proposing. Mark, could you describe exactly
what changes to the JavaSpaces or other API you're suggesting?
In the SARE idea there are no modifications to the current
specifications, the protocol is trigger by the usage of an invocation
constraint.
I hope the below will make it clear, as an example I will use
ServiceRegistrar We have 2 new classes that play a role here namely:
SourceAliveRemoteEvent extends RemoteEvent
SourceAliveNotificationTime implements InvocationConstraint
You obtain the ServiceRegistrar proxy and prepare it with constraints
including a SourceAliveNotificationTime with a time-out or 30 seconds.
You registering for receiving ServiceEvents through the
RemoteEventListener passed in with ServiceRegistrar.notify().
Assuming the lookup service has support for this constraint the first
event you should receive is the SourceAliveRemoteEvent, if this doesn't
happen it appears the lookup service is not able to serve you at this
time, which might be due to various reasons (whether that is interesting
is up to you).
We assume the first SourceAliveRemoteEvent has been received so we can
conclude callbacks are working. Assume some state transitions take place
at the lookup server, this will result in ordinary ServiceEvent. Than no
state transitions occur at the server so there is no need for the lookup
service to send ServiceEvents, but after 30 seconds after the last
transmitted event it will notify the client with a
SourceAliveRemoteEvent. That event will carry the same sequence number
as the last event that has been sent before the SourceAliveRemoteEvent.
Note that if state changes in the lookup service happen every 30 seconds
*no* SourceAliveRemoteEvent will be sent as the ServiceEvent provide all
the indications one wants to have.
The idea behind it is that the client can assume the lookup server is in
good health and all components in between the server and you as well if
it turns out that latest event received is not older than 30 seconds
(although I would add an extra margin for this check).
There is not that much more to it, it has been suggested that a ping to
the lookup server could be used, but given the fact ping doesn't
necessary follow the same path as the events the reachability of the
lookup server has not that much value to me (even if it would return a
sequence number). Another suggestion has been to use the lease for this
purpose but it suffers from the same problem as ping, and in many cases
I expect the lease times to be much larger than the SARE time-out.
If something is not clear please ask.
I'm inclined to think that heartbeat events are already provided for by
the Distributed Event Specification (see comments below). I could see
an "application note" to the DE spec that describes how to implement
heartbeat events, but I don't think it's reasonable to establish a
single method for subscribing to an event stream with heartbeats, in the
same way that the DE spec doesn't try to provide any standardized
registration method.
SARE represents a pattern and 2 classes which allows the development of
frameworks/libraries that take care of the event publishing side and
utility classes for the detection of the aliveness of services. As an
example in Seven it has been implemented as trial with no changes to the
JSC API, the client side part I still have to do.
Part in Bob's response was that he was interested in patterns, and while
that is fine and maybe for someone with his background and intelligence
logical I think part of the reason why a lot of stuff is not being used
is because it is freaking hard to get right and apply properly.
As to whether heartbeat events should be added to the JavaSpaces
specifications (JavaSpaces07?), I don't think they are needed. My
rationale for this opinion is that the spaces implementation is not
actually the generator for any events; the events result from actions by
clients. In the case of a datasource that is dropping entries into the
space periodically, it's of little use to verify that the spaces
implementation is functional; what I care about is whether the
datasource is functional. So it makes more sense sense to have the data
source drop a heartbeat Entry into the space periodically, which will
trigger an appropriate event, rather than just have the space fire off a
periodic event.
I see what you mean but I tend to think of the JavaSpace service as the
event producer while the datasource is the event causer. But if it is
important that you want to know your event causer is alive you would
indeed need something else SARE is not going to work for that.
Whether this is useful for JavaSpace I don't know as I've never used
events with spaces, but I think when you use events with JavaSpaces you
still might like to have an indication the path between the space and
you is still working or whether you are able to receive events at all,
without doing to the trouble to generate your own phony events.
1) do you think it is generic (enough) an event producer should able to
notify a client of its ability to deliver events in the case there
are no events to notify the client of;
Seems like an application-level thing to me. When it is important that
the listener know within a bounded time that the sender isn't sending,
then the event protocol should include a "heartbeat" method. If it
makes sense to negotiate the frequency of the heartbeat, then the event
subscription protocol should include some indication of the desired
frequency. Having an additional parameter on the event registration is
no problem; to quote the Distributed Event Specification:
I don't disagree that you can consider it an application level thing
(that is what I did until 2 weeks ago), but that would mean that each
event protocol must decide whether this is required and each application
must code it and there is no standard way for clients to detect.
Given its recurring pattern I therefore came to the conclusion it was
something I wanted to provide as part of the JSC, but at the same time I
think this has value on a larger scale.
2) do you think it is essential a client must be able to find out
whether an event producer is able to deliver events at all;
Neutral.
I find this useful only because the cursed Windows firewall has changed
the assumptions that we can make about the LAN; it's now pretty common
to find the firewall blocking event notifications to the client. But it
just irritates me to implement this kind of checking, so I can't find it
in my heart to come out squarely in favour of it.
I'll grant you that if your system boundary includes crossing a firewall
to the internet, then it's probably essential. So far, I still
subscribe to the view that Jini's design centre is the LAN.
I leave it to those who invented it to provide the answer to that. But I
think that this view partly has been caused by the fact the technology
failed to adapt to a network environment where everybody tried to shield
itself from the big bad world and where not each 'thingy' is network
addressable.
Even in corporate environments that often are characterized as LAN
environment it is remarkable to see how many barriers/policies you find
on your network.
Still on my wish list for River is Jini accross the firewall so once we
come to the point that we find that worth pursueing this might be become
more relevant.
--
Mark
