On 2 January 2011 16:58, Greg Trasuk <[email protected]> wrote:
>
> On Fri, 2010-12-31 at 14:15, MICHAEL MCGRADY wrote:
> > Just thinking below -->
> >
> > I may misunderstand but are not you two in "violent agreement" in
> principle? Gr. Sim says that we should not force people to use a piece of
> software in a too restrictive way and Greg says that we should not freeze
> specific implementations by allowing them to infect the APIs, which is the
> same value.
> >
> I think you're right.
>
> > As an aside, do people think that JINI (River) is tied essentially to the
> dynamic proxy loading concept to the extent that changing this concept
> subverts the main thrust of JINI (River)? This seems to be true to me.
> >
>
> This is my belief. At the basic infrastructure level, service providers
> and consumers need to talk to each other, which requires some prior
> agreement between the provider and consumer. In Jini, the prior
> agreement is simply that
> (1) The service defines itself using a Java interface,
> (2) the consumer is running a compatible JVM with the Jini platform
> classes available, and
> (3) the provider supplies a marshalled object that implements the
> service's predefined interface.
>
> WS-*, by contrast, requires the provider and consumer to agree on the
> complete wire-level protocol, including transport-layer protocol and
> endpoint location.
>
> As such, I think Jini has an elegantly minimal requirement for prior
> agreement, plus allows the protocol between consumer and provider to
> evolve without the consumer's explicit involvement (including the
> possibility of providing for parts of the implementation to run in the
> client's VM - i.e. the smart-proxy concept, perhaps for caching). For
> instance if somebody developed a clustered Javaspaces implementation
> that used UDP multicast for its communications rather than JERI, the
> consumer would not have to know anything about it (consumer wouldn't
> even have to change any jar files in its classpath). The service simply
> registers the appropriate proxy object with the registrar and makes the
> appropriate jar files available in its codebase server.
>
> In addition, the proxy idea allows for some interesting patterns. For
> instance, if I subscribe to an event generator, I need to provide an
> object that implements the RemoteEventListener interface. Where does it
> say that object has to be a proxy to an exported object in my VM? It
> doesn't! I could very well provide an object that filters the event
> notification inside the event-producer's virtual machine and only relays
> interesting events back to me.
>
> Take away dynamic proxies and you have not much more than a
> statically-defined RPC framework. It isn't Jini anymore, and isn't
> terribly interesting.
>
>
The other bit that remains once you strip dynamic proxies out is dynamic
registration and discovery of endpoint information. I'd argue that is at
least still interesting (and would note it has nothing to do with
JavaSpaces) and only a few frameworks(*) attempt to address this problem
with greater or lesser success.
(*) JGroups could possibly do this though it's more designed for a single
clustered service than multiple service clusters offering different
facilities. DNS and Bonjour/ZeroConf offer some options in this area but
there are plenty of dark corners with unratified standards proposed and
implementation limitations.
Cheers,
>
> Greg.
>
> > And, if there is a conflict ("subversion") between the main thrust and
> simplification of use, is there a way to serve two "masters"? The value of
> simplicity of use should be "way high". This also seems true to me.
> >
> > Einstein's famous quip that we should keep things simple but not too
> simple comes to mind. Perhaps keeping things simple for the users might
> involve getting more complex in the architecture or layering of the code and
> functionality?
> >
> > How can the team "marry" what are the legitimate but seemingly
> conflicting concerns of Gr. Sim and Greg? This would seem to be the ideal
> solution to the problem and involves finding a new question (I believe in
> "question analysis" as the true QA), if the merger does not introduce
> unacceptable complexity and brittleness into the build.
> >
> > MG
> >
> >
> > On Dec 31, 2010, at 9:11 AM, Sim IJskes - QCG wrote:
> >
> > > On 31-12-10 17:18, [email protected] wrote:
> > >> Isn't that already jsk-platform.jar? I would object to anything that
> > >> subverts the dynamic proxy loading concept that is central to Jini.
> > >>
> > >> It is imperative that people don't, for instance, get the
> > >> service-registrar proxy impls in their local class path. That would
> > >> break compatibility with future or alternate impls.
> > >
> > > If it would be easier for people to work with river, why would we be
> against it. It is about offering people options, not about forcing people to
> use a certain concept. I do think to use the word 'subverting' is indicating
> a strong tendency to force people to use a certain piece of software in the
> way you think they should. I think this is way too directive.
> > >
> > > Gr. Sim
> >
> > Michael McGrady
> > Chief Architect
> > Topia Technology, Inc.
> > Cel 1.253.720.3365
> > Work 1.253.572.9712 extension 2037
> > [email protected]
> >
> >
> >
>
>
