2008/12/23 Rob Eamon <[email protected]>: > --- In [email protected], "Steve Jones" > > <jones.ste...@...> 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. > > Hmm. The second person to think I made this error in definition. > Perhaps I've worded somthing poorly. Integration is not in itself > SOA. I've never (intentionally) stated such a thing. > >> 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. > > Integration does not mean use of an intermediary.
Surely integration is always an intermediary in itself? > > I'm of the opinion that integration is a required capability in *all* > cases between consumer and producer. The interaction is inherently an > integration. Depends what you mean by interaction. I tend to limit interaction to human interactions (always async, ad-hoc) as opposed to integration (can be async, rarely ad-hoc). But C->P via an EC does imply something always happens in the middle yes. > > What varies in the implementation is which bits to which piece of > work. If all the work is done by consumer and provider, it is still > an integration. RM wise the work is done by the EC. What the C & P do is up to them but its the EC that bring it together and (IMO) that is a model that works. > >> To use a WOA analogy, TCP/IP is the enabler but it isn't the REST >> bit. > > I've never stated that integration is SOA. I've never said that SOA > is only integration. Integration is but one aspect of SOA. Agreed, its part of the EC bit. I think we are all agreeing here just using the wonderfully imprecise English language to do so. Steve > > -Rob > >
