Lists Home |
Date Index |
> -----Original Message-----
> From: Bullard, Claude L (Len) [mailto:email@example.com]
> Sent: Tuesday, November 30, 2004 1:21 PM
> To: 'Michael Champion'; firstname.lastname@example.org
> Subject: RE: [xml-dev] Web Services/SOA (was RE: [xml-dev]
> XML 2004 weblog items?)
> Are services responses to events?
I believe they are, though some consider this a
separate-but-related-to-SOA concept. I believe Gartner has a concept
called Event Driven Architectures (EDA), which - if I recall correctly
since reading up on it months ago - they consider as another
architectural style (i.e. apart from SOA), but related.
In essence, the invocation of a service is an event in and of itself -
for example, the receipt of a purchase order by a supplier that is using
Web Services in a SOA can trigger the processing of the purchase order
and (if all goes well) the creation and transmission of an invoice. So
the events here would be the receipt of the purchase order, the
validation of the purchase order, etc.
Booz Allen Hamilton
Strategy and Technology Consultants to the World
> That is likely at least one level higher in the
> organizational architecture if call and response is the
> lowest level of description, but if we are to speak of a
> 'services oriented architecture' that is meaningful beyond
> the most primitive descriptions, it can be useful to think in
> terms of event types over messages. Otherwise, a service and
> a method are indistinguishable. I'm not sure the fact of
> using XML to send and return the request or the opacity at
> the boundary are enough to distinguish a service from a
> method invocation, remote or otherwise.
> From: Michael Champion [mailto:email@example.com]
> For what it's worth, all these discussions beg the question
> of what a "service" is. I've taken a stab at this in
> 'In the real world, we use services all the time -- getting
> money from banks, ordering food from a restaurant, getting
> clothes dry cleaned, and so on. What makes these "services"
> is that we don't need to know anything about banking,
> cooking, cleaning, etc. in order to use them, we simply request them.
> ...In a nutshell, service orientation is an approach to
> designing systems in which each component knows only how to
> request and consume the services provided by other
> components, and little about their internal algorithms, data
> structures, stored data formats, query languages, etc.
> The xml-dev list is sponsored by XML.org
> <http://www.xml.org>, an initiative of OASIS
> The list archives are at http://lists.xml.org/archives/xml-dev/
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>