--- In [email protected], "Steve Jones" <jones.ste...@...> wrote: > > > > > Integration does not mean use of an intermediary. > > Surely integration is always an intermediary in itself?
Hmm. I'm not sure. Let's examine C -> P. C forms the requisite message. C calls P via the supported protocol. P processes the message. P returns a response (if only to say "got it"). Let's be more specific: C creates the XML. C calls P via HTTP, posting the XML. P parses the XML and processes the data. P returns an HTTP response (with or without a body). That's an integration. But no intermediary. The participating parties do the work themselves, although they are using an intermediate format and protocol. Is that what you mean? > 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). Sweet. More definition debate! ;-) What I mean by interaction: A talks to B. No further elaboration as to ad-hoc, sync/async, etc. > 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 work specifically? And must the EC be realized as a distinct entity? > 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. I'm with you on the model. Is it reasonable that C & P implementations incorporate the EC? > Agreed, its part of the EC bit. I think we are all agreeing here > just using the wonderfully imprecise English language to do so. It's a wonder we communicate at all! Or at least we have the illusion that we've done so. :-) -Rob
