OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [soa-rm] Groups - Rough notes taken during the last ebSOAmeeting.(ebSOA-Elements.pdf) uploaded


> "is it sufficiently different from other existing architecture reference 
> models to warrant existence as a concept?"

It would be helpful if we had abstract reference model documents of existing 
architectures in order to answer this question and to fully explain what 
distinguishes SOA.

Thomas

----- Original Message ----- 
From: "Duane Nickull" <dnickull@adobe.com>
Cc: <soa-rm@lists.oasis-open.org>
Sent: Monday, March 28, 2005 2:36 PM
Subject: Re: [soa-rm] Groups - Rough notes taken during the last ebSOA 
meeting.(ebSOA-Elements.pdf) uploaded


> Martin:
>
> IMO - SOA is potentially a specialization of a combination of many 
> things - interface based design (IBD), component architecture (CA), OO 
> methodology etc.   It seems to possess some elements of these things.  The 
> questions we need to answer are "How can we describe it as architecture?" 
> and "is it sufficiently different from other existing architecture 
> reference models to warrant existence as a concept?".  If it is 
> architecture, then surely it must be describable as architecture.
>
> My $0.02 worth:
>
> Services are core, but not sufficient by themselves to represent a new 
> class of architectural paradigm.  What else is needed for services to be 
> bound to in a true P2P environment?  Some way for the services to be 
> discoverable (Advertising) and some mechanism to describe all aspects of a 
> service (Service Description) that would be required in order to invoke 
> the service.  Additionally, knowing what invoking the service meant 
> (contract) and knowing the data that is passed in and optionally returns 
> from a service invocation (Data Model) are all core.  There are a lot of 
> questions we need to answer around this including whether or not semantics 
> of the data model is an important aspect.
>
> What is outside the core definition?  Messaging, Security, BPM, QoS and 
> any other items that is probably present in most SOA's but not all.  This 
> may seem very controversial at first but follow the logic.
>
> If I build something and that is "Service Oriented" architecturally, does 
> it have to have a "message"?  No - the service itself has a mechanism that 
> allows a service consumer to bind to it to invoke the service but it 
> doesn't actually have to be invoked for it to be "service oriented 
> architecture".  Does a car have to be driven on a road before it is a car? 
> The answer is likewise "no".  An application only has to be architected to 
> utilize the concepts surrounding a service in order to be utilized by 
> service consumers when it is implemented.  The reference model therefore 
> would not have a core messaging component.  Any architecture developed 
> using the reference model will likely have messaging as a component and 
> over half will likely employ some form of security.
>
> Summary:
>
> Following this core model, SOA is definable as architecture (as a 
> reference model) and is sufficiently distinct to warrant existence.  It 
> has a unique combination of components that work together to facilitate 
> services being present, discoverable and invokable.
>
> Duane Nickull
>
> ***********
> Senior Standards Strategist - Adobe Systems, Inc. - http://www.adobe.com
> Vice Chair - UN/CEFACT Bureau Plenary - http://www.unece.org/cefact/
> Adobe Enterprise Developer Resources  - 
> http://www.adobe.com/enterprise/developer/main.html
> ***********
> 




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]