A Semantic Interoperability Extension Model to the ebXML Registry

Wudong Liu Lulu He Jing Liu Keqing He

State Key Lab of Software Engineering, Wuhan University
{wudong, helulu, jingliu}@sklse.org, hekeqing@public.wh.hb.cn

Abstract
The ebXML registry & repository standard is one of
the most well accepted standards in the field of
registry. Several products claiming to be ebXML
compatible [1, 2, 3, 4] have been developed. While the
ebXML standard is initially designed for registering
and storing e-business related artifacts for the
automation of the e-business, it doesnt prevent us
from using it as a versatile registry and repository for
any kind of industrial artifacts. However, some
problems arise in this case. This paper describes a
semantic model for the ebXML registry and also
illustrates how to utilize it to extend semantic
interoperability. The model doesnt violate the existing
ebRS [5] or ebRIM [6] standard. On the contrary, its
based on and complementary to them, which is
essentially important when we register artifacts in a
versatile and federated environment.

1. Introduction
E-business has given companies the prospect of
reducing costs and improving efficiency by
exchanging business information in electronic form.
Electronic Data Interchange (EDI) has gained much
attention in the last two decades. But as the XML
becomes the standard for data interchange formats
over the Internet in the latest years, an XML based ebusiness standard, ebXML is prevailing in this field. It
builds on the experience and strengths of existing EDI
knowledge and also recognizes the XML effort [7].
The vision of ebXML is to create a global
electronic marketplace where enterprises of all sizes
and in any geographical location can meet and conduct
businesses with each other [8]. The ebXML registry
plays an essential role in achieving that vision. It
provides a set of services that enable informationsharing between interested parties for the purpose of
enabling business process integration between parties
based on the ebXML specifications. The ebXML

registry acts as a common repository mechanism which

holds different types of artifacts. Additional
information sharing mechanisms such as slot,
classification, and relation etc. are provided to make
the sharing and exchanging easy.
As the using of center registries arises, the industry
has paid more and more attention to it. Some new
requirements such as federation, interoperability, and
semantic identification are rising above the horizon.
Federation recently is included as a new part of
standard in the ebXML RS/RIM 2.5 [5, 6], which
provides limited federation functionality. As for the
interoperability, service interface is well defined in the
ebRS, making the service interoperability possible. But
when it comes to the semantic interoperability, the
existing standard rarely addresses it. The semantic
interoperability also mandates the need of the semantic
identification for a registry object, which is also a
weak point of the existing standard.
This paper mainly targets at the new requirements
for the registry mentioned above. We hope to solve the
problems without violating the existing standard. We
describe a semantic model for the registry based on the
MOF and ebXML RIM. And we also illustrate the use
of this semantic model in the context of federated,
interoperable environment.
This paper is organized as following. Section 1,
namely this section, gives an introduction of this paper.
Section 2 talks more about the background information
and based on that, identify the problems we faced.
Section 3 describes the semantic model for the ebXML
registry, which is the main focus of the paper, and
Section 4 illustrates a case study to prove the
practicability of the model. In the last Section, we
specify our contribution and conclude with an outlook
on the future work.

2. Background and problems

In a real-world business environment a single
physical registry that is centrally controlled by a
standard organization seems impractical. Instead, a

Proceedings of the International Conference on Information Technology: Coding and Computing (ITCC05)
0-7695-2315-3/05 $ 20.00 IEEE

powerful system of distributed ebXML registries is

desirable, allowing the registries to interact with and
cross-reference each other. This is what the registry
federation [9] wants to solve. Putting it more formally,
the federation targets at:
Enabling information-sharing between interested
parties from different domains for the purpose of
enabling business process integration, the public
available registries provide a seamless service
federated with different registries in different domains.
As we stated before, the specification of an
ebXML-compliant registry is quite generic and flexible.
This is due to the fact that an entry is nothing but an
object in the perspective of a registry. The rather
generic information model makes it easy to store
information into the repository, but difficult to retrieve
exactly the information needed [7]. The generality in
the nature of ebXML standard make it possible to
accommodate different types of artifacts for different
domains.
A federated registry environment can connect the
different domains for worldwide collaboration, which
will greatly enhance the automation of e-business.
From our point of view, for federation, two kinds of
challenges exist:
1. How to define the service interface of a registry
federation for the client and for the individual
registry in the federation?
2. How to define the semantics for different artifacts
from different domains
The newly approved ebXML Registry Service and
Registry Information Model provide limited support
for the federation capability. It standardizes the service
interface for federation. However, it doesnt provide
enough mechanism to solve the second challenge. And
its what this paper wants to make contribution to. We
call this problem as the problem of semantic
interoperability in a federated registry environment.
But first, we will define what semantics is in the
context of registry. Semantics is a much generic term
used to tell what the exact meaning is behind a thing
[10]. In a registry, we think, to inquire what the
semantics is equals asking what the registry object
really is. As we know, an ebXML registry can really
accommodate lots of types of artifacts: program file,
xml file, standard document, or anything a repository
can hold. Under the condition that only the most
general attributes exists in the registry many problems
come up. How to tell one object from the other? How
to make the exact use of the objects? What the
specifications have provided is a common
infrastructure for registry facility on which things are
registered by metadata and stored in repository. From
this point of view, different industries can make

different use of these specifications for different

reasons. This is an extremely beneficial aspect of
ebXML registry in terms of flexibility. However, this
flexibility debilitates the interoperability of different
registries across various industries, because no more
information is provided except the basic attributes
inherited from ebRIM. In this case, the problem of
semantics missing will hinder the automatic
interoperability between different domains.
When an arbitrary artifact is registered in the
registry, only the most generally attributes defined by
the ebRIM can be preserved and it becomes a registry
object; its own meaning or semantics is missing in this
process. We call this the semantics missing of registry
objects. Faced with this problem, we define the
semantics of a registry object as following; its
constituted of the three aspects:
1. Intentional Semantics: What the registry object is
really about.
2. Internal Semantics: The structure of a set of
related registry objects.
3. Extensional Semantics: How to resolve this
semantics, and retrieve the registry object
according to the semantics.
And we want to provide a solution to restore the
missing semantics of the original artifact. For effective
large scale federation, the semantics of a registry
object is essential.

3. The semantic interoperability model

3.1. What the existing standard does
In the ebRIM, a classification model is provided to
classify the object into different concept categories.
Actually, the classification model is not only used as a
mechanism to classify, the ebXML standard also
makes use of it to identify the type of a registry object,
that is, to identify the semantics of a registry object
through its type.
In ebXML standard, schemes such as ObjectType,
AssociationType, is used as the semantics identification
for a registry object. The value of objectType attribute
in RegistryObject must be a reference to a
ClassificationNode in the canonical ObjectType
ClassificationScheme defined by the ebXML standard
[6]. This Scheme can be expanded to designate the
new type of object. The problem of this method is that
it can only specify the type for one object, but not for a
set of related objects.
Because of the nature of the ebRIM, only limited
types of registry objects can be registered. But in
different domains, domain object different from

Proceedings of the International Conference on Information Technology: Coding and Computing (ITCC05)
0-7695-2315-3/05 $ 20.00 IEEE

We make use of the classification model to term the

different object types. A standard and extensible
ClassificationSchema has been provided to define this
term hierarchy. When an object is registered with an
objectType attribute linked to a ClassificationNode in
this ClassificationSchema, we can tell what the object
really is.
But for Complex object, however, things become
complicated because we need to define not only the
term of semantics, but also its structure implied by the
semantics. How to define the structure, or the model of
complex object, is the problem. So, In addition to the
classification model, we need a mechanism to link the
ClassificationNode to a model, which defines the
structure of the semantics, where the node represents a
registry complex object.

Semantic Extension

3.2. The whole architecture of our solution

Complex Object

ebRIM objects must also be registered. Even in the ebusiness itself, lots of new types that are beyond the
ebRIM are emerging, such as Business Process Model
[11], BIE Library [13], Core Component Library [14,
15], etc. Some of them can be mapped to the ebRIM,
but some of them can not easily be mapped. However,
the ebRIM provides a generic enough mechanism to
achieve this goal. When the registry is in a federated
context, its very likely that the objects in it are not
isolated. That means several objects are related or
organized together to form a semantic whole. In this
case, the existing method cant resolve the semantic
problem.
Thus, we propose two kinds of registry objects for
the ebXML registry in the consideration of semantics:
z Simple Object: A standalone object that can
completely represent itself. No other objects are
needed to fulfill its semantic meaning. Most of the
objects defined by the ebXML standard are
simple objects
z Complex Object: Several objects together
constitute a semantic complex object. The
individual object in a complex object has no
concrete meanings unless its treated as a part of
the whole.
As explained above, the semantics of Simple Object
can be easily settled by the existing standard. But for
Complex Object, the standard do nothing more. And to
make things worse, the semantics of Complex Object
implies a structure, which is also an unsettled problem
when we want to resolve the semantics and retrieve the
registry object according to this semantics.

Figure 1. The Semantic Extension Model

In the picture above, the ExtrinsicObject noted with
the EntryClass play two roles: first, it acts as a
container for the all related objects in a complex object;
second, it acts as an identification for the complex
object. The ExtrinsicObject is classified as a normal
registry object by one ClassificationNodes in the
canonical ObjectType ClassificationScheme. The
ClassificationNode represent a (new) kind of
RegistryObject, or the objectType value. And the
ExtrinsicObject noted with model definition has
content to describe the model structure formally.
There are several ways to define the model.
Standards like MOF/XMI [16], RDF [17],
XMLSchema [18] or MMF [19] can all meet our
requirements. In this paper, we choose the relatively
more mature standard MOF/XMI as our modeling
mechanism. MMF, as a more suitable solution for the
model registry and repository, may also play an
important role in this scenario when it has been
approved by ISO.

3.3. The MOF-based semantic interoperability

model
MOF defines a four layered architecture to formally
define a model. Here we will not elaborate on the
architecture. Instead, we will show how the four layers
can fit in our solution.
The ebRIM is an informally metamodel of ebXML
registry. In short, ebRIM defines which kind of object
can be registered into a registry. Its kind of easy in the
case of Simple Object. Every simple object is a kind of
the objects that has already been defined in ebRIM.
But for Complex Object, things are more complicated.
The complex object groups different objects defined in
the ebRIM to formulate a new type of object. Here, the
ebRIM acts as a meta-layer for the modeling of
complex object. While ebRIM provides enough
mechanism to be a meta-layer as modeling construct,
the standard doesnt make more effort to make it
explicit. And to make things worse, the ebRIM itself
mingles different meta-layers when it is defined [6].
Thus we extract the ebRIM to a more compact and
consistent one, which we called the Core Part of

Proceedings of the International Conference on Information Technology: Coding and Computing (ITCC05)
0-7695-2315-3/05 $ 20.00 IEEE

ebRIM, to be used as a modeling facility for complex

object. On the other side, because ebRIM are defined
by UML, some facilities it used are not aligned with
the MOF; we modify it to be MOF compatible.
However, we didnt change any meaning of the
original ebRIM elements, thus ensure its compatibility
with ebRIM. The core part is as following:

(/(0(175,00HWD5HJLVWU\2EMHFWFODVVLILFDWLRQ
5,00HWD&ODVVLILFDWLRQ !
(17,7<5,00HWD5HJLVWU\2EMHFW)HDWXUHV
;0,H[WHQVLRQ
_5,00HWD5HJLVWU\2EMHFWWR_5,00HWD5HJLVWU\2EMHFWIURP
_5,00HWD5HJLVWU\2EMHFWVORW_
5,00HWD5HJLVWU\2EMHFWFODVVLILFDWLRQ
!
(17,7<5,00HWD5HJLVWU\2EMHFW$WWV
;0,HOHPHQWDWW
;0,OLQNDWWWR,'5()6,03/,('IURP,'5()6,03/,('
VORW,'5()6,03/,('FODVVLILFDWLRQ,'5()6,03/,('
!
(/(0(175,00HWD5HJLVWU\2EMHFW
5,00HWD5HJLVWU\2EMHFW)HDWXUHV !
$77/,675,00HWD5HJLVWU\2EMHFW
5,00HWD5HJLVWU\2EMHFW$WWV!


5,00HWD([WULQF2EMHFW

!

(/(0(175,00HWD([WULQF2EMHFWREMHFWW\SH

Figure 2. The Core Model of ebRIM

We say the Core Model of ebRIM is defined by the
MOF, means that:
1. Its MOF compatible and fits in the M2 layer in
the MOFs four layer architecture.
2. As a M2 layer, or Meta language of MOF, it can
be used to define a M1 model, which in our
concept, is the model of the Complex Object.
3. The model for Complex Object is ebRIM
compatible, thus ensure the structure can be
registered in the ebXML registry.
4. As a MOF compatible meta-language, the model
defined by it can be serialized to a XMI
document, which is a plain XML file and can be
saved in the registry as an ExtrinsicObject.
5. A MOF aware client can understand the XMI file
and thus understand the structure of the complex
object, and retrieve it as required.
The core model is specifically targeted to model the
complex object. Note that the name of the class
defined above is different from those in ebRIM only
for purpose of description convenience. The meaning
and structure of these classes are the same as their
counterparts in ebRIM. The instance model of it also is
a valid ebRIM instance model, while bearing
additional structure information of Complex Objects.
According to MOF/XMI specification, the
metamodel we defined can have a DTD/XMLScheme
definition to make its instance model XMI-able. The
DTD fragment of it is given below:
.


5,00HWD5HJLVWU\2EMHFW

!

(/(0(175,00HWD5HJLVWU\2EMHFWWR5,00HWD$VVRFLDWLRQ 
!
(/(0(175,00HWD5HJLVWU\2EMHFWIURP
5,00HWD$VVRFLDWLRQ !
(/(0(175,00HWD5HJLVWU\2EMHFWVORW5,00HWD6ORW !

5,00HWD&ODVVLILFDWLRQ !
(17,7<5,00HWD([WULQF2EMHFW)HDWXUHV

5,00HWD5HJLVWU\2EMHFW)HDWXUHV_
5,00HWD([WULQF2EMHFWREMHFWW\SH
!
(17,7<5,00HWD([WULQF2EMHFW$WWV

5,00HWD5HJLVWU\2EMHFW$WWVREMHFWW\SH,'5()6,03/,('
!
(/(0(17
5,00HWD([WULQF2EMHFW5,00HWD([WULQF2EMHFW)HDWXUHV !
$77/,675,00HWD([WULQF2EMHFW


5,00HWD([WULQF2EMHFW$WWV!

.
List 1. DTD for the Core Model of ebRIM

4. Case study
Here we provide a case study for this ebXML
semantic extension model. Its based on a project of
software component registry and repository, which is
funded by Wuhan municipal government. The goal of
this software component registry & repository is to
provide an infrastructure for the registering, searching,
and exchanging (maybe commercially) of software
components, and in turn to promote the prosperity of
software industry. It should meet the following
demands: open, service oriented, security and scalable.
After research, we decide to adopt the ebXML
standard, namely the ebXML Registry Service
specification [5] and the ebXML Registry Information
Model [6] specification as our starting point. However,
for the sake of the problem mentioned at the beginning
of this paper, we had to make some extension to the
existing standard to accommodate the software
component into the ebXML registry.
First, we define the software component model
using the ebRIM core metamodel. Then we export it to
the XMI. The XMI file is saved somewhere, in the
registry or not, which is not important. Here we save
the XMI file in the registry as an ExtrinsicObject for
convenience.
An
additional
objectType:

Proceedings of the International Conference on Information Technology: Coding and Computing (ITCC05)
0-7695-2315-3/05 $ 20.00 IEEE

softwarecomponent is defined for the software

component, and when the client gets aware of this
objectType, it will find the XMI file through another
additional associationType: typemodel. Then the client
read the XMI file for the structure information.
As an example, here we give a model of software
component.

now, it is ebXML standard-compatible and thus ready

for future extension. The architecture of the client-side
is based on MVC pattern. New model can be defined
as required. Then the model is read in and then used to
generate the corresponding viewer for that model for
the user. Using this mechanism, the client can flexibly
deal with different kinds of complex objects.
Viewer

Controller

Common Viewer
Viewer1

Viewer2
output

Model
input

plugin
Model Def1

Figure 3. Software Component Model based

on the Core Model of ebRIM
The XMI file fragment is as follow:
;0,FRQWHQW!
5,00HWD(QWULQF2EMHFW
[LPLG BFEBBB
REMHFWW\SH 6RIWZDUH&R!
5,00HWD5HJLVWU\2EMHFWVORW!
5,00HWD6ORW[LPLG BFEBBB
VORWQDPH SULFH!
5,00HWD6ORW[LPLG BFEBBB
VORWQDPH DOLDVQDPH!
5,00HWD6ORW[LPLG BFEBBB
VORWQDPH NH\ZRUGV!
5,00HWD6ORW[LPLG BFEBBB
VORWQDPH IXQFWLRQDO2YHUYLHZ!
5,00HWD6ORW[LPLG BFEBBB
VORWQDPH GHWDLO,QIRUPDWLRQ!
5,00HWD5HJLVWU\2EMHFWVORW!
5,00HWD(QWULQF2EMHFW!
5,00HWD(QWULQF2EMHFW
[LPLG BFEBBB
REMHFWW\SH 6RIWZDUH&R!
5,00HWD(QWULQF2EMHFW
[LPLG BFEBBB
REMHFWW\SH 'RFXPHQW!
5,00HWD(QWULQF2EMHFW
[LPLG BFEBBB
REMHFWW\SH 3URJUDPILOH!
5,00HWD&ODVVLILFDWLRQ
[LPLG BFEBBB
UHJLVWU\2EMHFW BFEBBB
FRQFHSW BFEBBB!
5,00HWD&ODVVLILFDWLRQ
[LPLG BFEBBB
UHJLVWU\2EMHFW BFEBBB
FRQFHSW BFEBBB!

;0,FRQWHQW!

List 2. The XMI of Software Component Model

We also developed a client-side application for the
software component registry and repository. Although
it is mainly targeted at the software component up till

Model Def2

EBRIM Model

Figure 4. MVC based Architecture of the Client

The following picture is a snapshot of the prototype.

Figure 5. Screen Snapshoot of the Client

This case study gives us an overview of the
execution engine for the semantic extension model we
provides. As we can see, it intentionally leaves out the
server side of ebXML registry, which means that there
is no other requirement for the server implementation
as long as it is standard compatible. For a client that is
not aware of the semantic model we defined, all the
information can also be attained by manual checking

5. Conclusions and future work

This paper provides a semantic extension solution
for ebXML Registry, to solve the problem encountered
when new types of ebXML registry objects appear.
Though the extension is beyond the scope of ebRIM,
the mapping can be easily established to ensure the
standard compatibility. We also demonstrate a case
study based on the semantic extension, proving that the
extension is practical and flexible.
However, the current meta-model of the semantic
extension is just an extraction of ebRIM, which by no
means is complete. Additional model facility should

Proceedings of the International Conference on Information Technology: Coding and Computing (ITCC05)
0-7695-2315-3/05 $ 20.00 IEEE

provide more complicate modeling support. The future

work should provide a more delicate meta-model and
define the corresponding model transformation to
ebRIM in a more formal way. In addition, the client
prototype we developed is now left out from the
semantic extension model. We will refine its
architecture and integrate it into the semantic extension
model to provide a unified and consistent architecture
that take full consideration of both the client and server
sides.

6. References
[1] Sun Microsystems
http://www.sun.com/software/xml/developers/regrep/.
[2] Korea Institute of eComerce
http://www.ebxml.or.kr/board_read.asp?index=list&inflag=b
&page=1&seq=82&f
[3] Korea Trade Network
http://www.GXMLHub.com/english/index.html3.

[10] Enriching ebXML Registries with OWL Ontologies for

Efficient Service Discovery, Asuman Dogac,Yildiray Kabak,
Gokce B. Laleci, Proceedings of the 14th International
Workshop on Research Issues on Data Engineering:Web
Services
for
E-Commerce
and
E-Government
Application(RIDE'04).
[11] ebXML Business Process Specification Schema,
Version 1.05 , Business Project Team, 15 July 2002.
[12] Kabak, Y., Exploiting Web Service Semantics through
ebXML Registries, MS Thesis, Middle East Technical
University, June 2003
[13] ISO/TC154N418 OASIS UBL Report,
http://isotc.iso.ch/livelink/livelink.exe/1907809/
154n418_oasis_ubl_report.pdf?func=doc.Fetch&nodeid=190
7809.
[14] UN/CEFACT ebXML Core Components Technical
Specification V1.9, http://xml.coverpages.org/CCTSv1902002.pdf.

[4] XML Global http://www.xmlglobal.com.

[15] UN/ECE Business neutral core component library,

http://www.itu.int/ITU-T/e-business/mou/related/unecep1.html.

[5] OASIS/ebXML Registry Services Specification v2.5,

http://www.oasisopen.org/committees/regrep/documents/2.5/specs/ebrs2.5.pdf

[16] XML Metadata Interchange Specification,

Version 1.2, Object Management Group, January 2002.

[6] OASIS/ebXML Registry Information Model v2.5,

http://www.oasisopen.org/committees/regrep/documents/2.5/specs/ebrim2.5.pdf.
[7] ebXML: Status, Research Issues, and Obstacles, Birgit
Hofreite, Chrisian Huemer, Wolfgang Klas,Proceedings of
the 12th International Workshop on Research Issues in Data
Engineering: Engineering e-Commerce/e-Business Systems
(RIDE'02)0.
[8] Vision for ebXML, http://lists.ebxml.org/archives/
ebxml-awareness/200010/doc00001.doc.
[9] Discovery of Web Services in a Federated Registry
Environment, Kaarthik Sivashanmugam, Kunal Verma, Amit
Sheth, Proceedings of the IEEE International Conference on
Web Services(ICWS'04)

[17] Resource Description Framework (RDF) Primer, W3C

Working Draft, March 2000.
[18] W3C XML Schema, http://www.w3.org/XML/Schema.
[19] The MMF Approach to Engineering Object-Oriented
Languages. Tony Clark, Andy Evans, Stuart Kent, Paul
Sammut. Workshop on Language Descriptions, Tools and
Applications (LDTA2001), April 2001.
[20] Kotok, A., and D. R. Webber, ebXML: The New Global
Standard for Doing Business on the Internet, New Riders
Publishing, August 2001.
[21] Nickull, D., et al., Professional ebXML Foundations,
Wrox Press Inc, November 2001.
[22] Webber, D.R., and Dutton, Understanding ebXML,
UDDI,
XML/EDI,
XML.org
Newsletter,
http://www.xml.org/feature_articles/2000_1107_miller.shtml

Proceedings of the International Conference on Information Technology: Coding and Computing (ITCC05)
0-7695-2315-3/05 $ 20.00 IEEE