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 -----
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.
2. Information is defined externally to any given service or tool and
is readily available to all authorized users.
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.