approach.
requirements. For ALL of the government projects I've
testable, and measurable. Requirements are checked and
signed off during formal acceptance testing.
statements about a SOA-based system.
e.g. there is not a single entity that can exercise
control over all identified SOA services.
implementation of a particular system. Therefore, I
would classify it more in the category of a principle.
boundaries. ...
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.
Never miss a thing. Make Yahoo your home page.