Lists Home |
Date Index |
> -----Original Message-----
> From: Bullard, Claude L (Len) [mailto:email@example.com]
> Sent: Thursday, January 19, 2006 2:12 PM
> To: 'Paul Downey'; Michael Champion
> Cc: Chiusano Joseph; firstname.lastname@example.org
> Subject: RE: [xml-dev] Will The Real SOA Please Sit Down?
> We have that one posted on a bulletin board outside the hall.
> It might be
> funny if it weren't so true.
> The problem of SOA is that abstract concepts not grounded in
> pricelist technologies lead to an infinite set of points on a
> line where each point is
> a cost. The more you measure, the higher the cost.
> The SOA RM obligates the business/sales organization to
> create a business model of each business type as a set of
> composite services that are then implemented or mapped to
> physical web services (or Howie carrying buckets of snail
> mail from room to room).
> As useful as the RM is at defining the terminology, it
> doesn't help explain to a customer, say, the distinctions
> between data warehousing and peer to peer services, or in
> other words, real Business Intelligence systems vs.
> massively indexed search services.
Agreed - a reference architecture may help this (we have just begun a
reference architecture effort within the OASIS SOA-RM TC). The Reference
Model is too abstract (as reference models are, by nature) to be
definitively tied to scenarios that are that concrete.
> One wishes it were like a Mexican restaurant where there are
> fifty items on the menu made of six fast to cook cheap
> ingredients. Unfortunately, it is exactly the reverse so all
> of the initial risks are assumed by the vendor using the SOA
> RM as a basis for an RFP.
I'm not envisioning vendors using the OASIS SOA-RM as the basis for an
RFP (too abstract), but am open to possibilities.
Booz Allen Hamilton
700 13th St. NW, Suite 1100
Washington, DC 20005
Visit us online@ http://www.boozallen.com
> From: Paul Downey [mailto:email@example.com]
> On 10 Jan 2006, at 17:18, Michael Champion wrote:
> > So, "web services" are a set of architecturally-neutral
> > whereas "service architectures" are a technologically
> neutral design
> > principles.
> As much as I like this distinction, both terms are
> essentially "meaning neutral".