Mark Brouwer wrote: > 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: "Yeah, I think this could help a lot of people in the community." Sun: "No. I didn't think of it. Useless." I honestly don't understand what's going on. There are the standard Jini classes and packages. Let's hold them as something sacred and not screw with them for posterity. On the other hand, we have classes that are well known to NOT be standard, subject to change, and just might disappear at any point in time. If you are worried about well known NOT standard classes being modified, you're just a jerk who is holding back progress. I would agree with fundamental changes in Jini as being disruptive, but the rest is up for grabs. Sun didn't move Jini, Jini hasn't changed all that much from its fundamentals, and it's a stagnant heap right now (not really, but as far as most people are concerned) with probably a lot of room for improvement (particularly in attractiveness and ease of use from the outside). I think that we can still add peripheral things to it without affecting the initial concepts and ideals that brought it to life. So, with that, if Mark wants to contribute something that may help some people, let him. If it's going to help a lot of people, they will speak up. If it's going to hurt someone, they have all of the room in the world to speak up as well. Otherwise, it will die just like everyone thought Jini had. I hope that River has more going for it than just taking over the code from Sun and letting it rot. Nobody is going to win by having the raw implementation of a relatively basic set of constructs. It's going to succeed by having value added to it, and that value comes in many forms. Keep Jini standard, but let River make people's lives easier. -- Christopher G. Stach II
