I'll take a whack at it. Typically, integration is associated with components from different execution environments or ownership domains. Strictly speaking, components within a monolithic application are integrated too (e.g. GL integrated with AP), though we don't normally focus on that. How GL and AP interact is a (relatively hidden) detail. We don't know or care how, they just do.
There is no question that getting SAP modules to interact with say, Oracle financials, is integration. Both run in their own environment. Both are typically operated and managed by different groups. Now let's take the modules within SAP and blow them up--take them out of their "SAP container" and turn the capabilities into proper services. How the GL interacts with AP (or vice versa) now becomes quite visible. That's because the GL interface(s) are now fair game to be used by anything (depending on policies), not just other SAP components nor just the SAP published interface (which generically fronts all components). The GL has interfaces all its own. Interacting with it is inherently an integration exercise-- identify/discover capability, discover/define how to access that capability, code, test, deploy, repeat. Integration between services is quite similar to integration between any two components. The biggest difference between them is that the services likely have the necessary interface already since defining interfaces is the essence of SOA. Typical integration projects need to define and create new interfaces for the end points. With luck, one or more end point will have an existing interface that can be used. With services, the possibility that the service already has a usable interface is greatly increased--because service interfaces are defined up front with an eye to being used/called by anything that needs the capability defined by the service. In an OO program. objects interact by calling methods. This is a form of integration, though because the objects are within a single execution context, we don't call it that. The objects are simply interacting. Services, by definition, are independent entities. Connecting these entities is an integration exercise, regardless of how easy that exercise may be. Indeed, SOA strives to make integration wicked simple. -Rob --- In [email protected], Michael Poulin <m3pou...@...> wrote: > > BTW, does anybody know how the service-oriented integration differs > from the NON-service-oriented integration? > > Cheers, > - Michael
