OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm-ra message

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


Subject: Re: [soa-rm-ra] what is a generalized SOA RA?


To me RA is a generalized view of an purposeful architecture that may be
specialized for one or more domains of application.  As such, a RA often
specifies the major components of a system or systems, their externally
visible properties and the relationships amongst them in a manner abstract
of domain, technologies or specifics that would constraint the RA from being
applicable to the widest possible scope of use.


On 12/20/07 7:31 PM, "Francis McCabe" <frankmccabe@mac.com> wrote:

> I have a couple of reasons for leaving the wording as is:
> 1. This *is* a follow-on work from the RM
> 2. The second sentence, which is apparently from TOGAF, defines an
> architecture without requirements. I don't like that so much.
> 
> I picked up the last wording on the email thread I could find. There
> might be a better one.
> 
> I will, however, have another go at the later part of the section.
> Frank
> 
> On Dec 20, 2007, at 6:37 PM, Duane Nickull wrote:
> 
>> Didn't Jeff already have wording and a definition for RA?
>> 
>> D
>> 
>> 
>> On 12/20/07 4:11 PM, "Francis McCabe" <frankmccabe@mac.com> wrote:
>> 
>>> Proposed wording for the section:
>>> 
>>> The SOA Reference Model defines reference architecture as łan
>>> architectural design pattern that indicates how an abstract set of
>>> mechanisms and relationships realizes a predetermined set of
>>> requirements.˛ More precisely, a reference architecture can be
>>> described as an architectural pattern that provides a set of
>>> predefined subsystems, specifies their responsibilities, and includes
>>> rules and guidelines for organizing the relationships between them
>>> [TOGAF v8.1].
>>> 
>>> It is possible to define reference architectures at many levels of
>>> detail or abstraction, and for many different purposes. In fact, the
>>> reference architecture for one domain may represent a further
>>> specialization of another reference architecture, with additional
>>> requirements over those for which the more general reference
>>> architecture was defined.
>>> 
>>> A reference architecture need not be a concrete architecture; i.e.,
>>> depending on the requirements being addressed by the reference
>>> architecture, it may not be necessary to completely specify all the
>>> technologies, components and their relationships in sufficient detail
>>> to enable direct implementation.  Such a concrete architecture may be
>>> valuable and necessary to ensure a successful implementation;
>>> however,
>>> the detail necessary in concrete architectures may force technology
>>> choices that are not forced by the requirements of SOA-based systems
>>> per se, but by the technology choices available at the time.
>>> 
>>> Our approach is to beis as high-level and as technology-neutral as
>>> possible; while at the same time being fully aware of the dominant
>>> technologies likely to be employed. In fact, while the degree of
>>> abstraction in the Reference Architecture is more concrete than in
>>> the
>>> Reference Model; we attempt to capture the essence of the
>>> architectural components that form SOA-based systems.In fact, the
>>> degree of abstraction in the Reference Architecture is more concrete
>>> than in the Reference Model; we attempt to capture the essence of the
>>> architectural components at an appropriate level of abstraction.
>>> 
>>> We believe that out our approach will serve two purposes: ensuring
>>> that the true value of the SOA approach can be realized on any
>>> appropriate technology, and it permitspermitting our audience to
>>> focus
>>> on the important issues without becoming over-burdened with the
>>> details.
>>> 
>>> -----
>>> I kept the initial sentence from Ken's proposal because I felt that
>>> the TOGAF definition missed something; but I thought that having it
>>> there helped.
>>> 
>>> I also elaborated some on the abstract vs concrete dimension;
>>> attempting to give our work a justification.
>>> 
>>> Frank
>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this mail list, you must leave the OASIS TC that
>>> generates this mail.  You may a link to this group and all your TCs
>>> in OASIS
>>> at:
>>> https://www.oasis-open.org/apps/org/workgroup/portal/
>>> my_workgroups.php
>>> 
>> 
>> -- 
>> **********************************************************************
>> "Speaking only for myself"
>> Senior Technical Evangelist - Adobe Systems, Inc.
>> Blog - http://technoracle.blogspot.com
>> Community Music - http://www.mix2r.com
>> My Band - http://www.myspace.com/22ndcentury
>> Adobe MAX 2008 - http://technoracle.blogspot.com/2007/08/adobe-max-2008.html
>> **********************************************************************
>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 

-- 
**********************************************************************
"Speaking only for myself"
Senior Technical Evangelist - Adobe Systems, Inc.
Blog - http://technoracle.blogspot.com
Community Music - http://www.mix2r.com
My Band - http://www.myspace.com/22ndcentury
Adobe MAX 2008 - http://technoracle.blogspot.com/2007/08/adobe-max-2008.html
**********************************************************************



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