So, according to Rob, it is enough to put an interface on something to get a SOA service. I do not buy it.
"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." What does it mean "turn the capabilities into proper services"? Is it the move of the SAP modules from "SAP container" into different execution environment constitutes a SOA service? Why I cannot "turn the capabilities into proper services" within "SAP container"? "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" Assume, we have a Web Service interface available from a SOA Service. However, we need to use a voice communication channel with the service but this interface does not exist. Does this mean that the service does not exist either? "n 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." If I take one of the interacting objects and deploy it into another run-time 'container' (e.g., JVM) and use RPC, I am resurrecting hidden integration, amn't I? That is, now I have to integrate objects... in NON-service-oriented manner because we call them objects, not services. "The deeper in the forest, the more woods" I think an integration as well as a communication protocol cannot be service-oriented, they are agnostic to any orientation, they are in different not-intersecting planes to an orientation. - Michael ________________________________ From: Rob Eamon <[email protected]> To: [email protected] Sent: Monday, December 22, 2008 3:39:38 PM Subject: [service-orientated-architecture] Re: Yefim Natis is sure that "SOA is integration" 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 service-orientated- architecture@ yahoogroups. com, Michael Poulin <m3pou...@.. .> wrote: > > BTW, does anybody know how the service-oriented integration differs > from the NON-service- oriented integration? > > Cheers, > - Michael
