A FRAMEWORK TO SUPPORT INTEROPERABILITY

AND MULTI-CHANNEL DELIVERY AMONG HETEROGENEOUS

SYSTEMS: TRAME PROJECT

Ugo Barchetti, Alberto Bucciero, Luca Mainetti and Stefano Santo Sabato

GSA Lab, Innovation Engineering Dept., University of Salento, Lecce, Italy

Keywords:

E-Procurement and Web-based Supply Chain Management, Middleware Integration, Legacy Systems,

Enterprise-Wide Client-Server Architecture, Database Security and Transaction Support, Multi-channel,

Multi-modal.

Abstract:

The e-commerce has become a point of strength for the companies that desire to increase their billing enlarging

their clients park and reducing the management costs. Therefore the demand has been born to use platforms

able to support the interoperability between heterogeneous systems and the multi-channelling with variegated

devices to access different services in reliable manner and to allow, so, a spread of the market toward partner

with particular needs. Furthermore, many available services have been typically designed for a single channel

the web one. In a real world scenario, an ever-growing number of users take advantage of different kind of

communication channel and devices. In this paper we propose a B2B oriented framework able to support

the interoperability among heterogeneous systems developed according to the ebXML reference model for

the business messages interchange suitable to any B2B marketplace that foresees the commercial interaction

among partners with different roles and proﬁles (including channel and device). Such framework has been

developed and experimented for the TRAME research project that has as objective to create a room of district

compensation of the peaks of productive ability demands within the Textile/Clothing sector and to give the

needed infrastructure for the business messages exchange among the partners of the productive spinneret.

1 INTRODUCTION

The evolution in ICT opens new perspectives in the

development of multi-channel applications that en-

ables the access to operative information systems via

different devices or media format. An objective is

therefore the development of augmented services that

enhance their effectiveness by adapting the behav-

ior to different devices and communication means.

The use of different devices determines technologi-

cal requirements that concur to the deﬁnition of dif-

ferent interaction modes (called sometimes conversa-

tions (Boualem Benatallah, 2004)). Therefore, multi-

channel delivery is progressively more integrated to

support seamless channel switches. For example, a

cellular phone and a personal computer introduces

new issues because of not only screens and keyboards

of different sizes, but also because a personal com-

puter is statically located on a ofﬁce desk, while a

cellular phone dynamically changes its spatial posi-

tion with the user. Consequently, the phone channel

enables for contextualized interaction that requires

location-aware services. In the enterprise applications

the database provides the medium to the applications

to save and to share data and metadata. Nowadays,

the enterprise applications are evolving towards Web

Applications or Web Services that have, also them,

the need to save and to share data and metadata. The

ebXML Registry (OASIS, 2005) is a powerful and

ﬂexible registry and it is the implementation of a

repository founded on a generic and extensible infor-

mative model; it provides a set of services that allow

the sharing of information among different commer-

cial party in order to integrate their business processes

founding itself on the ebXML speciﬁcations. The reg-

istry makes available the needed information to ac-

complish a typical service application. The shared in-

formation (as a ﬁle, application, multimedia data or

XML document) are kept as objects in a repository

and managed by the ebXML Registry services. The

ebXML registry provides advanced services of infor-

mation management and through ebXML Collabora-

tion Proﬁle (OASIS, 2005) speciﬁcations, it allows

the high level of formalization of the cooperation.

179

Barchetti U., Bucciero A., Mainetti L. and Santo Sabato S. (2008).

A FRAMEWORK TO SUPPORT INTEROPERABILITY AND MULTI-CHANNEL DELIVERY AMONG HETEROGENEOUS SYSTEMS: TRAME

PROJECT.

In Proceedings of the Tenth International Conference on Enterprise Information Systems - DISI, pages 179-189

DOI: 10.5220/0001690901790189

 SciTePress

ebXML Registry Services can seem a simple regis-

tration service according to Web Service speciﬁca-

tions similarly to UDDI, however, it allows, besides,

to publish and share the data that formalize com-

pletely not only the service interface proposed by a

public administration, but also the possible sequence

of information exchanges among two or more actors.

UDDI (OASIS, 2005) is an initiative born for creat-

ing a global registry of companies, organizations or,

generically, suppliers of good and services, organized

for services and products: a medium through which

to be able to ﬁnd suitable partners with which to in-

tegrate own productive chain in automatic and efﬁ-

cient manner. The lack of centralized systems through

which to get information around the potential com-

mercial partner, has involved to drastically limit the

potentialities that the interconnection offers. In or-

der to obviate such a problem, various attempts have

been developed as marketplaces and online address

books, although these have not produced exhaustive

results in the search of potential commercial counter-

parts. In this paper we propose an extension of the

concept of registry and its implementation in terms of

multi-channelling and multi-modality. Therefore, we

have structured this paper in three parts. In the ﬁrst

one is exposed a survey of software system for the

B2B integration and the interoperability. In the sec-

ond one is exposed the motivation for the new archi-

tecture and the detailed explanation of the proposed

framework. In the last one, the project experimenta-

tion is presented explaining the reached objectives.

2 RELATED WORKS

In this section we will analyze tools and software sys-

tems proposed by suppliers of marketplace solutions

proper for the B2B integration and the interoperabil-

ity. BEA WebLogic platform (WebLogic, 2005) is

a software foundation for the development and the

management of enterprise applications. BEA We-

bLogic platform tries to simplify the processing al-

lowing the IT organizations to develop theirs appli-

cation infrastructure providing an understanding of

the business guidelines to follow. BEA WebLogic

Platform combines three core products (Server, Inte-

gration, and Portal) to provide a platform for devel-

oping and deploying enterprise applications and ser-

vices. BizTalk Server 2006 (BizTalk, 2006) is the

Microsoft server for the development of solutions for

the business processes integration. BizTalk doesn’t

represent a new solution, but it is born from a col-

lection of existing tools, besides Microsoft guaran-

tees the full adhesion of these to the XML 1.0 spec-

iﬁcations (XML, 2006). BizTalk Server is able to

elaborate the followings formats: EDI (EDI, 2006)

(ANSI X12 and EDIFACT (EDIFACT, 2007)), well

formed XML documents, Document Type Deﬁnitions

(DTD, 2002), hierarchical Flat File, delimited and po-

sitional (for instance, SAP (SAP, 2007) and IDOCS

(IDoc, 2007)). BizTalk conforms to Business Pro-

cess Execution Language (BPEL) standards. Com-

merceNet’s eCo architecture (eco, 2007) provides an

interoperability framework that consists of an Archi-

tectural Speciﬁcation and a Semantic Speciﬁcation.

The Architectural Speciﬁcation presents information

about an e-commerce system in seven different cat-

egories. The Semantic Speciﬁcation, on the other

hand, provides a simple set of business documents

that can be used inside the eCo framework. Roset-

taNet framework (RosettaNet, 2007) consists of Part-

ner Interface Processes (PIPs), a master dictionary

and an implementation framework, the relationship

among these parts can be expressed with the follow-

ing analogies: RosettaNet dictionaries provides the

words, the RosettaNet Implementation Framework

(RNIF) acts as the grammar and RosettaNet Partner

Interface Processes (PIP) form the dialog. Commerce

XML (cXML) (cxml, 2007) is a standard for facili-

tating exchange of catalog content and transaction in-

formation between trading partners. The cXML cata-

log deﬁnitions consist of three main elements (Sup-

plier, Index, Contract). Seller organizations create

catalogs so that buying organizations’ procurement

applications can see their products and service of-

fering (Dogac and Cingil, 2001). The Sun Service

Registry is an open source implementation based on

the ebXML Registry speciﬁcations. Besides this im-

plementation supports UDDI speciﬁcations provid-

ing a discovery interface of the services through re-

quests developed using this standard speciﬁcations.

The combined support for both these standards in an

only package, offered by the Sun Service Registry,

provides wide management capability of the Web Ser-

vices, for a solution that tries to become a point of ref-

erence for the Service Oriented Architecture (SOA).

The freebXML Registry project (freebXML, 2006)

is a open source project that provides a free imple-

mentation of the ebXML Registry 2.0 speciﬁcation.

The project is managed by many authors of the same

standards of OASIS and is introduced therefore as

”the ﬁrst mostly compatible implementation of the

ebXML Registry speciﬁcations”. Usability, ﬂexibil-

ity and multi-channelling, key issues for our approch,

seem to be weak points of previous systems.

ICEIS 2008 - International Conference on Enterprise Information Systems

180

3 TRAME PROJECT

Global economy improves cooperation among enter-

prises. Effective cooperation is important for the en-

terprises to create and better respond to the valuable

market opportunities. Virtual enterprises (VEs) are

an appropriated cooperation alternative and a way of

gaining competitive advantage for enterprises. VE

consists of independent enterprise, which share the

costs and technologies to catch fast changing op-

portunities. One of the main goals of the TRAME

Project is to overcome the limits due to the local-

ism of some “self-centered close-enterprises” indus-

trial districts especially in terms of ﬂexibility of re-

sponse the market requests, proposing a dynamic re-

conﬁgurable collaborative networked structure based

on cooperation among different actors. Recent ap-

proaches in such a ﬁeld goes under different names:

Intelligent Enterprise (Quinn, 1992), the Extended

Enterprise (J. Browne and Wortmann, 1995), the Ag-

ile/Virtual Enterprise (Cunha, 2000) and other mod-

els, each with its characterizing nuances. Coopera-

tion is a key aspect in the VE paradigm (Camarinha-

Matos and Afsarmanesh, 1999) (Camarinha-Matos

and Afsarmanesh, 2001). In a VE, autonomous en-

terprises cooperate with each other to form a dynamic

alliance in order to meet the changing market rapidly

and achieve a common goal. Because a VE is built

according to the changing business opportunity, the

cooperative partners in a virtual enterprise may be

different. These partners may have different behav-

iors, different motivations, and different priorities.

They can efﬁciently utilize complementary capabili-

ties and resources to achieve their goal in this tempo-

rary alliance, optimizing the utilization of resources,

reducing high investments and risks. In this scenario,

TRAME projects aims to deﬁne a ﬂexible technologi-

cal framework, that, exploiting the ebXML speciﬁca-

tions, allows the cooperation of the enterprises of T/C

industrial sector, enabling each of the to share their

productive capacity providing a multichannel deliv-

ery of the business information.

3.1 History

Our experience in the ﬁeld of VEs started with

MODA-ML project (Moda-ML, 2007). The MODA-

ML project was funded by the European Commission

(IST Take-Up Action Line IV.2.5, V Framework Pro-

gram). The project aimed to facilitate the ﬂow of tech-

nical and operational information between the ﬁrms

of the T/C supply chain thanks to the exchange of

XML documents via Internet. The concrete objective

of the project was the deﬁnition of a common data

format, suitable for the exchanges of information via

Internet along the supply chain: a format with fea-

tures enable to simplify the legacy systems integra-

tion. The quality of the documents was thought to be

high enough to propose their formalization as a part

of an international standard for the T/C sector in Tex-

tWeave initiative. TexWeave (Moda-ML, 2007) is

a standardization initiative of CEN (European Com-

mitte for Standardization), promoted by Euratex (Eu-

ropean Association of the T/C Industry). The aim

of TexWeave is the deﬁnition of a common reference

model for the data exchange (and enterprise network-

ing) in the European T/C industry. In the past an-

other initiative, TexSpin, was promoted by CEN and

Euratex in order to start the construction of an Eu-

ropean common language; then, with TexWeave, Eu-

ratex and CEN intended to improve that experience,

covering new aspects of the supply chain and begin-

ning to face the issues of cross-sectorial collabora-

tions (towards footwear, furniture and automotive in-

dustry). Starting from the previous results, during the

DISCoRSO project (Discorso, 2005) we investigated

”Inter-marketplace interoperability”. It had its main

result deploying a new and innovative ICT platform

for brand new processes and technologies in order to

coordinate enterprises belonging to the T/C sector but

being member of different marketplace, thus using a

different formats and operations for their electronic

data interchange transactions. The TRAME project is

the last step in our research activity.

3.2 Motivations for a New Architecture

The central problem on which the TRAME project

wants to operate, is to create a district compensa-

tion of the peaks of productive ability demands. For

this purpose it is needed to guarantee not only the

quality and the format of the exchanged information,

but also the information compatibility among differ-

ent systems. Multi-channel and multi-modal delivery

can offers the proper interoperability to make avail-

able all the needed elements to the business manager

to optimally plan the production. From the instant

of the business message (i.e. a textiles purchase or-

der of fabric supplying process) reception in elec-

tronic format, the companies have to be able to an-

swer in brief times on their own capability to satisfy

it in optimal manner, also resorting to external avail-

able resources absolutely in transparent way. Needed

condition is that such information have dynamically

and accurately been made available. Practically every

company on the one hand, publish for all partners the

own productive ability (capability to effect well de-

ﬁned manufactures with suitable characteristics) and

A FRAMEWORK TO SUPPORT INTEROPERABILITY AND MULTI-CHANNEL DELIVERY AMONG

HETEROGENEOUS SYSTEMS: TRAME PROJECT

181

the own availability (real availability of the machin-

ery for new orders of production in a well deﬁned pe-

riod). On the other hand, after the production plan-

ning, the company can indifferently see own machin-

ery and the external resources and optimally allocate

the own loads. From an architectural point of view

in an informative collaborative system as TRAME,

the cooperation among different organizations is got-

ten sharing and coordinating online services (usually

called e-service). These services must be ﬂexible not

only in the deploy mode(distributed and centralized

system), but also in the access channels.

3.3 Reference Model

After a deep analysis of the various standards,

we have considered the speciﬁcations proposed by

ebXML as the more ﬂexible and the more extensible

reference model. The United Nations (UN/CEFACT)

and OASIS sponsored the ebXML speciﬁcations for

use in e-business frameworks. ebXML Business Pro-

cess Speciﬁcation Schema (BPSS) (OASIS, 2005) is

a proposed standard for specifying collaborations for

use in exchanging business documents through a set

of choreographed transactions. A business transaction

is an atomic unit of work between trading partners.

Each business transaction has one requesting (incom-

ing) document and an optional responding (outgoing)

document. BPSS also supports business signals, or

application-level documents that communicate a busi-

ness transaction’s current state (i.e. an acknowledg-

ment document). Each actor that takes place to the

business transaction is described by a CPP (Collab-

oration Protocol Proﬁle) (OASIS, 2005) which de-

scribes IT capabilities in terms of supported transport

protocols, messaging, security constraints, and bind-

ings to the business process. ebXML also provides

the CPA (Collaboration Protocol Agreement) (OA-

SIS, 2005) which describes the capabilities that two

parties have agreed to use to perform a business col-

laboration. Aligned to this ebXML approach there is

a set of federated electronic Registry services, that al-

low partners to discover each other and, more impor-

tantly, to store central deﬁnitions and the components

that are needed to conﬁgure the interchange between

them. These can then also be catalogued and shared

across an industrial community. The last feature of

ebXML is to provide secure and reliable communica-

tions across the Internet. A special XML based mes-

saging transport system based on XML SOAP server

foundation was developed. This is known as ebMS

(ebXML Messaging Service) (OASIS, 2005) which

is universally the most common component used by

implementers of ebXML. The ebMS server has now

evolved into a sophisticated component that, not only

exchanges messages but also checks trading partner

proﬁles to ensure that the exchanges conform to the

business agreements are being routed accordingly. In

the latest version ebMS can also perform business rule

checking.

3.3.1 Hermes Platform

In order to facilitate and promote the use of ebXML,

several implementations have been provided to help

companies taking full advantages of the technology.

One of the most used implementations is Hermes

(freebXML, 2006) which is an electronic message

transfer gateway that enables the exchange of ebXML

messages. Hermes is developed as a platform for

execution of ebMS that ensure a secure and reliable

information transmission. Hermes (Figure 1) pro-

vides individual listeners in handling different mes-

sage types, but all of them can be operated simulta-

neously in the common platform. Hermes also allows

to send ebXML message only invoking the endpoint

needed and letting the programmer mainly focus on

the business logic. Hermes operates as a Java web ap-

plication; the ebMS messaging capability is operated

by the corresponding plugin, written according to the

ebXML speciﬁcation. The messaging operation re-

quires a database with JDBC connectivity in keeping

track of the messaging status. The message transmis-

sion can be secured by using SSL or electronic cer-

tiﬁcates, which are provided by the public standard.

Figure 1: Hermes components diagram (freebXML, 2006).

3.3.2 Limits and Lacks

Even though Hermes is a robust and performing ar-

chitecture, already at its second major release, it only

supports P2P messaging. In a real and complex enter-

prise scenario often the degree of informatization as

well as business needs are very differentiated. Many

ICEIS 2008 - International Conference on Enterprise Information Systems

182

business sectors, for example the Italian T/C supply

chain are based on a multitude of small and medium

enterprises with very heterogeneous information sys-

tems, different business proﬁles and practices, and

very different connectivity degrees, going from cases

of poor presence over the Internet, usual in the famil-

iar micro enterprise, to the bigger company with sev-

eral servers always connected and reachable. In such

a situation it’s not technically always possible to set

up the Hermes architecture in all the enterprises that

potentially could belong to the marketplace. It is thus

needed to relax the strict requirement of having a Her-

mes client/server installed in the company domain in

order to perform a P2P message exchange, and to al-

low also the smallest and not informatized companies

the access to the marketplace services (partner discov-

ering, B2B messaging, etc.). To overcome this limits

TRAME project provides an extension of the Hermes

architecture toward two main targets:

• Multi-modality: TRAME architecture intro-

duces a service centre that works as mediator be-

tween companies not provided with the Hermes

system through a web application, in a “webmail

fashion”, able to send and receive message to a

generic Hermes server.

• Multi-canality: TRAME architecture is able

to dynamically select and use different delivery

channel (es. SMS, fax) in order to auto adapt it-

self to the speciﬁc business transaction as well as

to the particular Collaboration Proﬁle of business

partner.

3.4 TRAME System Architecture

Following the guidelines offered by ebXML and us-

ing the experiences on Hermes platform, a logical

architecture of inter-company communication system

has been deﬁned, exploiting the speciﬁcation related

to the Message Service v2.0 (OASIS, 2005) and

ebXML Registry. This system is able to give sup-

port to the electronic management of the documental

ﬂow. It manages processes and structured information

(documents) beyond to implement an e-procurement

system that works as electronic broker to mechanize

the buying and selling processes of productive ability.

The TRAME architecture (Figure 2) is based on the

following components:

• Transport System: it manages the information

transmission from a business party to the central

database and vice versa through communication

client called MSH (Message Service Handler) for

the companies supplied with informative system,

moreover it provides a web application for the

companies without informative system.

• Central Infrastructure: it manages the search, the

retrieval and the reservation of productive abilities

and it attends to the advertising of the business

proﬁles and the business agreements between the

companies.

• Supporting Tools: they automate the creation of

own proﬁles according to the CPP ebXML spec-

iﬁcations and the generation of agreements docu-

ments between two different companies according

to the CPA ebXML speciﬁcation.

• The Dictionary: it provides messages schematiza-

tion that describe the most common marketplace

production processes according to the needs and

the roles of the several companies (tertiary, man-

ufacturer, and so on).

In the next paragraph we’ll explain in detail the used

approach for the creation of a multi-modal and multi-

channel architecture and its main components.

3.4.1 Multi-modal and Multi-channel Approach

The lack of a “de facto” standard for the speciﬁc

problem of the Supply Chain Management has lead

to a proliferation of approaches and proprietary so-

lutions suitable to satisfy the requirements of speciﬁc

applicative domains. P2P is a widespread model. This

paradigm is characterized from a multitude of actors

with different informatization level and availability

degree on web. A weak point of the P2P model is

the need of the companies not equipped with infor-

mative system “to make use”, for the interaction with

the counterpart, of the services with which any com-

pany must interact, forcing every spinneret partners to

provide outside accessibility of these services and in-

creasing so, data security risks. Another widespread

model in this area, is the HUB one. In this paradigm,

every interaction between two organizations is medi-

ated from a central entity, a kind of service center,

that manages different supporting tasks as: to carry

the business messages exchanged between the sender

and the buyer, to maintain a copy of the attached data

to every transaction, to expose the spinneret services

through a web application, to work as documents

repository, to work as central authority agency. The

weak points of the HUB model are the following:

• The presence of a central archive containing busi-

ness information is viewed with distrust from the

actors.

• The operation of the entire system is strongly de-

pendent from one only node of the architecture,

the central HUB.

The problems deriving from the previously described

models, have raised the need to use a multi-modal ap-

A FRAMEWORK TO SUPPORT INTEROPERABILITY AND MULTI-CHANNEL DELIVERY AMONG

HETEROGENEOUS SYSTEMS: TRAME PROJECT

183

proach for the deﬁnition of the TRAME architecture,

trying to take advantage from the strength points of

the previous models (P2P and HUB) and giving ade-

quate guarantees to the business partner. So, TRAME

system is based on a hybrid model, and is therefore

composed of two functional distinguished parts: the

peripheral systems and the central infrastructure. The

ﬁrst one are composed essentially from the message

transport system, called ”Message Service Handler”

(ebXML MSH) that interacts with Company Infor-

mation Systems. The central infrastructure stores the

information on the companies, such as their proﬁles

(CPP) and other general information. Furthermore,

for the development of the TRAME architecture it has

been considered the need to give support to the multi-

channel delivery and therefore it has been foreseen

the business messages transmission not only through

the transport protocols that, by now, are consolidated

such as HTTP and SMTP, but also through more spe-

ciﬁc protocols able to interface with different devices

such as SMS and fax.

3.4.2 Transport System

The transport system has been developed as an

ebXML message based applications that allows the

business documents dispatch and reception. Such sys-

tem can ensure the interoperability among all the part-

ners, providing for the needs of all the companies of

great and small dimensions. We made a separation

among:

• Companies of big dimensions that have an infor-

mative system: the message system needed to ex-

change business documents, does not have nowise

to force to eventual changes or updating. These

companies can develop a driver that extracts in-

formation from own informative system and sends

business message through MSH. The driver is the

interface with MSH application.

• Companies of small dimensions without informa-

tive system: they must not have the need to equip

itself of an informative system for being able to

use the message system with own partners.

The interoperability among companies is obtained

making reference to the OASIS ebMS v2.0 speciﬁ-

cations. The business documents come, therefore,

enclosed inside a ebXML envelope and transmitted

to destination, respecting the agreements, deﬁned ac-

cording to CPA speciﬁcation. The communications

among the companies follow the P2P paradigm, but

there is also a central system on which the applica-

tions are installed that allow to the companies without

informative system of being able to use the message

system. Thus, a P2HUB communication joins to the

P2P ones between two companies: it is possible, how-

ever, to consider the central system as a “special” peer

to which a company does not correspond effectively,

but an automated system.

Figure 2: TRAME architecture.

The general TRAME architecture is showed in

the ﬁgure 2.

Companies with Informative System. A com-

pany that has an informative system, does not have to

be forced to modify it: in order to make it compatible

with the ebMS v2.0 speciﬁcations it is needed

therefore to add a module, called MSH (Message

Service Handler), and a MSH connector, that allows

to interface the business informative system to the

MSH. To simplify the integration with the enterprise

informative system, the MSH connector is composed

by a driver that interface itself with the enterprise

database through a polling mechanism. The devel-

opment of this driver is delegated to the companies,

because it’s closely correlated to the internet database

structure. So the driver doesn’t became nowise

invasive for the business informative system and

moreover extends his potentialities, making it able

to communicate with the outside. All that implies to

three types of considerations:

• The business informative system has only the re-

sponsibility of the creation of the business docu-

ments and its storage in the “sending” documents.

The driver must extract from database such docu-

ments, but it cannot access to other information.

• The business informative system doesn’t know of

the MSH existence, not even in phase of messages

reception: the received documents are saved in the

business database from the driver.

ICEIS 2008 - International Conference on Enterprise Information Systems

184

• Any other information, from the notiﬁcation of

communication errors by MSH to the validation

errors, cannot be communicated directly by MSH

to the business informative system.

The ﬁgure 3 shows the components if the transport

architecture for the companies that already have an

informative system. The business informative sys-

Figure 3: MSH communication modules.

tem is not nowise altered and, in order to maintain

a high level of generalization, the only obligatory as-

sumption is that the business informative system has a

database. The driver is taken care to put in communi-

cation the business informative system with the MSH

Client in the both directions. In sending phase, the

driver is taken care to carry out a periodical polling

on the business database. Beginning from contained

information into the database, the driver creates busi-

ness documents in XML format according to cho-

sen and shared schema by all the companies that use

TRAME system, and stores them into ﬁle system

shared with MSH Client. In the receiving phase, MSH

Client sends a document to the driver that carry out

the polling in the shared ﬁle system and takes care to

insert it into the business database. In the MSH Client

architecture we can identify the following modules:

• Filesystem poller: it controls XML outgoing ﬁles,

inside of the shared ﬁlesystem. It is, therefore,

an interface between business informative system

and MSH Client.

• XML Parser: it extracts the message content, veri-

ﬁes the data correctness and takes the needed data

for the transmission.

• Web Service Poller: it cyclically controls the pres-

ence of new messages on the server. Such opera-

tion is developed through the Axis Stub for the

Web Service invocation.

The MSH Server is composed by the Hermes server

opportunely conﬁgured. It will usually ﬁnd beyond

a ﬁrewall, inside of a DMZ. The communication

between MSH Client and MSH Server takes place

using a MSH Stub object.

Companies without Informative System. A

company that haven’t an informative system must

be able to access to the service supporting the lower

possible cost. The solution that better answers to

such requirement is the web application, that allows

the companies to access the service through any

device provided with an Internet connection. The

central system results the perfect candidate in order

to accommodate such a web application, because

it already has all the needed logic to communicate

with the companies (thanks to its MSH module):

the web application will have therefore to interact

with the MSH on the central system (Figure 2). This

system provides several functionalities for every

preventively registered company such as an own

private area. From the private area it can be reached

the ebXML messages exchange functionalities with

the other companies. There is a database for the

storage of the messages exchanged among companies

in which there are the needed information for the

proper working of the overall system, such as the

documents that describe the agreements between

parts (CPA). The Web application uses a typical logic

of the web-mail through which the deputy person

can send, receive, examine the exchanged messages

with the counterpart, controlling also that if there are

errors found during the transaction.

3.4.3 Central Infrastucture

Central infrastructure offers the discovery service of

business partners. It can be a useful support in the se-

lection of the companies using the database contain-

ing the presumptive productive abilities of the bidder

companies. Using these information, the target com-

panies will be able to deﬁne contract contests and,

through the transport system, to opportunely select

the companies with which to establish a partnership.

Therefore, the infrastructure centers is based on a reg-

istry that contains the companies’ productive abili-

ties and manages the negotiations among the com-

panies. Moreover the registry acts as remote repos-

A FRAMEWORK TO SUPPORT INTEROPERABILITY AND MULTI-CHANNEL DELIVERY AMONG

HETEROGENEOUS SYSTEMS: TRAME PROJECT

185

itory to which making reference for being able not

only to discover new company, but also, to ﬁnd busi-

ness documents usable in spinneret for the B2B mes-

sages exchange. The system ﬂexibility can give sup-

port to all the actors of productive spinneret (supplier,

buyer, and tertiary) allowing their identiﬁcation in the

system as bidder and target companies. The registry,

moreover, is perfectly integrated in the transport sys-

tem providing the capability to send service messages

on the contests deﬁned by target companies through

the creation of CPA between bidder companies and

registry. In this context, the registry, considered as

guarantee authority, takes care of the sending and the

receiving of the messages about negotiations among

the companies through a integrated adapter in the web

application that allows the communication with the

transport system. The registry architecture has been

thought in order to decouple the presentation layer

from the business logic layer (Figure 4). The pre-

sentation layer has been designed according to MVC

pattern using struts as reference framework. The busi-

ness logic layer is composed, besides DAO module

for interconnection to the database, also by the trans-

action manager module that manages the interaction

with the MSH Server, and the CPA manager module

that manages the CPA creation between company and

registry.

3.4.4 Supporting Tools

Two applications, named CPP-Editor and CPA-

MatchMaker, have been developed to allow the cre-

ation and editing of the collaboration ebXML pro-

tocols documents. CPP-Editor allows the creation

and modiﬁcation of ebXML CPP proﬁles; CPA-

MatchMaker allows the creation and editing of CPA

agreement. Such tools have been integrated inside

of the central infrastructure, providing the offered

services access through the registry. The CPAs ob-

tained using the CPA-MatchMaker describe Company

to Company communication agreement according to

formalized business processes with the ebXML ebBP

(OASIS, 2005) standard.

3.4.5 Dictionary

For the TRAME project has been used the acquired

experience with TexWeave (Moda-ML, 2007) in or-

der to identify and to use dictionaries of business doc-

uments for the B2B transactions between companies

of the T/C sector. The (template of) documents of

each release are represented by:

• XML Schemas, that are used to validate the XML

documents.

Figure 4: Registry architecture.

• User Guides, that completely describe the struc-

ture and the aim of the business documents, to-

gether with the elements and their coding rules.

• In some cases, Samples and Stylesheets XSL

(XSL, 2007) might be available and can be used to

visualize with a browser the content of the XML

documents. The proposed stylesheets should be

considered as a sample or a reference to be used

directly or customised or ignored at all and substi-

tuted with custom stylesheets.

4 EXPERIMENTATION

TRAME project is born from the textile district of

Biella, Italy; its participants are 23 companies, usu-

ally localized in the district of Biella. They are lead-

ers in woollen sector and their tertiary. They are inter-

ested to share and to optimize the use of own produc-

tive ability for a inter-business collaboration while the

clothing companies are interested to implement with

their suppliers, a fast answer strategy to the evolutions

ICEIS 2008 - International Conference on Enterprise Information Systems

186

Table 1: The supported processes by XML documents.

Process Activities

Fabric Supply Selection of fabrics, Pur-

chase of fabrics, Despatch

of fabrics with groupage,

Fabric delivery and Quality

reporting activities

Subcontracted

Fabric Manufac-

turing

Subcontracted warping,

Subcontracted weaving,

Subcontracted fabric

dyeing-ﬁnishing, Subcon-

tracted fabric printing,

Subcontracted fabric

darning activities

Subcontracted

Yarn Manufactur-

ing

Subcontracted yarn twist-

ing, Subcontracted yarn

dyeing activities

Yarn Supply yarn products, Delivery of

yarn activities

of market and improvement of the performances in

the cloth supply. To obtain concrete feedbacks on the

proposed platform, it has been foreseen and carried

out a validation and experimentation phase with the

companies that had the following objectives:

• Prototype functional validation (trasport system

and central infrastucture).

• Loading of the participants’ registry ofﬁce and

ﬁlling of the archives with technical content.

• Inner test to the companies verifying the inte-

gration and the supporting procedures for the

company informative systems interoperability and

combined test of the centralized services.

From a functional point of view, the centralized ser-

vices structure has been thus delineated:

• Central service: “Repository of the productive

abilities and the availabilities”, accessible via

web, but fed from the business systems thanks to

electronic messages (XML).

• Reservation service of the accessible productive

abilities via web or directly from the company in-

formative systems.

• Development of advanced business front-end for

the management of automatic answer and sucure

communication mechanisms.

In this phase has been foreseen the use of speciﬁc

messages in order to test possible beneﬁts in real con-

ditions. The use cases tested during the experimen-

tation are the “normal” and “short” search. In the

ﬁrst one, the target company deﬁnes a ﬁrst selection

(anonymous) of prospective tertiary according to type

of service identiﬁed, selecting a number of parame-

ters (ﬁrst level parameters) about manufacture, ma-

chinery and service. This pre-selection can help the

target company to deﬁne a subset of bidder compa-

nies able to potentially satisfy the demands. In the

next step, the target company can select other spe-

ciﬁc parameters (second level parameters) to deﬁne

a contract contest. Instead, the short search is used by

target company to ﬁnd the bidder company and de-

ﬁne a contract contest in the same step. In order to

clarify the previous use cases and to understand bet-

ter the cental infrastucture, the ﬁgure 5 shows the se-

quence diagram of “short” search describing the reg-

istry components interactions (Figure 4). The ﬁgure

6 shows the bid request message schema and a frag-

ment of bid request message instance. This message

is generated when the target company begins a con-

tract context (for examaple through a “short” search)

as shown in the ﬁgure 5.

For giving support to the several companies, Dom-

ina, a project partner, it has been taken care to guide

and to check up on the companies for the all experi-

mentation activities, creating the customized adapter

in order to allow the interconnection between the

company informative system and the transport sys-

tem. At last, Domina has been taken care to man-

age through a district server, all the information re-

garding the registry and the trade transactions, de-

ploying the central infrastucture on aforesaid server.

Still, the services pre-industrialization feedbacks are

being collected with the experimentation of a ﬁnal

pre-competitive version of the system. The ﬁrst result

have shown a effective beneﬁt for the companies part-

ner giving thus encouraging feedbacks for the future.

The TRAME project is currently in the experimenta-

tion phase. Estimable results could be evaluated at the

end of such phase.

5 CONCLUSIONS AND FUTURE

WORKS

In this paper has been introduced a B2B oriented

framework able to support the interoperability among

heterogeneous systems developed according to the

ebXML speciﬁcations. The illustrated architecture

bases its strength and effectiveness on technological

solutions of proven value (Hermes), and on market-

place standards that have caught up a wide spread

level (ebXML, J2EE). Moreover, such framework

supports the multi-modal and multi-channel delivery

through a P2P and P2HUB architecture, and the use

of different communication protocols such as HTTP,

SMTP, SMS, and fax. In this framework it has been

A FRAMEWORK TO SUPPORT INTEROPERABILITY AND MULTI-CHANNEL DELIVERY AMONG

HETEROGENEOUS SYSTEMS: TRAME PROJECT

187

Figure 5: Sequence diagram of “short” search use case.

developed a central infrastructure able to give support

to the peaks of productive ability demands within the

T/C sector and to give the needed infrastructure for

the business messages exchange among the partners

of the productive spinneret. The future works foresees

to extend the framework supplying greater ﬂexibility

to the all system and extending the multi-channel abil-

ities. This system has been moreover used also for

the FIM project experimentation in the furniture sec-

tor. At last, a system evolution foresees its use in the

footwear sector through an experimentation with the

companies localized in the area of Casarano (Lecce,

Italy).

ACKNOWLEDGEMENTS

Thanks to Domina S.r.l and ENEA research center for

the contribution to the architecture. Moreover, partic-

ular thanks to the Italian Ministry of the Economic

Development that has founded TRAME project, and

to the 23 companies of the textile district of Biella

(Italy) for their contribution to the experimentation

phase.

REFERENCES

BizTalk (2006). http://www.microsoft.com/biztalk/-

default.mspx. Microsoft.

Boualem Benatallah, Fabio Casati, F. T. (2004). Web

service conversation modeling: A cornerstone for

e-business automation. IEEE Internet Computing,

8(1):46–54.

Camarinha-Matos, L. M. and Afsarmanesh, H. (1999). The

virtual enterprise concept. In Proceedings of the IFIP

TC5 WG5.3 / PRODNET Working Conference on In-

frastructures for Virtual Enterprises: Networking In-

dustrial Enterprises, pages 3–14. Kluwer, B.V., De-

venter, The Netherlands.

Camarinha-Matos, L. M. and Afsarmanesh, H. (2001). Vir-

tual enterprise modeling and support infrastructures:

applying multi-agent system approaches. New York,

NY, USA.

Cunha, M.M., P.-G. v. P. (2000). Towards focused markets

of resources for agile virtual enterprise integration.

In Proceedings of the TC5/WG5.3 Forth IFIP/IEEE,

pages 15–24. Kluwer, B.V., Deventer, The Nether-

lands.

cxml (2007). http://www.cxml.org. Commerce XML.

Discorso (2005). http://www.discorso.eng.it/. Discorso

Consortium.

Dogac, A. and Cingil, I. (2001). A survey and compari-

son of business-to-business e-commerce frameworks.

ACM SIGecom Exchanges, 2(2):16–27.

ICEIS 2008 - International Conference on Enterprise Information Systems

188

DTD (2002). http://xml.coverpages.org/ieeestandards.html.

IEEE Standard.

eco (2007). http://eco.commerce.net/. CommerceNet.

EDI (2006). http://www.w3.org/ecommerce/. W3C.

EDIFACT (2007). http://www.unece.org/trade/untdid/-

welcome.htm. UNECE.

freebXML (2006). http://www.freebxml.org/. freebXML.

IDoc (2007). http://www.thespot4sap.com/articles/. SAP.

J. Browne, P. J. S. and Wortmann, J. C. (1995). Fu-

ture manufacturing system-towards the extended en-

terprise. COMPUTERS IN INDUSTRY, 25:235–254.

Moda-ML (2007). http://www.moda-ml.org/. ENEA.

OASIS (2005). http://www.oasis-open.org/. OASIS.

Quinn, J. (1992). Intelligent Enterprise: A Knowledge and

Service Based Paradigm for Industry. Free Press, New

York.

RosettaNet (2007). http://www.rosettanet.org. RosettaNet.

SAP (2007). http://www.sap.com/index.epx. SAP.

WebLogic (2005). http://www.bea.com/. BEA.

XML (2006). http://www.w3.org/tr/rec-xml/. W3C.

XSL (2007). http://www.w3.org/style/xsl/. W3C.

Figure 6: Bid request message.

A FRAMEWORK TO SUPPORT INTEROPERABILITY AND MULTI-CHANNEL DELIVERY AMONG

HETEROGENEOUS SYSTEMS: TRAME PROJECT

189