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] Reference Model vs. Reference Architecture (Road Map)


Joseph:

I am going to take a try at this. Please forgive this next sentence:

"A reference model is a model while a reference architecture is an 
architecture. "
 
Okay - so what does that really mean (other that I couldn't find 
appropriate words)?  Not an easy question to answer.

There are multiple differences you can state such as "One is 
implement-able, the other is not".  A reference architecture does tend 
to be more generic than most use cases would require and would still 
need to be specialized further for a particular set of requirements.

Reference architecture is sort of a proof of concept. Individual 
requirements and implementations  may vary, but with the
data and guidelines from such reference implementations the system 
designer can make more informed decisions.  A reference architecture 
also may force you to consider things the RM does not delve into.  The 
RM for building a house may have a notion of a bathroom and also a 
kitchen.  The reference model states you have to have one instance of 
each to fulfill the functional requirements of providing a habitat for a 
human being, but does not show a level of detail of how you could build 
a house having both.

The reference architecture for a house would delve into how plumbing 
gets from the source/target to both the bathroom and the kitchen, as 
well as a documented layout that shows how they are connected and what 
other common touchpoints and infrastructure they share.  It is a more 
specific design that can also be further specialized.  It forces someone 
architecting another house to consider the same question and perhaps 
even shows them a solution paradigm (example - hide the pipes in the 
wall).  This also hints at ways of implementing things that are 
optimized (hiding pipes in the wall is better than running them outside 
the house in climates where they may freeze).

The Reference Architecture for this alleged house can also be modified 
for someone who owns property that is on a 10 degree slope or is not 
connected to a city water and sewage system (let's not get into those 
details).  It may also further optimize the house's orientation to 
optimize it for natural sunlight and views via windows.

The order of abstraction is as follows:

1. Meta models and meta conventions(ADL's and notions such as patterns 
of pipes and filters, stacks, etc.)
2. Reference Models
3. Reference Architectures
4. Specific Architectures.

There is of course, not 100% consensus on this subject and even 
something as simple as a definition of architecture itself has proven to 
be very difficult.

I would also pick Matt's brain on this subject.  He is far more 
knowledgeable since he lives in this world every day.

Duane
Duane


Chiusano Joseph wrote:

> I think it is very important that at some point we include in our spec 
> the necessary guidance for users of our spec to move from our 
> reference model to a reference architecture, and perhaps beyond.
>  
> I have seen so many cases in which the terms "reference model" and 
> "reference architecture" have been used interchangeably (and sometimes 
> in the same resource!) that I am no longer crystal clear on the 
> similarities/differences between the 2. I know that there has been 
> preliminary discussion that reference model != reference architecture.
>  
> Can someone please provide a clear distinction between the 2, and how 
> we envision our RM "flowing" into an RA?
>  
> Thanks,
> Joe
>  
> Joseph Chiusano
> Booz Allen Hamilton
> Visit us online@ http://www.boozallen.com <http://www.boozallen.com/>
>  


-- 
***********
Senior Standards Strategist - Adobe Systems, Inc. - http://www.adobe.com
Chair - OASIS Service Oriented Architecture Reference Model Technical Committee - 
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm
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]