Reference Model References (Was RE: [soa-rm] Groups - Rough notes taken during the last ebSOA meeting.(ebSOA-Elements.pdf) uploaded)

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

> 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.

Here are 2 that come to mind (note that #1 below is intended to be a SOA
RM, according to its description):

(1) http://xml.coverpages.org/ni2005-03-25-a.html

Announced 03/25/05: "The Commonwealth of Massachusetts has released a
review draft Version 3.0 for its Enterprise Technical Reference Model
(ETRM). The six-part document introduces Disciplines, Technology Areas,
and Technology Specifications for the Information, Application,
Integration and Security Domains. The ETRM calls for the development of
a SOA model built around interoperable XML specifications, including the
adoption of open formats, defined as necessarily "royalty-free.""

(2) SCORM: http://xml.coverpages.org/scorm.html 

Kind Regards,
Joseph Chiusano
Booz Allen Hamilton
Visit us online@ http://www.boozallen.com
 

> -----Original Message-----
> From: Thomas Erl [mailto:terl@serviceorientation.org] 
> Sent: Tuesday, March 29, 2005 1:39 AM
> To: soa-rm@lists.oasis-open.org
> Subject: Re: [soa-rm] Groups - Rough notes taken during the 
> last ebSOA meeting.(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
> > ***********
> > 
> 
> 
>