Re: Initial Draft of 'beginningtodefine' in Word/PDF

[Erik_J_Leckner@Seagate.COM]

FYI

After reading this draft and seeing a set of components (gateway servers, etc.)
defined for an architecture which is yet to be defined, I propose that a
Reference Model for the Electronic Business XML Architectural Task Force should
first be introduced.


A RM would resolve integration problems, interworking and provide a framework
for the design of ebXML systems and services. ebXML would benefit from these
models by adopting ideas and approaches and utilising them to the needs of the
problem domain. This email offers a brief overview of a Reference Model for the
ebXML which can be used to describe the ebXML environment.


Viewpoint


A viewpoint is a subdivision of the architecture of a complete system,
established to bring together those particular pieces of information relevant to
some particular area of concern of the system design.


The six viewpoints defined for the Reference Model could be as follows:


a)     the enterprise viewpoint (V1); a viewpoint that focuses on the purpose,
scope, and policies for ebXML;
b)     the information viewpoint (V2); a viewpoint  that focuses on the
semantics of the information and information processing performed;
c)     the logical viewpoint (V3); a viewpoint that enables distribution through
logical decomposition of the system into entities which interact as interfaces;
d)     the functional viewpoint (V4); a viewpoint that focuses on the functions
required to support distributed interaction between entities in the ebXML;
e)     the physical viewpoint (V5); a viewpoint that focuses on the mechanisms
required to support interaction between elements in the ebXML; and
f)     the technology viewpoint (V6); a viewpoint that focuses on the choice of
technology in the ebXML;
Viewpoints can be thought of as projections onto the underlying system.


The different viewpoints outlined above create a separation of concerns in the
specification of the system being modelled.



Reference Model


The author prefers to use the phrase ?<viewpoint> architecture? throughout the
remainder of this email. In particular, the author will refer to the Enterprise
Architecture, the Information Architecture, and so on.


The following subsections provide the six viewpoints for RM.



Enterprise Architecture


The Enterprise Architecture describes the objectives, policies, and requirements
of the concerned system. In order to do this, the system is represented by one
or more enterprise entities within a community of enterprise entities, and by
the roles in which these entities are involved. These roles represent, for
example, the users (consumers) and providers (suppliers) of information
processed by the system.


One of the key ideas is that of a contract, linking the various performers of
the various roles and expressing their mutual obligations in the activity or
enterprise.


A federation is one particular kind of community; a federation is an agreement
of a number of groups of entities answering to different authorities in order
that they may jointly cooperate to achieve some objective.



Information Architecture


In the information specification, the semantics and requirements for the
processing of the information are specified.


A system can be represented in terms of information elements and their
relationships, where information elements are abstractions of entities that
occur in the real world, in the system, or in other viewpoints.


Basic information elements are represented by atomic information elements. More
complex information is represented as composite information elements expressing
relationships over a set of constituent information elements.


The information specification consists of a set of related schemata.  In RM, a
distinction is made between invariant, static, and dynamic schemata.


An invariant schema is a set of predicates on one or more information elements
which must always be true. The predicates constrain the possible states and
state changes of the objects to which they apply.


A static schema is a specification of the state of one or more information
elements, at some point in time, subject to the constraints of any invariant
schemeta.


A dynamic schema specifies the allowable state changes of one or more
information elements, subject to the constraints of any invariant schema.



Logical Architecture


The logical (or conceptual) architecture decomposes the system into logical
groupings of elements performing individual functions and interacting at
well-defined interfaces (reference points). The logical specification thus
provides the basis for decisions on how to logically distribute the functions
that need to be performed. The logical specification also allows for
encapsulation of existing applications as components of a larger application.


The functions and mechanisms are defined in the functional and physical
specifications to support the behaviour at the interfaces.



Functional Architecture


The functional architecture is comprised of a set of primitive functions which
describes the distribution of functionality within the system by means of
function blocks. Function blocks exchanging information are separated by
reference points. Function blocks provide the capabilities of Operations,
Administration, Maintenance, etc.


Function blocks may represent the edge functions found at the boundaries of the
logical architecture.  By specifying the function block pairs that may exchange
information, the RM can identify architectural reference points with associated
requirements for the interfaces at each reference point. A reference point is a
point of information exchange between non-overlapping function blocks.


The function blocks are themselves made up of functional components.



Physical Architecture


An engineering or physical specification defines the infrastructure required to
support functional distribution of a system, by identifying the functions
required to manage physical distribution, communication, processing, management,
and storage and identifying the roles of different engineering elements
supporting the functions. A physical architecture describes realizable
interfaces and physical components that constitute the system. The interfaces
correspond to the reference points described in the functional architecture. An
engineering specification is expressed in terms of a configuration of
engineering objects, structured as specialised elements; the activities that
occur within those engineering elements, and the interactions of those
engineering elements.


The physical entities are referred to as building blocks to contrast them with
functional blocks representing functionality without physical implementation. A
key aspect of the physical architecture is the interfaces that form the common
boundary between associated building blocks. Interfaces are found at the
architectural reference points.



Technology Architecture


The technology specification defines the choice of technology for a system in
terms of a configuration of technology objects (such as hardware and software
components) and the interfaces between them. A technology specification
expresses how the specifications for a system are implemented; identifies
specifications for technology relevant to the construction of systems, provides
a taxonomy for such specifications; and specifies the information required from
implementors to support testing.


The technology architecture provides a link between the set of viewpoint
specifications and the real-world implementation. Such a selection of solutions
is necessary to complete the overall system specification.


Comments/questions/etc are encouraged in response to this email. The last
viewpoint may be unnecessary, but to be consistent with the RM-ODP, it may be
included.


Regards,


Erik J Leckner


Seagate Technology: Chair, Electronic Business Task Force















srh@us.ibm.com on 01/31/2000 08:22:58 PM

To:   ebxml-architecture@lists.oasis-open.org
cc:    (bcc: Erik J Leckner)

Subject:  Initial Draft of 'beginningtodefine' in Word/PDF





This is the initial draft of the 'beginningtodefine' document
in Word and PDF, making it easier to work from
this week. A vision is that some day this will evolve into
the ebXML Architecture Document.

(See attached file: BeginningToDefineebXML_v1.doc)(See attached file:
BeginningToDefineebXML_v1.pdf)

Thanks,
Scott R. Hinkelman
IBM Austin
Architecture and Development, Industry XML/Java Standards
Office: 512-823-8097 TL793-8097
Home: 512-930-5675
Cell: 512-940-0519
srh@us.ibm.com
Fax: 512-838-1074

Mac Word 3.0

Adobe Portable Document