Dan Creswell wrote:
Of course all of the above can be developed for each specific event
protocol, but in my humble experience that has proven to be a repetitive
task which requires less than trivial logic at the event producer
side. The watchdog logic at the client side is repetitive as well and a
lot of people dismiss remote events as being unreliable while I think we
have the means to alter that notion.
Mmmmm, I'm not sure we should alter that notion. There's more than just
the software at work here.
When we talk about events being unreliable we don't just mean that
services go down etc. What we're saying is something like:
"You need to figure out what your failure recovery processes are and
design them into your system at human, code and hardware levels".
One thing you might do is the kind of thing you're describing but it's
not the whole picture.
I don't disagree here Dan, reliability covers a lot of ground. But with
regard to events it is often the fact you don't know whether an event
occurred or that any of the above occurred that is inferred by it.
Otherwise we should label synchronous invocations as 'unreliable' too,
which of course we know are unreliable too ;-)
For that matter I believe the pattern is that common that I consider it
a proper (optional) addition to the Jini Distributed Event Model and of
course together with the 'inverted' event model. When we 'standardize'
this practice we can developed the client side utilities, we can have
framework support for the server, but of course you are also allowed to
do all the heavy lifting yourself ;-). We can write articles about best
practices, etc, etc. Bottom line is that we should be able to create
event based solutions for which our friends in the 'you want data, I
have data' have to write oh so many lines of error prone code to get the
same level of robustness (or information to base decisions upon).
No issue there but I'm not clear on just how deeply baked in this
support needs to be.
Fair enough questions. To me some things only have value when we
'standardize' it [1] (either optional or mandated) as part of the core
of Jini. Standardizing allows me to build upon or for something that is
larger than the world I'm part currently part of.
The LUS that comes with Seven does things for people who need to cross a
firewall, but it is a propriety solution as it only works with the SDM I
supply as part of the Seven Suite. This is a situation I don't like for
various reasons and some other people also don't like because they want
to be able to swap. Some end up using it anyway because when the pain is
hard enough 'principles' fade away ... but it is far from ideal.
If it turns out nothing needs to be 'deeply baked in' I really question
the value of continuing with Jini as to me that would mean it is
finished. It might be other tasks are more important but so far it is
rather silent with ideas and I guess nothing prevents from discussing
ideas while we are awaiting the code, I grew a beard by the way :-)
[1] soon I'm going to stop with these quotes ...
As a last note, I think the addition of such a protocol would be
particular useful for ServiceRegistrar. Not only would this enable a
test for whether callbacks can be received (Jini Distributed Event
Could I not test the ability to do callbacks with something like:
(1) Register a notify for a special test proxy I'm about to publish
temporarily.
(2) Register my test proxy.
(3) See if I get an event.
(4) If I got an event I'm all done otherwise I'll try a few more times.
etc.
The above assumes that you can register your proxy with the same LUS as
the LUS from which you want to receive events. This already takes a lot
of assumptions with regard to security e.g. The trust relationship for a
pull versus push event model can be completely different.
But of course we can work our ways around everything what is missing at
this point in the Jini Specification, but at what costs and what are the
benefits compared to standardizing a common pattern.
I'm not saying what I came up with is sound, although it represents the
pattern I developed when writing a lot of event based services and
turned out to work quite well.
But I hope that if at least the problem resonates with people we can try
together to come up with something that takes all roadblocks into
account and the improve the current situation.
--
Mark
