Steve,
Does integration only belong to the execution context? Doesn't two
components that needs to integrate share some understanding about the
semantics? The way I see it, a big part of integration is about the
semantics. I would say that semantics belongs to the information
architecture and the business architecture and not the technical
architecture, where the execution context belongs, as far as I understand.
// Dennis Djenfer
Steve Jones wrote:
Rob,
What I'd say is that the _execution context_ in SOA is the integration
and it is an _enabler_ for consumers and producers to be brought
together, but the integration is not _in itself_ SOA. In many cases
integration is a _required_ facility for the interaction of consumer
and producer but in itself it doesn't represent either the consumer or
the producer.
To use a WOA analogy, TCP/IP is the enabler but it isn't the REST bit.
Steve
2008/12/22 Rob Eamon <[email protected]>:
+1.
That's what I've been attempting to illustrate, though Mike has
phrased it (via ZT statements) in a much better way than I.
"If however the point of interaction is a higher level business
service contract, the individual integration points become less
relevant."
But still there and still important--without them, nothing happens.
SOA is a form of integration. But integration is not the primary
focus.
Perhaps the objection to "SOA is integration" is rooted in the common
use of integration capabilities: resolving syntactic and semantic
differences between components. Does "integration" not exist when
there are no differences between these? What if the end points
resolved these differences internally (client A must create document
Z as defined by service B's interface)? Is that not still
integration, just accomplished by the end-points rather than an
intermediary?
-Rob
--- In [email protected], "Nibeck,
Mike" <mike.nib...@...> wrote:
Zapthink has a very specific take on SOA and integration. They
state the following:
- One goal of SOA - Integration as a byproduct of Service
composition
- One Goal of legacy integration: building Services to support this
goal, NOT connecting systems to address a particular business need
Their primary point being that in a SO architecture, integration is
simply one of the steps or parts of a
composition, and it no longer gets seen as a distinct and separate
set of processes or technologies. In most cases,
integration efforts are designed to somehow "join" two or more
disparate systems. If however the point of interaction
is a higher level business service contract, the individual
integration points become less relevant.
You will always have the need to interact with remote systems, and
the lower level details will still be very similar to traditional
integration efforts, but these efforts will exist in a larger
context, the service model, that will hopefully not be directly
impacted by the individual integration efforts.
_mike
------------------------------------
Yahoo! Groups Links
No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.176 / Virus Database: 270.9.19/1859 - Release Date: 2008-12-20 14:34
