To all my SOA friends, As this holiday season descends on us and I take a moment to reflect on all I have to be grateful for, I wish to thank all of you who participated in this thread for helping me realize that I am grateful that Anne and Richard are covering SOA and Integration for Burton Group and I get to focus on BPM and Presentation. :-)
Happy Holidays to you all and may 2009 be a whole lot better than they're predicting! Warm Wishes, JP Morgenthal On Tue, Dec 23, 2008 at 8:37 AM, Dennis Djenfer <[email protected]> wrote: > 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]> <[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...@...> <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 > > > > >
