Let's avoid the "person riding in a vehicle" metaphor. It doesn't work. I've put in a software based example later that may help us explore our ideas.
--- In [email protected], Michael Poulin <m3pou...@...> wrote: > yes, and somebody is doing this 'hook up'. Why? Because none of the > pieces cannot do it by themselves. Now, assume a Piece 1 with > reserved publicly available hook (interfaces) and a Piece 2 - a > smart distributed SW agent, which is looking for available hooks of > others to connect its own hook with them. What you're describing is integration. Defining an interface is integration work. Piece 1 defines an interface ahead of time (anticipating integration). Your description says that Piece 2 has decided upon a message format and comm path (anticipating integration). Piece 2 is discovering what is out there, hopefully finding something that matches the interface it wants to use. You're describing components that have already been integrated. And the "smart agent" is simply making the communication connection. What are the chances that Piece 1 and Piece 2 independently and magically adopting the same format and comm path? Zero. They either agreed with each other or independently agreed with a 3rd party definition. > There is no a 3rd Party for doing hooking (I mean, no hookers :-), > there is no adjustments on any Pieces, and the only shared thing is > the execution environment. If the fact of interaction is equal to > integration, then we can say that the Pieces are disintegrated > after the interaction complete. How close this conclusion to absurd? You keep describing integrated components but insist that they are simply "interacting." Let's use an example that I think covers what we're both saying. Ariba provides tools, formats and protocols to support the purchasing process. They defined cXML and a schema to define the various documents involved in the typical purchasing process. Shopping cart, PO, PO ack, invoice, etc. On the one side of the Ariba network were sellers. They are to support particular interactions to enable a buyer to browse their catalog, load up a shopping cart and check out. On the other side were buyers. They were to support interaction with the shopping cart, generate POs, etc. Independently, sellers and buyers could develop the interfaces to their systems to support the Ariba-defined interactions. Ariba provide test beds to help sellers and buyers confirm that what they did worked per the Ariba specifications. By adhering to the Ariba specs, any buyer could interact with any seller (presuming the proper Ariba network setups were done to allow the interactions--primarily a security thing). >From what you've been posting as your position, the buyer and seller are >simply interacting. No changes are needed on either end. A buyer just needs to >seek out the seller that it wants to use. My position is that all Ariba buyers are integrated with all sellers by virtue of implementing the Ariba-defined interfaces. A buyer is integrating with a "generic" seller and vice versa. It is true that Buyer A didn't know about Seller Z during development, but that's immaterial. They are integrated because they share formats, semantics and protocol. The run-time interaction is simply the end result of the earlier work. Omit the agreement on format, semantics or protocol and the interaction is useless at best, outright wrong at worst. What SO does to help streamline integration is force providers to consider and define the useful interfaces for a service in anticipation of being integrated with all kinds of consumers. SO, from an interface definition perspective, is a culmination of all the good integration practices that preceded it. -Rob
