Bob Scheifler wrote:
Mark Brouwer wrote:
I think I try to ask whether you think an inverted event model should be
'standardized' as a mandated or optional feature of ServiceRegistrar,
JavaSpace, etc. and be on par with the Jini Distributed Event
specification.
I'm not particularly keen on having two events models around
where avoiding callbacks is the only justification for the
second model. I'd be much happier if there were additional
significant value adds in a new model (I don't have a list).
I think it is good to mention that the origin of the JSC Service Event
Model as it is officially called (alias inverted/pull event model) was
not developed for preventing from callbacks in deployments where that
was not possible due to reachability.
It was developed because we were creating a lot of services that had
smart proxies with large amount of state [1] (caches) for which
sometimes the state needed to be modified due to some event on the
server (update of some data). Therefore we needed a notification
mechanism so we could tell the smart proxy it had to do something. Well
this sound the right approach for using events, but in general using
Jini Distributed Event for this is not very practical. To export an
object in the smart proxy and to hand it over to your server, in the lab
it works nice but from a configuration (security) and deployment point
of view it is something you don't want to do.
We could have created a polling based custom solution for each of these
services but due to it being a recurring pattern I decided to provide
support in the JSC container. Here you have a splendid example that once
you can agree an a common pattern you can provide the tools for it. As
of that date the inverted event model has been used by many service
developers for bringing all kinds of events into the smart proxy with a
minimal amount of coding.
It is only since the beginning of 2005 that I also decided to come up
with RegistrarX (lookup service with support for inverted event) due to
deployment issues and because at that time the support for the Jini
Distributed Event Model was completed in Seven.
I like the fact that from a client perspective (besides the
registration) they represent the same programming model, SARE would work
equally well over the inverted event model.
[1] Imagine things as ISO 4217 currency service, bank holiday service.
All services that are backed by a large amount of data that can be
administered and change at the server side but that was accessible by a
business interface and that had to perform. So they got smart proxies
with specialized caches, saving from many roundtrips (as with XML web
services) and preventing from clients (without any domain knowledge)
building cache with invalidation policies. Again this is one of the
things Jini excels in.
--
Mark
