Checking the conformability in CORBA component mode specifications

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (7.32 MB, 11 trang )

(1)<div class='page_container' data-page=1>

VNU Journal of Science, N atural Sciences and Technology 24 (2008) 92-102

Checking the conformability in CORBA component mode

specifications

Tran Thi Mai Thuong*, V o Van Thanh, Truong N inh Thuan

College o f Technology, VNU, 144Xuan Thuy Road, Cau Giay District, Hanoi, Vietnam

Received 31 October 2007

A bstract. We proposed in this paper an a p p ro a c h for checking the conformability in CORBA

com ponent m odel specifications. In software engineering, it is dem onstrated that discovering bugs

in earlier phases is much more economical than later phases. We focused thus on verifying

com ponents by their ports specification. In order to do this, firstly we determ ined constraints on

kinds of port as well as on types of port which the connection between ports must satisfy, and then
formalized them to be able to prove automatically using formal prover tools. Here, we proposed to

u s e th e B m e th o d fo r v e rify in g c o m p o n e n ts in a CCM s p e c ific a tio n .

1. In tro d u c tio n

T he enorm ous expansion in the use o f
softw are in every field o f life make dem ands on
installing and developing reusable, robust,
reliable, flexible, adaptive softw are systems
m uch accelerating. As these dem ands are

grow ing stronger, the com plexity o f processes
that softw are m anages is increasing along with
the dem and for the integration o f processes
from different areas. As a consequence,
softw are program s are becom ing increasingly
large and com plex. The appearance o f
com ponent based softw are engineering (CBSE)
adapts this challenge o f the software
developm ent; it proposes an easy and efficient
m ethod for developing large software.

In this approach, the architecture o f a
system is described as a collection o f

Corresponding author. E-mail:

com ponents (reusable parts) along w ith the
interactions am ong those via their ports. The
main feature o f CBSE is to allow the
construction o f an application using
independently developed softw are com ponents,
leading to reduce developm ent costs and
im proved softw are quality. In this process, it is
essential to ensure that individual com ponents
can in fact interoperate together in the system.
H ow ever the com ponents do not interact
seam lessly. Problem s could arise in the system
if there are m ism atches and inadequacies o f
connected points betw een com ponents. It is
im portant to verify the coưecùiess o f

com ponent com position. In order to do it, there
are m any approaches appeared to verify the
com patibility betw een com ponents by
interfaces [1,2], behaviour specification [3],
m odels [4’ ...

As we know, how ever, CBSE is also an
approach to develop softw are systems, hence

</div>
(2)<div class='page_container' data-page=2>

T.T.M. Tỉm ong et a i / V N U Journal o f Science, N atural Sciences and Technology 24 (2008) 92-102 93

discovering bugs in the earlier phases will
reduce much time and effort in building
softw are systems, especially large systems. So,
in this paper, we propose an approach to verify
the conform ability betw een com ponents
through specifications o f their ports. This is a
buffer step before verifying behaviour
specifications o f com ponents, because it will
remove many unneccesary cases w hich are
inputs for checking behaviours.

Here, we use the C O RB A Com ponent
M odel (CCM) ports. Firstly, CCM specification
o f com ponents is described by XM L. W e then
determine the conditions such that ports can be
connectable. From the X M L desciption and
these constraints, we finally build a B abstract
m achine which can be used to check the
consistency o f connected ports in the model.

The B m ethod [5] is used to verify the
compatibility betw een ports. B ecause, the B
notations rUvQ based on set theory, generalised 
substitutions and first order logic, these are
easily to describe ports and their relation. In
addition, the p ro o f obligations for B
specifications are generated autom atically by
support tools like AtelierB [6], B -Toolkit [7'
and B4free [8]. C hecking p ro o f obligations with
B support tools is autom atically perfom ed.

In the following, we present an overview o f
com ponents specifying approaches. W e then
describe our m ethod in Section 3 and illusừate
it with the case study o f the Stock Q uoter
System. In Section 4, we discuss related work.
The paper finishes w ith som e concluding
rem arks in Section 5.

2. Specification o f so ftw a re c o m p o n en ts

Specification o f softw are com ponents is one
o f the most im portant research challenges in
com ponent-based softw are engineering. It
represents the first step tow ards true com ponent

reuse as the com ponent specification gives all
neccssary inform ation to the com ponent user on
how /w hy the com ponent can be (re) used.

A com ponent is considered to be a black
box. Hence, interfaces are the only access
points to the com ponent and the specification o f
the com ponent com es dow n to the specification
o f the com ponent interfaces.

Specification o f the com ponent interfaces in
the current com ponent-based systems is done
by two levels:

• On the first level, syntactical level, there
are some specification models such as
JavaB eans [9], C O M + [10], CCM [11],
.NET [12], and the O pen Service G atew ay
Initiative (O SG I) [13]. A t this level, The
com ponent specification consists o f
specification o f provided and required
interfaces. Provided interfaces are the one
that contain operations that a com ponent
provides to other com ponents or to the

c o m p o n e n t u s e r, w h ile re q u ire d in te rfa c e s

are the one that contain operations used by
the com ponent.

• On the second level, sem antic

s p e c ific a tio n , th e re a re tw o re p re s e n ta tiv e s:

U nified M odeling Language (U M L) and
the O bject C onsừ aint Language (O CL), in
which a com ponent im plem ents a set o f
interfaces. Each interface consists o f a set
o f operations w ith associated pre and
postconditions, as well as com ponent state
and invariants. Preconditions are assertions
that the com ponent assum es to be fulfilled
before an operation is invoked, w hile
postconditions are assertions that the
com ponent guarantees w ill hold ju st after
the operation has been invoked. An
invariant is a predicate over the interface’s
state that will alw ays hold.

</div>
(3)<div class='page_container' data-page=3>

94 T.T.M. T h u o n g et a l / V N U Journal o f Science, N atural Sciences and Technology 24 (2008) 92-102

is the m ost recen t and com plete com ponent
specification from O M G [14]. It has been
designed on the basis o f the accum ulated
experience using C O R B A service, JavaBeans,
and EJB. The m ajo r goal behind the CCM
specification is to provide solution to the
com plexity reach ed by C O RB A and its
services. O ne o f the advantages o f CCM is its
effort to integrate m any o f the facets involved
in softw are engineering. A s a consequence, a
softw are application is described in different
form alism s along tw o dim ensions: the time

dim ension (the life cycle, from design to
deploym ent) and the abstract dim ension (from
absừ actions to im plem entation). Altogether,
this m akes a rath er com plex specification.

C CM sim ply defines the concept o f
connection as an object reference; thus CCM ,

like all other industrial com ponent m odels, does
not provide a connector concept. N evertheless,
com ponents are connected by linking facets to
receptacles and event sources to event sinks.
Connections are binaries and oriented, but the
same port can handle m ultiple connections.
Connections can be explicitly described (in the
assem bly descriptor, an X M L file) and
established by the CCM fram ew ork at
initialization.

C om ponents support a variety o f surface
features through w hich clients and other
elem ents o f an application environm ent may
interact w ith a com ponent. These surface
features are called ports. The com ponent model
supports four basic kinds o f ports [15] (see
Figure 1):

A ttribute
Event source
Event sink

Receptacle
Facet
CO RB A com ponent interface P ort

Fig. 1. CO RB A com ponent interface and its ports.

Facets, w hich are distinct nam ed interfaces
provided by the com ponent for client
interaction.

R eceptacles, w hich are nam ed connection
points that describe the com ponent’s ability
to use a reference supplied by some external
agent.

E vent sources, w hich are nam ed connection
points that em it events o f a specified type to
one or m ore interested event consum ers, or
to an event channel.

Event sinks, w hich are nam ed connection
points into w hich events o f a specified type
m ay be pushed.

Basic com ponents are not allow ed to offer
facets, receptacles, event sources and sinks.
They m ay only offer attributes. Extended
com ponents may offer any type o f port.

3. C ase stu d y : S to ck Q u o te r S y stem

T o dem onstrate our approach, we use a case
study o f the Stock Q uoter S y stem ’ with two
com ponents connected by their ports. However,
our approach will w ork w ith m ore complex
system s in w hich there are m any connected
com ponents. A ccording to this approach, we

</div>
(4)<div class='page_container' data-page=4>

T .T .M . Thiion<ị et a l / V N U Journol o f Science, N atural Sciences and Technology 24 (2008) 92-102 95

firstly transfonn CCM specification o f
com ponents into X M L format. W e then express
XML description and constraints which we
defined above as inputs o f B abstract machine.
Finally, we use an autom atic p ro o f tool to check
the consistency o f connected ports in the model
with B absừact machine.

Figure 2 illustrates the com ponents in stock
quoter system exam ple using the CORBA

C om ponent M odel (CCM ). The

StockD istributor com ponent m onitors a real

time stock database. W hen the values o f
particular stocks change, it pushes a CCM
eventtype that contains the sto ck ’s name via a
CCM event source to the corresponding CCM
event sink im plem ented by one or m ore

StockBroker com ponents. If these com ponents
are interested in the stock they can obtain more
inform ation about it by invoking a
request/response operation via their CCM
receptacle on a CCM facet exported by the
StockD istributor com ponent.

notifier_in
n o tifie ro u t

^ỉ>---...^

Q quoter_info_out

quoter_info^in

2

- Stock

Broker

Fig. 2. CO RBA com ponent interface and its ports.

component StockBroker {

consumes StockName notifier_in;
uses StockQuoter quoter_info_in;
) ;

StockB roker contains two ports that
coư espond to the follow ing two roles it plays.

It’s a subscriber that consum es a
StockN am e eventtype called n o tifie r jn th at’s 
published by the StockD istributor when the
value o f a stock changes. As shown in Figure 2,
the n o tifie r jn event sink w ill be connected to 
the S tockD istributor’s notifierjD ut event source 
by the standard CCM deploym ent and
configuration tools when the application is
launched.

It uses the StockQ uoter interface provided
by the StockD isừibutor com ponent, which
reports additional inform ation about a stock,
such as the high, low, and m ost recent ừading
values o f the stock during the day. The

dependency o f StockB roker on StockQ uoter is
indicated explicitly in ID L 3.x via the

q u o t e r j n f o j n receptacle, w hich will be

connected to S tockD istributor’s

quoter infojD ut iacade by the deploym ent and 
configuration tools w hen th e ” application is
launched.

We now present the im plem entation o f the
StockD isừibutor com ponent, w hose ports are

shown here:

component StockDistributor
supports Trigger (

publishes StockName notifier_out;

provides StockQuoter

quoter_info_out;

attribute long notification_rate;
} ;

</div>
(5)<div class='page_container' data-page=5>

96 T.T.M. Thiiong ct al. / V N U Journal o f Science, Natural Sciences and Technology 24 (2008) 92-102

changes. In addition, it defines a StockQuoter
facet called q u o te rjn fo _ o u t, w hich defines a 
factory operation that returns object references
that StockBroker com ponents can use to obtain
more information about a particular stock.
Finally, this com ponent defines the

notification_raie attribute, w hich system

adm inistrator applications can use to control the
rate at which the StockD istributor com ponent
checks the stock quote database and pushes
changes to StockBroker subscribers.

We now consider the verification o f
conform ability betw een com ponents when we
have information describing the connection
between ports o f com ponents from their CCM
specification in this system.

Recall that inform ation in com ponent
specification can be described by XM L. XM L
(Extensible M arkup Language) [16] is a simple,
very flexible text format derived from SGML.
Originally designed to meet the challenges o f
large scale electronic publishing, X M L is also
playing an increasingly im portant role in the
exchange o f a wide variety o f data on the W eb
and elsewhere.

XM L can also use to define m etam odel or
metadata o f a system specification. W ith a
X M L docum ent described valid CO RBA
system, it can provide an easy way to extract
infom iation about com ponents and its ports for
the verification purpose.

The ADL specification o f the Stock Q uoter
System presented in Figure 2 can be described
by XM L as the following.

Note that, in a CCM specification, if a
receptacle’s uses declaration does not include
the optional multiple keyw ord, then only a

single connection to the receptacle may exist at
a given time. If a receptacle’s uses declaration
includes the optional m ultiple keyword, then
multiple connections to the receptacle may exist
simultaneously.

There are two categories o f event sources,
em itters and publishers. Both are implementec
using event channels supplied by the container.
An em itter can be connected to at most one
proxy provider by the container. A publishei
can be connected through the channel to an
arbitrary num ber o f consum ers, who are said to
subscribe to the publisher event source. A
com ponent m ay exhibit zero or more emitters
and publishers.

A publisher event source has the following
characteristics [ 11]:

• T h e e q u iv a le n t o p e ra tio n s fo r p u b lis h e rs

allow m ultiple subscribers (i.e., consum ers)

to connect to the same source

sim ultaneously.

• Subscriptions to a publisher are d e le g a te d

to an event channel supplied by the
container at run time. The com ponent is
guaranteed to be the only source publishing
to that event channel.

An em itter event source has the following
characteristics [ 11]:

• The equivalent operations for emitters allow
only one consum er to be connected to the
em itter at a time.

• The events pushed from an emitter are
delegated to an event channel supplied by the
container at run time. O ther event sources,
however, may use the same channel.

As a consequence, CCM components can
be connected if their ports satisfy conditions:

P D l. Facet can connect only to receptacles
(provides port connect only to uses port)
PD2. Event source can connect only to event

sinks (W e can say that publishes and emits
ports can connect only to consumes ports)
PD3. Each provides port (facet) can connect to

</div>
(6)<div class='page_container' data-page=6>

Ĩ .T .M . Thuong et aỉ. í V N lỉ Ịournnỉ o f Science, N atural Sciences and Technoỉo<^y 24 (200S) 92-702 97

^D4. Each em its port connect only to one
consum es port.

^D5. With tw o connectcd ports, type o f
provided ports (facets, event sources) is a
subtype o f the one o f required ports
(receptacles, event sinks).

I / . C h ecking types o f p o r t in connections

Each com ponent IS described m a
component based model with two phases. The
first one is the type, represents the functional
interface o f the com ponent, w hat is visible by
other com ponents. The second one is the
im plem entation, describes the contents o f the
component.

The aim o f separation o f a component
description into a type and an im plem entation is
the point o f view o f the com ponent. Describing
the type m eans specifying the com ponent
interface, expressing how it is seen from an
external point o f view. On the other hand, the
im plem entation represents the interior. In
practice, Ihc description o f the type and the
im plem entation m ay be done by different
persons, each o f them dealing with one step in
the refinem ent o f the architecture description,
from the top level to the detail level.

An inheritance m echanism exists to
describe the com ponents. It may be used for
both the types and the implem entations. This
m echanism is useful to refine a description by
o v e rw ritin g an already existing component.

Restrictions exist, w hich m ust be respected.
Thus, a com ponent type may inherit from
another com ponent type o f the same category.
In the same way, a com ponent implementation

may inherit from another component

im plem entation o f the sam e category.

The final condition o f the compatibility
betw een ports (PD5) states that, type o f
provided ports is a subtype o f the one o f
required ports. A verification shound be
considered to ensure the conform ity between
the types and directions o f the connected ports.

In order to verify conditions for connecting
ports in a CCM specification, we propose to use
the B method [5].

From the inheritance relationship between
types o f ports, we create a simple B abstract
m achine called Types m achine (Figure 3). In

this machine, if an interface T Y P E l inherits
from an interface TY PE2, we define TY PEl is
subtype o f the TY PE2 (T Y PE l c TYPE2).

MACHINE Types

CONSTANTS

TYPEỈ, TYPE2, TYPES...

PROPERTIES

TYPEỈ ^ TYPE2; TYPE3 a TYPE2. 
END

</div>
(7)<div class='page_container' data-page=7>

98 T.T.M. Thuong et a i Ị V N U Ịournaỉ o f Science, N atural Sciences and Technology 24 (2008) 92-102

From the Types m achine, if we w ant to
check the consistency o f the type betw een two
ports in a connection, we have to get the type o f
required port (T Y P E l) and the type o f provided
port (TYPE2). Each time we get a connection,
we have to give a fragm ent specification as the
following into the B specification, according to
the definition o f subtype:

A N Y conn WHERE 
conn e TYPE2

THEN

conn : e TY P E l

END

The B prover will check if TY PE2 is a
subtype o f TY PE 1 from this specification.

3.2. Checking kinds o f p o rt in connections

The B machine that we build to verify the
coưectness o f the ADL A cm e specification [17^
is called the C onnectionCheck. From the X M L
description, we can get all ports and the kind o f
port (uses port, provides port, consum es
ports...) in the specification. They are presented
in the SETS clause o f the machine.

We declare the variables connectionU _P to 
contain and check the connection betw een uses

ports and provides ports, connectionC _P tc 
contain the connection betw een consum es ports
and publishes ports, connectionC _E to contair 
the connection betw een consum es ports and
emits ports. These variables have to satisfy four
conditions (P D l, PD2, PD3, PD4) described in
the above. These constraints can be formally
described in the E W A R IA N T S clause as the
following:

con nectionu^peU SE SP O R T 7 -^ PRO VIDESPORT^ 
connectionC_EeCONSUMESPORT-^EMỈTSPORT^ 
comectionC_PeC0NSUMESP0RT7^PUBUSHESP0RT

In these constraints, type o f these three
variable define the type o f a possible
connections in the specification.

W e use the partial function (-H>) to denote
the relation betw een the dom ain and the range
o f the connection betw een uses port and
provides ports; consum es port and publishes
port. It m eans that, one elem ent o f the domain
cannot connect to have more than one element
o f the range and one elem ent o f the range can
connect to m any elem ents o f the domain
(Figure 4). W e use the partial bijection (>-^) to
denote the relation betw een consum es port and
emits port. It m eans that each elem ent o f the
domain can connect only to one elem ent o f the
range.

</div>
(8)<div class='page_container' data-page=8>

r.T.M. T huong et a l / V N U journal o f Science, N atural Sciences and Technologỵ 24 (2008) 92-102 99

In the O PERA TIO N S clause o f the

m achine, wc define operations for extracting all
connections in the CCM specification. In these
operations, we intergrate the fragment
specification o f checking types betw een ports o f
the connection. T he m achine presented in
Figure 5 illustrates the B notations o f the
verification puqDose for the case study o f the
Stock Q uoter System in Figure 2. It is to be
noted that, all infonnation in this abstract
m achine can be extracted from the X M L
description hence it can be built automatically.

4. R elate d w o rk

Several proposals for verifying the
interoperability betw een com ponents have been
made.

The paper [4] present a tool called Cadena,
an integrated environm ent for building and
m odeling CCM system s. Cadena provides
facilities for defining com ponent types using

CCM IDL, specifying dependency information
and transition system sem antics for these types,
assem bling system s from CCM components,
visualizing various dependence relationships
betw een com ponents, specifying and verifying
coưectness properties o f models o f CCM
system s derived from CCM IDL, component

assem bly inform ation, and Cadena

specifications, and producing CORBA stubs
and skeletons im plem ented in Java.

As a point o f com parison, this paper
generated a D Spin m odel for the scenario that
check the num ber o f tim eouts issued in a
system execution.

Zarem ski and W ing [18] propose an
approach to com pare two softw are components.
They determ ine w hether one required
com ponent can be substituted by another one.
They use formal specifications to model the
behavior o f com ponents and exploit the Larch
prover to verify the specification m atching o f
com ponents

M A C H IN E ConnectionCheck
SEES Types

SETS

U S E S P O R T = {quoter_ in fo jn };

PROVIDESPORT = {quoter_info_out};
CONSUMESPORT = jnotifierjn};

PUBLISHESPORTS - {notirier_out}; EMITSPORTS;

VA RIA B LES

connectionU P, connectionC P, connectionC_E
INV A RIA N TS

ConnectionU _P

e

Ư SESPORT -^P R O V ID E SP O R T A

ConnectionC P G

CONSƯMESPORT -^PUBLISHESPORT A

ConnectionC_E e

CONSƯMESPORT EM ITSPO RT

INITIA LISA TIO N
C onnectionU P := 0 II

connectionC_P 0 II connectionC_E 0

OPERA TIO N S
G e tC o n n e c tio n U _ P =

PRE

</div>
(9)<div class='page_container' data-page=9>

100 T.T.M. T huong et al. / VhJU Journal o f Science, N atural Sciences and Technology 24 (2008) 92-102

TH EN

ConnectionU _P

connectionU _P u {n o tifier_ in ~*notifier_out} II
A N Y conn W H ER E /* Check type o f ports */ 
conn STO CK N A M E /* type o f p ro v id e s port */
TH EN

conn ; e STOCKNAME /* type of uses port */

END
END;

getConnectionCP =

PRE

connectionC_P G

CO N SƯ M ESPO RT ->PU B L ISH ESPO R T
TH EN

connectionC _P := connectionC P u

{quoter_info_in —>quoter_info_out} II

A N Y conn W H ER E /♦ Check type o f ports V

conn e STOCKQƯOTER /* type of publishes port */

TH EN

conn : 6 STOCKQUOTER /* type of consumes port */

END
END;

g e tC o n n e c tio n C E =
PRE

connectionC _E e C O N SU M ESPO RT -> EM ITSPO RT
TH EN

connectionC _E := connectionC_E u 0 . . .
END

END

Fig. 5. B abstract m achine for verifying com patibility betw een com ponent ports.

In [1,2], protocols are specified using a
tem poral logic based approach, w hich leads to a
rich specification for com ponent interfaces.
H enzinger and Alfaro [19] propose an approach
allow ing the verification o f interfaces
interoperability based on autom ata and game
theories: this approach is well suited for
checking the interface com patibility at the

protocol level.

The paper [3] proposes the Port State
M achine (PoSM ) to model the com m unication
on a Port. B uilding on their experience with
behavior protocols, they m odel an operation
call as two atom ic events request and response,
perm itting PoSM to capture the interleaving

and nesting o f operation calls on provided and
required interfaces o f the Port. The trace
sem antics o f PoSM yields a regular language.
They apply the com pliance relation o f behavior
protocols to PoSM s, allow ing to reason on
behavior com pliance o f com ponents in software
architectures.

</div>
(10)<div class='page_container' data-page=10>

T .T M . Thuon^ii ct nL / V N U journal o f Science, Natnrnl Sciences and Technoỉo^ỵ 24 (2008) 92-102 101

5. C onclusion R eferen ces

We have presented some aspects o f
com ponent specifications, outlined our
approach o f com ponents verification based on
kinds o f connectable ports, through proving the
correctness o f iheir CCM specification using B
method. C oncurrently, we also described more
detail the transform ation from p o rts’ informal
connection constraints to formal formats to be
able to input into B m achine for verifying. W e

have presented a small but illustrative case
study, show ing in particular kinds o f ports
w hich can be connectable as well as the activity
m achenism o f B m achine in proving the
soundness o f C CM specification.

In previous work, we defined constraints on
ports, and thanks to these we can know which
com ponents can connect together properly if
their ports satisfy requirem ents w hich we given.
At this degree, we have ju st only known kinds
o f port (facet, receptacle, event source, event
sink) and only verified constraints on these
kinds o f port. In this paper, we conừibuted to
verifying connection conditions on types o f port
and integrating it into kinds o f port to assist our
approach. This will support us much on
verifying the com patability betw een
coinponenls by behaviour specification at
sem antic level.

In the future work, we will c a n y out to
check the com position betw een behaviors o f
ports w hen connection betw een types o f port is
coưect. Since then, we will build a fram ew ork
supporting the process o f installing, verifying
and developing com ponent-based systems. This
leaves the opportunity for the designer to use
the tool best suited to the problem , and to
perform formal analysis on parts o f the system

that particularly deserve it.

A ck n o w leg m en ts. This w ork is partly
supported by the research project No. QC.07.04
granted by V ietnam N ational U niversity, Hanoi.

[1] J. Han, “ A com prehensive interface definition
fram ework for software com ponents”, In A sia Pacific
software engineering confcrcnce, ỈE E E C om puter 
Society (1998) 110.

[2] J. Han, Tem poral logic based specification o f
com ponent interaction protocols, In P roceedings o f 
the Second Workshop on Object Interoperability 
ECO O P-2000, Springer-V crlag, (2000) 12.

[3] V. Mcncl, “ Specifying com ponent behavior with port
state m achines” , Electronic N otes in Theoretical
Com puter Science, Special issue: Proceedings o f the 
Workshop on the C om positional Verification o f UML 
A/oi/e/5, i01C :129, 2004.

[4] J. H. ct al. ‘‘Cadcna: an integrated developm ent,
analysis, and verification environm ent for
com poncnt-bascd system s”, In Proceedings o f 25th 
International Conference on Software Engineering, 
(2003) 160.

[5] J.R. Abrial, The B-Book, A ssigning P rogram s to 
M eanings, Cam bridge U niversity Press, 1996.

[6] Stcria, O bligations de preuve: M anuel dc r e f ercnce'.
Steria - Technologies de I’inform ation, version 3.0,
A vailable at http://w w w .atelicrb.societe.com .

[7] B.C. Ltd. B-Toolkit U ser’s M anual, O xford (UK),
1996, Release 3.2.

[8] Cicarsy, B4frcc. A vailable at http://w w w .b4free.com ,
2004.

[9] Sun M icrosystem s, JavaB cans 1.01 Specification,
/beans.

[10] G. Eddon, H. Eddon, Inside COM + Base Services.
M icrosoft Press, 2000.

[11]C0RBA Component Model Specification, Version
4.0, http://w w w .om g.org/cgi-bin/doc7ptc/2006-05-01.
[12] M icrosoft, .NET, http;//w w w .m icrosoft.com /nct/.
[13] OSGI, OSGI Service G atew ay Specification, Release

1.0, http://w w w .osgi.org.
[14] http;//w w w .om g.org.

[15] I. C m kovic, M. Larsson. “ B uilding reliable
com poncntbased Software System s”, A rtech House,
Inc, 2002.

[16] W orld W ide W eb Consortium , XM L,

http://w w w .w 3c.org/X M L /.

[17] Nguyen Hoang Ha, Tran Thi Mai Thuong, Truong
Ninh Thuan, Nguyen V iet Ha, “ V erifying the
com patibility o f com ponents’ ports upon
specification” , In Japan Vietnam W orkshop on 
Softw are E ngineering 2007, Septem ber 2007.

[Ỉ8] A. M. Zarem ski, J. M. W ing, “Specification m atching
o f software com ponents” 6(4) (1997) 333.

</div>
(11)<div class='page_container' data-page=11>

ANNEX - XML specification for CMM stock Quoter System.

< c o n n e c t i o n s >

< ? x m l ver si o n = " 1 . 0" e n c o d i n g s " U T F - 8" ? >

< c o n n e c t i n t e r f a c e >

q u o t e r _ i n f o _ i n < t y p e > S t o c k Q u o t e r < / t y p e >

< c o m p o n e n t i n s t a n t i a t i o n r e f i d r e f = " S t o c k B r o k e r " />

q u o t e r _ i n f o _ o u t < t y p e > S t o c k Q u o t e r < / t y p e >

< c o m p o n e n t i n s t a n t i a t i o n r e f idref=*' S t o c k D i s t r i b u t o r ” />

< / c o n n e c t i n t e r f a c e >

< c o n s u m e s p o r t > < c o n s u m e s i d e n t i f i e r > n o t i f i e r _ i n < / c o n s u m e s i d e n t i f i e r >