On Dec 20, 2008, at 9:35 AM, Dan Creswell wrote:
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.
SOA, as I understand it, is an architecture that uses as its
fundamental unit not procedures, not objects, not containers, not any
IT component but, rather, a service defined in an SLA at the business
level on business paper by business people. This is its genius, and
genius I believe it is, being orthogonal to IT concerns.
If you think a stateful service can be a SOA service, I would have to
disagree, no matter what "definition' you talk about. (I side with
those linguists who say the meaning of terms like "SOA" are in their
use rather than in any definition.)
The great promise of JavaSpaces and the one I am particularly
interested in is in its ability to do what is in effect a stateful SOA
by bringing the functionality to the data rather than vice versa, as
recently used to great effect in GigaSpaces, my moving remote
conversations to the local level, converting communication to
computation.
Mike
