Lists Home |
Date Index |
- To: "Guillaume Lebleu" <firstname.lastname@example.org>
- Subject: RE: [xml-dev] Web Services/SOA - on SOA, and EDA and other TLAs.
- From: "Chiusano Joseph" <email@example.com>
- Date: Tue, 30 Nov 2004 22:24:24 -0500
- Cc: <firstname.lastname@example.org>
- Thread-index: AcTXUF7Tko8S/0tNTJCboBKYlfFPWgABIZ0g
- Thread-topic: [xml-dev] Web Services/SOA - on SOA, and EDA and other TLAs.
> -----Original Message-----
> From: Guillaume Lebleu [mailto:email@example.com]
> Sent: Tuesday, November 30, 2004 9:47 PM
> Cc: firstname.lastname@example.org
> Subject: Re: [xml-dev] Web Services/SOA - on SOA, and EDA and
> other TLAs.
> EDA (event-driven architecture) does not imply SOA
> (Service-oriented architecture).
> SOA does not require EDA.
> EDA can be useful to implement parts of the SOA.
> SOA just requires people to follow the rules expressed in the
> service contract (and thus, tools to make it easier to follow
> those rules are nice to have).
> more details..
> IMO, an IT architecture is all about providing the
> constraints for IT organizations to deliver working software,
> whether it is during development, testing, production, maintenance.
> In an SOA, the constraints are that every software
> components' interface is described in a unique language and
> published in some central location. XML and XML Schema just
> happens to be good enough technologies to get the job done,
> particularly in massively heterogeous environments.
> Of course, in a real project, you want to add more
> constraints than that, for instance security contraints,
> transactional constraints, semantic constraints, etc., but
> this is currently left to IT architects, although they can
> pick from WS-* specs but then suffer interoperability issues
> that SOA was supposed to solve...
> On the other hand, the notion of Event-Driven Architecture
> implies to me an architecture where you have:
> - events,
> - a dispatcher (which may produce events themselves, for
> instance alerts)
> - and event handlers (which may produce events themselves).
Excellent points. I consider the above list to be "active" features
(please see next comment below for the rest of this point).
> Of course, SOA does not require EDA and EDA does not imply
> SOA, but EDA could be a nice part of an SOA, for instance,
> IMO, in terms of monitoring (they call it BAM - Business
> Activity Monitoring),
In this context, BAM seems to be a "passive" feature - that is,
monitoring what has already occurred. That does not seem to me to be the
essense of EDA. I may be misunderstanding your point.
Booz Allen Hamilton
Strategy and Technology Consultants to the World
> so I would follow Jason Bloomberg of
> ZapThink on this: EDA is not opposed to SOA, but rather
> included into SOA.(1)
> I think the most important thing about SOA is that languages
> and platforms don't matter anymore, so you can choose the
> implementation language that fits best the requirements, as
> long as it satisfies the service contract.
> (1) http://www.zapthink.com/report.html?id=ZAPFLASH-06092004
> Guillaume Lebleu
> Chiusano Joseph wrote:
> >>-----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
> >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.
> >Kind Regards,
> >Joseph Chiusano
> >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
> >>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
> >>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
> >>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 <http://www.oasis-open.org>
> >>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>
> >The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> >initiative of OASIS <http://www.oasis-open.org>
> >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>
> 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>