On 6/9/07, Rob Eamon <[EMAIL PROTECTED]> wrote: > > --- In [email protected], "Anne Thomas > Manes" <[EMAIL PROTECTED]> wrote: > > > 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. > > I guess I was being a bit loose and ambiguous with my wording. I > agree 110% that SOA is not a "thing" in terms an implementation or an > infrastructure, etc. My intent with "an SOA" in this context was the > SOA definition/description itself--the set of principles, concepts > and logical components (e.g. "a service provider component has these > characteristics..."). > > I'm usually more careful about using "SOA" as a stand-alone term, > preferring "SOA definition" or "SOA description" or "SOA principles." > This one slipped through my editorial filter!! :-) > > > You "do" SOA by applying these principles in a design project. > > Yes, yes, yes! > > > ... > > SOA places no 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-*.) > > Hmmm. Interesting. I thought the presumed constraint was more due to > an assumption that service-oriented implied a request/reply > interaction. In fact, Gartner's "Introduction to Service-Oriented > Architecture" paper states "Service-oriented architecture is a best- > practice architecture pattern for the systematic design of > request/reply applications." > > This would seem to preclude "fire and forget" interactions. > > Just to play devil's advocate (and to help me understand more about > your point) what if I said that SOA principles DO prescribe only a > request/reply interaction style? >
I don't think Gartner is the definitive source of definition regarding SOA. That's not a valid prescription. SOA design principles don't constrain interaction models. Fire and forget is certainly appropriate, as is initiation in response to an event, or publishing to a subscription list. > > I'm not sure what you mean by CEP. > > Complex Event Processing. Tibbling mentioned it in the article that > prompted this thread. I've seen it mentioned in several places > as "one of the compelling business needs justifying SOA." The folks > at Progress/Apama/Sonic seem to be pushing this pretty hard as > an "SOA thing." "SOA/ESB finally provides the technologies necessary > for CEP." Ugh. As I said, SOA design principles don't constrain interaction models. As far as I can tell, it's much easier to implement CEP if the capabilities initiated by events are implemented as services. > > > > > > 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. > > You and I seem to have the same disdain for this sort of abuse. :-) > > > ... > > > 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". > > Again, my intent here was on the creation of the SOA > definition/description for a given enterprise. The focus should be on > the creation of an enterprise architecture description (again, just > principles, concepts and logical components) that incorporate SOA > principles, concepts and logical components. > > -Rob
