--- In [email protected], Michael Poulin <m3pou...@...> wrote: > > "The interactions between the components might be specified in an > SO way (service wrappers around non-service capability, sort of)." > > After you create a service that encapsulates a component, the > interaction happen between services, not components any more.
Not exactly. The interaction might be service oriented with a component that is not. I agree that from an interface perspective, the distinction is all but nil but at the architecture level, we know that the component is not a service and thus the interface may contain compromises in principles. Not an ideal scenario but pragmatic. > If you put, e.g., a Web Service interface on the component, you > have an interaction between components via that interface but it is > not a service-oriented interaction I think that it is. > - you can put any type of interface on the component and it does > not make it a service. Agreed. I hope I've not promoted that notion. > This is exact the reason I argue against 'integration=SOA' I've not argued that integration == SOA. I've argued that designing an SO architecture results in an integrated system. One could argue that virtually an type of architecture represents an integrated system. That's almost the entire point of an architecture--define components and the relationships/interactions between them. > -integration via interfaces called 'service' does not convert a > monolithic application into the service. Agreed. Wasn't arguing for that. > Unfortunately, many people do exactly this - wrapping monolithic > application with Web Services - and claim they have SOA solution. > Why then they cannot find SOA benefits from such "SOA" and saying > us the SOA fails? I agree that such an approach can be lacking in many ways. > Does SOA include integration? Sure, it does. Then we agree. > Does integration constitute SOA? No, it does not. I don't think anyone argued for that view. The simple presence of integration characteristics indicates nothing about the encompassing architecture. > I am saying that integration with Web Services/CORBA/RMI/etc. is > not SOA yet; there has to be a business orientation first. I agree that simply the presence of WS-*/CORBA/RMI/et al does not indicate an SO architecture. Architecture is preferrably driven by business orientation first, but as we all know, that's not always the case. SOA != BA. SOA != EA. SOA does not imply any particular level of architecture. I know many feel that SO at other levels does not constitute SOA, that "true" SOA must be at the business and/or enterprise level. But I disagree. The greatest benefits will be achieved when SO is applied at the highest levels, but applying SO principles at lower levels is not without merit. Might the real problem be that folks apply SO to lower level architectures and then expect higher level benefits? I suspect that is the case. -Rob
