RE: [xml-dev] Web Services/SOA - on SOA, and EDA and other TLAs.

["Chiusano Joseph" <chiusano_joseph@bah.com>]

> -----Original Message-----
> From: Guillaume Lebleu [mailto:gl@brixlogic.com] 
> Sent: Tuesday, November 30, 2004 9:47 PM
> Cc: xml-dev@lists.xml.org
> Subject: Re: [xml-dev] 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@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>
> >
> >  
> >
> 
> -----------------------------------------------------------------
> 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>
> 
>