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?


Fine, then make 1.2 do what I was going after in 1.x.  Just make sure the reader doesn't have to sift through a lot of prose to figure out what we see as our core principles and any requirements we care to explicitly derive.

Ken

P.S.  Hey guys, I'm heading home and then off to traveling over the holidays.  (Yes, Frank, I intend to sneak back into work at some point to work on service description.)  May you and yours have a great set of holidays whatever you celebrate.  Be careful out there and with any luck we can all meet back in Frank's dining room sometime next year.


On Dec 21, 2007, at 5:21 PM, Danny Thornton wrote:

I think the 1.x section about requirements may be
viewed as overlapping with what is currently in
section 1.2 for the three key principles of the RA
approach.

I will reiterated what Jeff stated earlier about
requirements. For ALL of the government projects I've
worked on in the past, requirements are traceable,
testable, and measurable. Requirements are checked and
signed off during formal acceptance testing.  

If we provide requirements, then we are providing an
initial set of traceable, testable, and measureable
statements about a SOA-based system.

For example, take the following requirement:

Resources are distributed across ownership boundaries,
e.g. there is not a single entity that can exercise
control over all identified SOA services.

This is an accurate statement about a SOA ecosystem
but would not be something to measure about the
implementation of a particular system.  Therefore, I
would classify it more in the category of a principle.
 To be a high-level testable requirement that could be
traced to more detailed testable requirements, the
above requirement could be written as:

Resources shall be accessable across ownerhips
boundaries.  ...

Danny

--- Ken Laskey <klaskey@mitre.org> wrote:

Frank,

Let me go back to what I proposed 11/12/2007 but
modify for Jeff and  
Danny's comment and some of your initial ones:

1 Introduction

Service Oriented Architecture is an architectural
paradigm that has  
gained significant attention within the information
technology (IT)  
and business communities. The OASIS Reference Model
for SOA provides  
a common language for understanding the important
features of SOA but  
does not address the issues involved in
constructing, using, or  
owning a SOA-based system. This document focuses on
these aspects of  
SOA.


1.1 What is a Reference Architecture

A reference architecture models the abstract
architectural elements  
in the domain independent of the technologies,
protocols, and  
products that are used to implement the domain. It
differs from a  
Reference Model in that a Reference Model describes
the important  
concepts and relationships in the domain focusing on
what  
distinguishes the elements of the domain; a
Reference Architecture  
elaborates further on the model to show a more
complete picture that  
includes what is involved in realizing the modeled
entities. While  
still remaining abstract, a reference architecture
is more concrete  
than a Reference Model in that it identifies and
provides a high  
level description of architectural components and
artifacts.


1.x What is this Reference Architecture

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.


While requirements for this reference architecture
are discussed in  
Section 2, an overview of those requirements
specifies a SOA for which:


Resources are distributed across ownership
boundaries, e.g. there is  
not a single entity that can exercise control over
all identified SOA  
services;
Resources have been developed for purposes other
than inclusion in a  
particular implementation following this reference
architecture, and  
those resources should continue to support those
initial purposes as  
well as the expanded access via SOA;
Infrastructure must be in place to enable
communications through the  
exchange of messages and with reliability
appropriate for the users  
and purposes for which the SOA implementation is
used;
Security, governance, and management must be
effective but consistent  
with multiple ownership boundaries;
Appropriate mediation must be available to enable
coordinated use of  
independently developed resources;
[other overarching assumptions/requirements?]

Below, we talk about such an environment as a SOA
ecosystem.  
Informally, our goal in this Reference Architecture
is to show how  
Service Oriented Architecture fits into the life of
users and  
stakeholders in a SOA ecosystem, how SOA-based
systems may be  
realized effectively, and what is involved in owning
such a SOA-based  
system. We believe that this approach will serve two
purposes:  
ensuring that the true value of a SOA meeting the
stated requirements  
can be realized using appropriate technology, and
permitting the  
audience to focus on the important issues without
becoming over- 
burdened with the details of a particular
implementation technology.


1.2 Service Oriented Architecture – An Ecosystems
perspective

Many systems cannot be understood by a simple
decomposition into  
parts and subsystems. There are...


OK, at the time we discussed this I see some
comments but other than  
the mixing of architecture and design, there was no
major heartburn.   
Does this work in satisfying my stated goal?  Does
the goal itself  
not serve a useful purpose for this document?

Ken

On Dec 21, 2007, at 3:29 PM, Francis McCabe wrote:

Ken:
 Except that the wording you proposed would have
directly  
replicated existing wording and made for
redundancy.

 Personally, I think we need to move on.
Frank


On Dec 21, 2007, at 12:22 PM, Ken Laskey wrote:

Danny,

Following Jeff's point, we need to see where the
proposed words  
fit in the Intro.  When I originated the draft, I
intended for it  
to be part of a new section 1.x entitled "What is
This RA" that  
sat between 1.1 and 1.2.  I didn't intend to
alter (modulo other  
comments) the section 1.1 words on reference
architecture.

In the previous email thread with Jeff, I
realized the RM wording  
was unintentionally sloppy and suggested the
TOGAF reference as a  
way to "clarify" the RM definition.  Jeff
responded that he only  
supplied that for an example, and thought 1.1 was
sufficient.  I'm  
willing to go with that being my intent was not
the redefinition  
of reference architecture but a statement about
the problem being  
solved by our RA.  So I am more interested in 1.x
and not in  
rewriting 1.1.

This thread began 11/10/2007 and isn't very long,
so a quick  
review might help all.

Ken

On Dec 21, 2007, at 3:11 PM, Danny Thornton
wrote:

Jeff,

Didn't you propose the TOGAF reference?

All,

I think Jeff and I are both opposed to stating a
Reference Archicture is a design pattern because
we
both see the use of design pattern in this
context as
an incorrect statement.


=== message truncated ===



      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 


------------------------------------------------------------------------------------------

Ken Laskey

MITRE Corporation, M/S H305     phone:  703-983-7934

7515 Colshire Drive                        fax:        703-983-1379

McLean VA 22102-7508


smime.p7s



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