--- In [email protected], "Rob Eamon" <[EMAIL PROTECTED]> wrote:
> ... > I'm trying to reconcile how SOA, which is an architectural style > defining the guiding principles on how to build applications/systems, > has "functionality." > > In my mind, orchestration, automated business process, EDA and CEP > are not "SOA functionality." (Indeed, IMO SOA doesn't prescribe any > functionality whatsoever.) These things exist independently of SOA. > SOA principles can be applied to them, certainly, but they are not > part of SOA. > > ... > > Architecture is a set of characteristics, principles and concepts. > SOA is an architectural style that prescribes the use of services > and separation of the service interface from the service > implementation. IMO, any definition beyond that is probably from > someone with something to sell. :-) > I'm a little surprised that someone hasn't called me out on this. Architecture descriptions define components and associate functionality with those components. An SOA, depending on which definition(s) one uses, can certainly describe or prescribe certain functionality. What functionality should be included in an SOA description? Obviously Tibbling feels that orchestration, process automation, EDA, CEP and other functions belong in an SOA definition (see the "Tibbling likes ESBs" thread). Gartner promotes the notion that "basic" SOA + EDA is "Advanced SOA." IMO, both miss the mark. Why are we so focused on SOA? Why is *everything* seemingly part of SOA? The issue I'm concerned about is that an SOA-is-the-thing-to-strive- for focus may make us myopic. Rather than creating an SOA, shouldn't we be thinking more broadly? I think it is more valuable to create an enterprise architecture that incorporates not only SOA principles but other principles as well. Perhaps an SOA that an enterprise defines already incorporates other principles. That's great. Should such a definition be titled "SOA" then? Why focus only on one characteristic of the architecture? This train of thought leads me to the conclusion--Hey! Look who just caught up!--that an SOA cannot and should not stand on its own. SOA principles are part of an enterprise architecture, an application architecture, an information architecture, an integration architecture, etc. but an SOA definition in and of itself isn't sufficient. And a definition that covers more than SOA principles, concepts and components shouldn't be dubbed an "SOA."
