--- In [email protected], Michael Poulin <m3pou...@...> wrote: > > So, according to Rob, it is enough to put an interface on something > to get a SOA service. I do not buy it.
Where did I say that? I said services always have interfaces. Having an interface alone does not mean something is SO. > "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"? Surely you understand what that means. > 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"? You can. By creating SO interfaces that wrap SO capabilities which happen to be hosted (implemented) within the 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? I don't understand what you are driving at. This strawman is obviously a silly example. If you're saying that not all interfaces will be defined up front, then yes, I agree. But this begs the question--why not? How did such an interface get overlooked? If we're just going to define interfaces on an as needed basis, then how is that better than what we do now? I understand that we won't always get the interfaces exactly right. But we should be pretty darn close. If there was no inkling whatsoever than a voice comm channel interface was needed then that seems to be a pretty big miss. > "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? Yes. Because now instead of the run-time environment managing the invocation, you have to do something to make it happen (though we have tools to help with this too). > That is, now I have to integrate objects... in NON-service-oriented > manner because we call them objects, not services. Okay. Take an application that has been implemented following SO principles (SO applied to AA, with the main application components being services instead of objects). Now split out one of the services to another JVM. That would be the same conceptual scenario, correct? > 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. In other words, integrations don't have any observable charactistics? That seems rather odd. Message-oriented and document-oriented are often described as integration styles. I'm of the opinion that integrations can be service-oriented as well, even if the end-points are not. I like your house metaphor. Integrating the loo with other rooms makes best sense in the context of the house. Most excellent. -Rob
