[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] [soa-rm-ra] Architectural Principles (DRAFT)
I've examined these architectural principles further, and have the
following comments and a recommendation:
-
Some of them seem too detailed for our purposes (at least for our starting
purposes) - e.g. principle #2
-
They seem divorced from our SOA-RM spec
My recommendation would be for us to start from the top of the SOA-RM
spec and work our way through it, deriving principles that are either explicit
in the text, or implicit, and recording the following:
-
Page/line #
-
Principle
-
Explicit/implicit
-
If implicit, how we arrived at the principle
Thanks,
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 From: Jeffrey A Estefan [mailto:Jeffrey.A.Estefan@jpl.nasa.gov] Sent: Tuesday, February 28, 2006 3:53 PM To: soa-rm@lists.oasis-open.org Subject: [soa-rm] [soa-rm-ra] Architectural Principles (DRAFT) Colleagues,
My original message didn't get through the
subcommittee subscriber list so I'm sending this note to the SOA-RM list because
I need to get this material out before tomorrow's SC meeting. I've
submitted a request to be added to the SOA-RM-RA SC e-mail list
server.
Regards...
- J.A.E.
----- Original Message -----
From: Jeffrey A Estefan
Sent: Tuesday, February 28, 2006 11:57 AM
Subject: [soa-rm-ra] Architectural Principles (DRAFT) SOA-RM-RA SC Members,
I am a Wiki novice so I'm sending this response to
my action item to provide Architectural Principles via this e-mail note.
Hopefully, somebody can provide me with some quick guidance on posting this in a
special collection on our Wiki.
Text in bold face within the description of the
principles are defined/referenced in the SOA-RM specification. There are
two candidate sets of principles with a great deal of overlap between the two
and some minor wordsmithing between them. I will need to refactor these
later into the industry best practice of capturing principles in terms of
Name, Statement, Rationale, and Implications. For now,
these principles are presented for the SC members to provide feedback
before I go through the trouble of characterizing the principles in such a
recommended format.
Regards...
- Jeff Estefan, Jet Propulsion
Laboratory
SOA-RM-RA Architecture Principles (Version
1; 4 Principles):
1. Systems are composed of a loosely
coupled collection of well-defined and interoperable network services and
tools.
"Network services" implies that
the capability is available across the network via an industry
standard protocol and that the service's capabilities and
interface are publicly defined and reachable
via an industry standard method. "Interoperable" implies similar tools and
services expose the same or a subset of the agreed upon versioned interfaces,
i.e., plug-and-play.
2. Information is defined externally to any
given service or tool and is readily available to all authorized
users.
"Defined externally" means that there are one or
more information models (ontologies) that clearly represent the
information and concepts that are believed to be needed to be exchanged and that
all systems understand and communicate via the relevant portion of the
ontology. By "readily available" it is meant that information is held by
the system as a whole and is reachable by any authorized user
or system.
3. The reference architecture shall be
characterized as a distributed system architecture that is both tiered and
layered to support a separation of concerns.
Architectural tiers and architectural layers both
describe a logical separation of functions such that each tier or layer has a
specific set of roles and responsibilities. By "tiered" it is meant that
the boundaries between tiers are chosen/designed to support distribution,
scalability, and reuse. Logical tiers can be mapped to any number of
different physical computer network topologies. By "layered" it is meant
that there is a need to logically separate common infrastructure capabilities
(for example, communication) from general services (for example, authorization)
from business logic.
NOTE: The above principle
could arguably be a formal architectural requirement versus an architectural
principle. Let's discuss this! Further, this requirement (or
principle) will need to be referenced from an excellent external white
paper by Mike Rosen & John Parodi of IONA
Technologies.
4. Client interfaces and displays are
decoupled from their underlying processing and data management
functions.
"Decoupled" implies that the functions can be
severally, i.e., one could chose to use the processing capability, but choose to
use an alternative display interface. The intent is to allow for mission
or technology specific interfaces to the same underlying processing and data
management capabilities.
SOA-RM-RA Architecture Principles (Version
2; 3 Principles):
1. Systems are composed of a loosely
coupled collection of well-defined and interoperable network services and
tools.
By "network service," it is meant
that the capability is available across the network via an
industry standard protocol and that the service's capabilities and
interface are publicly defined and reachable
via an industry standard method. By "interoperable" it is meant that
similar tools and services expose the same or subset of agreed upon versioned
interfaces, i.e., plug-and-play.
By "defined externally" it is meant that there
exists one or more information models (potentially ontologies)
that clearly represent the information and concepts that need to be exchanged
and that all systems understand and communicate via the relevant portion of the
ontology. By "readily available" it is meant that information is held by
the system as a whole and can be easily reachable by any
authorized user or system.
3. The architecture should encourage
the use of common solutions, designs, and services where applicable. It
should facilitate re-use of common functionality, as opposed to re-creation of
similar capabilities.
By "common" it is meant that the capabilities
(services, components, designs) can be reused by multiple
systems, that new capabilities are realized by interconnecting
sets of network accessible services, and that new components and services are
developed only when absolutely necessary, i.e., re-use vice re-creation.
In order to achieve the desired level of reuse, the architecture promotes the
use of architectural tiering and layering to support a separation of concerns,
as well as guidelines for determining the appropriate level of granularity for a
service or component.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]