Approach to Cover the Interoperability Criterion in EIS:

Application to Storage Bid-requests in the Big Data of the BPIS

Khaoula Fatnassi

, Sahbi Zahaf

1,2 b

and Faïez Gargouri

MIRACL Laboratory, Higher Institute of Computer and Multimedia, University of Sfax, Sfax, Tunisia

Higher Institute of Computer Sciences, University of Tunis El-Manar, Tunis, Tunisia

Keywords: Enterprise Information System, Bid Process Information System, Interoperability, BPEL-WS, SOA, Big Data.

Abstract: Enterprise Information System (EIS) must cover the interoperability criterion between its business and

technical infrastructures. Nevertheless, the “vertical fit” problems, which has deduced from the business

infrastructure handicap the exploitation of this criterion. To overcome this failure, we propose in this paper

our solutions to reduce the gap between business and technical infrastructures of an EIS. Particularly, we

describe our approach in three main phases: Business, Middle and Technical views, in order to cover the

interoperability criterion between these infrastructures. We apply our contributions to storage bid-requests in the

Big Data of the Bid Process Information System (BPIS).

1 INTRODUCTION

Nowadays, the exploitation of new information and

communications’ technologies become increasingly a

necessary condition for the evolution of any enterprise.

It influences at the nature of its collaboration with its

customers, its partners and its subcontractors as part

of their project achievements. The competitiveness of

each enterprise depends on: its degree of integrity

respecting the Business Processes that it covers; its

degree of interoperability with its customers, partners

and suppliers that it coordinates; and its flexibility in

relation to its power to adapt skills and resources to

support market requirements (Zahaf, 2017 b).

The development of any enterprise depends on the

quality of its Enterprise Information System (EIS)

that it manipulates. Thus, the implementation of an

EIS is a delicate step to achieve, since its conception

until its exploitation and evolution (Zahaf, 2017 a).

The urbanization approach (Fournier-Morel et al,

2008) (Bertin, 2014) implements this EIS according

two infrastructures. Note that Each infrastructure

incorpotates two levels. The business infrastructure

which is the phase relating to the design of the EIS,

covers “Business view” and “Functional view”. The

“Business view” represents the modelling of the

https://orcid.org/0000-0002-4451-3663

https://orcid.org/0000-0002-3493-785X

business processes used by the enterprise. The

“Functional view” represents the functions and flows

information’s towards business processes regardless

of the technologies used.

The technical infrastructure which is the phase

relating to the design of the EIS, covers “Application

view” and “Physical view”. The “Application view”

represents the applications used to support functions

and flows, and to equip the processes. The “Physical

view” represents the material infrastructure.

Nevertheless, the Urbanization approach has to

deal with “three fit” problems (Zahaf, 2014). The

“vertical fit” represents the gap between business and

technical infrastructures. The “horizontal fit”

translates the deficiencies of identifying software’s

that cover the EIS at its business level (induced by the

“vertical fit” problems). In addition, this fit translates

the intra-applicative communications problems. The

“transversal fit” interprets the inter-applicative

communications problems. Such problems handicap

the exploitation of the integrity, interoperability and

flexibility criteria’s (Zahaf, 2014). In this paper, we

are interested to resolve the “vertical fit” problems of

the EIS. Thus, we describe our solutions to ensure the

interoperability criterion, which represent intra-

enterprise and inter-enterprises communications.

Fatnassi, K., Zahaf, S. and Gargouri, F.

Approach to Cover the Interoperability Criterion in EIS: Application to Storage Bid-requests in the Big Data of the BPIS.

DOI: 10.5220/0009563600820088

In Proceedings of the 17th International Joint Conference on e-Business and Telecommunications (ICETE 2020) - Volume 3: ICE-B, pages 82-88

ISBN: 978-989-758-447-3

Figure 1: Enterprise Information System reference model:

“three fit” problems (Zahaf, 2014).

Our approach in EIS is defining into three main

phases: Business, Middle and Technical views. We

apply our contributions to storage bid-requests in the

Big Data of the Bid Process Information System

(BPIS).

This work is organizing as follows. The second

section describes our EIS approach to treat

interoperability criterion. The third section represents

the specification of our approach in the context of the

BPIS. The fourth section shows the application of our

contributions to storage bid-requests in the Big Data

of the BPIS. We end this work by the conclusion and

with the prospects of our future works.

2 OUR APPROACH TO EXPLICIT

THE EIS INTEROPERABILITY

In order to cover “vertical fit” problems effects, we

propose an approach to guarantee the interoperability

criterion between business and technical

infrastructures of an EIS. Figure 2 shows our

approach to cover this criterion.

Our solution has based on modelling business

processes using BPMN (OMG, 2011) and executing

these processes using BPEL-WS (OMG, 2007).

Indeed, we rely on the work of (Zahaf, 2017 a) which

showed that BPMN and BPEL are the most suitable

languages to define and even to implement business

processes. In fact, each enterprise has its own strategy

to exploit its processes flows. The BPEL standardizes

the definition format of business processes flows.

This language guarantees the interoperability

criterion inside and between enterprises by using Web

Services (BPEL-WS). Indeed, BPEL permits to

orchestrate interactions between Web Services using

XML documents. However, BPEL was criticizing by

the difficulty to implement in the “application view”

business functions defined at the business

infrastructure. This premise increases the gap

between business and technical levels, and enhances

“vertical fit” problems effects. In order to deal with

this failure, we integrate SOA approach to define

functions as services in the “functional view”. This

solution facilitates the alignment and coherence

between business and technical infrastructures of an

EIS “SOA participates in the resolution of “vertical

fit” problems” (Zahaf, 2014). SOAP technology that

exploits SOA approach, permits to implement WS. It

allows the transmission of data between remote

applications while ensuring their security. However,

this transmission was characterizing by the heaviness

of the XML documents exchanged by the SOAP

services (Papazoglou, 2018). In order to cope with

this limitation, we propose to integrate REST-WS

technology with the JSON format that ensures faster

transmission than XML (Castillo, 2011).

Furthermore, we treat our interoperability

propositions between the two infrastructures of the

EIS. In fact, we use the Big data (Fermigier, 2012)

technologies to exploit the “application view” and we

show that our communication interface’s permits to

ensure data availability for a large volume and variety

of data (structured or unstructured). We prove that our

contributions permit to resolve “vertical fit” and

“horizontal fit” problems.

Figure 2: Our approach in Enterprise Information System to

treat the interoperability problems.

We propose to implement our approach in three main

phases (Figure 3):

 Business Level: we apply the BPEL language

to automate and implement the business

process. Note that the input of this phase is the

process modeled with BPMN language.

 Middle Level: we use in the frontend: HTTP

(Pasternak, 2016), Typescript (Bierman, 2014),

HTML and CSS (Frain, 2012). In the Backend,

we use SOAP/XML as a "repository". The

Output:

Process

automated

in BPEL.

BIG DATA

Input:

Process

modelled

in BPMN.

Business

Level

Middle

Level

Approach to Cover the Interoperability Criterion in EIS: Application to Storage Bid-requests in the Big Data of the BPIS

rapidity of transmissions was ensuring by the

conversion from XML to JSON format in the

Controller.

 Technical Level: we utilize MongoDB and

Hadoop technologies to exploit the Big Data

approach: (1) Hadoop is an open source

platform, which use to store and process the

huge volume of data; (2) MongoDB is a

document-oriented database characterized by

the notion of replication: the data is on multiple

servers, leading to greater fault tolerance

(Fermigier, 2012).

Figure 3 shows our implementation in EIS to

guarantee the interoperability criterion.

Figure 3: Implementation of the Interoperability in EIS.

In the next section, we apply our contributions to

explicit the interoperability criterion in the context of

the Bid Process Information System or BPIS (Zahaf,

2017 a).

3 SPECIFICATION OF THE BPIS

INTEROPERABILITY

The owner emits a specific offer in order to acquire a

product. After a certain delay, he receives proposals

from different contributors, which submit their

techno-economic expertise. The bid process studied

the product design activity by optimizing factors of

production (cost, price, quality of services and risks).

It is a key business process, which influences the

enterprise’s survival and strategic orientations

(Zahaf, 2017 a). The Bid Process Information System

or BPIS that supports the bid process must support the

interoperability (Zahaf, 2014). In fact, this criterion

guarantees communications between enterprises

involved to contribute together in the construction of

the techno-economic proposal that materializes the

bid proposition.

In the following, we propose to apply our

approach, which ensures the interoperability in the

functional scope of the BPIS. Concretely, we exploit

our three phases in the context of the BPIS.

3.1 Business Level of the BPIS

We rely on the work of (Zahaf, 2017 a) which

described the “bid process” modelling using BPMN.

The proposed modelling covers three main processes:

“assessment the eligibility of the bid”, “elaboration of

the bid proposition”, and “closure of the bid process”.

Particularly, we are interested at the phase, which

treats design activity of the product: “elaboration of

the bid proposition”.

Figure 4: Extract of our implementation that covers the

techno-economic Bid proposition with BPEL.

We extend the work of (Zahaf, 2017 a) by

implementing the techno-economic bid proposition

with BPEL. Figure 4 shows an extract of our

implementation.

During The construction of the technical solution,

the manufacturing tree permits to specify products to

manufacture and others to purchase. Figure 5 describes

Business Level

BPEL-WS

Middle level

Http

Request

Technical Level

Controlle

JSON

View

HTML5

CSS3

Typescript

MongoDB

(

NoS

)

Hadoop

Repositor

SOAP/XML

HTTP

Request

HTTP

Response

ICE-B 2020 - 17th International Conference on e-Business

Figure 5: Fragment of code in BPEL that represents the

selection type of product.

an extract of the fragment of code in BPEL that repre-

sents the selection type of product required to build the

technical solution. It shows the different alternatives

described by “control flows” to reuse an existing

product, purchase product or manufacture product.

The construction of the technical solution ends up

with incorporating the financial-proposal. It includes

the cost of the technical-proposal and an interval that

specifies the future price of the manufactured product

on the market. In addition, a study that assesses risks

related to the creation of the technical-proposal,

permit to support each contributor for its decision at

the end of this phase: to readjust the proposal, either

to finalize and transmit it to the owner or to abandon

the process (Zahaf, 2017 a).

3.2 Middle Level of the BPIS

BPEL was criticizing by the difficulty to implement

in the “application view”, services defined in the

“functional view”.

In order to deal with this failure, we integrate

SOAP-WS to solve the interoperability gap between

the business and the technical levels of the BPIS.

Figure 6 shows an extract of the conversion from

BPEL to SOAP/XML.

It is true that SOAP permits the transmission of

data while ensuring their security. However, this

transmission was characterizing by the heaviness of

the XML documents exchanged by the services. In

order to deal with this failure, we use SOAP/XML as

a "repository" and we convert XML to JSON format

in the Controller. Figure 7 shows a fragment of code

Java EE that convert XML to JSON of User Model.

Figure 6: Extract of the conversion of the BPEL techno-

economic Bid proposition to SOAP/XML Web Services.

Figure 7: Fragment code Java EE that convert XML to

JSON of User Model.

Figure 8: Fragment code JSON in angular 7 of User Web

Services.

Approach to Cover the Interoperability Criterion in EIS: Application to Storage Bid-requests in the Big Data of the BPIS

The conversion of XML document to a JSON

enables to exchange data’s between Web Services.

Figure 8 shows a fragment of JSON code writing with

angular 7 that describes the response of the WS of

user by HTTP.

In fact, HTTP verbs to these actions: GET (to read

information), CREATE (to create information), PUT

(to update information) and DELETE (to delete

information).

3.3 Technical Level of the BPIS

We propose to exploit our contributions, to evaluate

the response time of request that permits to insert

documents describing the characteristics of

manufactured products (code, cost, price, risks,

label, quantity, etc.), in the non-relational Database,

that’s why we propose to integrate Big Data

approach (Fermigier, 2012) at this level.

In fact, the need on real time response is very

important for any enterprise, which evolves in a

market characterized by stiff competition,

especially, in the context to contribute on the bid

proposition. The Big Data approach is characterizing

by:

 Volume: permits to treat a huge amount of data,

which produces at every instant and stores in

database.

 Velocity: permits to optimize the frequency on

which data exchanges, between the client and

the server.

 Variety: represents an amount of variety of

dataset with different forms (texts, documents,

images, sound, videos etc.), or different types of

data that can be structured (data is represented

with predefined format for example: image

video, etc.) or not structured (data is represented

without predefined format for example: text).

Big Data support technologies and tools to treat

different problems: store, treat and access the big

volume of data; an important variety of data type; and

especially the access of data with a faster speed to

reach. These technologies are: (1) non-relational

database (NoSQL) and (2) Hadoop (High-

availability Distributed Object-Oriented Platform)

(Piazza, 2013).

A distributed non-relational database offers a

huge volume of data with fast random access. It

allows the fault tolerance in the case of a big volume

of stocked data. For example, we use MongoDB,

which is oriented distributed document database and

an open source Big Data framework. We choose

MongoDB because it bases on the principle of

master-slave, and it has the capacity to store an

important volume of unlimited data. Its principle is

characterizes by the notion of replication in such a

way data is on multiple servers, which leading to

having the fault tolerance. Furthermore, the division

and the duplication of documents realize as the most

requested documents be in the same server.

MongoDB database is exploiting by two fundamental

components of Hadoop: (i) HDFS: Storage

component, (ii) MapReduce: Treatment component.

In fact, Hadoop is an open source apache framework

written in java. It supports a huge volume of data

approximately pet octets of data.

4 STORAGE OF BID-REQUESTS

IN THE BPIS BIG DATA

We propose to evaluate the response time that

represents the duration of execution between the

moment of sending a message and the moment of the

reception of results of the request.

In our approach, we are interested especially to

accomplish an experimental study of response time

with non-relational database « MongoDB » and «

Hadoop » (Big Data).

We chose to test the response time of Web Service

while using Big Data. Besides, we measure the

response time for example: the response time of the

bid of manufactured product by 100 millisecond (ms).

Figure 9: Fragment of function intervallFunc() for products

design during a period of 100 ms with Big Data.

ICE-B 2020 - 17th International Conference on e-Business

Figure 9, Figure 10, Figure 11 and Figure 12

present the obtained results by testing the response

time of Big Data.

Figure 9 depicts JavaScript code of the

intervallFunc() function. It represents the number of the

inserted documents into a relational database Big Data,

during a period of 100ms. We add, also, properties

(code, cost, price risks, label, and quantity) which is

relative for each inserted product.

Figure 10: Extract the compilation of MongoDB database

that store a dataset of product.

Figure 11: Extract of MongoDB database that store a

dataset of product in the progress of compilation.

After the compilation of the intervallFun() function,

Figure 10 and Figure 11 demonstrate that Big Data

approach is more optimal for the storage a huge volume

of datasets: more than (+232.7 k) during a period of 100

ms for inserted documents.

We notice that the response time of Big Data

permits to store more than thousands of inserted

documents during 100 ms. We deduce that the response

time of Big Data is one of the most efficient database

systems that it aims to ensure a faster speed, and to store

a large variety, huge volume and high velocity of data

sets.

Figure 12: The inserted document of Big Data (MongoDB

and Hadoop) in progress of the compilation.

Figure 12 shows an extract of MongoDB database

that store user, product and message datasets, required

to definite the techno-economic bid proposition.

5 CONCLUSIONS

In this paper, we have proposed our contributions to

ensure the interoperability criterion in the Enterprise

Information System (EIS), which is the executing

support of business processes. Concretely, we have

defined an approach defining into three main phases.

In the “Business View”, we have proposed to treat

this criterion by modelling business processes using

BPMN and executing them using BPEL language.

The proposed solution permits to guarantee

interoperability in the business infrastructure of the

EIS.

Approach to Cover the Interoperability Criterion in EIS: Application to Storage Bid-requests in the Big Data of the BPIS

In the “Middle View”, we have proposed to

integrate SOA approach to define functions as

services in the “functional view” of the EIS. In fact,

BPEL was criticizing by the difficulty to implement

in the “application view” business functions defined

at the business infrastructure. In fact, the SOAP

allows the transmission of data between remote

applications. However, this transmission was

characterizing by the heaviness of the XML

documents exchanged by the SOAP services. To

overcome this limitation, we have proposed to

integrate JSON messages for the data transmissions

between Web Services (WS). The proposed solution

permits to cover “vertical fit” problems effects

between business and technical infrastructure of the

EIS.

In the “Technical views”, we have relied on the

Big Data technologies in the “application view” of the

EIS (MongoBD and Hadoop). In fact, our main

objective consist to check communications validities

between business and technical infrastructures of the

EIS. Moreover, we needed to store a large volume and

variety of data.

We have applied our contributions to evaluate the

response time of request that permits to store

documents describing the characteristics of

manufactured products (code, cost, price, risks, label,

quantity, etc.) in the context to contribute on the bid

proposition.

In our future work, we propose to treat the

interoperability between applications that covers the

technical infrastructure of the EIS. Our perspectives

consist to deal with “horizontal fit” and “transversal

fit” problems.

REFERENCES

Bertin, E., Crespi, N. (2014). Urbanization of information

systems: an outdated method?. In Digital Enterprise

Design & Management (pp. 83-91). Springer, Cham.

Bierman, G., Abadi, M., Torgersen, M. (2014, July).

Understanding typescript. In European Conference on

Object-Oriented Programming (pp. 257-281). Springer.

Castillo, P. A., Bernier, J. L., Arenas, M. G., Merelo, J. J.,

& Garcia-Sanchez, P. (2011). SOAP vs REST:

Comparing a master-slave GA implementation. arXiv

preprint arXiv:1105.4978.

Fermigier, S. (2012). Big Data & Open Source: une

convergence inévitable?. Livre Blanc (http://fermigier.

com/blog/2012/03/new-whitepaper-big-data-open-

source/).

Fournier-Morel, X., Grojean, P., Plouin, G., & Rognon, C.

(2008). Le guide de I'architecte.

Frain, B. (2015). Responsive web design with HTML5 and

CSS3. Packt Publishing Ltd.

OASIS, Standard. (2007). "Web services business process

execution language version 2.0." http://www. oasis-

open.org/committees/tc_home. php? wg_abbrev=

wsbpel.

OMG, B. P. M. (2011). Notation (BPMN) Version 2.0

(2011). Available on: http://www. omg.

org/spec/BPMN/2.0, 2.

Papazoglou, M. P. (2008). SOAP: Simple Object Access

Protocol. Tilburg, Holanda. Piazza, Adriano

Girolamo."NoSQL".http://doc.rero.ch/record/209288/fi

les/Travail_de_BachelorNoSql_Etat_de_l_art_et_Benc

hmark.pdf.

Pasternak, M. (2016). U.S. Patent No. 9,231,819.

Washington, DC: U.S. Patent and Trademark Office.

Zahaf, S., Gargouri, F. (2014). ERP Inter-enterprises for the

Operational Dimension of the Urbanized Bid Process

Information System. 6

Conference on ENTERprise

Information Systems, Journal of Procedia Technology,

Vol. 16, p. 813-823, Elsevier Ltd, Troia, Portugal.

Zahaf, S., Gargouri, F. (2017a). The Urbanized Bid Process

Information System. 21

International Conference in

Knowledge Based and Intelligent Information and

Engineering Systems, Vol. 112 (2017), Journal of

Procedia Computer Science, pp. 874-885, Elsevier Ltd,

06-08 Septembre, 2017, Marseille, France.

Zahaf, S., Gargouri, F. (2017b). Specification for the

Cooperative Dimension of the Bid Process Information

System. 9

Conference on ENTERprise Information

Systems, Journal of Procedia Computer Science, 121,

1023-1033 Elsevier Ltd, Barcelona, Spain.

ICE-B 2020 - 17th International Conference on e-Business