[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Web Services/SOA - on SOA, and EDA and other TLAs.

  • To: "Guillaume Lebleu" <gl@b...>
  • Subject: RE: Web Services/SOA - on SOA, and EDA and other TLAs.
  • From: "Chiusano Joseph" <chiusano_joseph@b...>
  • Date: Tue, 30 Nov 2004 22:24:24 -0500
  • Cc: <xml-dev@l...>
  • Thread-index: AcTXUF7Tko8S/0tNTJCboBKYlfFPWgABIZ0g
  • Thread-topic: Web Services/SOA - on SOA, and EDA and other TLAs.

eda soa
> -----Original Message-----
> From: Guillaume Lebleu [mailto:gl@b...] 
> Sent: Tuesday, November 30, 2004 9:47 PM
> Cc: xml-dev@l...
> Subject: Re:  Web Services/SOA - on SOA, and EDA and 
> other TLAs.
> 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).

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.

Kind Regards,
Joseph Chiusano
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
> Brixlogic
> Chiusano Joseph wrote:
> >>-----Original Message-----
> >>From: Bullard, Claude L (Len) [mailto:len.bullard@i...]
> >>Sent: Tuesday, November 30, 2004 1:21 PM
> >>To: 'Michael Champion'; xml-dev@l...
> >>Subject: RE:  Web Services/SOA (was RE:  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@g...]
> >>
> >>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>
> >
> >  
> >
> -----------------------------------------------------------------
> 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>


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.