"SOA is a form of integration. But integration is not the primary focus" sounds 
a bit absurd to me: according to this Rob's expression the core of something 
may be not its primary focus...

I would rather say that SOA assumes, allows, encloses some integration but 
"integration is not the primary focus", like a bathroom (in the form of a 
plastic module) is not a house (for normal people).

Now, if it is not then what has to be in place (in addition to the bathroom) to 
call it a house? This is THE question I would like developers to ask themselves 
when they integrating two packaged applications.

- Michael



________________________________
From: Rob Eamon <[email protected]>
To: [email protected]
Sent: Monday, December 22, 2008 3:14:42 PM
Subject: [service-orientated-architecture] Re: Yefim Natis is sure that "SOA is 
integration"


+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

 


      

Reply via email to