river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Creswell <...@dcrdev.demon.co.uk>
Subject Re: Split JavaSpaces and JINI
Date Sat, 20 Dec 2008 17:11:10 GMT
Michael McGrady wrote:
> On Dec 20, 2008, at 3:08 AM, Dan Creswell wrote:
>> Michael McGrady wrote:
>>> Imagine that in order to use Log4J you had to setup JINI because an
>>> interface important to Log4J were in JINI.  This problem would not be
>> So you are complaining that making use of Entry requires you setup Jini?
>> Not true - the reason you must setup Jini is to discover your JavaSpace
>> because there is no other mechanism for that right now.  It's not a
>> direct result of including Entry.  It's a direct result of running a
>> JavaSpace that wants to do discovery/join.
>> So it seems to me we're not talking architecture at all.  We're talking
>> about providing a .jar with all dependencies and providing a
>> non-networked lookup implementation to slot in.
>> And thus I claim you confuse packaging and implementation (physical
>> details) with architecture.
> I realize that JINI allows JavaSpaces to be discovered.  I think that
> the discovery mechanism should be separate from the JavaSpaces.  JINI
> should compete in this regard, rather than be built in as the JavaSpaces
> solution.  The analogy with Log4J is apt, I think.  The problem is, I

The discovery mechanism is independent of the JavaSpaces spec.  However
all the available implementations choose to use that mechanism.
Although discovery is all interfaced up and could be done using ZeroConf
/Bonjour for example.  Basically the coupling is occurring at an
implementation level not architectural or spec level.

Note that you could do discovery using a null-implementation (if someone
writes the code).

Still not seeing any coupling or cohesion problems although maybe
there's a bit of spec to write or a tweak to the discovery APIs to make
a null implementation possible.

> think, architectural.  Architecture, of course, is closely aligned with
> packaging, since structure with emergent properties are the center of
> architecture.

How much of the Tomcat container's architecture dictates it's .jar

How much of Jini's architecture dictates it's .jar structure?  Actually
a fair amount of Jini's .jar structure is due to classloader behaviours
which are less about Jini and more about Java.

> Michael McGrady
> Senior Engineer
> Topia Technology, Inc.
> 1.253.720.3365
> mmcgrady@topiatechnology.com

View raw message