river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McGrady <mmcgr...@topiatechnology.com>
Subject Re: Split JavaSpaces and JINI
Date Wed, 10 Dec 2008 17:07:28 GMT

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

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:


A. physical - tight is a direct physical link - loose is a physical  
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.


On Dec 10, 2008, at 10:54 AM, Dan Creswell wrote:

> Michael McGrady wrote:
>> +1  This is not, I would stress, to question or to otherwise lessen  
>> the
>> value of JINI.  This is just to allow JavaSpaces to live its "natural
>> life" and to move what is in JINI but belongs in JavaSpaces to
>> JavaSpaces so that a Java implementation of Linda spaces can stand on
>> its own.  Then, as Niclas has noted, JINI can use and extend  
>> JavaSpaces
>> as required.
> Could you please explain your logic for placing some of these core  
> (and
> shared across services) classes into JavaSpaces.  I hear what you're
> saying but at least for me right now it feels like you'd be making a
> less cohesive system rather than a better split one.

Michael McGrady
Senior Engineer
Topia Technology, Inc.

View raw message