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.
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]
>
>
>
