Proposed wording for the section:
The SOA Reference Model defines reference architecture as “an
architectural design pattern that indicates how an abstract set of
mechanisms and relationships realizes a predetermined set of
requirements.” More precisely, a reference architecture can be
described as an architectural pattern that provides a set of
predefined subsystems, specifies their responsibilities, and includes
rules and guidelines for organizing the relationships between them
[TOGAF v8.1].
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.
A reference architecture need not be a concrete architecture; i.e.,
depending on the requirements being addressed by the reference
architecture, it may not be necessary to completely specify all the
technologies, components and their relationships in sufficient detail
to enable direct implementation. Such a concrete architecture may be
valuable and necessary to ensure a successful implementation;
however,
the detail necessary in concrete architectures may force technology
choices that are not forced by the requirements of SOA-based systems
per se, but by the technology choices available at the time.
Our approach is to beis as high-level and as technology-neutral as
possible; while at the same time being fully aware of the dominant
technologies likely to be employed. In fact, while the degree of
abstraction in the Reference Architecture is more concrete than in
the
Reference Model; we attempt to capture the essence of the
architectural components that form SOA-based systems.In fact, the
degree of abstraction in the Reference Architecture is more concrete
than in the Reference Model; we attempt to capture the essence of the
architectural components at an appropriate level of abstraction.
We believe that out our approach will serve two purposes: ensuring
that the true value of the SOA approach can be realized on any
appropriate technology, and it permitspermitting our audience to
focus
on the important issues without becoming over-burdened with the
details.
-----
I kept the initial sentence from Ken's proposal because I felt that
the TOGAF definition missed something; but I thought that having it
there helped.
I also elaborated some on the abstract vs concrete dimension;
attempting to give our work a justification.
Frank
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs
in OASIS
at:
my_workgroups.php
Senior Technical Evangelist - Adobe Systems, Inc.