This is mot Steve, this is Michael. Execution Context is not only technical but also business entity.
However, agreement on semantics may be not necessary an integration element but an aspect of integrity :-) If a consumer requires semantic translation of the Service Description (which includes service interfaces and message vocabulary), this does not mean that consumer integrates with the service - the latter may be not chosen after all. - Michael ________________________________ From: Dennis Djenfer <[email protected]> To: [email protected] Sent: Tuesday, December 23, 2008 1:37:00 PM Subject: Re: [service-orientated-architecture] Re: Yefim Natis is sure that "SOA is integration" 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 <rea...@cableone. net>: +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 service-orientated- architecture@ yahoogroups. com, "Nibeck, Mike" <mike.nibeck@ ...> 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
