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 10:07:28 GMT
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.....

> Mike
> 
> 
> 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.
> 1.253.720.3365
> mmcgrady@topiatechnology.com
> 
> 
> 
> 
> 


Mime
View raw message