John Gagon said:
Yes, that's a rather helpful reply and one which my further reading
confirms. I realize it can be any kind of "protocol" for server to
server data exchange or "client type agnostic" even. It would be
interesting to know if there is a formal definition to these "sets
of practices"
Sorry for the delay in replying -- I was busy building an SOA.
;-)
The set of practices is, indeed, somewhat ill-defined. The Oasis
organization recently produced what they call a "reference model" for
SOA, available at:
http://www.oasis-open.org/committees/download.php/16587/wd-soa-rm-cd1ED.pdf
I'm not a big fan of the creation of standards in an attempt to define
a technology rather than documenting existing practice, but I know
that at least one of the contributers to that document isn't an idiot
so it is worth reading.
The definition debate sparks up periodically on the Yahoo! SOA
group list. The dynamic register-find-bind characteristics are at the
core, so that's what I stick with.
but they sound similar to a J2EE stack of technologies if you ask
me. Being able to automatically go down the list in a registry seems
more like a mirrored cluster.
Some SOA technologies, notably Jini, support multiple lookup
services running simultaneously. Lookup services can be added and
removed dynamically. In practice it is far more lightweight and
flexible than an application server cluster.
'Self healing' sounds misleadingly better than what it is. It sounds
like a protocol might be able to diagnose and restart offline mirrors
in so many cases. What it seems like it really is would be the simple
ability that is found in TCP/IP and that is routing around or perhaps
"self healing" the connection if the connection breaks.
Not exactly. While resiliency can be improved through active
monitoring, it arises from the ability to automatically request a
proxy for a different service instance if the instance currently being
used becomes unavailable. This, in turn, is supported by the ability
to run an arbitrary number of service instances on multiple machines
across the network.
Perhaps "session" is involved. I'll have to look up more on jini.org
but this seems to contradict what is being said on Java World about
SOA soon to replace J2EE.
That sounds like hype to me. No doubt the Web Service vendors
see J2EE application servers as competition, but I hardly think that
the concept of SOA is going to lead to their demise.
What I think might be more true would be multiple core support and
SOA might give some languages and advantage over others as these two
new trends take a foot hold in enterprise. It's clear there is
support for SOA and all kinds of projects for various CPU
architectures, real time etc etc. out there in Java. It comes across
as a mere whinge about J2EE's complex set of technologies.
Well, J2EE is complex and getting ever more so ("J2EE" in this
context including EJBs, containers, application servers, and pretty
much everything other than just JSPs and servlets). It's not a good
choice for implementing an SOA because it is so heavyweight and
complex, but there is a fair bit of business functionality inside
existing application servers that can be exposed as services.
Regards,
Patrick
