IBIS – Interoperability in Business Information Systems
IBIS
International Journal of
Interoperability in Business
Information Systems
Issue 2 (2), 2007
ISSN: 1862-6378
http://www.ibis-journal.net ISSN:1862-6378
IBIS – Issue 2 (2), 2007
Publisher:
University of Oldenburg
Department of Business Information Systems
D-26111 Oldenburg
Germany
Tel.: +49 441 798 4480
Fax: +49 441 798 4472
[email protected]
http://www.ibis-journal.net
ISSN: 1862-6378
Editors (in alphabetical order):
Sven Abels, Axel Hahn, John Krogstie, Kai Mertins,
Andreas L. Opdahl, Mathias Uslar
License:
All our articles are published under the Digital Peer Publishing License. This ensures
free distribution and it also guarantees the authors' rights that no content is
modified or reused without citing the names of authors and holders of rights and
the bibliographical information used. Additionally, the rights to use in physical
form, particularly the rights to distribute the work in printed form or on storage
media, are retained by the authors or other rights holders and are not covered by
this license.
The full license text may be found at http://www.ibis-journal.net
Scope:
The capability to efficiently interact, collaborate and exchange information with
business partners and within a company is one of the most important challenges of
each enterprise, especially forced by the global markets and the resulting
competition. Today, many software systems are completely isolated and not
integrated into a homogeneous structure. This makes it hard to exchange
information and to keep business information in sync. Interoperability can be
defined as the ability of enterprise software and applications to interact. In Europe
between 30-40% of total IT budgets is spent on issues tied to Interoperability.
This journal aims in exchanging and presenting research activities in the area of
creating interoperability in business information systems. Ambition of this journal
is to get an overview of current research activities as well as to offer a broad
discussion in selected areas of the interoperability of heterogeneous information
systems. It is proposed to connect research experts from this domain and to
exchange ideas and approaches. It is our goal to connect latest research results
with real-world scenarios in order to increase interoperability in business
information systems.
© IBIS – Issue 2 (2), 2007
IBIS – Interoperability in Business Information Systems
Review Board:
Submitted articles of this journal are reviewed by the members of the IBIS
review board. At the date of this issue, the review board contains the
following persons in alphabetical order:
Sven Abels, TIE Nederland B.V., Germany
Antonia Albani, Delft University of Technology, Netherlands
Bernhard Bauer, University of Augsburg, Germany
Arne-J. Berre, SINTEF, Distributed Information Systems, Norway
Jean Bézivin, University of Nantes, Brittany, France
Flavio Bonfatti, University of Modena, Italy
Frank-Dieter Dorloff, University of Duisburg-Essen, Germany
Peter Fettke, Institute for Information Systems, DFKI, Germany
Michael Goedicke, University of Duisburg-Essen, Germany
Jan Goossenaerts, University of Eindhoven, Netherlands
Norbert Gronau, University of Potsdam, Germany
Axel Hahn, University of Oldenburg, Germany
Wilhelm Hasselbring, University of Oldenburg, Germany
Martin Hepp, Digital Enterprise Research Institute (DERI), Germany
Willem-Jan van den Heuvel, Tilburg University, Netherlands
Paul Johannesson, Royal Institute of Technology, Sweden
John Krogstie, Trondheim, Norges Teknisk-Naturvitenskapelige
Universitet, Norwegen
Kai-Uwe Kühnberger, University of Osnabrueck, Germany
Kai Mertins, Fraunhofer Institut für Produktionsanlagen und
Konstruktionstechnik, Germany
Michele Missikoff, IASI, National Research Council (CNR), Italy
Andreas Lothe Opdahl University of Bergen, Norway
Frank Teuteberg, University of Osnabrueck, Germany
Mathias Uslar, OFFIS - Institut für Informatik, Germany
Martin Zelm, CIMOSA Association e.V., Germany
The editors thank all reviewers for their help! This IBIS issue wouldn’t be possible
without the support of our reviewers that help us to ensure a high quality.
© IBIS – Issue 2 (2), 2007
http://www.ibis-journal.net ISSN:1862-6378
IBIS – Issue 2 (2), 2007
© IBIS – Issue 2 (2), 2007
IBIS – Interoperability in Business Information Systems
Content
Editorial………………………………………………………………………………………………………………………7
PLASMA: A Platform for Schema Matching and Management…………………………………….9
Using Ontologies to Model and Understand Product Development………………………….21
An Enterprise Application Integration Architecture Supporting
Ontology Based Approach for B2B Collaboration………………………………………………………39
IESA-Call…………………………………………………………………………………………………………………….65
Call for Articles…………………………………………………………………………………………………………71
© IBIS – Issue 2 (2), 2007
http://www.ibis-journal.net ISSN:1862-6378
IBIS – Issue 2 (2), 2007
© IBIS – Issue 2 (2), 2007
IBIS – Interoperability in Business Information Systems
Editorial
Dear reader,
we would like to welcome you to the second issue of the international journal of
Interoperability in Business Information Systems (IBIS).
By writing this editorial, we can announce that due to much request and some good
input, we managed to bring up a new journal system which should better meet
your and our needs towards Open Access publishing. Furthermore, we would like to
welcome our new co-editors, Kai Mertins, John Krogstie and Andreas L.Opdahl.
Professor Kai Mertins (class 1947) is a director of the IPK at Fraunhofer-Institut for
production plants and construction technology. Since 1998 he is additionally been a
honorary professor at the technical University of Berlin. After electromecanician
studies with emphasis measuring and control engineering, he received a engineer
(degree) in Hamburg. Subsequently, he went on to the industrial engineer studies
at the technical University of Berlin (Dipl. engineer). It closed its graduation with
Professor Dr. h. C mult. Dr. Ing. G. Trace over "Steuerung computer-guided
Fertigungssysteme" off. His focal tasks today are: Enterprise modelling, enterprise
management, production organization, knowledge management, factory planning,
job controlling, manufacturing control systems, coworker qualification. Professor
Mertins has comprehensive experiences as a manager of international projects with
European and asiatic consortia.
John Krogstie (http://www.idi.ntnu.no/~krogstie) has a PhD (1995) and a MSc
(1991) in Information Systems, both from the Norwegian University of Science and
Technology (NTNU). He is Professor in Information, Systems at IDI, NTNU,
Trondheim, Norway. He is also a senior advisor at SINTEF. He was employed as a
manager in Accenture 1991-2000. John Krogstie is the Norwegian Representative
for IFIP TC8 and vice-chair of IFIP WG 8.1 on information systems design and
evaluation, where he is the initiator and leader of the task group for Mobile
Information Systems. He was general chair of the CAiSE'07 the conference and has
published around 90 refereed papers in journals, books and archival proceedings
since 1991.
Andreas Lothe Opdahl is Professor of Information Systems Development and Head
of the Information Systems (IS) Group at the Department of Information Science
and Media Studies at the University of Bergen, Norway.
His main research interest is development, maintenance and use of enterprise
models which support IS development and operations, in particular enterprise
models for interoperability between enterprises and their information systems. He
focuses on models and languages that integrate the various perspectives of
stakeholders tightly and that may embed multiple partial models for different uses
and purposes.
© IBIS – Issue 2 (2), 2007
http://www.ibis-journal.net ISSN:1862-6378
IBIS – Issue 1 (1), 2007
Selected articles for this issue
For this issue, we accepted about 15% of all submissions.The following titles are
included in issue 2 of our second volume:
•
PLASMA: A Platform for Schema Matching and Management
•
Using Ontologies to Model and Understand Product Development
•
An Enterprise Application Integration Architecture Supporting Ontology
Based Approach for B2B Collaboration
We hope you will appreciate the journal and the articles we selected for this issue.
Best regards,
your IBIS Editorial Board
(Axel Hahn, Sven Abels, Mathias Uslar,
Kai Mertins, John Krogstie and Andreas L. Opdahl)
© IBIS – Issue 2 (2), 2007
IBIS – Interoperability in Business Information Systems
PLASMA: A Platform for Schema Matching and Management
Aïcha-Nabila Benharkat
LIRIS-INSA de Lyon
National Institute of Applied Sciences of Lyon
Villeurbanne, FRANCE
[email protected]
Rami Rifaieh
San Diego Supercomputer Center
University of California
San Diego, USA
[email protected]
Sana Sellami, Mohamed Boukhebouze, Youssef Amghar
LIRIS-INSA de Lyon
National Institute of Applied Sciences of Lyon
Villeurbanne, FRANCE
[email protected] [email protected],
[email protected]
Abstract: This paper introduces an XML Schema management platform that promotes
the use of matching techniques to fulfill the requirements of data integration and data
exchange. The existing platforms, in the market, deal only with graphical but not
automatic matching. Several matching algorithms were suggested, by different
researchers, to automate the correspondences discovery between XML Schemas. These
algorithms use a wide range of approaches and matching techniques with
systematically many parameters and weights to be adjusted manually. In our platform
(PLASMA) we suggest a matching algorithm that uses constraints and a combination of
structural and description matching. In addition to our innovative matching algorithm,
we adopt an automating tuning for the various structural parameters used and propose
a Mapping Expression model along with a collection of transformation operators.
Hence, PLASMA enables a semantic matching process followed by a visual mapping
process to optimize the translation process between exchanged documents or
integrated schema.
Introduction
A growing number of applications are giving enterprises new opportunities to
implement cost-effective translation and integration solutions. However, the
problem resides in simplifying, automating, and reusing theses solutions. Building
manual processes or add-hoc scripts are time consuming that fail to provide the
conversions and transformations required between applications. In order to handle
these challenges, a framework for document and data translation should be
provided.
For data integration and data exchange, we should distinguish between two
processes at the schema level: matching and mapping. Firstly, schema matching
© IBIS – Issue 2 (2), 2007
http://www.ibis-journal.net ISSN: 1862-6378
IBIS – Issue 2 (2), 2007
helps to identify the correspondent elements in two schemas. Afterward schema
mapping with expressions, functions, conditions, etc., is required to define how
the matched elements can be mapped [RIF03]. The input of the mapping process is
the list of matched elements and the output is the individual mapping expression of
target elements.
We suggest avoiding the manual process by generating the transformation
automatically on the basis of a set of correspondences generated by a matching
process called EXSMAL and then visually editing these matched with expressions
and mapping rules. EXSMAL is a matching algorithm that we have initially studied
for matching components of two EDI messages [CHU05]. We use this algorithm in
PLASMA, which covers the matching, mapping and code generation processes.
PLASMA aims at creating a new generation of tools with goals in mind to simplify
the task of users working on document exchange. It can be considered as semiautomatic tool for identifying matching between schemas and generating
automatically the data transformation scripts.
The paper is organized as follows: the section 2 reviews related works in the
domain of data exchange. We give special attention to the effort in the domain of
schema matching and schema mapping. After explaining different related works,
we present in section 3 the PLASMA platform and its four layers (Matching,
Filtering, Mapping Transformation and Integration). We start by presenting EXSMAL
algorithm then we show how to filter the matching set produced by EXSMAL in
order to eliminate irrelevant correspondences. We explain then the principles of
ATA: Algorithm of Tuning Automation that leads to reduce human efforts when
adjusting parameters. The following section describes the third layer (Mapper),
where we use the previous filtered set and a dynamic ontology to generate usable
transformation rules. This section ends with a brief discussion of the
transformation layer. Finally, the section 4 concludes the paper.
Related works
XML is increasingly becoming the used format for B2B and B2C with ebXML,
semantic web techniques, and web Services with SOAP. B2B integration servers
include tools for XML transformation starting from a graphical but manual
definition of correspondences. For instance Visual XML Transformation Tool (IBM)
defines graphically XSLT stylesheets to make easier the transformation of XML
documents. However, many visual tools rely on domain knowledge expertise and
technical skills for performing the transformation task.
In this context, schema matching has attracted recently considerable attention in
research. The XML schema matching can be automatic and used for building
complex transformation of XML documents. This process of matching is unavoidably
required for building a platform of document exchange.
In schema matching, we can identify algorithms working with Meta data schemas
(DTD, database schema, XML Schema) such as Cupid [MAD01]. Similarity Flooding is
a structural matching algorithm used for XML Schema, SQL DDL, RDF schema, UML
© IBIS – Issue 2 (2), 2007
IBIS – Interoperability in Business Information Systems
and OEM [MEL02]. This graph based algorithm uses the idea of node influence by
adjacent node [MEL03]. XClust in [MON02] is an integration strategy based on (DTDs
or XML, schema) Clustering. In the ARTEMIS project [BER99] schema integration is
dealt with attributes clustering. The algorithm operates on a hybrid model
(relational and object oriented). The affinity between names is based on a
linguistic thesaurus (synonymy, hypernymy). The affinity between types is based on
a generic table of data type’s similarity. Finally, COMA [DO 02] and COMA++
[AUM05] are frameworks for schema matching. COMA allows using many algorithms
with different techniques for results rendering. The schemas are translated into
acyclic graphs that can be performed simultaneously by different matching module.
Intermediary results can be reused with possibilities of selection and aggregation.
This fully-personalized feature makes it difficult to average user to identify the
best combination between different modules.
On the other hand, schema mapping is studied separately than schema matching.
Clio [MIL01], is presented as a semi automatic tool allowing mappings among
relational schemas. It takes into account the constraints between the source
attributes and the global, schema ones. The correspondences are supposed to be
already identified and expressed in a first order logics language. Protoplasm
[BER04] inspired by COMA's approach, aims at incorporating different existing
approaches in a single platform for customizable schema mapping. The latter uses
the SMM (Schema Matching Model Graph) as an internal representation in which are
translated Meta models as (SQL DDL, ODMG, and XSD). SCIA [WAN04] is yet another
platform for matching, mapping and code generation. It offers a generic platform
to deal with meta-data (XML Schema, DTD) from scientific domain.
We can distinguish in the preceding review that not every matching algorithm has
created a mapping platform with user interface and case studies and none of these
approaches is applied to document exchange in E-Commerce and EDI. We aim in
this work to study an integrated approach that deals essentially with this domain of
interest. We showed in [RIF03] the drawback of not using a dedicated approach to
tackle the problem of document translation and document exchange for EDI. The
similarity between our approach and the cited ones is obvious in term of content.
However, the difference is shown through the quality of matching algorithm used
for EDI document and the usefulness of suggested mapping platform to cover the
state of the art needs for document exchange in E-Commerce (EDI, B2B, etc.).
The PLASMA Framework
PLASMA provides a general framework to perform data exchange with minimal
effort on the user side having limited technical skills. In order to build a complete
framework, we focused firstly on related studies including mapping expression
model and matching algorithm. We studied mapping expressions that are needed
between two schemas and defined a generic model to cover these expressions. We
suggested the EXSMAL algorithm to simplify finding the matches between
schemas.In the framework PLASMA (Figure.1), two XML Schemas entries are
© IBIS – Issue 2 (2), 2007
http://www.ibis-journal.net ISSN: 1862-6378
IBIS – Issue 2 (2), 2007
transformed into trees will be treated through multiple steps, that can be
described as follow:
The matching process yields a set of (1-1, 1-n, n-m) correspondences. A filtering
process is then performed in order to eliminate irrelevant correspondences. This
filtering provides an extension of EXSMAL Algorithm with two types of similarities
(path and internal) and aims at refining matching to 1-1 cardinalities in the case of
irrelevant similarities. Afterward, a mapping process is applied with the user
intervention to clean the resulted matched values. This process includes as well
the definition of mapping rules with respect to mapping expression model. Finally a
transformation process (i.e. code generation) is carried by the system in order to
offer the executable mapping to apply on data instances. In the following, we
describe briefly these steps.
Figure 1: PLASMA Architecture
The matching Layer
The input of our framework is a couple of XML schemas (e.g. Schema 1 and Schema
2). The matching algorithm calculates a set of correspondences EC1. We can
consider as examples the two schemas shown in Figure.1. EC1 is represented by the
set of lines joining source schema S1 on the left side and the target Schema T on
the right side. We assume in this step that user has identified the best set of
coefficient to be used in the matching algorithm.
EXSMAL
© IBIS – Issue 2 (2), 2007
IBIS – Interoperability in Business Information Systems
We have introduced in [CHU05] a new matcing algorithm, taking into consideration
the specific characteristics of EDI message's branching diagram expressed with XML
Schema. Our choice for the XML Schema was motivated by its potential to define
the structure and semantics of an EDI message. EXSMAL is fully described in [RIF05]
with a case study. It realizes matching of XML schemas taking into account textual
description, data types and context description of elements. The similarity
computation is based on a pairwise element similarity (basic and structural) and a
filtering process eliminating the correspondences with a value below the threshold
thraccept given by the user (Figure.2).
The Basic similarity basicSim is computed as the weighted sum of the textual
description (using information retrieval technique) and data type similarity(using a
static matrix defining the XML schema primitive data type affinity).
The Structural similarity structSim is computed by using two modules: the
structural neighbors computing and the aggregation function agg. The structural
neighbors of an element e is a quadruplet <ancestor(e), sibling(e),
immediateChild(e), leaf(e)>. The structural similarity value of two elements s
(source schema) and t (target schema) depends on the similarity value resulting
from the comparison of each pair of structural neighbor’s items. The similarity
value of each structural neighbors items’ pair is computed by using the function
agg(M, thr) which take a matrix M and a threshold value thr ∈ [0, 100] as input. It
returns the aggregated value of the input matrix M.
Figure.2: Snapshot of the matching generated by EXSMAL
The Pair-wise element similarity is then computed as the weighted sum of the
basic similarity value and the structural similarity value. It’s proposed as the final
similarity value for a pair of elements in our approach. The pair wise element
similarity of s and t is computed by the following formula:
Similarity(s,t)= basicSim(s, t)*coeff_base + structSim(s, t)*coeff_struct
Finally, a filtering can be done according to a threshold thraccept.
© IBIS – Issue 2 (2), 2007
http://www.ibis-journal.net ISSN: 1862-6378
IBIS – Issue 2 (2), 2007
Constraints Management
We have proposed in [SEL06] an algorithm completing the matching step by using
the constraints in XML Schema. We have identified the different constraints that
can be applied on the elements (sources and destinations) of schemas and
established a classification of these constraints (intrinsic and process). We have
also proposed an algorithm which takes into consideration the intrinsic constraints
and returns the penalty of violation of these constraints. The algorithm was
integrated with EX-SMAL to determine more efficiently the degree of similarity
between elements of XML Schemas.
Tuning of Matching Algorithm
In our work [BOU07], we have tried to automate the tuning of parameters existing
within the matching systems. This will help in reducing the human intervention,
from developers and users, and also to reach better matching quality (precision,
recall, and overall). Indeed, our approach consists in finding the best parameters
to use according to the studied schemas and their characteristics.
In particular, we believe that schema topology (number of nodes, number of paths,
depth, etc.) is directly related to the quality of the matching with respect to
structural parameters. Indeed, matching algorithm uses structural parameters (e.g.
for COMA [DO 02]: P_Parents, P_Children, P_Leaves, etc.) that can influence the
matching results. In order to discover some of the rules that exist between the
schema topology and the values of these parameters, we have proposed the
following approach:
Firstly, we have started by applying series of experiments, hereafter called
benchmark, with three selected algorithms (COMA [DO 02], EXSMAL [RIF05], SCIA
[WAN04]). We have collected schemas and created manual correspondences
between them. Afterward, we have repeatedly applied the automatic matching on
the schemas in the aim of finding a set of consistent mathematical model (or
relations). The consistency of the relations with a topological pattern can help us
refine the values of structural parameters.
Secondly, we have created a data store that includes all the rules empirically
deduced form the benchmark. Then, we have defined a tuning algorithm that uses
these stored statistical relations and apply them on new schemas. In other words,
the algorithm will seek in the entered schemas some topological patterns similar to
those stored in the data store and suggest the best set of parameters’ values for a
specific algorithm.
The two steps of our approach are depicted in Figure.3. The input of the first step
is a set of XML Schema and a set of tools. At first, the benchmark identifies the
structural parameters to study with each tool. Then it tries to apply a common
methodology using heavily data analysis and statistical methods to verify and test
models. The output of the first step is a set of acceptable models also called rules
or relations. The second part of our approach aims at suggesting values to be used
for a specific matching task.
© IBIS – Issue 2 (2), 2007
IBIS – Interoperability in Business Information Systems
Figure 3 : Steps of the Automatic Tuning Approach
To adjust the various structural parameters used within the studied matching
systems, we proposed in [BOU07] an algorithm for automatic tuning that uses the
results of benchmark and offers a better precision for the matching task.
Automatic Tuning Algorithm (ATA) has as input two schemas and the tool that we
want to optimize its structural parameters. The algorithm initially will calculate
the number of elements, numbers paths and the depth of each diagram. Then it
chooses, among the relations saved, from the benchmark, the relation to be
applied with respect to the characteristics of the schemas. Finally, ATA calculates
and displays the suggested values for each structural parameter involved in the
tool.
Besides EXSMAL, we applied a final test with COMA to check the results coming
from the tuning algorithm. The experiment consists in applying COMA to match
between two given schemas (never used in the test before). We calculated the
precision and Recall of the results obtained, figure 4 shows that the precision is
equal to 0,23 and that Recall is equal to 0,6 using standard value for structural
parameters. We have repeated the same matching after using the value of
parameters suggested by the tuning algorithm. The precision has improved to 0.33
and Recall improved to 0,8,matching shown in Figure 5.
The filtering Layer
In [HER06] we have extended EXSMAL by extracting the Path Similarity followed by
the internal Similarity. We have suggested the refinement of EXSMAL based on
these two similarities in order to obtain 1-1 cardinalities and eliminate irrelevant
similarities. The later are used for automating XML documents transformation.
© IBIS – Issue 2 (2), 2007
IBIS – Issue 2 (2), 2007
http://www.ibis-journal.net ISSN: 1862-6378
Figure 4. The matching before the execution of
the tool
Figure5 The matching after the execution of the
tool
The mapping Layer
Based one the Mapping Expression Model defined in [RIF04], we have suggested in
[SEL06] the XME (XML Mapping Expression Model). XME model is expressed using
XML Schema and defines all the properties of the mapping model as well as the
used transformation operators. It helps identifying how to generate the value of a
target element/attribute from sources elments. In this respect, a target elment is
expressed as follows:
−
Ai =
∑ [ f ( a ,a
i
r
p ,...,ae
),li ,ci ] + τ i = α i ( A ) +τ i
i
Where :
Ai represents an element/field of the target representation,
αi(A) is a mapping expression applied on multi-sources to generate a part of the
target field A or to generate a sub-field of the field A, αi= < fi , li ,ci> where fi is a
mapping function,
li is a set of filters for sources rows, we could find a filter li(ar) for each source
field ar,
Ci is a condition on the mapped value of the field A. This enables us to ignore
mapped results that do not satisfy the condition,
τi represents a generic function, independent of the source. The generic function
covers all the cases that the mapping expression model doesn’t generate. This
function can be a constant value or, an incremental function, an automatic
function or a skolem function in DB.
© IBIS – Issue 2 (2), 2007
IBIS – Interoperability in Business Information Systems
Figure 6: Example of generated mappings between XML Schemas
The transformation and integration Layer
The mapping layer generates a set of mapping as shown in Figure 6. Once these
semantic mappings (source, target and operation) are defined, a script is
automatically created by the platform in in data transformation language such as
XSLT or XQuery. The result will be used for translating XML documents instance
valid with the source schema to an instance of the target schema. This part of the
project is still in progress.
We have implemented the front end of PLASMA prototype. We integrate the
EXSMAL algorithm with restrcturing the code source of EXSMAL.We have realized a
new Graphical user Interface with adding functionality of mapping editing between
matched elements. We have added to the initial GUI of EXSMAL two panels in the
interface and a canavas that accepts the drag and drop of objects representing
schemas, mapping functions, multiple schemas, etc. This development has been
realised using Java (J2EE JDK 1.5, and Eclipse). A snapshot of the PLASMA
prototype is presented in Figure 7.
© IBIS – Issue 2 (2), 2007
http://www.ibis-journal.net ISSN: 1862-6378
IBIS – Issue 2 (2), 2007
Figure 7: Snapshot of the matching generated by EXSMAL
Conclusion
The use of XML and XML schema is a major trump for interoperability. However,
the matching and mapping process is unavoidably required before performing any
interoperability in data integration and data exchange. We have presented through
the PLASMA framework a matching and mapping approach for documents exchange
and pre-integration. Our EXSMAL algorithm has been placed in the first layer core.
Its execution provides a matching set with (1-1, 1-n and n-1) cardinalities. We have
also developed an extension to the matching algorithm EX-SMAL that uses the
constraints existing in XML Schema. We have proposed and implemented an
algorithm for automatic tuning that uses the results of a matching benchmark. We
have carried an experiment to evaluate the precision of our algorithm. This
experiment showed that the optimal values suggested by the algorithm lead to a
better precision and better Recall. We have tried then to filter this set in order to
obtain 1-1 correspondences between the elements of XML schema and eliminate
irrelevant ones with two new calculations: Path similarity and internal similarity.
This filtering algorithm is not implemented yet in the current version of PLASMA.
The final mappings are then expressed in the data model XME (XML Mapping
Expression) using operations such as: Connect and Rename for the simple matching,
Merge and Split. Then, transformation layer can be applied to generate final results
from source instance. The implementation of the back end of the PLASMA
framework is still work in progress. We intend in the future to improve the
algorithm of constraints including all the constraints (intrinsic and process). We aim
to improve the prototype of PLASMA and to integrate the algorithm of constraints
and all the operators of transformation. Future works cover also extending
matching techniques to large scale matching between ontologies and taxonomies.
© IBIS – Issue 2 (2), 2007
IBIS – Interoperability in Business Information Systems
References
[AUM05]
[BER04]
[BER99]
[BOU07]
[CHU05]
[HER06]
[DO02]
[MAD01]
[MEL02]
[MEL03]
[MIL01]
[MON02]
[RIF03]
[RIF04]
[RIF05]
[SEL06]
[WAN04]
Aumüller,D.; Do,H.H.; Massmann,S.; Rahm,E.: Schema and Ontology Matching with
COMA++. Proceedings SIGMOD 2005 (Software Demonstration), Baltimore, June
2005, pp 906-908.
Bernstein,P.; Melnik,S.; Petropoulos, M.; Quix,C.: Industrial-Strength Schema
Matching. In SIGMOD Record, Vol. 33, No. 4, December 2004, pp 38-43.
Bergamaschi,S.; Castano,S.; Vincini,M.: Semantic Integration of Semi structured
and Structured Data Sources. SIGMOD Record 28(1), 1999, pp 54-59.
Boukhebouze,M.; Rifaieh,R.; Benharkat,A.N; Amghar.Y.: Benchmarking XMLSchema Matching Algorithms for Improving Automated Tuning.
In ACS/IEEE
AICCSA-07, Amman, Jordan, May 13-16, 2007, pp 917-925.
Chukmol,U.; Rifaieh,R.; Benharkat,A.N.: EXSMAL: EDI/XML semi-automatic Schema
Matching Algorithm. In IEEE CEC 2005, July 19-22, 2005, Technische Universität
München, Germany, pp 422-425.
Herzi, K.; Benharkat,A.N.; Amghar,Y.: Refinement of Correspondences in EXSMAL
for XML Document Transformation. In DEXA Workshops 2006: 304-308
Do,H.; Rahm,E.: COMA-A system for flexible combination of Schema Matching
approaches. In Proceeding of the 28th VLDB Conference, August, 2002, Hong Kong,
China,pp 610-621
Madhavan,J.; Bernstein, P. A.; Rahm, E.: Generic Schema Matching with Cupid. In
Proceedings of the 27th VLDB Conference, 2001, Rome, Italy, pp.49-58.
Melnik,S.; Garcia-Molina, H.; Rahm,E.: Similarity Flooding: A versatile Graph
Matching approaches. In Proceeding (ICDE), 2002, San Jose, California, USA, pp
117-128.
Melnik,S.; Rahm,E.; Berstein,P.A.: Rondo: A programming Platform for Generic
Model Management. In Proceedings of SIGMOD Conference, June 9-12, 2003, San
Diego, California, USA, pp. 193-204.
Miller, R.J. ; Hernandez, M.A; Haas, L.M. ; Yan, L.L. ; Ho, C.T.H.; Fagin, R.;
Popa,L. : The Clio Project: Managing Heterogeneity. In ACM SIGMOD Record,
Volume 30, Issue 1 (March 2001), ACM Press, New York, NY, USA 200, pp.7883, ISSN: 0163-5808.
Mong-Li,L.; Liang Huai ,Y.; Wynne,H.; Xia,Y.: XClust: clustering XML schemas for
effective integration. In CIKM 2002, pp 292-299
Rifaieh,R.; Benharkat,A.N.: An Analysis of EDI’s Message Translation and
Integration Problems. In proceedings of the International Conference on Computer
Science, Software Engineering, Information Technology, e-Business, and
Applications (CSITeA’03), June 5-7, 2003, Rio de Janeiro, Brazil.
Rifaieh,R.: Using Contextual Ontologies for Semantic Sharing within Enterprise
Information Systems, PhD Thesis, National Institute of Applied Sciences of Lyon
(INSA-Lyon), Dec. 2004, http://docinsa.insa-lyon.fr/these/2004/rifaieh/these.pdf
Rifaieh,R.; Chukmol,U. ; Benharkat,A.N.,: A Matching Algorithm for Electronic Data
Interchange. In TES 2005, pp 34-47.
Sellami,S.; Benharkat,A.N.; Rifaieh,R.; Amghar,Y.: Schema Matching for Document
Exchange: A Constraint Based Approach. In (SITIS' 2006), Hammamet TUNISIE, pp.
299-309. springer Verlag, LNCS series . ISSN 2-9525435-1. 2006
Wang,G. and al.: Critical Points for Interactive Schema Matching. In Proceedings of
Sixth Asia Pacific Web Conference, Hangzhou, China, April 2004, Springer LNCS,
Springer Verlag, volume 3007, 2004, pp 654-664.
© IBIS – Issue 2 (2), 2007
http://www.ibis-journal.net ISSN: 1862-6378
IBIS – Issue 2 (2), 2007
About the authors
AÏCHA-NABILA BENHARKAT received her Ph.D. degree from the National Institute of
Applied Sciences of LYON in 1990. Since 1992 she is Associate Professor at the
Computer Science Department (INSA of LYON). Since 1993 she worked on the
Integration of heterogeneous databases using Description Logics. Currently, her
research interests include the interoperability domain, matching techniques in
small and large scale and ontologies.
RAMI RIFAIEH is a Research Fellow in San Diego Supercomputer Center; he received
his Ph.D. degree in Computer Science from National Institute of Applied Sciences of
Lyon in 2004. He is working on Data and Schema Integration, Matching/Mapping
Techniques, and resource integration in Life Sciences.
SANA SELLAMI is a PhD candidate at the INSA (National Institute of Applied Sciences
Lyon France). She received her Master degree in Computer Science from INSA-Lyon
in 2006 , and Engineering degree form INSAT, Tunisia in 2006. Her research interest
spans over the Large Scale Schema Matching domain.
MOHAMED BOUKHEBOUZE received his Master degree from Computer Science from
National Institute of Applied Sciences of Lyon in 2006 and currently is pursuing a
PhD in formal verification and business processes management.
YOUSSEF AMGHAR is Professor at the National Institute of Applied Sciences of LYON
since 2003. His research interests cover data engineering, interoperability and
formal models. His main field of teaching concerns information systems.
© IBIS – Issue 2 (2), 2007
IBIS – Interoperability in Business Information Systems
Using Ontologies to Model and Understand Product
Development
Axel Hahn, Kevin Hausmann, Stefan Häusler, Jan Strickmann
OFFIS – Institute for Information Technology
26121 Oldenburg, Germany
{hahn | hausmann | haeusler | strickmann} @ offis.de
Abstract: New product development is crucial for almost any company’s future. At the same time,
it is one of the most knowledge-intensive and complex business processes. Nowadays the high
complexity of most products requires the cooperation of engineers from various fields such as
mechanical engineering, electronics and software design to achieve outstanding results. Thus,
project management becomes a most important issue to guide a development project through
conflicting goals, misunderstandings or scarce resources.
To ease the interoperability between engineering domains, to understand the different phases of
development projects and translate technical properties into meaningful key figures for project
assessment, ontologies are a promising technology. The semantic approach they provide can help to
bridge the inconsistencies between the many domains involved and to deliver one integrated,
flexible model for engineering projects and processes.
This article shows how partial development information from domain-specific IT-systems is
converted into an integrated semantic model. Therefore, we discuss generic development processes
and ontologies representing individual phases and partial models. In this paper we focus on the task
of data integration when dealing with a set of partial product or project models: transformations
from source systems into an ontology, mapping of partial models and coherence of variable models.
The thereby arising integrated model grows with the product and serves as repository for various
questions concerning the development project such as: Is the project on time and in budget? Which
requirements are met? Are there conflicts between product elements? To answer these questions,
metrics and a method for their derivation are introduced and shown in an example from Software
Development.
The paper closes with the introduction of Permeter, a performance measurement framework
implementing the described methodology. The framework is under development at the University of
Oldenburg.
Introduction
Product development is a challenging research area due to its creativity,
complexity and its intricate management demands. At the same time, it is of vital
and growing importance to any company’s success in today’s fast paced and global
markets. There are several methods developed in science and industry which claim
to describe, manage and improve development processes. However, these solutions
are often very specific and of limited portability. As the business objects differ
from industry to industry, so do their design processes – developing a new laundry
detergent formula is naturally different from designing a packing machine or
coding a computer game. This is acknowledged by cross-industry standards such as
the ISO 9000 by different process groups. Our research goal is to understand the
mechanisms which influence the performance of product development. For
empirical analysis we propose new measurement method. In this paper we start
© IBIS – Issue 5(2), 2007
http://www.ibis-journal.net ISSN:1862-6378
IBIS Issue 2(2), 2007
with a characterization of development processes as a basis for our research
approach and introduce an ontology-based method integrating development results
in a flexible semantic environment for further analysis. It is designed to serve as a
knowledge base for a wide array of scientific and industrial analysis’s and problems
such as project controlling or the assessment of certain engineering methods by the
use of metrics. Special attention is given to explain the transformation and
integration from source data into a semantic model. The article closes with the
introduction of Permeter, a tool implementing the suggested methodology.
Development Processes
The notion of the ingenious inventor who single-handedly creates ground-breaking
new products is long gone – if it ever was true. Today new products and innovations
brought to the market are the result of many experts working together in a
somewhat structured, however complex, dynamic and sometimes chaotic course of
action: the development process. Development processes run from the first
product definition (requirements specification) to the start of (series) production
often going through a number of phases with specific goals. Each phase adds more
details and information to the product model ([Kah04], [Ehr03]). The content and
sequence of phases depends on the industry sector under consideration. Most
sectors have developed their own practice approach. Some of these will be
presented here to illustrate the complexity and entropy to be dealt with when
creating a development process model.
An example for an industry with a large supply of procedures to guide product
development is the software industry. Due to the intangibility and complexity of its
products, Software Engineering has been a dominating field of research ever since
the first computers were developed in the 1940s [Som04].
Classic procedures of Software Engineering are the waterfall-model of Royce and
the spiral model by Boehm [Boe88]. The waterfall-model is a sequential model
(with limited loopbacks) while the spiral model acknowledges the iterative nature
of product development. The most commonly known modern, object oriented
approach to software engineering is the Rational Unified Process (RUP) by
Jacobson, Booch, and Rumbaugh [JBR99]. It consists of the phases: Inception,
Elaboration, Construction and Transition (all with distinct milestones). The RUP is
divided into the work packages: Business Modelling, Requirements, Analysis &
Design, Implementation, Test and Deployment. All of these are supported by
Configuration & Change Management and Project management. Its success is
largely due to its sound foundation on the Unified Modelling Language (UML,
[JBR04]), which provides an ample supply of formal diagrams to model the
structure, behaviour and interaction of computer programs. Other well known
development procedures are the V-Model or eXtreme Programming (XP, [Bec03]).
The V-Model is a tailorable solution devised by the German government. XP is an
agile, incremental and iterative approach with short cycles and few formal
requirements. A thorough inspection of software development processes can be
found in [Bal00].
As soon as we leave exclusive software development and move into more
hardware-oriented industries such as mechanical engineering or electronics, the
level of interaction between different disciplines increases dramatically despite
available methodologies of construction and design. To cope with the explosion of
© IBIS Issue 2 (2), 2007
IBIS – Interoperability in Business Information Systems
complexity and yet arrive timely at development results, Simultaneous Engineering
methods (SE) as described in [Bul98] and [Rib00] have been devised. SE is
characterized by a number of Simultaneous Engineering Teams working
concurrently on partial problems with integration teams taking care of
synchronizing the different groups, discussing issues and determining project
status. This creates a significant amount of communication overhead but currently
is the most common way to control large development projects as Sörensen points
out for the automotive industry in [Sör06]. Due to their innovative and unique
nature, product development activities are usually carried out in a project format,
often involving diverse organizations across the globe. The challenges faced by
global engineering networks and in integrated product developments are described
in detail in [GHK+06]. They are met by more structured approaches like design
flows in chip design and mechatronics or Gate Processes in the automotive
industry.
All development processes face the same challenges:
1. Dealing with technical complexity
2. Understanding the interactions and dependencies between phases and
partial models
3. Defining the status of the project in terms of time, cost and quality
(Evaluating performance)
The first point can be well mastered by CAx-Software, Integrated DeveIopment
Environments (IDEs) or Product Data Management Systems. However, engineers
often abandon the two latter points that are less easy to tackle.
IT support and scientific exploration of individual domains is available, but hardly
any research has been done on formally modelling and understanding development
processes based on the actual observation of development activities and their
(digital) results (= partial product models). Thus a sound, flexible and integrated
model enabling automatic transformation of technical qualities into economic key
figures is needed. A promising application domain for such a system is project
controlling - a crucial issue in development projects (see [STG94], [Har03]).
Another application is the contribution of firm metrics to development maturity
models such as CMMI [Car06] or SPICE [Aut05a].
Related Work
Prior to illustrating the use of metrics in the context of this paper, a short overview
of related work shall be given.
The foundation of metric use in software project management has been laid out by
the TAME project [BR88]. Basili and Rombach were the first authors to join the
project management perspective with actual product and process models in order
to record and reuse development experience and measure performance. However,
this early concept lacks inter-phase-relationships (for an integrated analysis of all
phases of the design process). Henninger presents an organizational learning
environment for software development, which captures project-related
information during the creation of individual software products to be later
disseminated to subsequent projects. While Henninger acknowledges the necessity
© IBIS – Issue 5(2), 2007
http://www.ibis-journal.net ISSN:1862-6378
IBIS Issue 2(2), 2007
of metrics, the prototype BORE (Building an Organizational Repository of
Experiences) only provides the infrastructure for capturing project events but
offers no evaluation functionality ([Hen97a], [Hen97b]).
The exploration of invisible software structures is tackled by LaSSIE, a semanticsbased approach to discover code relations, find related projects and promote reuse
from software libraries. LaSSIE models enhance the software development process,
but yet again lack metrics to analyze it. Examinations of metrics for conceptual
software models can be found in [PGP+05]. A more practical approach to
measurement in development processes is given in the “Capability Maturity Model
Integration” (CMMI [Car06]) and “Software Process Improvement and Capability
Determination” (SPICE, [HDH+06]), two approaches aiming to determine the
maturity level of defined processes. Even though both models rely heavily on the
use of metrics, they are based on informal assessments not formal models of actual
development results. Even though most of development performance research has
been done in the field of Software (due to the unique characteristics of SE) these
results now diffuse into classic fields of engineering such as the automotive
industry. A good example in this field is AutomotiveSPICE [Aut05b] which translates
the classic SPICE-procedures into the much wider field of automotive engineering.
Methods for the integration of metric results into a performance measurement
system and the derivation of KPIs are described in [And05]. What is missing is a
generic methodology to evaluate the process outcome of different phases of the
design
methodology
and
for
different
domains
of
engineering.
To derive the requirement for this generic methodology the authors stated with the
outcome of our measurement: aggregated and suitable metrics.
Metrics and Methods for the Integrated Model
As presented in the introduction a great number of metrics has been defined in
literature and was applied to actual projects. An overview of R&D metrics can be
found in [Hau96]. Still, despite all measuring efforts, a great number of projects
fails or exceeds its planned limits as shown in [HAS07] One reason is that the
metrics suggested are often indirect indicators for the project status, but do not
capture the “as is” status because they neglect actual development results. For
example the number of patents or the amount of R&D investments are somewhat
related to the engineering output, but allow no decision support in daily project
work. Another example is the number of research staff which does not indicate
whether they are working on the right projects. Other reasons why common R&D
metrics are not helpful are the complexity and interdependencies of the various
partial models found in engineering. Therefore, we need metrics that quantify the
interrelations and methods for finding and understanding them. The Goal Question
Metric approach from the TAME-project [BR88] is used to obtain these metrics. It
helps to find fitting metrics for an information request by asking appropriate
questions answered by a set of metrics as presented in figure 1 for fault reduction
metrics.
Metrics can be classified by a number of dimensions such as object of study,
research goal, quality characteristic, etc. (see [PGP+05]). The most common one is
the object of study. Usually, one differentiates between product and process
metrics. Combined models give insight into the overall status of the project.
© IBIS Issue 2 (2), 2007
IBIS – Interoperability in Business Information Systems
Goal
Fault Reduction
Question
How many faults
are in the product?
Metric
# faults
What are frequent
faults made?
Fault clasification
# faults made
Which overhead is
caused by faults?
Which method
causes few faults?
# duration of tests
# faults / method
# of iterations prior
to release
# faults per phase
Figure 1: The Goal Question Metric Approach for fault reduction.
A metric is defined to measure ONE product or process quality ([IEE98]). A single
metric gives little insight into the status of a project. Thus methods for
combination of metric values need to be acquired. A good example is the metric
editor described later. Other well known methods for combining metrics in order to
ease their interpretation are the earned value methods which contrasts work done
(=value achieved) with expenses occurred or trend diagrams for costs or milestones
(e. g. [Lit95]).
Product Metrics
As stated in the previous section, it is important to derive ones measurement
methods/metrics from the domain that it should be used in. This includes the
complete environment of a project. The information that is needed and the
source(s) that it comes from have to be clear before a metric is established. The
product that is developed and the process that it emerges from are the most
important factors in a project. There is no one size fits all metric set that can be
used for every type of product or every new project, because the information that
exists in a project and the specific properties of a product differ from one project
to another. However there are some points of interest and patterns that can be
applied to product measurement in general.
The reason why metrics are used is that there is an overflow of information in
general and a lack of specific information (which is needed for a better
understanding of project activities and their outcome) at the same time. In case of
the product it is important to secure its quality. Quality is a complex issue and its
meaning depends on the quality management used in the specific project. As a
simple example product quality can mean that the product is operating in a
reliable manner and at the same time the product has to fulfil its specifications,
which is not necessarily covered by the first point. Therefore, there is a need for
good documentation when developing and using metrics. To show some aspects of
product measurement it is suitable to use software metrics as examples, because
software engineering is the engineering discipline that makes most use of metrics.
As mentioned before it depends on the project and the product what should be
measured and how it can be measured. The object of measurement is called
attribute. Fenton [FP97] distinguishes between internal and external product
attributes. In case of the (software) product internal attributes mostly mean size
© IBIS – Issue 5(2), 2007
http://www.ibis-journal.net ISSN:1862-6378
IBIS Issue 2(2), 2007
and complexity. The Lines of Code (LOC) metric is the easiest example for
measuring size in software products. This very early metric evolves around doing a
simple thing as counting elements in the source code. The LOC metric is as
ambiguous as it is simple. In most cases where the metric is used it is not ensured if
the physical lines where counted, or the functional statements in the code (e.g.
the statements separated by a ";" in Java). It is also not possible to determine the
effort that went into a certain part of source code by just using LOC, as the value
of LOC depends largely on the program writing style of the person and the
programming language that is used. LOC shows the problems that are generated
while measuring even simple properties of software like its size.
In case of complexity you can name McCabe’s Cyclomatic Complexity [McC76],
which measures software by its control flow, counting the number of linearly
independent paths.
The external attributes of a product are often not easy to measure, because they
depend on the product itself as well as its environment (the project). Fenton
names reliability, usability, testability etc. One can also name quality as an
external product attribute, while it is for sure dependent on even more factors or
even includes the previously mentioned attributes.
The distinction between internal and external product attributes also has its
impact on the measurement process itself. As external attributes are often derived
from the products internal attributes in some way, one needs to distinguish
between direct and indirect measurement. The internal attribute size for example
can be measured directly as seen for the LOC metric. A simple example for indirect
measurement is the Module defect density ([FP97] p.40) which computes as
number of defects divided by the module size (in LOC for example).
While these examples are focused on software engineering, the basic patterns of
product metrics mentioned are transferable into other domains. Good
understanding of the data available in a project is an important factor for
successful measurement activities because of the high complexity of today’s
products. The usage of ontologies helps to organize and understand data and makes
metric definition easier.
Process metrics
Apart from understanding product properties, a firm understanding of the
development process itself is necessary. Common questions are: Which activities
were necessary to create a product? Which systems/methods were involved? How
much iteration was made. What did it all cost? Will we finish on time?
These questions may be answered by looking at the development process. In
[GRP05], Garcia et al. cite four steps before process evaluation can take place:
definition, evaluation, control and improvement of the process. An emphasis is put
on the existence of an integrated framework measurement beforehand – a set of
metrics suited for processes. The first task of process definition is the most
cumbersome. While for example a well tailored manufacturing process can be
statically modelled and expressed with flow charts or process languages such as the
Business Process Modelling Languages (BPML), it is hard to define a creative process
like product development beforehand. The same problem exists in regards to the
control of a process via a workflow management system. An alternative to explicit,
ex-ante modelling of processes well suited for our application context can be found
with process mining. Process models may also be derived through observing the
© IBIS Issue 2 (2), 2007
IBIS – Interoperability in Business Information Systems
evolution of development results or the process protocol itself, if it is available e.
g. from a Product Data Management System (PDM) which logs all activities and
changes for the sake of configuration management and traceability in case of
liability claims. This has been presented for automotive development processes in
[Jen01].
Process Metrics
Resource per phase/Task
Indicates whether a project has too
much or too little manpower. If
categorized, it may help to identify key
personnel.
Cycle Time
Time for one revision cycle to be
completed
Concurrency Index
Number of parallel activities.
Fault metrics:
Faults are a good indicator of process
- Fault rate
quality. A “healthy” level of discovered
- Ratio
new/closed
problem defects shows that if faults are made,
reports
they are discovered. The ratio of new
vs. closed problem reports shows
whether faults are mended (< 1) or if
more problems arise.
Time metrics:
Indicators for quality of project planning
- % of tasks finished on time
and work achieved.
- % of passed checkpoints at first
review
Strategic Metrics
# of patents and copyrights
Show overall quality of design processes
and effectiveness.
% of accepted project proposals
Figure 2: Common Process Metrics.
For the evaluation, control and improvement tasks, a semantic model as presented
here is helpful in order to avoid slow and inaccurate manual reporting of process
properties since an integrated automatic feedback that is achieved by tapping into
the operative systems of product development is much more accurate. This leaves
us with the last important requirement: The measurement framework that defines
which properties need to be considered and how they are measured. This is
achieved by a number of process specific metrics. A selection of common process
metrics is presented in figure 2 based on [GRP05] and [Tha00].
A Methodology Towards the Integrated Product Model
As elaborated in the previous section, literature knows various methods to cope
with the technical and organizational complexity of product development. Despite
their individual maturity, they are hardly applicable for today’s requirements and
projects with numerous participants and artefacts, especially when it comes to
item 2 (understanding of the dependencies) and item 3 (status reporting) in the list
© IBIS – Issue 5(2), 2007
http://www.ibis-journal.net ISSN:1862-6378
IBIS Issue 2(2), 2007
of challenges stated in section 1 [Lit95]. The methodology presented in this
document is designed to meet these requirements.
Figure 3 sketches the proposed solution for a phase-connecting methodology of
product development. Based on conceptual ontologies of project phases and the
manual or (semi-) automatic interconnection between corresponding development
artefacts during the development process, it is possible to design metrics for a
project controlling dashboard and performance indicators.
KPI
Mapping on KPI‘s
Metrics
t-box
Analysis/ Assignment
Administration
a-box
Semantic Net
Linkage
Requirements
Linkage
Functions
Linkage
Linkage
Transformation
Transformation
Concept
Implementation
Test, QS
Project Management (PDM, CVS)
Figure 3: Overview of proposed methodology, an extension of [LR93].
A closer look at figure 3: At the bottom a generic example process runs with five
development phases along the timeline. The generic phases picked for the example
are:
Requirement
definition,
functional
design,
conceptual
design,
implementation, test and quality assurance.
For each phase, conceptual ontologies (t-boxes) are created. These ontologies, in
the following referred to as partial models, describe the artefacts created in the
corresponding step of the development process. The figure displays them in the
line labelled "t-box". In this specific project, the a-box is filled with corresponding
instances; e. g. a specific requirement for a product is an instance of the concept
"Requirement" established by the t-box. This procedure is shown in the line
labelled "a-box". In some phases, this modelling is done manually; in others an
automatic transformation from project data is possible. Requirements, for
example, are usually recorded manually. In this case, the a-box model may replace
the text file, allowing easy reuse in subsequent project phases, and is created and
maintained using an ontology editor. Other a-boxes can be created by a
transformation (indicated as arrows), for example an XSL transformation of UMLdiagrams. However, these are examples only: If the requirements are already
© IBIS Issue 2 (2), 2007
IBIS – Interoperability in Business Information Systems
captured in a structured way, the manual maintenance can be replaced by a
computer-aided transformation with ease.
A similar procedure is used for horizontal links between items (artefacts) of
different partial models. To establish these links, the framework implementing the
methodology offers a specific editor as well as automatic linkage facilities – as
detailed in section ’Integrating partial product models’. The phase-spanning
semantic web established by these relations offers a representation of the
development process previously not available. Dependencies and interrelations
between individual phases and artefacts are made apparent.
Metrics and reporting tools find a rich playground to derive figures from this new
integrated information basis, as indicated in the upper part of figure 3. Hence,
surveillance, control and management of development processes can be improved.
Key figures are now derived from the project context and do not have to be
interpreted in the isolated frame of a certain phase. To implement the surveillance
and control functions, methods described in literature and research are applied as
conceptual and process oriented metrics, to be later transformed into key
performance indicators (KPI, see
[Sch02]). They form a basis for process
monitoring that allows both measurement and active control. Since the KPIs are
estimated from development processes and artefacts, any events and changes show
up directly, allowing early intervention by decision makers.
Aside from conceptual models of the development artefacts and their relations,
other relevant information for the project success is found in project management
and product data management systems. They offer a second pillar and additional
input for a profound evaluation system. Therefore, project management data, e.g.
task and resources involved in specific tasks are also integrated by the framework,
compare section ‘Permeter’.
This section provides an overview of the methodology proposed for the integration
of models in product development. The upcoming section focuses on how the
actual integration takes place in detail.
Integrating Partial Product models
After explaining how product data from different sources are loaded, the next step
in creating an integrated product model is the establishment of semantic relations
between the created instances of ontologies. As stated in the previous section,
both manual and (semi-) automatic establishing of relations is possible. After
exploring possibilities and (dis)advantages for these two approaches, this section
goes into details on both the manual method and the automatic linkage algorithms.
Manual vs. Automatic relation establishment
The manual and the automatic relation establishment approaches have both their
advantages. The following figure summarises the properties of both methods in
question:
© IBIS – Issue 5(2), 2007
http://www.ibis-journal.net ISSN:1862-6378
Manual linking
Suitable for small data sets only
High user interaction
High accuracy
Vulnerable to “metric gambling” and
abuse
IBIS Issue 2(2), 2007
(Semi-) Automatic linking
Suitable for small and large datasets
Low to medium user interaction
Medium to high accuracy
Figure 4: Manual vs. automatic linking
These properties given, the automatic linking approach is to be preferred.
Nevertheless, there are partial models where automatic algorithms can not be used
and a manual process is sufficient. For example, if artefacts of partial model
Requirements are to be connected with the artefacts of Functionality that fulfil
one or more requirements. In that case, the number of artefacts is rather small the
amount of time needed is acceptable. Furthermore it can be assumed that an
automatic algorithm would not lead to more accurate results, since only a
developer has the knowledge about what functionality fulfils which requirement.
On the other hand, if the amount of data grows, the manual mapping of partial
models is time-consuming and error-prone as it happens more often that a required
relation is overlooked. Automatic algorithms can ease the process of mapping
partial product models, especially for large data sets. These algorithms should be
combined with manual user interaction of a semi-automatic approach to verify the
results and make modifications, as it is the trend in actual ontology alignment and
mapping tools ([NM03], [ESS05]).
Regardless of the approach chosen, a high accuracy of correct relations between
artefacts can only be achieved if a domain expert is involved in the process.
Therefore, the usability of the linking tools needs to be increased (compared to the
state-of-the-art today) accordingly.
Manual linking
A graphical editor is needed to support the manual and semi-automatic
establishment of semantic relations between artefacts of different partial models.
The editor has to offer both the ability to explore large data sets of two ontologies
at the same time and also the functionality to establish defined relations between
two artefacts of these ontologies.
A suitable approach is the Matrix Browser [ZCB02] developed by IAO for the
visualization and navigation of networked information spaces like in ontologies.
The central idea of this approach is to map the underlying graph as an adjacency
matrix, an alternative representation from graph theory where the nodes are
shown along the horizontal and the vertical axis of a matrix. Each axis shows a
hierarchical structure of the ontology and can be interactively expanded and
collapsed.
© IBIS Issue 2 (2), 2007
IBIS – Interoperability in Business Information Systems
Figure 5: Matrix Browser
As shown in figure 5, we adopted this approach to use it for the manual
establishment of relations between artefacts of different partial models. The user
is enabled to select the partial model that should be set to one of the axes. For
example, it is possible to set partial model ‘Requirements’ to the vertical and
‘Function’ to the horizontal axis. By selecting two artefacts in the Matrix Browser,
they can be connected via one or more relations defined between their
corresponding ontology concepts in the t-box. This concept is based on the same
idea as the widespread Quality Function Deployment-method (QFD, [Aka04]).
Automatic linking
For our purpose, algorithms have to support the user in detecting which artefacts
of different partial models can be connected, e.g. which function realises which
requirement or, another example, which java class implements a class modelled in
UML.
As described above, it is unrealistic to perform this process fully automated,
further user interaction is needed.
In research, a lot of strategies were proposed to combine different ontologies along
with different terminology like ontology merging, aligning or mapping. Regarding
the definitions of Klein [Kl01], the strategies of aligning and mapping is more suited
for our purpose since we do not want to create a new ontology. Therefore, we
focus on using existing approaches concerning the alignment and mapping of
ontologies.
In recent years, different solutions for (semi-) automatic alignment of ontologies
were developed, using multiple methods to calculate the similarity between two
© IBIS – Issue 5(2), 2007
http://www.ibis-journal.net ISSN:1862-6378
IBIS Issue 2(2), 2007
ontology elements, e.g. terminological (string-based), structural, extensional
(instance-based) or semantic methods [EE03]. These solutions (e.g. PROMPT [NM03]
or APFEL [ESS05]) developed semi-automatic alignment processes around these
mapping methods.
The person applying the proposed framework in a development project is enabled
to use the research-proposed mapping and alignment strategies for the integration
on partial product models. This action is processed in the following manner:
1. Selection of two or more partial models to be linked
2. Selection of a semantic relation to be used for the correspondences
identified
3. Selection of a strategy for correspondence revelation (as proposed in
research) and configuration of its options and properties
4. Execution of the method and preview of the correspondences extracted
5. Manual addition or deletion
Before
After
Person
Person
com.test.Person
Freelancer
same as
com.test.Person
Freelancer
com.test.Employee
com.test.Employee
sameAs
same
as
Employee
com.test.Freelancer
com.test.Freelancer
Employee
Relation Establishment Process
1
Selecting
UML and Java
Partial Model
Selecting
„sameAs“
relation
2
Configure
string-based
alignment
3
4
Calculate
mappings
5
Adjust results
Figure 6: Semi-automatic relation establishment
Figure 6 illustrates an example instantiation of the described process. The partial
models selected for the process are UML and Java, each containing three instances.
These instances have to be connected by the “same as”-Relation for an UML class
(which the instance of the UML partial model represents), because it represents
the same artefact as the Java implementation of the class (on a different level of
abstraction). The strategy used for the example examines the identifier of the
instances in the models and proposes the creation of a semantic relation for the
artefacts corresponding.
Permeter
In this chapter we propose Permeter, an application implementing the proposed
methodology that is able to handle all described steps like loading partial model
specific project data, establishing relations between artefacts of different partial
models, running metrics on the integrated product model and displaying the
aggregated results in reports.
© IBIS Issue 2 (2), 2007
IBIS – Interoperability in Business Information Systems
Which partial models are applicable for specific projects depends on the domain.
E.g. the partial models for chip design projects will differ from the ones in
software engineering shown earlier. Even two projects of the same domain can
have different partial models. Creating an analogue component will differ from
creating a digital one. A project with the aim to design a mixed-signal chip will
need additional partial models compared to a project, where a digital chip without
analogue components is developed. In software development distinct ontologies
are needed addressing the particular programming languages used for the
implementation. Therefore, the Permeter architecture can be divided into two
parts, a domain and project independent core implementation and the domain
specific plug-ins that are used to configure the partial models, metrics, and
customized reports.
Permeter Rich Client
Analysis
View
ProductModel
View
Report
Engine (BIRT)
Metric
Engine
Metrics (XML)
ProjectModel
View
Ontology
Core
Reportdesigns (XML)
Report
Editor (BIRT)
Metric Editor
Modell
Repository
Domain-Specific
Plug-Ins
Extensions
Figure 7: Permeter Architecture
Figure 7 shows the architecture of the Permeter framework and its three main
views.
The central view and therefore the first main function of Permeter is the Product
Model View. This view offers the functionality to create an integrated product
model, representing the current status of the product under development.
For each partial model, a conceptual ontology (t-box) is defined that is located
online. In a specific project, the a-box is filled with corresponding instances, e. g.
directly from an ontology or via an implemented transformation process.
To establish links between artefacts of different partial models, Permeter offers a
specific editor as well as automatic linkage prototypes as described in ‘Integrating
Partial Product Models’ above. The partial model-spanning semantic web
established by these relations offers an overview of the process not previously
available. Dependencies and interrelations between artefacts are made apparent.
Thus, surveillance, control and management of development processes can be
greatly improved.
© IBIS – Issue 5(2), 2007
http://www.ibis-journal.net ISSN:1862-6378
IBIS Issue 2(2), 2007
The second important view supplied by Permeter is the Project Management View,
depicting the organizational context of the development project. Here, all tasks,
milestones and costs are collected and integrated with the product view. By
semantically bridging the technical and the organisational perspectives, the
derivation of KPIs into a “project cockpit” is made easier and founded on accurate
measures directly derived from development results.
The third main functionality of Permeter is therefore the analysis of the collected
data to achieve this improvement. Like partial models, reports and especially
metrics are only applicable to specific domains. It is even possible that some
metrics are important to one company and uninteresting to another one. For this
reason Permeter has a metric engine that can run metrics in a defined XML format
and a visual editor to create metrics.
Only base component metrics like math operators (addition, multiplication, etc.) or
instance/concept counters are directly implemented. These components can be
combined to metrics stored in a XML file. It is also possible to combine previously
defined metrics to new ones. The implemented base components, the derived XML
metrics and the relations between them are modelled in an ontology, which is used
by the editor to decide which combinations are valid and which are not. This
metric concept is a flexible approach to create domain specific metrics in a quick
and easy way.
In using the report system BIRT (Business Intelligence and Reporting Tools) it is
possible to aggregate and visualise results from executed metrics. The system
comes with a report designer that allows a free definition of reports and metrics
that serve as input for the defined reports.
Applying Permeter in Software Engineering
Besides Automotives and Chip Design, Software Engineering is the third domain
specific derivation available for Permeter. Here, one idea particularly stands to
reason: to examine the development of Permeter using the tool itself. We present
this evaluation as a case study here, mainly because it allows the illustration of the
methodology while reusing the concepts and the wording introduced in the above
sections.
In order to facilitate the case study, special care and emphasis has been laid on the
early phases of the development, i.e. the creation of requirement and functional
models. Due to the fact that the designers of Permeter are familiar with the
modelling of ontologies, requirements and functions have been represented
directly as OWL instances. Thus, their import to Permeter is straight forward. This
does not imply that Permeter cannot be used by other projects. Transformations
for requirement and functional models defined in other formalisms are available.
In the next step, three additional partial models were transformed and integrated:
the UML conceptual model, the Java source code and the JUnit test cases. Using
the matrix browser and the automatic mapping tooling provided by Permeter, the
five partial models were interconnected. This procedure was repeated weekly on
every Friday. Figure 9 shows relations inside the Permeter Java implementation
(here: the metric engine plug-in) by means of the Matrix Browser. The creation
date of this integration model capture is August 3rd 2007.
© IBIS Issue 2 (2), 2007
IBIS – Interoperability in Business Information Systems
Figure 9: Permeter Java implementation shown by the Matrix Browser
In the integrated product model, formally implicit relationships were made
explicit. Taking the requirements as root nodes, relation trees were spanned
reaching via functions, conceptual elements, source code entities to test cases.
Each test case in turn provides information on its status, e.g. whether it had the
expected result or whether it failed to run, which was used to infer the project’s
requirements fulfilment status. Obviously, this measure is profoundly improved
compared to its former definition that relayed on a simple, manual flag denoting a
requirement as (not) fulfilled. Similarly, other metrics concerning complexity of
design and implementation were improved respectively became applicable by the
integration of the partial models. As Permeter development is work in progress the
reports derived are not yet ready to be published. We will put more emphasis here
in future papers.
In a nutshell, the case study showed that Permeter is able to measure a project’s
progress and to increase the predictability of product development.
© IBIS – Issue 5(2), 2007
http://www.ibis-journal.net ISSN:1862-6378
IBIS Issue 2(2), 2007
Conclusion
The examination of development processes has shown that a great number of
development methods are suited to solve specific problems but fail to act as a
generic approach to understand and model the many interactions between domains
and partial models. This deficit is addressed by the proposed ontology-based
framework for integration and evaluation of development results. Its advantages lie
in the generic approach, the expandability, the use of semantics instead of data
models and the definition and use of metrics with the GQM-method. The
applicability of the framework is demonstrated with the Permeter tool which is a
work in progress at the University of Oldenburg.
Further research will consist of creating more appropriate metrics and applying
Permeter to real world-projects. The authors will cooperate with product
developing companies both in the chip design and in the automotive area.
Accompanying their activity, an assessment of the methodology and the prototype
implementation will be performed based on context-driven metrics and feedback
from the companies’ experts.
References
[Aka04]
Akao, Y.: QFD-Quality Function Deployment. 2004.
[And05]
Andy Neely, M. G. K. P.: Performance measurement system design: A literature
review and research agenda, pp. 1228-1263, 2005.
[Aut05a]
Automotive SIG: Automotive SPICE Process Reference Model. 2005.
[Aut05b]
Automotive SIG: Automotive SPICE Process Assessment Model. 2005.
[BR88]
Basili, V.R.; Rombach, H.D.: The TAME Project: Towards Improvement-Oriented
Software Environments. IEEE Transactions on Software Engineering, Vol. 14, No. 6.,
pp. 758-773. June 1988.
[Bal00]
Balzert, H.: Lehrbuch der Softwaretechnik. 2000.
[Bec03]
Beck, K.: Extreme Programming. 2003.
[Boe88]
Boehm, B. W.: A Spiral Model of Software Development and Enhancement. In
Computer, Vol.21, No.5 pp. 61-72, 1988.
[Bul98]
Bullinger, H.: Concurrent Simultaneous Engineering Systems. The Way to Successful
Product Development, Springer, 1998.
[Car06]
CarnegieMellon Software Engineering Institute: CMMI® for Development, Version
1.2. 2006.
[EE03]
Ehrig, M.; Euzenat, J.: State of the Art on Ontology Alignment. Knowledge Web
Deliverable 2.2.3, University of Karlsruhe, 2004.
[Ehr03]
Ehrlenspiel, K.: Integrierte Produktentwicklung. 2003.
[ESS05]
Ehrig, M.; Staab, S.; Sure, Y.: Bootstrapping ontology alignment methods with
APFEL. 4th International Semantic Web Conference (ISWC-2005), 2005.
© IBIS Issue 2 (2), 2007
IBIS – Interoperability in Business Information Systems
[FP97]
N. E. Fenton, S. L. Pfleeger, Software Metrics - A Rigorous and Practical Approach
Second Edition, PWS Publishing Company, 1997.
[GHK+06]
Gausemeier, J., Hahn, A., Kespohl, H. D., Seifert, L.: Vernetzte
Produktentwicklung. 2006.
[GRP05]
Garcia, F., Ruiz, F., Piattini, M.: Metrics for Process Models. 2005.
[HAS07]
Hahn, A.; grosse Austing, S; Strickmann, J.: Metrics – The Business Intelligence Side
of PLM, in Product Lifecycle Management - Assessing the Industrial Relevance (Hrsg:
Garetti, M. et al.), Proccedings of the PLM 07, Mailand, Indersience, Genf, 2007 .
[Hau96]
Hauser, J.R.: R&D Metrics: An Annotated Bibliography, ICRMOT Working Paper,
M.I.T., Cambridge, MA 02142 1996
[Hen97a]
Henninger, S.: Case-Based Knowledge Management Tools for Software Development.
Journal of Automated Software Engineering, vol. 4, pp. 319-340. 1997.
[Hen97b]
Henninger, S.: Capturing and Formalizing Best Practices in a Software Development
Organization. The Ninth International Conference on Software Engineering and
Knowledge Engineering (SEKE '97). Madrid, Spain. 1997.
[HDH+06]
Hörmann, K., Dittmann, L., Hindel, B., Müller, M.: SPICE in der Praxis. 2006.
[Har03]
Harmuth, U.: Erfolgsfaktoren für Projekte. 2003.
[IEE98]
IEEE: IEEE Standard for a Software Quality Metrics Methodology Institute of
Electrical and Electronics Engineers. 1998.
[JBR04]
Jacobson, I., Booch, G., Rumbaugh, J.: The Unified Modeling Language Reference
Manual. 2004.
[JBR99]
Jacobson, I., Booch, G., Rumbaugh, J.: The Unified Software Development Process.
1999.
[Jen01]
Jenne, F.: PDM-basiertes Entwicklungsmonitoring. 2001.
[Kah04]
Kahn, K. B.: PDMA Handbook of New Product Development. 2004.
[Kl01]
M. Klein. Combining and relating ontologies: an analysis of problems and solutions.
In A. Gomez-Perez, M. Gruninger, H. Stuckenschmidt, and M. Uschold, editors,
Workshop on Ontologies and Information Sharing, IJCAI01, Seattle, USA, August 4-5
2001.
[LR93]
Lott, C. M., Rombach, H. D.: Measurement-based guidance of software projects
using explicit project plans, pp. 407-419, 1993.
[Lit95]
Litke, H.: Projektmanagement. Hanser Verlag, 1995.
[McC76]
McCabe, T.J. A complexity measure. IEEE Trans. Software Engineering SE-2, 4 , 1976.
[NM03]
Noy, N.F.; Musen, M.A.: The PROMPT suite: Interactive tools for ontoloy merging
and mapping. International Journal of Human-Computer Studies, 6(59), pp. 983 –
1024, 2003.
[PGP+05]
Piattini, M., Genero, M., Poels, G., Nelson, J.: Towards a Framework for Conceptual
Modelling Quality. 2005.
[Rib00]
Ribbens, J.A.: Simultaneous Engineering for New Product Development, Wiley &
Sons, 2000.
© IBIS – Issue 5(2), 2007
http://www.ibis-journal.net ISSN:1862-6378
IBIS Issue 2(2), 2007
[Sch02]
Schaefer, O. M.: Performance Measures in Value Management. 2002.
[Sör06]
Sörensen, D.: The Automotive Development Process, A Real Options Analysis, Stuttgart,
2006.
[Som04]
Sommerville, I.: Software Engineering. 2004.
[Tha00]
Thaller, G. E.: Software-Metriken einsetzen, bewerten, messen. 2000.
[STG94]
The Standish Group: The CHAOS Report. 1994.
[ZCB02]
Ziegler, J.; Kunz, C.; Botsch, V.: Matrix Browser – Visualisierung und Exploration
vernetzter Informationsräume. Mensch & Computer 2002: Vom interaktiven
Werkzeug zu kooperativen Arbeits- und Lernwelten. pp. 373-382, Stuttgart, 2002.
About the authors
Axel Hahn is professor for
business engineering at
the
University
of
Oldenburg.
R&D
management
and
interoperability are his
research topics.
Stefan Häusler is researcher at
Institut für Informatik OFFIS
Oldenburg. His research topics
requirement
engineering
performance measurement in
design.
the
in
are
and
chip
Jan Strickmann works at
Kevin
Hausmann
is
the Porsche Research and
researcher at the Institut
Development Center in
für Informatik OFFIS in
Weissach in the process
Oldenburg.
He
is
reengineering
responsible for the core
department. His research
development
of
interests
are
in
Permeter.
performance
assessment
of
simultaneous engineering processes and
virtual prototypes.
© IBIS Issue 2 (2), 2007
IBIS – Interoperability in Business Information Systems
An Enterprise Application Integration Architecture
Supporting Ontology Based Approach for B2B
Collaboration
Razika Driouche, Zizette Boufaida
Lire Laboratory, Department of Computer Science
Mentouri University of Constantine
25000, Algeria
[email protected], [email protected]
Fabrice Kordon
Lip6 Laboratory, Pierre & Marie Curie University
4 Place Jussieu 75252, Paris
Cedex 05, France
[email protected]
Abstract: An important task in Enterprise Application Integration (EAI) is to resolve
syntactic and semantic heterogeneity. Especially difficult the latter is. Some existing
integration approaches have been criticized for their lack of semantic richness. They
focus mainly on the technical and syntactical integration. To overcome these
limitations, this paper introduces novel ontology based architecture to ensure both
sides of integration: inside Application to Application (A2A) and outside Business to
Business (B2B), in order to support larger scale of integrations.
Our proposal includes two important parts. First, we suggest an integration process
basing on mapping approach to bridge applications ontologies. Second, we introduce an
approach to build business process ontology using web services composition strategy
and an integration scenario. We also use BPEL4WS language as a specification language
for expressing business process control flow and constraints.
Introduction
Enterprise integration has gained considerable attention both from academia and
industry. Scholars as well as practitioners have emphasized that the so-called
Enterprise Application Integration (EAI) is one of the key challenges in information
technology [27]. In essence, EAI technologies provide tools to interconnect multiple
and heterogeneous Enterprise Application Systems (EAS) such as Customer
Relationship Management (CRM), Supply Chain Management (SCM), Enterprise
Resource Planning (ERP) and legacy systems. This interconnection is difficult to
achieve because integrated systems are developed independently [28].
Despite the whole range of available tools and widespread standards adoption, the
main goal of EAI, which is the semantically integration of EAS, is currently an
unsolved problem. Indeed, EAI still focuses mainly on technical and syntactical
solutions but does not address adequately the semantic problem, which constitutes
the real integration problem [28]. Most previous publications do not sufficiently
take into account the semantic integration.
© IBIS – Issue 2 (2), 2007
http://www.ibis-journal.net ISSN:1862-6378
IBIS – Issue 2 (2), 2007
Semantic integration becomes very important in order to overcome heterogeneity
within EAI and which mainly concerns data, processes and services. Heterogeneity
may appear in the use of different programming languages, availability on different
hardware and operating system platforms. Moreover, the applications will most
probably rely on different data representation that increase difficulties when
exchanging them. They do not share the same semantics for the terminology of
their applications models. So, there is a disagreement about the meaning, i.e.
inconsistent interpretations.
B2B e-commerce is emerging as trading parties attempting to integrate
heterogeneous business processes. Collaboration of partners leads to the
interoperability issue [33], which represents a major obstacle in the business
sector. Heterogeneity arises from the fact that partners do not have the same
business process models. The partners cannot collaborate directly because their
processes are completely predefined. This means that a company, which models a
predefined order and selection of a group of activities cannot integrate directly
with enterprises having different orders and selections, even this company is
willing to conform to those orders. It also means that an enterprise sending and
receiving information, disposed in a set of messages and activities, cannot match
with another enterprise that exchanges the same information in a dissimilar
aggregate of messages and/or activities [29]. A solution to the problem is to model
enterprise processes in a flexible manner to support a larger scope of B2B
collaborations that companies my conform to, without necessity for model redesign
[25].
Previous approaches to explore EAI have focused on technical and syntactical
integration. Nevertheless, they must address the semantic level which is more
difficult but provide more added-value inside (A2A) and outside (B2B) the
enterprise [2]. On the one hand, integration helps to exchange data and to unify
software components. For this purpose, ontologies are often seen as a solution
providing exchange facilities of semantically enriched information. They
encapsulate heterogeneity of integrated applications and offer common
terminology. On the other hand, integration helps to streamline business processes.
The proposed solution in the literature is to model business processes in a flexible
manner to increase ability for process matching without requiring changes in their
design.
In this paper, we propose an approach that combines ontologies and web services
in order to address the semantic integration in the context of EAI, as well as both
sides of integration. In particular, we describe the integration architecture, which
has two levels: the applicative and the collaborative ones:
In the A2A integration level, a mapping approach is introduced to bridge
applications ontologies. The architecture supports several heterogeneous
applications accessing multiple local ontologies. A component, called wrapper,
generates a global ontology for managing heterogeneity based on the semantic
bridges concept [4]. The latter encapsulates all required information to translate
instances of the source ontology to instances of the target one.
In the B2B integration level, the focus is on partners collaboration basing on ebXML
extended scenario [35][44]. We also give details of our approach for building
business process ontology using Web services composition strategy. We define two
mechanisms to manage potential composition and monitor processes execution. We
specifically argue the idea that the BPEL4WS language can be used as a
specification language for expressing business process control flow and constraints.
© IBIS – Issue 2 (2), 2007
IBIS – Interoperability in Business Information Systems
The next section outlines some important related work. Then, we describe the two
levels of the proposed architecture and present a description of the wrapper for
bridging the application ontology and its components. The following section focuses
on how to develop the application ontology and on the application integration
process. The main section of the paper gives details of business processes
collaboration. We explain the service ontology building and the business process
integration scenario based on a composition strategy of Web services. Finally, we
draw some conclusions from our work and sketch directions for some future
research.
Related work
EAI is a multifaceted field of research. It includes integration of heterogeneous
software applications, data and business processes. The integration is the process
of adapting a system to make distributed and heterogeneous applications work
together to carry out a common objective [27]. In companies, the essential
requirement for heterogeneous and distributed information systems is to be able to
exchange information and services in a semantically rich and sound way. Thus, the
semantics should be captured, verified and used to validate reliable information
exchange. This is commonly referred to as the problem of interoperability. The
integration is closely related – but not equal- to interoperability [33].
Ontologies, which seem to be a suitable technology of semantic web, are actively
used in order to deal with the semantic interoperability problem. According to
Gruber, an ontology is defined as an explicit specification of a conceptualization
[19]. Ontologies could be key elements in many applications such as the semantic
integration, web-services search and composition, and web site management for
organization and navigation [12]. Researchers do also believe that ontologies
provide a basis for enabling interoperability between software applications across
different organizations [22].
More recently, Web services have emerged with the advent evolution of the
Internet and provided a set of standards for EAI. Even if Web services are not fully
mature, they seem to become the linga franca of EAI, which makes integration
simpler and easier through using Web protocols and standards. Web services can be
used for integrating applications and processes via standards such as Business
Process Execution Language (BPEL) and Web Service Flow Language (WSFL) [24].
Furthermore, some new integration products are based on Web services such as
Cape Clear, XML Global, Colloxa, BPEL4WS Java Runtime (BPWS4J), etc. [31]. Even
if Web Services are promising to solve the integration problem, they do not
correctly address the semantic aspect supported by UDDI annuaire with the help of
some standards, like North American Industrial Classification Scheme (NAICS) [36]
and UNiversal Standard Products and Services Classification (UNSPSC) [3].
As a consequence, the combination of Web service technology with Semantic Web
technology will make EAI dynamically possible for enterprises of all types and sizes,
unlike the traditional technologies [35]. In addition, enterprise integration will
become more reliable and easier to achieve without the tedious low-level
implementation problems.
In the context of application and process integration, some important initiatives
that aim to bridge the gap between Web services and ontologies have been taken.
© IBIS – Issue 2 (2), 2007
http://www.ibis-journal.net ISSN:1862-6378
IBIS – Issue 2 (2), 2007
OWL-S [38] provides an ontology mark up language to describe semantically
capabilities and properties of Web services. The ESSI WSMO working group, part of
the ESSI cluster aligns the research and development efforts in semantic Web
Services between the SEKT, DIP Knowledge Web and ASG research projects. This
group aims at developing a language called Web Service Modeling Language (WSML)
that formalizes the Web Service Modeling Ontology (WSMO) [39]. Both efforts
introduce for example the notions of process and Web Service composition to
describe behavior. Whereas, OWL-S has a process model. WSMO, in contrast,
distinguishes orchestration (problem solving through Web service invocation) from
choreography (communication pattern through message exchanges) [3]. More over,
there are differences: WSMO proposes the explicit representation of goals and
capabilities for dynamic discovery. In addition, data and process mediation are
explicit concepts applied by Semantic Web services to overcome the heterogeneity
problem.
As Web services become ubiquitous, there are few current efforts to define a
coherent model to compose them and build business processes. Some service
composition models have been proposed [1, 12] based on ontologies of services (for
sharing semantics of data/information), dynamics of component services (i.e.,
behavioral features, complex forms of dataflow, transactional attitudes,
adaptability to varying circumstances) and dynamic of the target service.
Papazoglou et al. [12] describe manual composition of services by specifying
composite service using the service scheduling language and the service
composition execution language. Bouguettaya uses services as atomic actions which
are semantically described in terms of their I/O interfaces and non-functional
properties such as their purpose, their category and their quality [1]. In Knoblock
work [8], services are modelled as views over data source. Each service is
represented in terms of I/O parameters, binding patterns and additional
constraints in the source. The composition of Web services may be developed using
a specification language such as BPML [24], BPEL [30] and BPEL4WS [29], WSCI
(Web Service Choreography Interface) [30], etc and executed by an engine such as
BPWS4J [14].
What has not yet been addressed by these work is the development of a
methodology for designing an actual integration scenario like travel planning or
goods purchasing.
The contribution of the proposed work lies in a comprehensive approach to flexible
modeling inside (A2A) and outside (B2B) integration. The work is based on
ontologies and Web services composition to ensure greater interoperability.
Ontologies offer the semantic aspects to exchange data and to unify terminology in
the models of applications. Web services can encapsulate heterogeneity in business
processes and their composition provides a flexible manner to support a larger
scope of B2B collaboration. Business processes are described by building service
ontologies and composition strategy. The latter focuses on a composition schema
managed by two mechanisms. The first one is the composition manager, which
establishes a classification of the potential compositions according to
organizational constraints and client requests. The second one is the supervisor
mechanism, which is the core of the composition schema. It monitors the process
execution engine in order to control constraints and handle possible exceptions.
The BPEL4WS language is used as a specification language for modeling business
process.
© IBIS – Issue 2 (2), 2007
IBIS – Interoperability in Business Information Systems
Application integration architecture
Within our ontology architecture, we identify several types of legacy, client/server
and Web applications, developed using different programming languages. They
work on different operating system platforms and use various format for the
exchange of data. Ontologies allow to heterogeneous and distributed systems to
interoperate seamlessly with each other. They are mainly used to provide
interaction between applications and also between applications and users. For
example, they enhance the invocation of application systems or the expression of
data and processing queries that can be defined by the user.
The integration system we propose aims at offering a support for integrating
heterogeneous and distributed applications, and accessing multiple ontologies
(Figure.1). It provides a communication framework as a central service. It permits
an appropriate exchange of information between applications ontologies and
generates the global one using mapping process for managing heterogeneity. The
integration process is based on the semantic bridges to indicate the semantic
equivalence of ontology entities for assembling them.
Figure 1: Integration system architecture.
Furthermore, we give an overview about the two-levels for application integration,
the application and the collaboration levels.
© IBIS – Issue 2 (2), 2007
http://www.ibis-journal.net ISSN:1862-6378
IBIS – Issue 2 (2), 2007
The application level consists of heterogeneous, autonomous and distributed
application systems, where each application has its local ontology. The
application ontologies are related to each other with a global ontology. In the
architecture, we aim at overcoming the gap between application ontologies,
according to the semantic relations. A special component, named wrapper, is
invoked to perform its tasks for building the global ontology. The latter can be
seen as the enterprise ontology and permits the resolution of semantic conflicts
in both concepts and properties.
• The collaboration level takes place in the business process collaboration with
partners. Each company has a mobile agent that is responsible of requesting,
providing the services and the negotiation for selecting the best partner basing
on criteria (e.g., price limits, product configurations or delivery deadlines). It
uses an ebXML extended collaboration scenario for achieving business process.
The mobile agent permits to perform the integration tasks according to process
ontology and using optimized itinerary. The latter improves the quality of the
system and reduces the response time. EbXML extended scenario is based on the
integration of agent paradigm to guarantee a saving of search time, to
negotiate business parameters and to offer a great performance, especially in
the presence of the characteristic of mobility which, solves problems related to
the networks while decreasing consumption in resources. We have used jbuilder
(version X) language and Jade plateform to implement the extended
scenario[44].
Additionally, an overview about the wrapper component is given in the following.
The main task of the wrapper is to find semantic relations between concepts of
application ontologies and reuse mapping information for communication. It is
composed of four parts:
•
•
•
•
•
The identifier is used to find related concepts or attributes of ontologies and
the relations between them. This can be done automatically, semiautomatically or manually with the help of domain experts. For instance, it can
use lexical ontologies such as WordNet or domain specific thesaurus to define
synonym terms, antonym terms and encoding (e.g. miles/kilometers,
Fahrenheit/Celsius, hours/minutes) [4].
The adaptor is used to represent the identified relations of equivalence
between ontologies based on the semantic bridges. It combines many algorithms
to measure the similarity. It adopts a multi-strategy approach to compute the
concepts similarity at various levels, such as lexical, properties (roles and
attributes), hierarchical and instances similarities. Then, the adaptor checks
the domain and the cardinality inclusion.
The linker transforms instances from the source application ontology into
instances of the target application ontology by evaluating the equivalence
relations defined earlier by the adaptor. Two problems that may arise are that
the mappings are incomplete or the that the mapped entities differ in the
context. The missing mappings can be gained through inference mechanism.
The communicator is used to enhance the communication between global
ontology (enterprise ontology) and local ones (application ontologies). It is
responsible for information exchange to answer the user’s request using the
appropriate mapping. It translates the query sent by the user to an equivalent
one. This is done by using the mapping information in order to facilitate the
© IBIS – Issue 2 (2), 2007
IBIS – Interoperability in Business Information Systems
query interpretation, according to the concepts of the concerned application
ontology.
Application ontology integration process
The application integration process based on ontologies is a new approach that has
rapidly been developed with the emergent semantic web [36]. This is mainly due to
the fact that actually, the ontology provides a basis for enhancing interoperability
and integration of heterogeneous applications. The proposed iteration process for
integrating applications considers the addition of a new application and the
evolution of company requirements and market criteria. The process is divided into
four basic steps: capturing, building, integrating and exploiting.
The suggested process includes two sub-processes, essential for building and
integrating ontologies. The first one shows how to develop the application
ontologies. It includes many steps from meta-modeling to implementation. The
second one presents how to integrate application ontologies, starting from
collecting the applications needs and ending to a global ontology.
Capturing requirements
A company model is a computational representation of the structure including,
activities, processes, information, resources, people, behavior, goals and business
constraints. This step consists of taking information about the field of integration
while identifying the applications behavior as well as the relations which they
maintain between them. The goal is to capture the sets of the enterprise
applications, the activities that they perform, the required resources, the
manipulated data and the invoked messages. Then, we identify the information
flow, their structure and the technical infrastructure to support them for building
the application ontologies. This step is carried out by the industrial specialists and
domain experts.
Building the application ontology
A range of methods and techniques have been reported in the literature regarding
ontology building methodologies [15, 26]. Mike Uschold’s methodology [16],
Michael Grüninger and Mark Fox’s methodology [17] and Methontology [18] are the
most representative. Grüninger methodology is only limited to ontologies using
first-order-logic languages [17]. Uschold’s and Methontology have in common that
they start from the identification of the ontology purpose and the need for
knowledge acquisition. Whereas Uschold proposes a knowledge codification in a
formal language, in Methontology a set of independent intermediate
representations of the formal language to be used is expressed.
For our purpose, we use UML class diagram [41] to represent the meta-model
application ontology. In this purpose, the ontology building process contains all the
tasks to develop the application ontology based on the information identified in the
previous step. It consists in a classification of relevant applications characteristics
© IBIS – Issue 2 (2), 2007
http://www.ibis-journal.net ISSN:1862-6378
IBIS – Issue 2 (2), 2007
whereby each categorized class is linked with associated information. Then, the
formalization implies the representation of the ontology in a formal language. The
implementation builds computable model and checking consistency. Our building
process contains four steps: meta-modeling application, formalization,
implementation and adaptation [45].
Meta-modeling application
Let us notice that we retain the logical structure in layers where each application
is made up of data, activities and a user interface. The concepts of the application
ontology are represented as a set of UML class diagrams (Figure 2). Ontologies
include class/subclass hierarchies, relationships between classes, class attribute
definitions and axioms that specify constraints. This information is usually modeled
in a class diagram (the reason why UML is a promising notation for ontologies). Our
ontology makes it possible to offer an intelligent layer to manage semantics
heterogeneity in the integrated applications.
The meta-model in figure 2 illustrates the principle of the deployed ontology. It
specifies the activities called upon by messages (coming/outgoing), using resources
and manipulating data. The handling data are represented by schemes. Each
application has a behavior represented by links. The application properties (level,
link-type, data and activities) are made up of a certain number of concepts. Each
concept is described with properties, axioms, types and semantic relations
connecting the concepts between them. These relations can be relations of
aggregation, composition or synonymy. The axioms make it possible to capture
more complex rules on the concepts. These relations and axioms will enable us to
solve the conflicts related to semantic heterogeneity.
Figure 2:
Meta-model of application ontology.
The domain ontology gives a formal representation of concepts of the studied
domain as well as their relations. However, the domain ontology cannot describe
specific functionality neighter the differences between applications. It attempts to
© IBIS – Issue 2 (2), 2007
IBIS – Interoperability in Business Information Systems
find the set of concepts covering the domain. In our work, we consider business
enterprises which provide products and services for partners and potential
customers. We identify two overlapping domains, sale and purchase.
Let us give a description of the application ontology concepts, which is a 13-tuple:
Application Ontology = (APPLICATION, ACTIVITY, DATA, SCHEME, RESOURCE,
MESSAGE, LEVEL, LINK-TYPE, CONCEPT, RELATION, TYPE, AXIOM,
PROPERTY )
We give a semi-formal description of concepts in the UML class diagram. We create
the concept dictionary according to Methontology [18]. In this dictionary, we
define for each concept: synonyms, instances, attributes, roles. Table 1 represents
a concept dictionary for the application ontology.
The binary relations are showed as properties, which relate a concept to another.
For each role, we define its name, the name of the source concept, the name of
the target concept, the cardinality and the name of the inverse role. Table 2
represents a role table for the application ontology. Example: manipulates
(Activity, data) shows that the relation manipulates connects an activity to its
data.
Concept
name
APPLICATION
Synonyms
Instances
Attributes
PROGRAM
SOFTWARE
Sale
Marketing
Application-name
Application-profile
Application-domain
Application-behavior
ACTIVITY
FUNCTION
SERVICE
Request quote
Check stock
Invoke
purchase
Balance cash
Delivery article
DATA
PARAMETER
INPUT/OUTPUT
SCHEME
RESOURCE
DESCRIPTION
REQUIREMENT
NEED
Customer
Invoice
product
XML-shema
Memory
CPU
MESSAGE
QUERY
Activity-name
Activity-type
Precondition
parameters
Sub-activities
Time-begin
Time-end
Resource-assigned
postcondition
Data-name
Data-type
Access-right
Schema-name
Resource-name
Resource-type
Resource-state
Message-id
Message-content
communication-mode
Level-name
LEVEL
LINK-TYPE
..
MySQL Request
OWL API
-
How
relevant?
Compulsory
Important
Important
Important
Compulsory
Important
Important
Important
Important
NicetoHave
NicetoHave
Important
Compulsory
Important
Compulsory
compulsory
Compulsory
Important
Important
Compulsory
Important
Important
Compulsory
Applicative
Collaborative
CONNECTION
Data-exchange Link-name
Compulsory
Service-sharing
collaboration
..
..
..
..
Table 1: Concepts dictionary for the application ontology.
© IBIS – Issue 2 (2), 2007
Roles
from-a
to-a
has-type
is
composed
participates
..
in
out
is
manipulates
assigned to
composed
represented
manipulates
represented
assigned to
in
out
participates
has-type
..
http://www.ibis-journal.net ISSN:1862-6378
Role name
Source concept
composed
represented
is
manipulates
assigned to
from-a
from
has-type
participates
in
has-p
..
APPLICATION
DATA
APPLICATION
ACTIVITY
ACTIVITY
APPLICATION
CONCEPT
APPLICATION
APPLICATION
ACTIVITY
CONCEPT
..
Source
cardinality
1..N
0..N
1..N
0..N
0..N
1..1
0..N
0..N
1..1
0..1
1..1
..
Target concept
DATA
SCHEME
ACTIVITY
DATA
RESOURCE
APPLICATION
RELATION
LINK-TYPE
LEVEL
MESSAGE
PROPERTY
..
IBIS – Issue 2 (2), 2007
Target
cardinality
0..N
1..1
0..N
0..N
1..N
1..1
0..N
1..1
0..N
0..N
0..N
..
Inverse role
belongsto
describes
refers-to
manipulatedby
usedby
to-a
to
hasbehavior
indicates
out
concerns
..
Table 2: Roles description for the application ontology.
Let us remark that starting from the class diagram, the instantiation will vary
according to the application. In particular, each application has its activities and
its data. For example, a sale application contains activities as: receive order goods,
check availability, invoke purchase, make payment, delivery goods and
manipulates data as: customer, product, supplier, invoice.
Formalization
A standard framework for representing ontological knowledge is the theory of
Description Logics (DL). DL forms a language family of knowledge representation. It
allows to represent knowledge relating to a specific area using "descriptions" which
can be concepts, relations and instances. We consider the SH [9] family [13], which
includes the SHOIN(D) DL, extension of the influential SHOQ(D) DL. Ontology Web
Language (OWL) [38] is equivalent to SHOIN(D), i.e. SHOIN(D) is a syntactic variant
of OWL DL.
Formalization consists of two parts: terminological language TBOX in which
concepts and relations are defined; and an assertion language ABOX in which we
introduce the instances.
• TBOX construction: Here, we define here domain concepts and roles by means of
constructors provided by DL. For example, an activity must have one and only one
name. it refers to an application. It manipulates data to which a resource is
assigned. It reacts to incoming messages and produces an outgoing message to
send the response.
(∃ Activity-Name.String) ∩ (=1 Activity-Name.String) ∩ (≥1 Manipulates.Data )
∩ (≥1 Assignedto. Resource) ∩ (≥1 Refers-to.Application) ∩ (=1 In.Message) ∩
(=1 Out.Message).
Moreover, we specify subsumption relations which exist between various concepts;
for example to specify that the Activity class is subsumed by the Application class
we write: ACTIVITY ⊆ APPLICATION (cf. table 3).
• ABOX construction: The assertion language describes facts, by specifying the
instances (with their classes) and the relations between them in the following
way:
© IBIS – Issue 2 (2), 2007
IBIS – Interoperability in Business Information Systems
a: C
to indicate that a is an instance of class C.
Example: Sale-product: APPLICATION.
(a1, a2): r to indicate that the two instances a1 and a2 are connected by the role
r. Example: (Make-payment, Invoice): manipulates.
Concept
Definition
APPLICATION
(∃ Application-Name.String) ∩ (=1 ApplicationName.String) ∩ (≥1 is. ACTIVITY ) ∩ (≥1
Composed.DATA)∩ (=1 Participates.LEVEL)
∩ (≥1 Has- type.LINK-TYPE)∩ (=1 Froma.APPLICATION)∩(=1 From-a.APPLICATION)∩ (≥1 Is.
CONCEPT) .
(∃ Activity-Name.String) ∩ (∃ Activity-Type.Thing) ∩ (=1
Activity-Name.String) ∩ (=1 Activity-Type.Thing) ∩ (≥1
Manipulates.DATA ) ∩ (≥1 Assignedto. RESOURCE)
∩ (≥1 Refers-to.APPLICATION) ∩ (=1 In.MESSAGE)∩ (=1
Out.MESSAGE).
(∃ Data-Name.String) ∩ (∃ Data-Type.Thing) ∩ (=1 DataName.String) ∩ (=1 Data-Type.Thring) ∩ (≥1
BelongsTo.APPLICATION ) ∩ (≥1 ManipulatedBy.ACTIVITY)
∩ (=1 Represented.SCHEME)
ACTIVITY
DATA
Subsomption
relation
APPLICATION
THING
⊆
ACTIVITY
APPLICATION
⊆
DATA
APPLICATION
⊆
SCHEME
(∃ Schema-Name.String) ∩ (=1 Schema-Name.String) ∩ (=1 SCHEME ⊆ DATA
Describes.DATA)
RESOURCE
(∃ Resource-Name.String) ∩ (∃ Resource-Type.Thing) ∩
(=1 Resource-Name.String) ∩(=1 Resource-Type.Thing) ∩
(≥1 UsedBy.ACTIVITY )
RESOURCE⊆
ACTIVITY
MESSAGE
(∃ Message-id.String) ∩ (=1 Message-id.String) ∩ (=1 In.
ACTIVITY ) ∩ (=1 Out.ACTIVITY)
(∀ Level-Name.{ Collaborative-level, Applicative-level })
(∃ Link-Name.String) ∩ (=1 Link-Name.String) ∩ (=1 HasBehavior. APPLICATION )
..
MESSAGE
⊆
ACTIVITY
LEVEL ⊆ THING
LINK-TYPE
⊆
THING
LEVEL
LINK-TYPE
..
..
Table 3: Concepts definition for application ontology in TBOX.
Implementation and test
The implementation deals with building a computable model using the appropriate
language. The effort is concentrated on the suitability of OWL DL [9], which is
equivalent to SHOIN(D) [42]. For checking, we use the inference services provided
by many systems such as FACT [9], Renamed Abox and Concept Expression Reasoner
(RACER) [10] and DLP [9]. The RACER system can read OWL files, convert them in
the form of DL knowledge bases and provide inference services.
Protégé-OWL [21] is an open source ontology development environment with
functionality for editing classes, slots (properties) and instances. The current
version of Protégé (3.1.1) [21] is highly extensible and customizable. We have used
it for developing the application ontology. We also base on Protégé-visualisation
plug-in to browse the ontology and ensure its consistency. The visualisation is
particularly helpful when trying to understand hierarchical relations.
© IBIS – Issue 2 (2), 2007
http://www.ibis-journal.net ISSN:1862-6378
IBIS – Issue 2 (2), 2007
Adaptation and evolution
Ontologies may change over time or may be adapted for application specific needs.
Therefore, mechanisms are required to discover changes and recognize different
versions (e.g. OnToKnowledge [7] or PROMPT [6]). Ontology versions may not be
compatible with each other. So, explicit information must be available to indicate
compatibility (backward, upward, full compatible, incompatible). OWL provides
some built-in constructs to mark version compatibilities.
For managing the evolution of ontology, a classification takes place once a
definition of concept is newly created. For this purpose, we propose the use of the
DL classification algorithm [11].
Integration of application ontologies
In order to achieve an ontology-based semantic integration, we propose a subprocess that includes several main tasks: comparison, bridging and inferencing.
•
The comparison allows to compare concept A in source ontology with concept B
in target ontology and to determine metric similarity. We adopt a multistrategy process [4] which computes similarities between ontology entities using
different algorithms. Using just one approach is unlikely to achieve as many
good mapping candidates as one; so, we combine several approaches. The first
one focuses on acquiring a lexical similarity. The next step computes the socalled property similarity that is responsible for acquiring the similarity
between concepts based on their properties, either attributes or relations.
Then, we propagate the similarity to other parts of the taxonomy, the super
and the sub-concepts. Finally, we check the domain and the cardinality
inclusion.
•
The bridging is responsible for establishing correspondence between entities
based on the similarities computed previously. Each instance represented
according to the source ontology is translated into the most similar instance
described according to the target ontology. It intends to associate a
transformation procedure to the translation.
•
The inference mechanism is used when the source concept has not a target
concept. It means that the source concept does not have a direct counterpart in
the target ontology. For example, the concept 4-stars room may differ between
several tourism information systems. Differences in the context can be solved
by making plausibilityn and consistency checks on the data. For example, the
concept 4-stars room differ between several Tourism Information System (TIS).
According to the given facilities of the room, one TIS may categorize the room
as 4-stars another TIS only as 3-stars because of the lack of certains services
[7].
© IBIS – Issue 2 (2), 2007
IBIS – Interoperability in Business Information Systems
Exploitation
This step deals with the realization of the computational model of integration,
which makes it possible to link the enterprise applications. Once the system is
deployed, what remains is to maintain the technical infrastructure of integration.
Furthermore, this step covers the exploitation of the integration system which
function is not limited by time. It is necessary to address the evolutions of the
enterprise (e.g. integration of a new application) and to manage the ontology
versions.
In the next section, we outline a description of collaborative level for assessing B2B
integration. One objective of our business process model is to investigate and
assess the B2B collaboration level. As discussed in the introduction, close
integration may well reduce flexibility and agility of the enterprise to work with
other business partners. For this purpose, enterprises must react to the raised
innovation pressure and facilitate flexible collaboration on a global scale by
aligning their business processes. Thus, B2B collaboration is closely related to A2A
integration. Additionally, more details about business collaboration is given in the
following sections.
Business collaboration
Business enterprises are organizations that perform collective work. In order to
achieve necessary operational efficiencies, the work need to be governed by
processes that define the flow of work throughout the organization. According to
Coase [43], the exitence of the enterprise itself is dependent upon its ability to
achieve internal transactional. Unfortunately, enterprises cannot achieve every
need internally because, at some point, the overhead burden of these operations
exceeds their abilities. When this occurs, organizations form partnerships and
collaborative agreements with one another.
The field of investigation is referred to as collaborative business between partners.
It describes the internet based interlinked collaboration of all participants in an
added value network from the raw material supplier to the end consumer [32]. It
allows a comprehensive information exchange between employees and even
between organizations.
In the next section, we describe the business process modeling views. Then, we
focus on service ontology building and business process integration scenario.
Business process flexible model
Compared to traditional business processes, the complexity of inter-organizational
processes has risen considerably as a result of the strategic, structural and cultural
differences between the partners. The allocation of performances and resources of
the business partners, the determination of responsibilities for materiel and
financial exchange relationships, as well as the information and data exchange over
interfaces have to be planned and coordinated. Thus, the demands on Business
© IBIS – Issue 2 (2), 2007
http://www.ibis-journal.net ISSN:1862-6378
IBIS – Issue 2 (2), 2007
Process Management (BPM) increase [32]. Finding consensus between the different
partners is considerably facilitated by a general approach. It encompasses the
common model of a collaborative business process [5].
On purpose of process specification, the model takes into account the process
profile description. It specifies what the process does and how to invoke its
functionalities besides the process requester perspective, associated with a
particular partner and operating in a business context with special organizational
constraints, that specify which collaboration scenario is require. The model
considers business collaboration, functional, organizational and technical aspects.
•
•
•
•
The business collaboration view defines the choreography of the business
collaboration and the structure of exchanged information. A business
collaboration is performed by two (binary collaboration) or more (multi-party
collaboration) partners. It might be complex involving a lot of services between
business partners. However, the most basic collaboration is a binary one
realized by a requester from one side and a provider from the other side.
The functional view describes the business process profile. It shows the process
structure: the sets of services, I/O parameters, execution order and
participated partners.
The organizational view refers to collect information about partners and
organizational constraints in order to specify the business context. For this
purpose, the business process must be defined in the exact business context
that means the execution scenario used in its organization.
The technical view monitors the process execution based on partners goals. The
control flow is the most important aspect for describing a business process at
runtime. The collaborative partners have to compare the results of the
execution continuously with their goals and adjust deviations by handling
exceptions.
In our approach, functional aspects are used to build the business process ontology
and to permit process discovery on the basis of partner needs. Organizational
aspects are exploited to give the appropriate business context and further to
improve the process execution according to the business collaboration scenario and
control flow aspect in technical view.
Building the service ontology
A service is mainly described by a set of operations and I/O parameters providing
by the service interface description. Pre and post-conditions are stated on each
single operation and on the whole service. They are logical expressions on I/O
entities. They must be verified before the execution of an operation, or of the
service, and must be satisfied after the execution.
For example, a selling service may require as a precondition a valid credit card and
as input the credit card number and the expiration date. As output, it generates a
receipt and as post condition the card is charged. Further characterization of
service regards the order in which the operations are performed. Then, we define
what messages the service reacts and what messages the service produces.
Moreover, services maintain relations between them such as semantic ones
© IBIS – Issue 2 (2), 2007
IBIS – Interoperability in Business Information Systems
(synonymy, specialization, aggregation …) and conjunctural ones (localization,
composition, exchange, ...).
A service ontology is a 9-tuple consisting of :
Service
ontology
=
(SERVICE,
SERVICECLUSTER,
SERVICEPROFILE,
SERVICERESOURCE,
SERVICEMESSAGE,
SERVICEPARTNER,
SERVICELOCATION, SERVICEQUALITY, SERVICEEXCEPTION )
In our approach, the service ontology aims to define the semantic of services
composing the business process. In our work, three types of service are identified.
Atomic service: It is an elementary service directly invocable. It is the
description of the service proposed by the provider. It is described in terms of
interface (input, output, operations, error parameter and message types),
behavior, quality and implementation properties. In our ontology, we study the
description of atomic services to establish semantic relations between them and
to group them into sets (cluster) of similar services.
• Composite service: It represents a cluster of similar atomic services. This is
generally appropriate within large and complex enterprises with several
different business domains (production, marketing ...). Three kinds of relations
between composite services are considered. The is-similar relation holds when
a composite service has the same operations as another one. The is-equivalent
relation is maintained when the two considered services have the same
preconditions, inputs, operations, outputs and post-conditions. The is-part
relation is viewed when a composite service includes the other.
• Domain service: It is a composite service enriched with organizational
properties. They are augmented with information about provider/requester
partners, time availability, causality constraints, synchronization and the
manipulated objects: resource, inventory, orders and products. Three kinds of
relations between domain services are considered. The has-same relation holds
when a domain service has the same business domain as another one. The iscomplement that is obtained when the execution of a domain service implies
the execution of the other. The is-independent relation shows that two disjoint
services.
According to the presented service model, we develop a methodology to build the
service ontology, articulated in four phases: identification, description, mapping
and clustering.
•
Identification of concepts and roles
In this phase, the service characteristics are identified as concepts with properties
(roles and attributes), which are represented in table 4. Specific concepts of
services such as profile, cluster, resources, messages and partners are integrated in
the service ontology. How relevant means the importance of the concept in the
system (Important, Compulsory, NicetoHave). Table 5 shows the source and target
concept, source and target cardinality and the inverse role for each role.
© IBIS – Issue 2 (2), 2007
IBIS – Issue 2 (2), 2007
http://www.ibis-journal.net ISSN:1862-6378
Concept name
Synonyms
Instances
Attributes
SERVICE
FUNCTION
METHOD
Checkavailability
Invokepurchase
Makepayment
ServiceID
ServiceState
ServiceType
IsSimilarTo
How
relevant?
Compulsory
Important
Important
Important
SERVICECLUSTER
SERVICEGROUP
-
ClusterID
NumberOfServices
Compulsory
NicetoHave
SERVICEPROFILE
SERVICEDESCRIPTION
-
ServiceOperation
ServExeOrder
ServInput/Output
ServicePre/Post
Important
Important
Important
Important
SERVICERESOURCE
SER-REQUIREMENT
SERVICE-NEED
-
SERVICEMESSAGE
SERVICEINVOCATION
-
SERVICEPARTNER
COMPANY
SUPPLIER
-
ServiceResourceID
ServiceResourceType
ServiceResourceURL
MessageID
MessageContent
ProviderPartner
RequestorPartner
..
Compulsory
NicetoHave
Important
Compulsory
Important
NicetoHave
NicetoHave
..
..
..
..
Roles
issimilar
belongstocluster
containsservice
describes
hasserviceprofile
usedbyservice
reactstomessage
..
belongstocluster
containsservice
..
hasserviceprofile
describes
..
useresource
usedbyservice
..
producemessage
reactstomessage
provides
requests
..
Table 4: Concepts dictionary for the service ontology.
Role name
Source concept
belongstocluster
issimilar
describes
producesmessage
useresource
..
SERVICE
SERVICE
SERVICEPROFILE
SERVICEMESSAGE
SERVICE
..
Source
cardinality
0..1
0..N
1..1
1..N
1..1
..
Target concept
SERVICECLUSTER
SERVICE
SERVICE
SERVICE
SERVICERESOURCE
..
Target
cardinality
0..N
0..N
1..1
1..N
1..N
..
Inverse role
containsservice
issimilar
hasserviceprofile
reactstomessage
usedbyservice
..
Table 5: Roles description for the service ontology.
Service description and comparison
In this work, WSDL language [3] is used to represent the structure of Web services
in terms of interface, behavior and quality properties. In this phase, atomic
services are compared on the basis of their properties to evaluate their similarity.
Semantic relationships are established among them on the basis of the performed
similarity computation. Two atomic services are grouped in the same cluster when
the weight of semantic relationships connecting them is greater than a given
threshold.
Service mapping and inferencing
In order to perform a semantic analysis of services on the basis of their own
properties, we adopt a multi-strategy process to compute similarities between
entities using different algorithms. We use the same mapping process inspired from
semantic bridge concept employed in the application ontologies. We compute
similarity basing on interface, behavior and quality properties for each source and
target service:
© IBIS – Issue 2 (2), 2007
IBIS – Interoperability in Business Information Systems
•
Interface similarity: The service interface includes the I/O entities, operations
and message types. To perform a semantic analysis of service interface, three
types of the entities similarity are distinguished. For each type, the domain
experts affect a value in the interval [0..1].
- I/O similarity refers to the evaluation of the input/output information
entities names of the two services Si and Sj, denoted by I/OSim (Ei, Ej).
Lexical ontologies such as WordNet or domain specific thesaurus are used
to define terminological relationships (e.g. synonym and antonym) for
acquiring similarity [34]. Names ni and nj of I/O entities are compared to
evaluate their degree of affinity A().
1 : ∃ at least one path of terminological relationships
in the thesaurus between ni and nj.
A (ni, , nj) =
0
: Otherwise.
We define Ei as a vector of I/O entities of service Si and Ej as a vector of
I/O entities of service Sj.
Ei = (ei1, ei2, …, eik) ⇒ | Ei |= k
Ej = (ej1, ej2, …, ejl) ⇒ | Ej |= l
I/OSim (Ei, Ej) = ∑ i,j (A (ni, , nj))/ | Ei |+|Ej|
- Operation similarity: It refers to the evaluation of the operations of the
two services Si and Sj denoted OSim(Oi, Oj) is computed by comparing their
names, their input/output information entities based on WordNet or
domain specific thesaurus. Two operations are similar if their names and
their I/O entities have affinity in the thesaurus. The similarity value of two
operations is obtained by summing up the affinity values of their
corresponding elements. OSim (Oi, Oj) value is the average of similar pairs
of operations, one from the first service and the other from the second.
We define Oi as an operations vector of service Si and Oj as a vector of
operations of service Sj.
Oi = (oi1, oi2, …, oim) ⇒ | Oi |= m
Oj = (oj1, oj2, …, ojn) ⇒ | Oj |= n
OSim (Oi, Oj) = ∑ i,j (A (ni, , nj))/ | Oi |+|Oj|
- Message similarity: It focuses on the message name and type to measure
similarity MSim(Si, Sj). Two services having the same type of received
(resp. sent) messages and their names having affinity in the thesaurus, are
similar.
The global interface similarity ISim(Si, Sj) for each pair of services is evaluated by
taking a weighted sum of I/O, operation and message similarities. Services where
interface similarity is greater than a threshold are the only ones taken into
account.
ISim(Si, Sj)= (I/OSim (Ei, Ej)+ OSim (Oi, Oj)+ MSim(Si, Sj))/3
•
Behavior similarity: It concerns the evaluation of sets of operations for
services. A service is defined as a vector S with N dimension:
S= (O1, O2, …, ON)
© IBIS – Issue 2 (2), 2007
http://www.ibis-journal.net ISSN:1862-6378
IBIS – Issue 2 (2), 2007
∀ i ∈ {1, 2, …, N}/ Oi is an operation of service S.
The behavior similarity relies on the idea of semantic bridge concept [4], which
means that for each source operation in the first vector, there is a target operation
in the second one, giving two services Si and Sj where their vectors have the same
dimension; operation oik of service Si is bridged to operation ojh of service Sj if:
1- oik and ojh have the same name;
2- oik and ojh have the same I/O parameters;
3- oik and ojh have preconditions (resp. postcondition) logically equivalent.
This means that the two operations are equivalent.
We can now extend the definition of semantic bridge to two services. Two services
are bridged if there is a bijective relation between their associated vectors. Each
operation in the one service must be compatible with a corresponding operation in
the other service.
When the source operation does not have a target operation, this means that the
source operation does not have a direct counterpart in the target vector. For
example, if an enterprise sends a purchase order and receives the confirmation as
one single operation in the service, it cannot match with another enterprise that
sends order and receives confirmation as two separate operations in another
service. For this purpose, the source operation can be bridged with the composition
of the two target operations.
Quality similarity: Each service is characterized by a set of quality parameters
provided by available classification standard (for example, ISO 9000 STANDARD).
Some services may be very good, reliable and quick to respond; others may be
unreliable, sluggish, or even malevolent. Specific application dependent quality
parameters are considered (for example, the number of credit cards accepted
by an on-line ticket reservation service). Each quality parameter is described by
means of a type, a metric and a predicate. Quality type means quantitative and
qualitative feature of parameter. The metric indicates the measure unit (e.g.
second …). The predicate is a logical expression (e.g. response time < 1s). The
quality similarity of the two services Si and Sj denoted QSim(Si, Sj) is evaluated
by comparing their properties. Si and Sj have similar quality iff:
1- Si and Sj have the same type;
2- Si and Sj have the same metric;
3- Si and Sj have predicates logically equivalent.
•
Finally, global similarity GSim for each pair of services Si and Sj is evaluated by
taking a weighted sum of ISim(Si, Sj), BSim(Si, Sj) and QSim(Si, Sj). Only services
where similarity is greater than a threshold are considered.
The inference mechanism is used when the service does not have a similar service.
That means the service does not belong to any cluster.
Service clustering and classifying
The result of similarity-based description is a set of clusters of similar services with
defined similarity relationships. A hierarchical clustering algorithm [40] is used to
determine clusters based on global similarity established among services. Some
problems appear, when the service exists in many clusters. If the intersection of
the clusters is not the empty set so, clusters should be amalgamated.
© IBIS – Issue 2 (2), 2007
IBIS – Interoperability in Business Information Systems
After the application of the four phases, the effort is concentrated on the
suitability of the OWL DL, which is equivalent to the SHOIN(D) to formally describe
the obtained ontology [9]. A concept definition is a statement of the form A:=D,
where A is a concept name and D is a concept description. In the following, the
formalization of SERVICE, SERVICEPROFILE and SERVICECLUSTER concepts is
presented in table 6.
Concept
SERVICE
Definition
SERVICE:=(∃ ServiceID.String) ∩ (∃ Has
ServiceProfile. SERVICEPROFILE) ∩ (≥1 Has
ServiceCluster. SERVICECLUSTER) ∩ (∃
ReactsToMessage. SERVICEMESSAGE) ∩ (≥0
IsSimilarTo. Service) ∩ (≥1UseResource.
SERVICERESOURCE).
Subsomption relation
SERVICE ⊆ THING.
SERVICEPROFILE
SERVICEPROFILE := (∃ ServiceOperation.String)∩
( ∃ ServExeOrder.Integer)∩(∃ Descibes.SERVICE)∩
(∃ ServiceInput/Output.String)∩
(∃ ServicePre/Post.Boolean).
SERVICEPROFILE
SERVICE.
⊆
SERVICECLUSTER
SERVICECLUSTER: = ( ∃ ClusterID.String) ∩ ( ∃
NumberOfService.Integer) ∩ (≥1 ContainsService
SERVICE).
..
SERVICECLUSTER
SERVICE.
⊆
..
..
Table 6: Concepts definition for service ontology in TBOX.
For checking, we need to use the inference services provided by the DL formalism
for supporting the building process and improving our ontology quality. The use of
the RACER system[10] can make it possible to read OWL file and to convert it in the
form of a DL knowledge bases. It can also provide inference services. To
manipulate the application ontology, Protégé-OWL [21], version 3.1.1 offers a
convivial graphical user interface. It permits to visualize and to edit the ontology
hierarchical relations. For example, the transitive property of the IsSimilar role is
described in OWL DL as follows:
<owl: ObjectProperty rdf: ID="IsSimilar">
<rdf: type rdf:resource ="http://www.w3.org/2002/07/owl#TransitiveProperty"/>
<rdfs: range rdf: resource ="#Service"/>
<rdfs: domain rdf: resource ="#Service"/>
<owl:inverseOf rdf:resource ="#IsSimilar"/></owl:ObjectProperty>
Composition strategy
Collaborative processes are defined as the abstraction of complex business
processes involving different partners. They specify the interaction between Web
services and their coordination. In this work, business processes are defined as a
composition of domain services. Only at runtime, for a given domain service, a
composite service is retrieved and invoked. If the needed service is not available,
then another similar service in the same cluster is invoked. For this purpose, a
composition strategy is defined as follows:
© IBIS – Issue 2 (2), 2007
http://www.ibis-journal.net ISSN:1862-6378
IBIS – Issue 2 (2), 2007
A CS (Composition Strategy) of Web services is formally defined as a set of triplets:
CS= (S, R, C)
S: a set (S1, …, Sn) of domain services.
R: a client service request.
C: a composition schema that fulfils R by suitably orchestrating (S1, …, Sn).
The composition schema is defined as a set of triplets:
C= (Pc, Pr, Co)
Pc: potential composition of domain services.
Pr: Partners implied in the composition.
Co: Constraints used for the selection of the current composition (service
availability, quality of service: response time, cost …).
The composition schema is monitored by two mechanisms:
Composition manager
This mechanism uses the information provided by the UDDI registry to establish a
classification of the potential compositions according to organizational constraints
and client request. It tries to find a conformity between organizational and
customer constraints. The latter analyzes the constraints required by the customer
and checks the availability of services to deduce the best combination from the set
of composition. After making a decision, it sends it to the supervisor mechanism.
The behavior of the manager mechanism is described in the Figure. 3
Figure. 3. Composition manager mechanism.
Composition supervisor
The supervisor mechanism is the core of the composition schema. It monitors the
process execution engine in order to control constraints and to handle possible
exceptions. It invokes the appropriate services after receiving the best
composition. This mechanism uses the constraints of selection to monitor the
execution of services. It is based on mechanisms provided by BPEL4WS language. In
© IBIS – Issue 2 (2), 2007
IBIS – Interoperability in Business Information Systems
case of errors caused by failure in service discovery, the compensation mechanism
(scope) is used to cancel the execution of the current composition and to send an
alarm signal to the manager mechanism in order to select a new combination.
Moreover, the exceptions mechanism (throw, catch) refers to manage the problems
at runtime (Figure. 4.).
Figure. 4. Composition supervisor mechanism.
Business process integration scenario
In this work, the integration scenario includes the process views: business,
functional, organizational and technical ones. The composition schema shows the
management of the business process (invoking services and scheduling the different
steps at runtime). Each service is augmented with constraints on treatment and
data based on the service provider. Then, we define the constraint causality to
give execution order monitoring by partners goals. The obtained dynamic schema is
consistent with partners’ business contexts. For this purpose, the schema
composition is the program steps to be executed for managing the business
process.
In the following, we present the process integration scenario.
Let’s now give the process integration scenario. As shown in Figure. 5, the
integration scenario begins once the Web services have been described using the
WSDL language (1). Then, they are published both in the service ontologies
registries and in the UDDI registry (2, 3). Next, the user requirement is used to
enhance the requested services (4). When the services are identified, they can be
identified by service discovery. If a given service is not available at the execution
time, then another similar service in the same cluster is selected and invoked in
the appropriate service ontology (5, 6). Once the needed services are discovered,
they are based on a composition strategy to form business process using
© IBIS – Issue 2 (2), 2007
http://www.ibis-journal.net ISSN:1862-6378
IBIS – Issue 2 (2), 2007
composition schema. Once the set of desired services have been discovered, they
are ordered according to implied partners and constraints to select the best
composition (7). In this approach, the trace of each composition schema is kept in
the repository to minimize response time. The current composition is executed
under the control of the supervisor mechanism in the orchestration engine (8). The
latter monitors the service execution and handles possible exceptions (9). Finally,
the result is returned to the user (10).
Figure. 5. Business process integration scenario.
BPEL4WS and business processes
Current process based languages such as BPEL4WS [14] support some flexibility,
with the common control flow which constructs such sequence, iteration, and/or
splits and joins. BPEL4WS represents the union of WSFL [24] and XLANG [3]. This
merger has created the market consolidation necessary to make BPEL4WS the de
facto standard for expressing process consisting of Web services. Structurally, a
BPEL4WS file describes the order by stating whom the participants are, what
services they must implement in order to belong to the composition, and the
control flow of the process.
For example, in a tourism agency, the reservation process needs several services
orchestrated in this order: service for booking a flight, service for hotel reservation
and service for payment. The tourism agency collaborates with airlines companies,
hotels and banks to satisfy the customer request. For each service, the provider
partner gives its organizational constraints to execute it. Each constraint is
described by name (constraint name), type (operation-constraint, data-constraint),
partner (partner name), predicate (logic expression), order (the service before, the
service after) and frequency (the number of times to check constraint). We use the
BPEL4WS language to describe the business process:
© IBIS – Issue 2 (2), 2007
IBIS – Interoperability in Business Information Systems
- Definition of partners
<partners>
< partner name=”custmor” partnerRole= ”clienttourismagency”>
< partner name=”webserviceairlinecompany” partnerRole =”reservationticket”>
< partner name=”webservicehotel” partnerRole =”reservationroom”>
< partner name=”webservicebank” partnerRole =”confirmationpayment”>
</partners>
- Definition of organizational constraint
< name= “c1- card-credit” constraint type=”data-constraint” partner=” webserviceairline”
predicate=”card credit = valid” order =”before: reservationticket” frequency=”1” constraint/>
< name=”c2-card-credit” constraint type=”operation-constraint” partner=”webservicehotel”
predicate=” card credit = valid” order=”after: reservationticket” frequency=”1” constraint/>
< name=”c3-confirmationpayment” constraint type=”message-constraint” partner=”customer”
predicate=”card credit = valid” order =” after: reservationroom” frequency=”3” constraint/>
- Definition of data types and messages
<variables>
<variables name= “request” messagetype =”typerequest”>
< variables name= “recepisse” messagetype =”typerecepisse”>
< variables name= “reservationticket” messagetype =”typereservationticket”>
< variables name= “reservationroom” messagetype =”typereservationroom”>
< variables name= “confirmationpayment” messagetype =”typeconfirmationpayment”>
<variables/>
- Definition of business process
<sequence name=”seqsejourreservation” name= “c1- card-credit” >
<receive partner=”customer” operation “sejourreservation” variable= “request”>
<flow>
<invoke partner=”webserviceairline” operation =”reservationticket”>
<invoke partner=”webservicehotel” name=”c2-card-credit” operation =”reservationroom” >
</flow>
<invoke partner =”webservicebank” operation = “confirmationpayment”>
<reply
partner
=”customer”
name=”c3-confirmationpayment”operation=”sejourreservation”
variable=”recepisse”>
</sequence>
Conclusion and perspectives
Semantic integration is a major problem that can affect data, applications and
processes. A solution is to use an ontology-based approach associated to Web
services. The ontologies provide the semantic basis to unify terminology in
applications models. The Web services can encapsulate heterogeneity in business
processes and their composition provides a support to orchestrate the execution.
In this paper, we have outlined an architecture for applications integration with
two levels: applicative and collaborative ones. It is comprehensive in the sense
that it (a) comprises different integration levels and (b) includes ontologies for
managing heterogeneity and ensuring flexibility in business processes. It is generic
because it is not tailored to specific technologies or business applications.
We believe that the results presented here give many interesting insights for
researchers who wish to explore B2B integration more thoroughly. Our architecture
© IBIS – Issue 2 (2), 2007
http://www.ibis-journal.net ISSN:1862-6378
IBIS – Issue 2 (2), 2007
will also be useful for practitioners who wish to assess the flexibility of B2B
integration.
We have organized our architecture along two dimensions, namely, A2A and B2B
integration. In the A2A integration, we have focused on a mapping approach to
bridge applications ontologies. It supports several heterogeneous applications
accessing multiple local ontologies. A component, called wrapper, generates a
global ontology for managing the enterprise information heterogeneity based on
the semantic bridges concept. In the B2B integration, we have built service
ontologies based on domain services, enriched with information about
organizational aspects to keep business context for each partner. These ontologies
are developed for supporting the design and execution of business processes using
Web services composition strategy.
There are numerous of interesting directions for future research. One area is to
focus on the dynamic reconfiguration of the Web service composition strategy to
improve service quality. Another area is to further detail and tailor the
architecture for specific technologies. For this purpose, we will consider the
heterogeneity in the standards of exchange like RosettaNet and BizTalk in order to
propose a portal to support partners collaboration [24]. A third area is to detail and
to empirically test similarity in the mapping process using context properties. A
last direction might address some perspectives for service ontologies: (i)
experimentation to validate the service ontology; (ii) using the framework MAFRA
[7] to support the integration of service ontologies; and (iii) improving services
similarities based on OWL aspects.
References
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
Medjahed, B.; Bouguettaya, A.; Elmagarmid, A. K.: Composing Web Services on the
Semantic Web. Very Large Data Base Journal, 12 (4), 2003.
Linthicum, D. S.: Next Generation Application Integration, Addison-Wesley edition,
2004.
Chauvet, J.: Services Web avec SOAP, WSDL, UDDI, ebXML. Eyrolles edition, 2002.
Maedche, A.; Motik, B.; Silva, N.; Volz, R.: MAFRA A MApping FRAmework for
Distributed Ontologies in the Semantic Web. In ECAI’02 Workshop Knowledge
Transformation, Lyon, France, 2002.
Gronau, N.; Uslar, M.: Skill Management Catalogues Built via KMDL- Integrating
knowledge and Business Process Modeling. ECAI’04 Workshop Knowledge Management
and Organizational memory, Valencia, Spain, 2004.
Noy, N. F.; Musen, M.A.: PROMPT-Algorithm and Tool for Automated Ontology Merging
and Alignment. Seventeenth National Conference on Artificial Intelligence, AAAI,
Austin, TX, 2000.
Gahleitner, E.; Wob, W.: Enabling Distribution and Reuse of Ontology Mapping
Information for Semantically Enriched Communication Services. The 15th International
Workshop on Database and Expert Systems Applications (DEXA), Zaragoza, Spain,
2004.
Michalowski, M.; Ambite, J.L.; Thakkar, S.; Tuchinda, R.; Knoblock, C.A.; Minton S.:
Retrieving and Semantically Integrating Heterogeneous Data from the Web. IEEE
Intelligent Systems, 19(3), 2004.
Horrocks, I.; Patel-Schneider, P. F.; Harmelen, F. V.: From SHIQ and RDF to OWL: The
making of a web ontology language. In Web Semantics Journal, 1 (1), 2003.
Haarslev, V.; Möller, R.: RACER System Description. In Proc. of the Int. Joint Conf. on
Automated Reasoning (IJCAR 2001), volume 2083 of Lecture Notes in Artificial
Intelligence, 2001, pp 701–705.
© IBIS – Issue 2 (2), 2007
IBIS – Interoperability in Business Information Systems
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
[21]
[22]
[23]
[24]
[25]
[26]
[27]
[28]
[29]
[30]
[31]
[32]
[33]
[34]
[35]
[36]
Baader, F.; Calvanese, D.; McGuinness, D.; Nardi, D. The Description Logic Handbook
Theory, Implementation and Applications. Cambridge University Press, 2003.
Yang, J.; Papazoglou, M.P.: Service Components for Managing the Life cycle of Service
Compositions. In Information Systems, 29 (2), (2004)
Knublauch, H.; Mugen, M.; Rector, A.: Editing Description Logic Ontologies with
Protégé OWL Plugin, In DL’04, Workshop on Description Logic, Canada. 2004.
BPEL4WS: http://xml.coverpages.org/bpel4wx.html.
Lopez, M. F.; Perez, A. G.: Overview and Analysis of Methodologies for Building
Ontologies, In Knowledge Engineering Review. 17(2), 2002.
Uschold, M.; Grüninger, M.: Ontologies Principles Methods and Applications, In
Knowledge Engineering Review. 11(2), 1996.
Grüninger, M.; Fox, M. S.: Methodology for the Design and Evaluation of Ontologies, In
IJCAI’95 Workshop on Basic Ontological Issues in Knowledge Sharing, Montreal, 1995.
Fernandez, M.; Gomez-Perez, A.; Juristo, N.: Methontology from Ontological Art
Toward Ontological Engineering, In AAAI’97 Spring Symposium Series on Ontological
Engineering, USA, 1997.
Gruber, R. T.: A Translation Approach to Portable Ontology Specification. In
Knowledge Acquisition, 5:199-220, 1993.
Borgida, A.; Serafini, L.: Distributed Description Logics Assimilating Information from
Peer Sources, In Journal of Data Semantics, 2003.
Protégé OWL, version 3.1.1, 2005,
http://protege.stanford.edu.
Albani, A.; Dietz, J.; Zaha, J.: Identifying Business Components on the Basis of
Enterprise Ontology. Konstantas, D., Bourrieres, J.-P., Léonard, M., Boudjlida, N.
(ed), Interoperability of Enterprise Software and Applications, Geneva, Switzerland,
2005.
Abels, S.; Haak, L.; Hahn, A.: Identification of Common Methods Used for Ontology
integration tasks. IHIS’05, November 4, Bremen, Germany, 2005.
Holfreiter, B.; Huemer, C.: Modeling Business Collaborations in Context. In the
Proceedings of On The Move to Meaningful Internet Systems OTM Workshops,
Springer-Verlag, 2003.
Bauer, B.; Müller, J. P.; Roser S.: A Decentralized Broker Architecture for
Collaborative Business Process Modelling and Enactment. Second International
Conference I-ESA’06, Interoperability for Enterprise Software and Application,
Bordeaux, 2006.
Kalinichenko, L.; Missikoff, M.; Schiappelli, F.; Skvortsov, N.: Ontological Modelling.
Fifth Russian Conference on Digital Libraries, RCD’03, St-Petersburg, Russia, 2003.
Stelzer, D.; Fischer, D.; Nirsberger, I.: A Famework for Assessing Inter-organizational
Integration of Business Information Systems. International Journal of Interoperability
in Business Information Systems, IBIS, 2(2), 2006, pp. 9-20.
Izza, S.; Vincent, L.; Burlat, P.: Unified Framework for Application Integration, in
seventh International Conference on Enterprise Information Systems, USA, 2005.
Martin, H.; Zdravkovic, J.; Johannesson, P.: Service-Based Processes Design for
Business and Technology. ICSOC’04, November 15-19, New York, USA, 2004.
Alonso, G.; Casati, F.; Harumi, K.; Machiraju, V.: Web Services-Concepts,
Architectures and Applications. Springer-Verlag edition, Berlin, 2004.
Acharya, R.: EAI- A Business Perspective. eAI Journal, www.bijonline.com/, 2003.
Zang, S.; Hofer, A.; Adam, O.: Cross Enterprise Business Process Management
Architecture–Methods and Tools for Flexible Collaboration, In OTM Workshop, LNCS,
vol. 3292, Springer-Verlag, Heidelberg R. Meersman et al. edition, Berlin, 2004.
Panetto, H.; Scannapieco, M.; Zelm, M.: INTEROP NoE- Interoperability Research for
Networked Enterprise Application and Software. OTM Workshop, Vol 3292,
Heidelberg, R.; Meersman et al edition, Berlin, 2004, pp. 866-882.
Bianchini, D.; De Antonellis, V.; Melchiori, M.: Domain Ontologies for knowledge
Sharing and Service Composition in Virtual Districts. In the Proceedings of the 14th
International Workshop on Database and Expert Systems Applications (DEXA), 2003.
Mertz, D.: Understanding ebXML, Understanding the Business Web of the Future
Phenomenological Unifier. Gnosis Software, Inc, 2001.
Dogac, A.: Semantic Web Services. In the Proceedings of International Conference
on Web Engineering, Munich, 2004.
© IBIS – Issue 2 (2), 2007
http://www.ibis-journal.net ISSN:1862-6378
[37]
[38]
[39]
[40]
[41]
[42]
[43]
[44]
[45]
IBIS – Issue 2 (2), 2007
Dogac, A.; Laleci, G.; Kirbas, S.; Kabak, Y.; Sinir, S.; Yildiz, A.; Gurcan, Y.: ArtemisDeploying Semantically Enriched Web Services in the Healthcare Domain ,
http://www.ing.uinbs.it/~deantone/interdata_tema3/Artemis/artemis.html , 2004.
Martin, D.; Burstein, M.; Lassila, O.; Paolucci, M.; Payne, T.; Mcllraith, S.: Describing
Web Services Using OWL-S and WSDL. http:// www.daml.org/services/owl-s/1.0/,
2003.
Roman, D.; Lausen, H.; Keller, U.; Oren, E.; Bussler, C.; Kifer, M.; Fensel, D.: Web
Service
Modeling
Ontology,
WSMO
working
draft.
http://www.wsmo.org/2004/d2/v1.0/20040920/, 2004.
Jain, A. K.; Dubes, R. C.: Algorithms for Clustering Data. Prentice-Halle, 1988.
OMG:
OMG
Unified
Modeling
Language,
Version
2.0.
2003.
http://www.omg.org/technology/documents/modeling spec catalog.htm#UML.
Horrocks, I.; Sattler, U.: Ontology Reasoning in the SHOQ(D) Description Logic. The
17th Int. Joint Conf. on Artificial Intelligence (IJCAI 2001), Morgan Kaufmann, 2001,
pp 199–204.
Williamson, O. E.; Winter, S.G.; Coase, R. H.: The Nature of the Firm: Origins,
Evolution and Development. Oxford University Press, New York, 1991.
Driouche, R.; Boufaida, Z.; Kordon, F.: Towards Integrating Collaborative Business
Process based on Process Ontology and EbXML Collaboration Scenario. In
6th
International Workshop on Web Based Collaboration’06, IEEE Computer Society,
Krakow, Poland, 2006.
Driouche, R.; Boufaida, Z.; Kordon, F.: An ontology based architecture for integrating
enterprise applications. In fourth Forth International Workshop on Modelling,
Simulation, Verification and Validation of Enterprise Information Systems, Paphos
Cyprus, May 2006.
Biography
Razika Driouche is a Ph. D. candidate in LIRE laboratory at Mentouri
University of Constantine, Algeria. She is currently working in the
area of application integration for the last three years. Her research
interests include building and integration of ontologies, Web
services composition and business processes modeling.
Zizette Boufaida is a full professor since 2003 in the Computer
Science department of the university of Constantine, Algeria. She is
actually, vice-dean of Faculty of Engineer, in charge of research and
external relationships. She is also in the program committee of
DEXA. Her current research activities are conducted in SIBC team of
LIRE Laboratory and include advanced information systems and
semantic web.
Fabrice Kordon is a full Professor at the University P. & M. Curie and
the head of the team "Modeling and Verification" in the "Network
and Distributed Systems" department at LIP6 lab. His research
interests mainly concern the development of high-level specification
languages and their relationship with formal modeling and analysis
in the context of model driven development for concurrent
software.
© IBIS – Issue 2 (2), 2007
IBIS – Interoperability in Business Information Systems
Fourth International Conference
I-ESA 2008
Interoperability for Enterprise Software and Applications
Science meets Industry
Berlin, Germany
Pre-conference: March 25th, 2008
Conference: March 26th – 28th, 2008
Call for Papers
Scope
Interoperability in the context of enterprise applications is the ability of a system
or a product to work with other systems or products without special effort from the
customer or user. The capability to interact and exchange information both
internally and with external organisations (partners, suppliers, customers) is a key
issue in the economic sector. It is fundamental in order to produce goods and
services quickly and at lower cost, while ensuring higher levels of quality and
customisation.
Today, companies maximise flexibility and speed of response to changing market
conditions, by focusing on core innovation and information centred activities,
outsourcing capital and labour intensive activities to less advanced economies.
They develop knowledge and links with other companies with which they can
collaborate to provide the products and services that the market demands – the
networked enterprise, or virtual organisation. Successful enterprises in this
knowledge economy may be small, but are highly productive, focussed on
innovation and capable of flexibly and rapidly sharing information and knowledge
to participate in highly competitive networked enterprises. The issue of
interoperability within the enterprise is therefore no longer limited to the
interoperability between silos of systems within single companies, but has become
one of interoperability throughout a value chain.
Furthermore, it is now recognised that interoperability of systems and thus sharing
of information is not sufficient to ensure common understanding between
enterprises. Knowledge of information meaning and understanding of how is to be
used must also be shared if decision makers distributed between those enterprises
in the network want to act consistently and efficiently. Enterprise interoperability
must therefore now embrace sharing of collaboration knowledge and core
competencies as well as the administration of such shared knowledge – knowledge
oriented collaboration.
Initiated in 2005 by two major European research projects of the 6th Framework
R&D Programme of the European Commission, the ATHENA IP (Advanced
Technologies for Interoperability of Heterogeneous Enterprise Networks and their
© IBIS – Issue 2 (2), 2007
http://www.ibis-journal.net ISSN:1862-6378
IBIS – Issue 2 (1), 2007
Applications, Integrated Project) and the INTEROP NoE, (Interoperability Research
for Networked Enterprise Applications and Software, Network of Excellence), the IESA conferences have been recognized as a tool to lead and generate an extensive
research and industrial impact in the field of interoperability for enterprise
software and applications.
I-ESA brings together the world’s leading researchers and practitioners in the area
of enterprise interoperability, and it is a unique forum for the exchange of visions,
ideas, research results and industrial experiences, dealing with a wealth of
interoperability research subjects for business, enterprise applications and
software.
The industry will find at I-ESA’08 an outstanding opportunity to exchange
experience and problems on business interoperability in their daily operations. IESA series of conferences have become a forum where industry and research worlds
meet and share experience, ideas and problems on different interoperability
aspects. In the I-ESA 08 arena the industry will point out the difficulties
encountered in their business life and show the way taken to solve those problems
while interrelate with other organizations sharing experience. The industry will be
able to meet interoperability experts and learn from them about emerging new
solutions and even establish relationships for further research and development
and problem solving. Special sessions will address industrial interoperability issues
for large scale industry like Automotive and Aeronautic and medium as well as
small sized ones like Furniture. Additionally, I-ESA’08 will feature a high-quality
pre-conference programme consisting of workshops, tutorials, the International
School on Interoperability and a doctoral symposium. During the main conference,
there will be an attractive exhibits programme and an additional brokerage event,
including a hands-on "industrial use case challenge".
The Doctoral Symposium is an opportunity for students involved in the preparation
of their PhD in any area of Interoperability for Enterprise Software and Applications
to interactively discuss their research issues and ideas with senior researchers, and
receive constructive feedback from members of the research community and other
Doctoral Symposium participants. Besides scientific matters, students will also have
the opportunity to seek advice on various aspects of completing their PhD and
performing research as a young professional in groupware.
Topics
Full and original scientific papers of high quality are invited to I-ESA’08. The
conference encourages submissions in (but not restricted to) the following areas:
Business Aspects of Interoperability

Micro-/Macro Economic impact of interoperability

Business interoperability requirements

Business Process Management
Interoperability Scenarios

Success stories and lessons learnt

Initiatives and communities

Problem statements

Case studies in interoperability solutions and their impact on day2day
business

How to reduce application gaps of new interoperability results

New Interoperability Scenarios and derived requirements – e.g.
Interoperability of Business Services
© IBIS – Issue 2 (2), 2007
IBIS – Interoperability in Business Information Systems
Business Interoperability

Computer-supported negotiation, agreement, and contracting for
interoperability

Managing differences between networked enterprises in terms of culture,
languages and work processes

Business Interoperability frameworks and their application

Interoperability issues in electronic markets

Measuring impact of new interoperable solutions

Knowledge management in networked enterprises

creation, transfer, distribution, management and application

Legal issues for interoperability

Security issues in interoperability

Business models for solutions and services

The human factor in interoperability
Systems engineering in the context of interoperability

Integration and federation of Product, Systems and Project Management

How to act as supplier for different OEMs and their systems

Catalogues and libraries

Managing complexity and variety

Corporate Standards

Control systems engineering and integration/federation

Reducing gaps between Sectors – e.g. Production, Logistics, and Finance

Reconciling requirements between different kind of partners
Specification and Implementation

Enterprise Application Integration in the context of networked enterprises

Self-organization and emergent behavior in the context of interoperability

Requirements engineering for interoperable enterprises

Design Methodologies

Validating, and verifying solutions and methodologies

Service Engineering and Methodology
Architectures and Frameworks

Model Driven Architectures

Service oriented (Enterprise) Architectures

Agent based approaches to interoperability

Ubiquity, mobility, open architectures and large scale interoperability
Enterprise Modeling for Enterprise Interoperability

Distributed Modeling

Synchronization of models

Meta-data and meta-models

Methods, tools and frameworks for (networked) enterprises

Semantic mediation and enrichment of enterprise models

Service Modeling for Business
SW - Platforms

Open platforms supporting collaborative businesses

Non-functional aspects of interoperable solutions

Intelligent infrastructure and automated methods for business system
integration
© IBIS – Issue 2 (2), 2007
http://www.ibis-journal.net ISSN:1862-6378
IBIS – Issue 2 (1), 2007
Interoperability of operational Systems

Aspects of Service Management
Semantics for Enterprise Interoperability

Semantic web based approaches

Enterprise applications analysis and semantic elicitation

Reasoning methods and tools for model transformation
reconciliation

and
data
Workshops and Tutorials
The 4th I-ESA conference invites proposals for workshops to be held in conjunction
with the main conference. Following the successful organization of the conference
and workshops in the first three I-ESA conferences, this year the workshop proposal
topics are open to other areas not covered by the main conference topics.
Workshop proposals should explore new interoperability issues, problems and
solutions in areas coming from not only enterprise software and applications, but
also from eHealth, mobile services, and end-user software and applications to
social and financial issues related to the introduction of interoperability.
I-ESA 2008 is the fourth in a conference series that provides one of the most
prestigious forums for researchers and practitioners in all aspects of
interoperability of enterprise software and applications. The conference has a
record of attracting innovative research of high quality related to all aspects of
interoperability (theory, frameworks, methods, techniques, software architectures,
empirical findings).
The conference and workshops will be complemented by tutorials and an
exhibition.
Workshops are meant to facilitate the exchange of ideas and experiences between
active researchers, and stimulate discussions on new and emerging issues in topics
related to interoperability. The workshops should be organized in a way that will
leave sufficient time for brainstorming and discussions between attendees, so that
at the end new research directions and topics can be identified. Workshops may
concentrate in-depth on research topics, or may also be devoted to application
and/or standardization issues.
Committees
GENERAL CONFERENCE CHAIR
Chair: Prof. Kai Mertins, Fraunhofer IPK Berlin, DE
Co-Chair: Dr. Rainer Ruggaber, SAP Research, DE
INTERNATIONAL PROGRAMME COMMITTEE
Chair: Prof. Keith Popplewell, Loughborough University, GB
Co-Chair: Prof. Xiaofei Xu, Harbin Institute of Technology, CN
STEERING COMMITTEE
Prof. Guy Doumeingts, Emeritus Professor of University Bordeaux 1, GFI Group, FR
Ms. María José Núñez. AIDIMA, ES
Prof. Kai Mertins, Fraunhofer IPK Berlin, DE
Ms. Petra Frenzel, SAP Research, DE
Dr. Rainer Ruggaber, SAP Research, DE
ORGANIZING COMMITTEE
Chair: Thomas Knothe, Fraunhofer IPK Berlin, DE
© IBIS – Issue 2 (2), 2007
IBIS – Interoperability in Business Information Systems
Co-Chair: Amparo Roca de Togores. AIDIMA, ES
Co-Chair: Cathy Lieu, University Bordeaux 1, FR
Co-Sponsorship
I-ESA 2008 is co-sponsored by:
IFIP- International Federation for Information Processing
Forum on the Technology Platform on the future manufacturing technologies:
MANUFUTURE, Germany
EIC - Enterprise Interoperability Centre, Belgium , Belgium
IFAC - INTERNATIONAL FEDERATION OF AUTOMATIC CONTROL
Deutsches Forum für Interoperabilität e.V., Germany
Important Dates
Conference
Full paper submission deadline: September 30th, 2007
Author notification due: October 31st, 2007
Camera-ready copies due: December 15th, 2007
Workshops & Tutorials
Workshops & Tutorials submission: November 9th, 2007
Acceptance notification due: December 15th, 2007
Information for authors
We encourage authors to submit original papers via the electronic I-ESA conference
management system. The paper submission deadline is September 30th, 2007. We
ask authors to register the electronic metadata of their publications (title, coauthors, keywords, short abstract) by September 20th, 2007. Only full paper
submissions will be accepted.
Previous I-ESA Conference proceedings have been published by Springer, this year
the proceedings will be again published by a recognised international publisher
with ISBN registration. Accepted papers will be included in the Conference
Proceedings book, only if they are presented by one of the authors at the I-ESA
2008 conference.
The maximum paper length is 12 pages according to Springer LNCS style (see the IESA homepage for details or http://www.springer.de/comp/lncs/authors.html).
International Scientific Journals have been supporting and observing the I-ESA
conferences, inviting authors of selected papers to publish there.
Submit NOW your Expression of Interest by www.i-esa.org, or contacting the IESA’08 Conference Chair ([email protected]).
Website
http://www.i-esa.org
© IBIS – Issue 2 (2), 2007
http://www.ibis-journal.net ISSN:1862-6378
IBIS – Issue 2 (2), 2007
© IBIS – Issue 2 (2), 2007
IBIS – Interoperability in Business Information Systems
Call for Articles
New issues of the IBIS journal are released three times a year. Authors are
encouraged to submit articles for inclusion in the next issue of the International
Journal of Interoperability in Business Information systems.
We are interested in both theoretical and practical research. We are also
interested in case studies and results of recently finished research projects.
Although our focus is on research results, we also accept a small amount of
practical articles. Contributions should be original and unpublished and need to
have a high quality.
Topics of the journal include, but are not limited to:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Integration of business information systems
Enterprise modeling for Interoperability
Interoperability architectures and frameworks
Interoperability of business standards
Intelligent mediators
Coupling of information systems
Interoperability of classification systems
(Semi-)Automatic transformation of standards
Interoperability of (meta) models
Semantic integration concepts
Interoperability between domain specific standards
Semantic analysis of structured, semi-structured, and unstructured data
Interoperability of catalog based information systems
Cooperation in heterogeneous information systems
Ontology matching, merging and aligning
Semantic combination of heterogeneous standards
Ontology- and model management
Interoperability of sector specific systems
Authors are encouraged to submit high quality articles online. Please carefully look
at the submission guidelines to prepare your submission. All submissions should be
made online using our online submission system. In case of any problems, please
contact us via email.
For additional information and deadlines, please visit our website at
http://www.ibis-journal.net
© IBIS – Issue 2 (2), 2007