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.