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 Architecture


> That brings up another question. Forgetting about 
> contradictions between the reference architectures for a 
> moment, could a given concrete architecture be generated from 
> more than one reference architecture.

I would say absolutely yes. In fact, I briefly touched on this in the
presentation that Rebekah and I gave last Tuesday, specifically when
speaking about the associations between SOA-RM and the DRM. I mentioned
the general notion of taking 2 reference models and extracting various
aspects of each of them, to form a new entity (thing). The same notion
may apply to reference architectures as well.

The example I gave was a car that could fly above the highway in
rush-hour traffic and get to the exit that is only 50 feet away from
them (us DC-area folks are thinking about the Capital Beltway of
course). Such an invention would have features of both a car and a
plane, though not all features of both.

Joe

Joseph Chiusano
Associate
Booz Allen Hamilton
 
700 13th St. NW, Suite 1100
Washington, DC 20005
O: 202-508-6514  
C: 202-251-0731
Visit us online@ http://www.boozallen.com
 

> -----Original Message-----
> From: Michael Stiefel [mailto:development@reliablesoftware.com] 
> Sent: Sunday, January 29, 2006 7:24 PM
> To: frankmccabe@mac.com; soa-rm@lists.oasis-open.org
> Subject: Re: [soa-rm] Reference Architecture
> 
> Agreed that the appropriate requirements should be part of 
> the RA. Also agreed that the requirements could vary in their 
> "concreteness".
> 
> To use our housing example, we could have any one of the 
> following requirements in the RA:
>          there has to be an eating area
>          the eating area may or may  not have room for dining
>          the eating area must have a dining area and either a 
> stove or a microwave
>          the eating area must take up between 10% and 20% of 
> the are of the floor it is on
>          etc.
> 
> It almost seems that the RA could be a sort of abstract BNF 
> or some set of production rules.
> 
> That brings up another question. Forgetting about 
> contradictions between the reference architectures for a 
> moment, could a given concrete architecture be generated from 
> more than one reference architecture.
> 
> For example, a Queen Anne style building originally borrowed 
> from pre-Georgian and late Medieval style buildings. It 
> eventually developed into a pastiche of various influences.
> 
> Michael
> 
> At 07:55 PM 1/26/2006, Francis McCabe wrote:
> >Right.
> >Although I think that the requirements need not be 
> completely concrete 
> >in a reference architecture. Also I think that we need to 
> ensure that 
> >the requirements we adopt are an explicit part of the RA itself.
> >One other thing, there are requirement of an architecture and 
> >properties of an architecture. So I think that the 
> appropriate logic is:
> >
> >There are requirements a,b and c. These are predicates, if you will, 
> >that must be satisfied by the architecture.
> >There are properties p, q and r. If these properties hold 
> then a,b and 
> >c will be satisfied. It may not be provable that p,q and r will give 
> >you a, b and c. But properties are measurable.
> >Then there are mechanisms (modules, patterns, relationships 
> whatever) 
> >that, in combination, exhibit properties p, q and r.
> >Then you are done!
> >
> >E.g., "the architecture shall be securable" is a reasonable 
> >requirement. We assert that proper authentication and auditing will 
> >result in a secure architecture. (Not by itself provable of course.) 
> >Then in an architecture in which agents must authenticate 
> themselves, 
> >and supply authentication tokens to an escrow for each communication 
> >then we have established a mechanism that gives us our required 
> >properties and have a secure architecture.
> >
> >Frank
> >
> >
> >On Jan 26, 2006, at 6:53 AM, Michael Stiefel wrote:
> >
> >>Frank:
> >>
> >>Fair enough.
> >>
> >>Let me see if I understand you correctly. A reference architecture 
> >>states principles such as:
> >>
> >>Given concrete requirements a and b abstract mechanism x 
> will be one 
> >>possible way to salsify it.
> >>Given concrete requirement c, abstract mechanism y will be the only 
> >>way to satisfy it.
> >>Given concrete requirements d and e, a you use abstract 
> mechanisms w 
> >>and z to satisfy it.
> >>Given concrete requirement f, a relationship between model 
> elements q 
> >>and r is the only way to satisfy it.
> >>
> >>Michael
> >>
> >>
> >>At 11:11 PM 1/25/2006, you wrote:
> >>>Michael:
> >>>  I have to confess that I don't much like this 
> definition. It gives 
> >>>no guidance or expectation as to what an RA will do for 
> you. That is 
> >>>why I used the phrase mechanisms - I want to be able to inform 
> >>>architects how to build something that will work.
> >>>Frank
> >>>
> >>>On Jan 25, 2006, at 6:58 AM, Michael Stiefel wrote:
> >>>
> >>>>Here is a link discussing using reference architecture within the 
> >>>>RUP framework: http://www-128.ibm.com/developerworks/rational/
> >>>>library/2774.html
> >>>>
> >>>>I am not advocating the RUP framework, but they seem to have a 
> >>>>definition of a reference architecture that could serve as a 
> >>>>starting point:
> >>>>
> >>>>A reference architecture is a resource containing a 
> consistent set 
> >>>>of architectural best practices for use by all the teams in your 
> >>>>organization.
> >>>>
> >>>>
> >>>>As a set of patterns it is reasonably abstract, yet 
> concrete enough 
> >>>>to help develop specific solutions.
> >>>>
> >>>>Michael
> >>>>
> >>>>At 12:33 AM 1/14/2006, you wrote:
> >>>>>The time has come to start considering the development of a 
> >>>>>Reference Architecture.
> >>>>>
> >>>>>The TC agreed to establish a sub-committee to pursue this, so we 
> >>>>>will be called the SOA RM TC RA SC !
> >>>>>
> >>>>>  The first item of business is to develop a statement 
> of purpose.
> >>>>>
> >>>>>  One suggestion is:
> >>>>>
> >>>>>  To develop, in accordance with the SOA RM TC Charter, 
> a reference 
> >>>>>Service Oriented Architecture.
> >>>>>
> >>>>>  Definition: A reference model that is mapped onto software 
> >>>>>elements that implements the functionality defined in 
> the reference 
> >>>>>model.
> >>>>>  www.sei.cmu.edu/architecture/glossary.html
> >>>>>
> >>>>>  Definition: A reference architecture is an abstract set of 
> >>>>>mechanisms and relationships that models a predetermined set of 
> >>>>>requirements.
> >>>>>  McCabe 2006
> >>>>>
> >>>>>  Keywords: abstract, mechanisms, model, requirements.
> >>>>>
> >>>>>  A reference architecture can be to guide the realization of 
> >>>>>implementations where specific properties are desired of the 
> >>>>>concrete system.
> >>>>>
> >>>>>  To initiate the discussion, some questions suggest themselves:
> >>>>>
> >>>>>1. What requirements should be captured in a reference 
> architecture 
> >>>>>2. What mechanisms are required to realize those requirements 3. 
> >>>>>What is the relationship between the Reference Model and the 
> >>>>>Reference Architecture 4. What additional concepts (if any) to 
> >>>>>those captured in the Reference Model are necessary to 
> develop an 
> >>>>>RA.
> >>>>>
> >>>>>  Immediate steps
> >>>>>1. To agree on a statement of purpose 2. To collect requirements
> >>>>>
> >>>>>Let the fur fly!
> >>>>>
> >>>>>Frank McCabe
> >>
> >>
> >
> 
> 
> 


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