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:35:32 GMT
Michael McGrady wrote:
> I beg to differ, Dan.  This is probably where we really disagree. 
> Lookup functionality should not be part of what it is looking up.  It
> should be decoupled.
>

Which bits of functionality related to lookup do you think are in the
JavaSpaces specification?  Which bits of functionality do you think are
in the multiple implementations.

I'm not attempting to be awkward - see my related question below for my
motivation.

> I hope we can have a productive discussion on this.
> 

Once again, you are inferring something.  I'll ignore it this time.

> I would begin with noting that the lookup design patterns in JEE are not
> included in the APIs of what they look up and for very, very good
> reasons indeed.  See  Service Locator pattern at
> http://java.sun.com/blueprints/patterns/catalog.html .  Even this
> decoupling proved to be insufficient, however, and led to the use of the
> Hollywood Principle ("Don't call me; I'll call you!") with IoC
> (Inversion of Control) or DI (Dependency Injection) in Spring and like
> lightweight application containers.  The same is true of the
> architecture of the Web.  Note that the Internet is defined solely by
> documents of various protocols: TCP/IP, HTTP, etc.  Lookup is not
> included.  In fact, the most important feature of IP addresses is that
> they are decoupled from physical locations.
> 
> If there is anything that should not be in JavaSpaces according to
> developments in network software engineering and architecture, in my
> opinion, if is the spaces lookup code.  If the lookup is (and it is) in

You state it is - okay, cite me some code - point at it please.

I am strongly suspecting that what you consider lookup functionality
mightn't be in line with mine.

> JavaSpaces, then there should be no JavaSpaces and should just be JINI. 
> In reality, that is what happens.  There really is nothing separate
> called "JavaSpaces" in the current architecture.  There is just JINI.
> 
> I would suggest it is a very bad state of affairs when the lookup code
> for services must be included in the services.  This is an architectural
> howler of the first order in my opinion.  If you decide to do this, it
> will never work in modern architectures, such as SOA.  This idea should
> be viewed clearly and rejected resoundingly.

Some of us would contend that SOA could be done with Jini or even CORBA
adequately well.  Alas that's for one definition of SOA, again, it'd be
useful if you could point to yours.

> 
> MG
> 
> 
> On Dec 20, 2008, at 2:07 AM, Dan Creswell wrote:
> 
>> Michael McGrady wrote:
>>> COHESION WORST TO BEST
>>>
>>> Cohesion is a measure of how strongly related the various
>>> responsibilities (operations, methods) of a software module (class,
>>> etc.) are.  High cohesion results in robust, reliable, reusable and
>>> understandable code.  Low cohesion results in difficulties with
>>> maintenance, testing, reuse and understanding difficulties.  (Do any of
>>> these ring a bell with JINI?)
>>>
>>>
>>> 1.  Coincidental: no relation
>>> 2.  Logical: grouping, for example, by IO routines even though different
>>> in nature.
>>> 3.  Temporal: grouped by when they are processed.
>>> 4.  Communicational: grouped because they operate on the same data.
>>> 5.  Sequential: grouped because the output of one part is the input of
>>> another part like an assembly.
>>> 6.  Functional: grouped because they all contribute to a well-defined
>>> task, e.g., calculating the sine of an angle.
>>>
>>> COUPLING WORST TO BEST
>>>
>>> Coupling is the degree to which a module relies on other modules.  High,
>>> tight, strong coupling contrasted with low, loose, weak coupling.  Low
>>> coupling is when a module interacts with another module and does not
>>> need to be concerned with the other module's internal implementation.
>>>
>>> 1.  Content: one module relies on the internal workings of another
>>> module so that changing the second module produces data will lead to
>>> changing the first module.
>>> 2.  Common: two modules share the same global data.
>>> 3.  External: two modules share an externally imposed data format,
>>> communication, protocol or device interface.
>>> 4.  Control: one module controls the logic of another by passing it
>>> information on what to do.
>>> 5.  Stamp: modules share a composite data structure and use only part of
>>> it, e.g., passing a whole record but only needing part of it.
>>> 6.  Message: modules are not dependent and use a public interface to
>>> exchange parameterless messages or event.
>>>
>>> Various technical levels have tight and loose coupling:
>>>
>>> TECHNICAL LEVEL
>>>
>>> A. physical - tight is a direct physical link - loose is a physical
>>> intermediary.
>>> B. communication style - tight is synchronous - loose is asynchronous
>>> C. type system - strong type (interfgace semantics) - weak typing
>>> (payload semantics)
>>> D. interaction pattern - OO style naviation or complex object trees -
>>> data-centric self-contained messages.
>>> E. Control of process logic - statically bound services - dynamically
>>> bound services
>>> F. Service discovery and binding - strong OS and lanaguage dependencies
>>> - OS and language independent
>>> G. Platform dependencies
>>> H. Time - compile time binding - runtime binding.
>>>
>>> What I suggested was putting in JavaSpaces all the interfaces that are
>>> part of the JavaSpaces functionality.
>>>
>>
>> The trouble is that they are also part of Lookup functionality.....
> 
> 
> Michael McGrady
> Senior Engineer
> Topia Technology, Inc.
> 1.253.720.3365
> mmcgrady@topiatechnology.com
> 
> 
> 
> 
> 


Mime
View raw message