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:24:23 GMT
Michael McGrady wrote:
> 
> On Dec 20, 2008, at 2:55 AM, Dan Creswell wrote:
> 
>> Michael McGrady wrote:
>>> A space is utterly useless without an entry.  Yet, Entry is not in
>>> JavaSpaces.  That is a serious architectural no-no, I think.
>>>
>>
>> Sorry, not true - that's like saying JDK APIs are not in my Tomcat
>> instance and it's a no-no.
>>
>> Entry is not in lookup either.....
> 
> No, Dan, it is not like that at all.  In my opinion, you are confused
> about decoupling and cohesion and do not understand them.  Sorry.  They
> are fundamental and your comments continually seem to misunderstand how
> they work.

Or perhaps you misunderstand and you're wrong.....

> 
> Imagine that the JDK API and implementation included Tomcat classes. 
> That is the situation I am talking about.  I know that you hate this
> Dan, but the analysis has to be conducted at the level of seeing where
> there is proper cohesion and decoupling.
> 

No I don't hate it.

Your contention is that JavaSpaces is the JDK, mine is Jini core is the
JDK.  Essentially you want JavaSpaces to be the centre of the universe,
that's fine.  But why then shouldn't TransactionManager be the centre of
the universe or any of the other Jini services?

And note that when I mention Jini core or TransactionManager, I am
talking about the specifications and associated interfaces not the
implementations of those specs and interfaces.


> I am not saying that the JDK API is not included in a Tomcat instance. 
> What I am talking about is something like an ESB implementation of a
> SOA.  People get really confused about this.  Especially engineering
> people.   The reason is that even though integration logic is totally
> separated from business logic, when things are running they are
> "mixed".  This is no surprise.  The reason is that even though higher
> level types of communication (event-based for example have producers and
> consumers that are utterly ignorant of each other, at some level they
> have to be connected to communicate.  The fact that the "instance" of an
> ESB network node must include both ends of the bus endpoints does not
> mean there is not really a separation and true decoupling.
> 
> Michael McGrady
> Senior Engineer
> Topia Technology, Inc.
> 1.253.720.3365
> mmcgrady@topiatechnology.com
> 
> 
> 
> 
> 


Mime
View raw message