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)


Title: Re: [soa-rm] Reference Model vs. Reference Architecture (R
Rex,
 
This is to simply clarify your explanation below - not concurring or disagreeing. Regarding the following:
 
<Quote>
a reference model, which, in my understanding is an abstraction at least one level removed from the actual physical components of an architecture, which for us is the machines, wires, networks and signal protocols of the physical world,
</Quote>
 
According to my understanding of the "roadmap to SOA implementation" that we are advocating here, it appears that the abstraction would be more than 1 level removed - it would be 2 levels removed. In the middle of the RM and the more concrete architectures you refer to, we have a Reference Architecture (RA). So the roadmap that I understand is RM -> RA -> Architecture -> Design/Develop/Test, etc. (please note that Duane did include a step prior to RM in his earlier explanation of this, which was ADL/MetaModel - I am starting from RM here only because that is where our work begins).
 
I think it's wonderful that we are discussing this now, rather than waiting until our core RM is solid and then addressing it in a Compliance statement. I am hoping that we can avoid a situation in which we produce an RM, then find through real-world usage that the gap between our RM and the notion of an RA is so great that either we would have to go back to the drawing board (something no one wants to do I'm sure), or accept the fact that our hard work resulted in something that was not usable. I think it simply makes sense that if one is constructing a component of a roadmap, that they make sure that the components are joined to each other in a robust, close-proximity fashion so that there is not a wide gap between any 2 components that renders the path untraversable.
 
I see the verifications were are doing here in this thread as critical, *while* we are constructing our RM - not when it's too late.
 
Joe
 

Joseph Chiusano

Booz Allen Hamilton

Visit us online@ http://www.boozallen.com


From: Rex Brooks [mailto:rexb@starbourne.com]
Sent: Thu 5/12/2005 9:25 AM
To: Ken Laskey; soa-rm@lists.oasis-open.org
Subject: Re: [soa-rm] Reference Model vs. Reference Architecture (Road Map)

Sorry, but I have a problem with the notion that a reference model, which, in my understanding is an abstraction at least one level removed from the actual physical components of an architecture, which for us is the machines, wires, networks and signal protocols of the physical world, is anything other than a "representation" of an architecture.

Architecture is defined in Webster's Ninth as the art or science of building; specifically: the art or practice of designing or building of structures, esp for habitation....

IMO, Architecture deals with the "physical," be it plans on paper or in electronically retrievable storage. Models are conceptualizations drawn from some physical object or set of objects, even if we make "representations" of those models, either in words or diagrams. Let's not lose track of fundamental semantics or we will be seriously lost in the weeds. Architectures are the physical things. When done well, architectures are usually constructed from architectural plans, which can be physically small scale models, though are usually diagrammatic representations one level up from scale models (in our case rather difficult to construct except as software simulations). Often, many models which are tried for the sake of looking at how those models would look, or perform, based on modeling.

I would say that a reference model provides the concepts by which which modeling can take place. We should be able to build modeling tools from our reference model. I would make that the acid test of our deliverables, and the way in which the work should be brought full circle for testing against the real world out there. That is also the reason why I wanted to start from the concrete and draw our abstractions from use cases pulled from real world operational scenarios, so that we can return to those use cases to make sure that we solve the problems that we set out to solve.

Ciao,
Rex

At 10:46 PM -0400 5/11/05, Ken Laskey wrote:
Matt,

In a previous email, I sent a definition of "framework".  How does RM compare to framework?  And if my framework definition works, does the architecture definition (which was supposed to build on the framework one) work too?

Ken

At 09:30 AM 5/11/2005, Matthew MacKenzie wrote:
In my way of thinking, a reference model is actually a form of architecture, although I have been straying away from portraying it in that light in order to help others understand the distinction.

What form of architecture?  I call it an "architectural framework".
(for the sarcastic, you'll note that I am using two of the most overused words in our field here, but I feel they work.)

In my world, and architecture must be implementable and should not contain too many undefined/undesigned component areas where engineers/developers can make grievous mistakes.  On the other hand, an architectural framework is somewhat like a UML pallette you would find in Visio -- all of the concepts are represented on the pallette, and a trained practitioner knows how to arrange the concepts on her canvas to draw the picture.  This reference model that we are writing is effectively the training material used to train practitioners.

Is that clear, or have I added confusion?

-Matt

Chiusano Joseph wrote:
<Quote>
I would also pick Matt's brain on this subject.  He is far more
knowledgeable since he lives in this world every day.
</Quote>
Thanks Duane - that all makes sense. Matt, I for one would be interested in hearing anything you'd like to add please.

Joe


Joseph Chiusano

Booz Allen Hamilton

Visit us online@ http://www.boozallen.com <https://webmail.bah.com/exchweb/bin/redir.asp?URL=http://www.boozallen.com/>


------------------------------------------------------------------------
*From:* Duane Nickull [mailto:dnickull@adobe.com]
*Sent:* Tue 5/10/2005 8:35 PM
*Cc:* soa-rm@lists.oasis-open.org
*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
***********


--
     ---------------------------------------------------------------------------------
  /   Ken Laskey                                                                \
 |    MITRE Corporation, M/S H305    phone:  703-983-7934   |
 |    7515 Colshire Drive                    fax:      703-983-1379   |
  \   McLean VA 22102-7508                                              /
    ----------------------------------------------------------------------------------

*** note: phone number changed 4/15/2005 to 703-983-7934 ***


-- 
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309


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