[
Lists Home |
Date Index |
Thread Index
]
IMHO...
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).
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), 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
Brixlogic
Chiusano Joseph wrote:
>>-----Original Message-----
>>From: Bullard, Claude L (Len) [mailto:len.bullard@intergraph.com]
>>Sent: Tuesday, November 30, 2004 1:21 PM
>>To: 'Michael Champion'; xml-dev@lists.xml.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.
>
>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 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.
>>
>>len
>>
>>
>>From: Michael Champion [mailto:michaelc.champion@gmail.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
>>http://www.cioupdate.com/trends/article.php/3434691
>>
>>'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
>><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>
>
>
>
|
