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.
I hope we can have a productive discussion on this.
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 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.
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
mmcgr...@topiatechnology.com
