RE: [soa-rm] explaination of RM to RA etc.

["Peter F Brown" <peter@justbrown.net>]

Duane:
I agree with your comment to my para 2...concepts don't build
castles...except in the air

I'm seeing some really useful parallels and analogies with the Topic Maps
standard in our work, and would even suggest to say a few things on it, and
its relevance to our work, at the F2F...

TTFN,
-Peter
-----Original Message-----
From: Duane Nickull [mailto:dnickull@adobe.com] 
Sent: 06 July 2005 18:32
To: peter@justbrown.net
Cc: soa-rm@lists.oasis-open.org
Subject: Re: [soa-rm] explaination of RM to RA etc.

Thanks Peter:

I was sure I had missed a bit. 

To your paragraph #1:
You are quite right. I'll start by correcting the bad use of the word
"instance"; yes - an instance cannot exist if the class cannot be
implemented.  It should have stated (from OO 101) An abstract class is "A
class that should never be instantiated; only its subclasses should be
instantiated. Abstract classes are defined so that other classes can inherit
from them."  The RM is not a programming language class, but in modeling,
the definition of "abstract" remains similar.

Paragraph #2:
To the bricks and mortar analogy, it is not quite correct IMO.  Yes - actual
bricks and mortar can be built into something, but the RM only contains the
abstract "concepts of" bricks and mortar, not the items themselves.

Paragraph #3:
I agree again.  The "how" is something that is definitely needed.  Most
models are used in some type of framework or other methodology to develop
architecture (Zachman, MDA, RUP et al.).  While it is outside the scope of
this TC, perhaps someone will take a lead on a subset of those for some sort
of SOA Framework?  The consensus from those I talked to at Java One seems to
be that SOA is more than just architecture; it is a way of thinking and the
"how" is embraced in that.  No one was quite able to be specific but I feel
that the "A" word at the end of SOA is no longer constraining SOA to just
software architecture.  It seems the marketing hype has lead this to be a
way of life (probably until something else like EDA, POA attracts more $$$).

Cheers!

Duane
(back from holiday wishing he was on another one;-)



Peter F Brown wrote:

>What is the "it" in this phrase? The "something" or the "instance" The RA?
>If you mean "once an instance of a (reference?) architecture can be 
>implemented, that architecture is no longer abstract": I don't like the 
>word abstract popping up here...maybe I just need a holiday. Anyway, 
>once an instance can be implemented it is obviously not abstract (if an 
>instance cannot be implemented, is it an instance? Sorry, but 
>terminology is going to haunt us all the way...)
>
>To say that an RM "must not be able to be implemented" is tautological 
>and possibly confusing. Its purpose is to conceptualise the necessary 
>"building blocks" and how they should be used together, no more, so 
>inevitably it cannot be implemented as that is not its function: it is 
>a bit like saying that "bricks and mortar must not be able to be 
>implemented": you will get those who will respond: "of course I can, I 
>just need some blueprints, building standards and guidelines, and a few 
>willing workers and we can build that castle...", but that's not our 
>point. The point is that an RM describes the what (and the why), but not
the how.
>
>The RA on the other hand should provide the how - not of a specific 
>implementation - but generically: does that mean the RA is (or is not) 
>abstract? Not sure it's helpful...For example, is an MDA-based Platform 
>Independent Model a reference architecture? If so, is it abstract? I 
>don't think so, but it is generic: it can be implemented in different 
>(platform
>specific) manners.
>
>So, RM, always abstract; RA, sufficiently detailed to enable *any*
>(conformant) implementation but sufficiently generic as to not 
>prescribe any
>*particular* implementation
>
>Peter
>(not yet on holiday but wishing he was...)
>
>-----Original Message-----
>From: Duane Nickull [mailto:dnickull@adobe.com]
>Sent: 06 July 2005 01:11
>To: flinn@alum.mit.edu
>Cc: soa-rm@lists.oasis-open.org
>Subject: Re: [soa-rm] explaination of RM to RA etc.
>
>Don:
>
>As I understand the term, once an instance of something can be 
>implemented, it is no longer "abstract".  (Please - someone correct me if I
am wrong).
>
>
>Therefor, to answer your questions:
>
>
>Don Flinn wrote:
>
>  
>
>>Duane
>>
>>I have a few questions.
>>
>>1. How abstract can/should the RA be?  IMO the more abstract the 
>>broader the coverage of potential, derived, concrete architectures.
>> 
>>
>>    
>>
>DN - It must be able to be implemented.  The RM, by its abstract 
>nature, must not be able to be implemented.  This has and will continue 
>to confuse many people with no architectural or OO knowledge.
>
>  
>
>>2. Do you mean the Profiles to be specific, abstract aspects of the RA?
>> 
>>
>>    
>>
>DN - Can you please elaborate?
>
>  
>
>>3. I'm not sure of the meaning of Related Models in this context.
>> 
>>
>>    
>>
>DN - if someone decides to model the network aspects of an RA using the 
>OSI reference model or if they also add in "process oriented" aspects 
>into the architecture, these models might be considered related.  I had 
>not decided on specific tests to determine the qualification of that 
>labeled association, however would enjoy any thoughts you, or anyone else
has.
>
>Cheers
>
>Duane (back from vacation and TOTTTTTTAAAALLLLY  relaxed).
>
>  
>
>>Don
>>
>>On Wed, 2005-06-29 at 11:46 -0700, Duane Nickull wrote:
>> 
>>
>>    
>>
>>>This is a graphic I developed this morning to depict how a RM may 
>>>relate to an SOA Framework.  Not sure if it is helpful or if we want 
>>>to pursue something like this in a separate white paper.
>>>
>>>Any comments would be appreciated.
>>>
>>>Duane
>>>   
>>>
>>>      
>>>
>> 
>>
>>    
>>
>
>
>  
>