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

[Duane Nickull <dnickull@adobe.com>]

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