Usage of Semantic Transformations in B2B Integration Solutions
Leonid Shumsky, Pavel Shapkin and Viacheslav Wolfengagen
National Research Nuclear University MEPhI (Moscow Engineering Physics Institute),
Cybernetics and Information Security Department, Moscow, Russia
Keywords: B2B, Integration, Ontologies, Conceptual Modeling, Semantics.
Abstract: We propose a computation-oriented approach to ontology-based B2B integration. The domain ontology is
used within the integration platform as a scheme for internal data representation. The main idea is to repre-
sent the ontology in a form that enhances the usage of static and dynamic type-checking features offered by
the programming language compiler or runtime environment. For these purposes the ontology is represented
as a set of types and transformation functions. We study the resulting integration platform architecture and
compare expressive power and logical inference possibilities to other ontology representations.
1 INTRODUCTION
Currently every organization needs to establish the
data exchange with its partners, counteragents and
clients. The amount of messages could exceed hun-
dreds of thousands and the count of integrated coun-
teragents could be more than several hundreds. It is
impossible to quickly organize a new or reliably
support the existing communication under such cir-
cumstances without the usage of tools that accumu-
late knowledge about methods of interaction with
specific systems as well as about process and data
semantics in the corresponding domain.
The B2B integration specifics consists in the fact
that the communication is to be carried out between
the organizations that are neither organizationally
connected, nor share common information systems.
On the other hand, many organizations face the same
integration tasks. These restrictions justify the re-
quirement to use some reusable “external” descrip-
tion of processes and message structures (data
blocks) that is standard for an industry or for a dis-
tinct task. Such standards are known as B2B integra-
tion standards. Nevertheless many tasks correspond
to a set of different process and data description
standards implemented by different applications
(Cui et al., 2002; Jridi and Lapalme, 2013). The need
to translate the data representation between different
standards complicates the deployment of integration
solutions. In such cases purely syntactic as well as
semantic problems appear — it is needed to provide
the full transition of semantics from the initial to the
target message. This problem can occur because
with a single B2B message one can send more in-
formation than it explicitly contains: the message
type, the delivery context etc. are also of great im-
portance. Furthermore different standards use differ-
ent restrictions on data types and different
dictionaries for standard codes.
The main premise of the current work is that
though the ontological approach to B2B integration
is being sufficiently studied and implemented it still
doesn’t use all the possible advantages. We propose
an approach that consists in the usage of a standard
intermediate ontology not on the side of one of the
systems being integrated but as a part of an interme-
diate system that provides services for data objects
extraction and their transformation into the required
format. The advantage of such approach is that ap-
plications that are connected as services and objects
from the domain model which they provide are de-
fined in a central system. Thus syntactic and seman-
tic features typical for each concrete application are
hidden from the user but nevertheless are fully im-
plemented. Furthermore, such an approach enables a
much faster deployment of standard B2B integration
solutions because the connection between the appli-
cations and the ontology and the correlation between
processes that take place in target systems are al-
ready defined.
The paper is organized as follows. Section 2 de-
scribes B2B standards along with their classification
and specific features. Section 3 presents the essence
of the proposed approach to the task of intermediate
152
Shumsky L., Shapkin P. and Wolfengagen V..
Usage of Semantic Transformations in B2B Integration Solutions.
DOI: 10.5220/0005119901520157
In Proceedings of the 11th International Conference on e-Business (ICE-B-2014), pages 152-157
ISBN: 978-989-758-043-7
Copyright
c
2014 SCITEPRESS (Science and Technology Publications, Lda.)
ontology-based integration and the progress
achieved by authors. Section 4 covers the specifics
of organizing the B2B communication using domain
ontologies. A simple example that uses the proposed
formalization is given in section 5. The conclusion
summarizes the key points and gives an overview of
the related works.
2 B2B STANDARDS
The main aim of that section is determination and
classification of B2B standards from the point of
view of their content and scope. This classification is
required by intermediate ontology construction algo-
rithm. We should consider common integration
standards and their specifics to determine which one
will be used for ontology construction.
The set of B2B integration standards describes
all integration steps, from technical characteristics of
transported messages to descriptions of the target
business process (Heravi et al., 2010). Table 1 shows
some examples of standards and their relationships.
This research considers levels 2 and 3, because the
task of syntactic parsing for a well-known structure
presents no difficulty and is not related to the seman-
tics of the message. On the other hand, the task
(problem) of parsing business process schemes,
which are described by standards has its own specif-
ics and is being solved in related works (see the con-
clusion section).
1 Syntax XML, XML-RPC, Beep,
SOAP
2 Messaging standards ebMS, RosettaNet Imple-
mentationFramework
(RNIF)
3 Data structure standards GISB, fPML, SWIFT,
OBI, OTA, CXML
4 Business process structure WS-CDL, XPDL, ebBP,
WE-BPEL
5 Business process templates UBP, OAGIS Scenarios,
RosettaNet PIPs
6 Business documents UBL, OAGIS, RosettaNet
Despite of the similarity of tasks and their im-
plementations’ aspects, standards from different
technological/instrumental stacks are not compati-
ble. It means that even if some system supports inte-
gration for some business object with respect to one
standard it can fail the integration for the same ob-
ject but carried out in accordance with business pro-
cess defined in another standard.
As Table 1 shows us, the most modern standards
are based on open general-purpose standards devel-
oped by large, independent companies, like W3C,
OMG, OAGIS etc., which fact simplifies our task of
parsing messages and extracting data from them.
Important requirement for the message syntax is
human readability. In case of program error, user
should be able to change message and resend correct
variant it manually.
We should discuss now each level of the model
in details. Standards from the second level of the
model prescribes specific features of messaging be-
tween systems. Standards of the third level deter-
mines data structures specific for some application,
industry or business-object. Higher level standards
are grouped in the same manner – they could be uni-
versal or industry specific. Nowadays, data structure
standards are distributed as DTD or XSD documents
or as WSDL service specifications to describe atom-
ic acts of data transfer. But, application-specific
standards may be described via low-level data struc-
tures and communication protocols, or even in terms
of (remote) method calls.
Levels 4 to 6 determines schemas for typical or
recommended integration business processes. A pro-
cess is described by: its technological model (BPEL,
XPDL etc.), suitable for execution with some spe-
cialized process engine; typical business process
model (BPMN, UML, etc.); and high-level docu-
ments, which describe the approach to data ex-
change in general.
Summarizing, the intended integration schema
for B2B integration includes following steps:
1. Business partners must come to an agree-
ment on the integration of some business
objects and choose any standard methodol-
ogy, which has a description of each select-
ed object;
2. Choose a required typical template for the
integration process;
3. Partners must produce a technology model
of the process, corresponding to the select-
ed methodology, and provide its implemen-
tation ;
4. Partners must come to an agreement on the
set of the standard messages, which will be
involved in the process;
5. Messaging implementation must be provid-
ed.
Based on the list of standards and typical inte-
gration schemes, we can state that ontology-based
approach may be applied to the fourth and the fifth
steps. On the fourth step it will be used for the data
semantic connection and errors investigation. On the
fifth step it will be used for dynamic validation and
incorrect messages filtering. The latter is particularly
UsageofSemanticTransformationsinB2BIntegrationSolutions
153
Figure 1: The message flow.
important, because syntactic structure of the mes-
sages is strictly defined and simple validation will
not bring expected benefits.
In section 4 we will discuss the specific require-
ments to the ontology suitable for such a context: for
semantic message validation inside integration pro-
cesses and the main purpose of that ontology.
3 THE ESSENSE OF THE
PROPOSED APPROACH
Approach, proposed in this paper, is based on the
idea of creation of intermediate conceptual model
for subject domain to provide independent data rep-
resentation and transformation rules.
Concepts in the ontology are organized depend-
ing on their respective represented business object
categories and (related to this object) processes. In
general, such an intermediate conceptual model is a
multilevel ontology. The top level contains descrip-
tions for typically encountered (in various sys-
tems/domains) objects, grouped by their field of use.
The second level corresponds to supported B2B
methodologies, the third one – to specific data struc-
tures, within each methodology. The last, fourth,
level reflects standards’ features specific to particu-
lar applications.
Data transfer from one representation level to
another is performed by a set of bidirectional trans-
formations, which allows using a single implementa-
tion of the standard for both receiving and sending
data. The main advantage of the proposed architec-
ture is a reduced average operation’s cost, due to
reducing amount of the most expensive operations.
The system of core concepts is rarely altered, as far
as the task of connecting a new system is concerned.
Adding a new standard means defining the third-
layer ontology for its objects and the set of bidirec-
tional transformations for that standard to core con-
cepts. Adding a new message type or a support for
new application normally would not require doing
extensive semantic modelling (so far as the applica-
tion in question stick to the standard), merely intro-
ducing some syntactical extensions to the
intermediate ontology.
The message flow in the proposed system is
schematically shown in figure 1.
The message flow starts from the data structure
of the fourth level received from the application and
deserialized to the structure defined on the third lev-
el. These steps include syntactic validation by the
scheme for that application and semantic validation
for the stated standard. This step helps to eliminate
messages that do not correspond to the standard se-
mantically or syntactically. E.g. messages with in-
consistent dates or undefined dictionary data fall in
this category. The next step is the correlation of the
data with the root concept which is the key ad-
vantage of the proposed approach. It includes stand-
ard-agnostic checks which accumulate expert
judgments in a given domain. This step eliminates
messages with deep inconsistencies which allow to
assert that the data is erroneous or intentionally
compromised. Such rules are set up for each copy of
a system independently but the setup process rules
from other installations or external sources can be
used.
The reverse dataflow is symmetrical to the input
flow. Root ontology data are serialized into a stand-
ard-specific and sent to the target application. On
this step an additional standard compliance or syntax
check for the outgoing message can take place.
Since the proposed approach is intended for a
wide integration standard support concrete imple-
mentation of the systems being integrated does not
affect the data transfer settings. It is only needed to
provide the data access properties. All the data vali-
dation and transformation logics is hidden from the
users but can be retrieved and altered if needed.
ICE-B2014-InternationalConferenceone-Business
154
4 SEMANTIC APPROACH TO
B2B INTEGRATION
Even if two organizations use the same standard
there is no guarantee that the communication will be
productive. The main source of the problems is that
all the integration standards define only the structure
of business processes and syntax structure of data
and do not mention the semantics. It alters the goal
of the ontology usage: usually the ontology defines
document structure but in the case of B2B integra-
tion, when the document structure is already known,
the ontology is used to implement complicated inner
data validations.
4.1 Structure of the Domain Ontology
An ontology is a semantic model of the domain cre-
ated as the result of classification. The process of
classification consists in grouping of information
objects (individuals) based on their similar features.
Groups obtained in this process represent concepts
which are abstract entities characterized by their so-
called intension and extension. An intension is a rule
used to determine whether an individual belongs to
this concept. Individuals that satisfy this rule are
called instances of the concept. An extension is a set
of individuals, viz. instances of the concept. Con-
cepts are organized in a hierarchical structure by the
subsumption relation that forms a partial order on
concepts.
The hierarchical structure of concepts is called
taxonomy. An ontology is a taxonomy equipped with
a system of declarative knowledge. In computer sci-
ence, the ontology of the domain is an explicit speci-
fication of its conceptualization (Gruber, 1993).
Knowledge that is added to a taxonomy can be seen
as a set of rules that help to infer new knowledge
about concepts from the existing knowledge. In or-
der to construct provably correct inference proce-
dures for ontologies we need a formal model of its
constructs. The mainstream way to formalize ontol-
ogies today is to use logical formalisms. Such ap-
proach is used in the semantic web: web ontologies
are formalized with description logics (Baader et al.,
2007) that are fragments of first order predicate
logics (FOPL).
From the point of view of business process inte-
gration, concepts of the domain ontology represent
domain entities (e.g. Customers, Organizations, Op-
portunities, etc. considering the CRM domain).
Moreover, for a domain entity concept, there may be
a set of more specific concepts that correspond to
representations of this entity in different applications
using different standards; each of these concepts
should subsume the main entity concept. From this
point of view we can prescribe different semantics to
concepts regarding their position in the subsumption
hierarchy. “Leaf” concepts correspond to specific
representations of the domain entities in different
systems and standards. Other concepts, which we
will call core concepts, correspond to semantic rep-
resentations of domain entities. Core concepts are
used internally in the ESB to represent the data.
4.2 Transformation Semantics of the
Domain Ontology
Our goal is to maximize the usage of the ontological
information in the process of construction, setup and
execution of the integrated business processes which
are examples of computational objects of a special
kind. Let’s consider how domain ontologies may be
interpreted from the computer science and pro-
gramming perspective. Ontology is a form of
metadata, viz. “data about data”: it’s the additional
data needed to interpret data objects. The basic way
to represent metadata in programming languages is
to use types. The advantage of type systems is that it
is metadata that could be used by the compiler or the
runtime environment to reason about programs, i.e.
to statically or dynamically prove some properties of
a program: absence of erroneous constructions, data
security (Sabelfeld, 2003) etc.
From the programming perspective, concepts
correspond to types. As for subsumption relations,
they could be represented as transformations be-
tween different types: if the concept A subsumes the
concept B then one can transform each instance of A
to its “view” as instance of B and vice-versa, if there
is a transformation from the objects of type A into
objects of type B it means that one could assert that
A subsumes B respecting this transformation. This
approach to inheritance is known as subtyping by
coercion. The equivalence of two concepts is under-
stood as a special case of subsumption: is equal to
iff subsumes and subsumes. Nevertheless
there is one additional restriction on corresponding
transformations: the compositions
∘
and
∘
should be identity functions on and
correspondingly.
We’ve intentionally relied on transformations in-
stead of inheritance relationship that could be used
to model subsumption in object-oriented languages.
Usage of transformations gives more possibilities as
inheritance could be viewed as a special case in
which the transformation function is just a trivial
typecast to the base class.
UsageofSemanticTransformationsinB2BIntegrationSolutions
155
Functional composition can be additionally used
to extend the domain ontology by computing derived
relations. Different transformations (e. g. → and
→) can be composed thus forming a chain of
compositions that is a composite transformation
(from to ). From the logical point of view ena-
bling the usage of composite transformation is equal
to treatment of subsumption as a transitive relation.
The relationship known as the Curry–Howard
isomorphism allows interpreting typing as proving
theorems about programs, with various type systems
corresponding to various logical systems. First order
predicate logic (FOPL) is associated with sufficient-
ly complicated type systems; nevertheless today
more and more languages support these systems. In
other words, the language of type systems is as ex-
pressive as the language of logical formalisms. It
guarantees that there is a way to express ontological
structures at the type-level of modern programming
languages without any loss in the expressiveness and
logical inference possibilities while making ontolog-
ical information fully “understandable” and “usable”
for the program language environment (i.e. compil-
er, interpreter, virtual machine etc.).
4.3 Usage of the Ontological
Knowledge in the Integration
Process Construction and
Execution
The availability of the domain ontology enables to
construct high-level descriptions of integrated pro-
cesses
Usage of the Ontological Knowledge in the Inte-
grated Process Construction and Execution
The availability of the domain ontology enables
to construct high-level descriptions of integration
processes which are bound not to concrete applica-
tions (e.g. SalesForce, AmoCRM, NetSuite, Open-
ERP, etc.) but rather to application classes (CRM,
ERP, etc.). Data flows are expressed in terms of core
concepts. The communication with concrete external
systems is implemented according to the following
rules:
concept X instances can be sent to the sys-
tem A if this system accepts the instances of
X or more general concepts
concept X instances can be obtained from
the system A if this system provides the in-
stances of X or more specific concepts
The rules mentioned could be used within the inte-
gration platform in the following ways:
to validate the connections of the integrated
process to external systems
to generate tips on the set of available opera-
tions and object types while creating new
processes
5 EXAMPLES
Let’s consider a simple integration scenario. Sup-
pose we need to exchange sale orders between two
point-of-sale applications
and
and two dif-
ferent ERP (
and
) systems. There are
different ways to formalize the corresponding ontol-
ogy in terms of object types and transformation
functions.
In the most “structured” case, if we are starting
the development from scratch, we can take the top-
down approach by creating a single data type
which accumulates order information which is
common to all systems. Then, we have to define
mappings which parse and generate representations
of the information formatted for the used systems. If
we need only to migrate orders from point-of sales
to ERPs we need to define four mappings: two
parsers from point-of-sales and two generators into
ERP formats. For bidirectional migration eight map-
pings are needed.
Another possible scenario is when it is already
known how to migrate data from
to
using
a type
as internal data representation and from
to
using
. It is the case of the bottom-up
approach when we first fully implement some mi-
gration functionality between concrete systems and
then generalize it to connect all the systems.
In other words, suppose that we have four legacy
mappings:
:
→
;
:
→
;
:
→
;
:
→
.
Using the proposed approach it is only needed to
define two (or one bidirectional) transformations
between the types
and
(named
and
) in
order to construct a system which is semantically
equivalent to the previous solution: the required
missing migration functions are available as compo-
sitions:
∘
∘
migrates data from
to
;
∘
∘
migrates data from
to
.
ICE-B2014-InternationalConferenceone-Business
156
The equivalence of this solution and the previous
one is proven by the fact that the ontology is seman-
tically the same. The only difference is that we use a
pair of equivalent concepts
and
instead of a
single concept . The equivalence of
and
is
justified by the availability of the bidirectional trans-
formation between them. Thus, using the proposed
approach the domain ontology naturally arises from
programming concepts: types and transformation
functions. The ontology can be constructed top-
down in the beginning of the project or it can be
learned bottom-up from a set of types and transfor-
mations between them obtained from legacy sys-
tems. Further, this ontology is used to compute new
ways of transforming the data and thus connecting
different systems.
6 CONCLUSION
In comparison to similar solutionsthat use ontologies
in the B2B integration domain (Haselwanter et al.,
2006; Bussler, 2001) the proposed approach helps
to abstract from the specific applications that take
part in the integration process and to focus on the
support of the standards used. In turn this not only
makes the maintenance and the connection of new
systems easier but also opens new perspectives in
the field of data verification in terms of standards
conformity, validation and consistency checks.
Related work. In order to have a richer B2B in-
tegration implementation from the beginning of the
process to the technical deployment authors carry
out research in the field of information process for-
malization in order to reveal connections with tech-
nological models and conceptual domain models
(Wolfengagen et al., 2013; Shumsky et al., 2013;
Shapkin and Demchenko, 2014). The combination
of the integration process modeling according to
B2B methodology standards and ontological data
transformation approach described above enables to
fully implement a B2B integration system. The de-
ployment of such a system requires only to define
the access points for the given applications in order
to implement a complete, standard, recommended
business process. In course of the execution such
system could monitor and validate both the data
(taking into account the history of requests) and the
process structure.
REFERENCES
Cui, Z., Jones, D., O’Brien, P., 2002. Semantic B2B Inte-
gration: Issues in Ontology-based Approaches. In
ACM SIGMOD Record. Vol. 31, Issue 1. ACM New
York, NY, USA, DOI: 10.1145/507338.507347.
Haselwanter, T., Kotinurmi, P., Moran, M., Vitvar, T.,
Zaremba, M., 2006. WSMX: A Semantic Service Ori-
ented Middleware for B2B Integration. In Lecture
Notes in Computer Science Volume 4294, pp 477-483,
Springer, DOI: 10.1007/11948148_43.
Bussler, C., 2001. B2B Protocol Standards and their Role
in Semantic B2B Integration Engines. In Bulletin of
the Technical Committee on Data Engineering, 24(1),
IEEE.
Jridi, J.E., Lapalme, G., 2013. Adapting RosettaNet B2B
Standard to Semantic Web Technologies. In: 15th In-
ternational Conference on Enterprise Information Sys-
tems (ICEIS 2013). Pp. 443–450.
DOI:10.5220/0004434404430450.
Rahmanzadeh Heravi, B., Bell, D., Lycett, M., Green, S.
Snelling, D, 2010. Towards Ontology Based E-
Business Standards. In Proceedings of the Interna-
tional Conference on e-Business, pages 169-175,
SciTePress, DOI: 10.5220/0002995901690175.
Gruber, T.R., et al., 1993. A translation approach to porta-
ble ontology specifications. Knowledge acquisition 5.
Baader, F., McGuinness, D.L., Nardi, D., Patel-Schneider,
P.F., 2007. The Description Logic Handbook: Theory,
Implementation, and Applications. Cambridge Univer-
sity Press.
Sabelfeld, A., Myers, A.C., 2003. Language-based infor-
mation-flow security. IEEE Journal on Selected Areas
in Communications 21, 5–19. doi:10.1109/JSAC.2002.
806121
Shapkin, P., Demchenko, A., 2014. Ontology-Based Type-
System Integrated Tools to Infer Facts about Infor-
mation Objects for .NET Platform. In Autom. Doc.
Math. Linguist. 48, 52–59 DOI:10.3103/S0005105514
020034.
Wolfengagen, V., Roslovtsev, V., Shumsky, L., et. al.,
2013. Applicative Approach to Information Processes
Modeling - Towards a Constructive Information Theo-
ry // In the proceedings of 15th International Confer-
ence on Enterprise Information Systems (ICEIS 2013).
pp. 323–328.
Shumsky, L., Roslovtsev, V., Kazantsev, N., et al., 2013.
A synthetic approach to building a canonical model of
subject areas in the integration bus // In the proceed-
ings of ISKO-Maghreb, 2013 3rd International Sym-
posium (ISKO 2013): IEEE Xplore : Marrakech,
Morocco - C. 1 - 7; DOI 10.1109/ISKO-
Maghreb.2013.6728118
UsageofSemanticTransformationsinB2BIntegrationSolutions
157
