On 6/8/07, Rob Eamon <[EMAIL PROTECTED]> wrote: > > --- 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.
I didn't call you out on this because I agree with you. Although I object to the use of the phrase "an SOA" -- SOA is not a thing. SOA is something you do, not something you build. As you say, SOA is a set of design principles. You "do" SOA by applying these principles in a design project. > > 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. > Again, I agree with you. These attempts to describe SOA in terms of the functional capability of the middleware used to implement services miss the mark. Orchestration is a programming model that takes advantage of a pre-existing set of services. Process automation is a the end result of a development effort that is orthogonal to SOA. (Process automation doesn't require SOA, and SOA doesn't require process automation, although process automation could be enabled and simplified by applying SOA principles to the project.) EDA refers to an interaction model. SOA places not constraints on interaction models. (The idea that earlier "versions" of SOA didn't support event-driven interactions stems from an inappropriate association between SOA and WS-*.) I'm not sure what you mean by CEP. > Why are we so focused on SOA? Why is *everything* seemingly part of > SOA? Because vendors are trying to sell you stuff. If it's not part of SOA, then it's part of Web 2.0. > 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. See my previous comment regarding "SOA is not a thing". > 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." > Exactly.
