Jan Algermissen wrote: > On 25.01.2007, at 17:29, Mark Baker wrote: > >> On 1/24/07, Alex Hoffman <[EMAIL PROTECTED]> wrote: >>> An SOA is simply a software architecture based on services. >>> What's a service? A software program that is intended to be used >>> by another program. >> Definitions need to be sufficiently precise in order to enable one to >> distinguish what is from what isn't. > > Here is a question that could provide a start towards an > architecturally meaningful definition of SOA: > > > > 1. In what way does SOA constrain components of a networked system? > (When I design a component, what am I allowed to do and what not) > > > 2. In what way does SOA constrain data elements of a networked system? > (When I design a data element, what am I allowed to do and what > not) > > > > (Of course the answers to this must be testable to be meaningful). > > <throwing-the-gauntlet-mode> > My take is that SOA does not have to say anything about 1 or 2 > that is testable. > </throwing-the-gauntlet-mode> > >
Just to expose my thinking a little more: I don't buy into styles and the associated things as particularly valuable. Bruce Lee said something like: "My style is no style" Referring to the fact that in combat, fixed approaches fail, dynamic adaption is king and thus you must be master of all styles. Thus when in combat we talk about fighting not whether we're doing Karate or Kung Fu etc. The same, for me at least, goes with systems design - my style is no style, I use what works mixing things together for best result. Consequently, classification for me is only of so much use. Cheers, Dan.
