--- 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 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-*.)

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'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.

> 
> >  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

Reply via email to