![](bg3.png)
by operation points. Those MOF concepts are con-
strained by a set of well formed rules. Those OCL
(Object constraint Language) statements come with
the “Ugatze::Component” package and express rules
between these concepts.
3.2 Integration devices: Interaction
ViewPoint
The “Interaction” viewpoint defines all the integra-
tion devices that the reuse architecture provides. This
metamodel is separated from the componential view-
point, because it aims different concerns: design for
reuse and design by reuse. The integration of the
components is based on the interactions points of
their interfaces (see section 3.1). In addition, inte-
gration rests on various interactions types: data, con-
trol and mixed interactions. The MOF package called
”Ugatze::Interaction”, relates to the formalisation of
these interactions. It contains the definitions of all
types of Interaction.
3.2.1 Integration mechanisms
From its most abstract form, the interaction connects
different kind of interaction points. For example, the
direct data interaction is a direct connection between a
OIP and a IIP, its communication mode is given by the
type of interaction points it connects. The concept of
direct “predefined” “Interaction” is similar to the con-
cept of “Binding Object” in the Computational View-
point of RM-ODP. In addition to these predefined in-
teractions, we allow the designer to define ”ad hoc”
interactions. There is three kind of “ad hoc interac-
tions”: data, control and mixed one.
3.2.2 Well formed rules
The well formed rules are used in this package to
build interactions. By example, the pre-defined direct
interactions can be built when the signature of con-
nected interaction points are compatibles, and such a
pre-defined control interaction only connects interac-
tion points whose “kind” is “control point”. More-
over, a “data ad hoc interaction” is defined by a rule
concerning the “kind” of interaction points it con-
nects. All those checks are done by OCL rules.
3.3 Middleware Origin Viewpoint
This Viewpoint, defined by the “Ugatze::Origin”
Package contains the implementation properties of
each legacy application, defining system origin of the
component. Its goal is to allow transformation tools
to generate or reuse the interoperability bridges.
3.4 Integration process
The reuse process we propose is “Architecture Cen-
tred”, it is composed by several transformation and
developpment steps, performed on an graph interac-
tions, and following the separation of concerns.
3.4.1 Application Architecture stage
The Application Achitecture process consists on
building an interaction graph, to perform the integra-
tion on design level. This stage exploits the com-
ponent interface viewpoint and the integration view-
point to provide a platform independant model (PIM)
of the component based distributed application. This
graph represents an interconnection of heterogeneous
components which interact thanks to data or con-
trol interactions, and use several predefined integra-
tion tools as mailbox or shared resources. ASIMIL
Project is a practical application of the integration
process. ASIMIL application graph is built from
ASIMIL components and Ugatze interactions. The
component MAS (Multi Agent System) is intended to
deliver a diagnosis on the behaviour of a learner who
is piloting a flight simulator, the PFC (Procedure Fol-
low Up Component) plays the role of supervisor of
this learner during the flight procedure. The reader
will be able to refer to ((Aniort
´
e and Seyler, 2002))
to have a more precise sight of the project and our
proposals relating to it.
Implementation stage is split into two sub activi-
ties, and can be managed by two roles: a specialist of
M2M inteoperability, and a classical component de-
velopper.
3.4.2 M2M Interaction Integration stage
M2M Interaction Integration stage essentially ex-
ploits the midlleware origin viewpoint. This stage
determines the architecture of interoperability bridges
according to the run time environment of the compo-
nents. The PIM is used to determine the sub graphs
constituted by middleware origins and communica-
tion modes. The graph let appears integration points,
shown by the intersection of each sub graph, and ac-
cording to the communication mode: synchronous
communication channel, or publish/subscribe one in a
CORBA/EJB interoperability bridge, GIOP or adhoc
Corba bridges. In this stage, pre-defined interaction
devices (as mail box, shared resource), and “ad hoc”
interactions are considered as classical components.
In Figure 2, this view let appear six M2M interactions
between two different run time environments.
3.4.3 Interaction Implementation stage
The Interaction Implementation stage concerns the
implementation or reuse of tools proposed by the plat-
MODEL BASED MIDDLEWARE INTEGRATION
597