Content uploaded by Piero de sabbata
Author content
All content in this area was uploaded by Piero de sabbata on Apr 22, 2016
Content may be subject to copyright.
Standard for eBusiness in SMEs networks:
the increasing role of customization rules
and conformance testing tools to achieve
interoperability
Arianna Brutti — Piero De Sabbata — Angelo Frascella —
Cristiano Novelli — Nicola Gessa
ENEA
Via Martiri di Monte Sole, 4
40129 Bologna
Italy
arianna.brutti@enea.it
piero.desabbata@enea.it
angelo.frascella@enea.it
cristiano.novelli@enea.it
nicola.gessa@enea.it
ABSTRACT: The adoption of a public standard at application domain level enables systems to
interoperate, with a positive impact for eBusiness adoption, especially towards SMEs
networks. Nevertheless conformance to standard specification is not enough to guarantee
interoperability between different implementations.
If we consider interoperability based on three levels (technical, semantic and organisational)
not all the standard specifications aim to cover all the three levels. One of the key enablers of
a 'service based economy' is the interchangeability of the service providers that requires that
all the three levels of interoperability are effectively achieved.
This paper analyses first these critical factors in adopting technical standardized
specifications for data exchange in eBusiness; then analyses one of the possible
countermeasure: domain specific use profiling and related conformance testing tools based
on customization rules.
KEY WORDS: interoperability, standard, conformance testing tool, customization rules,
eBusiness, UBL, Schematron, SMEs business.
2 Standards Ensuring Enterprise Interoperability
1. Introduction
Lack of interoperability is often observed between different implementations in
data exchange for eBusiness, even when the systems implement the same standard
specification. This paper tries to analyses the reasons of the problem and focuses on
customization and testing as critical factors to tackle this matter.
The problem is relevant in the present eBusiness applications but, in a ‘Future
Internet’ perspective, it could increasingly hamper a ‘plug and play’ interoperability
between applications and services.
Firstly this paper investigates the gap between the conformance to the
specifications of Information Technology (IT) systems and the achievement of
interoperability between different systems with the aim to identify the potential
causes.
Secondly, customization being the first action to improve interoperability, two
cases based on UBL (Universal Business Language, Bosak et al., 2006) towards
different domains are considered:
– eBIZ-TCF1, a project funded by the European Commission (EC) in order to
Harmonize eBusiness in the Textile, Clothing and Footwear industry, produced a set
of specifications based on UBL for its vertical domain;
– PEPPOL2, another project funded by the EC to establish guidelines and
specifications for the European public eProcurement, entirely based on UBL
document formats.
Thirdly, further possible countermeasures are analysed in order to reduce the
problem, with a specific focus on the role of business rules adopted in the use
profiles in order to enable automatic tools to discover contents that prevent the
achievement of interoperability.
2. The problem and the state-of-the-art
The adoption of public standards for business data exchange enables systems to
interoperate, with a positive impact for eBusiness adoption, especially towards
Small and Medium Enterprises (SME) networks.
These networks, indeed are, potentially, the greatest beneficiary of the
application level standard adoption: they have not enough resources and skills to
define by themselves complex specifications and are far from being able to impose
their solution to their commercial partners.
1. www.ebiz-tcf.eu
2. www.peppol.eu
Standard in SMEs networks: customisation and conformance 3
The drawback is that, presently, the implementation of really interoperable
systems sometimes is perceived more as a black art rather than the rational
application of a technical specification. That is exactly the opposite of a ‘plug-and-
play’ approach that is what is needed by the SMEs networks to be interoperable.
The point is that conformance to standard specification is not enough to
guarantee interoperability between real IT systems, due to different implementations
of the specifications. Different ways are in fact possible to express documental
specifications for a domain.
The most common representation of specifications is XML Schema3 to represent
the templates of the different types of business documents. They are used both for
automatic conformance test of an instance document and for documentation.
In the past EDI (Electronic Data Interchange) applications were less sensitive to
the problem: they were based on a one-to-one approach between large companies
(that had resources to tune the EDI systems exactly to their needs) or on a hub-spoke
approach where, again, the large company was able to define the implementation
and impose it (a black box, usually with a private EDI dialect) to its partner.
In the present eBusiness scenarios, the communication infrastructure is
‘commoditized’ and XML based tools allow a more diffused adoption of eBusiness
(for example lightweight EDI solutions but also new service based solutions) to the
industry in a real many-to-many networked approach where private dialects are less
effective and acceptable.
If the problem is relevant today, it could become fatal in the Future Internet
perspective (Hourcade et al., 2009, Papadimitriou et al
.
, 2009) by preventing the
creation of an “Internet of Services” where services should be clearly defined,
available and interchangeable (for example the interchangeability of the service
providers must be assured).
Thus it is relevant to identify different causes of the lack of interoperability
between systems implementing the same specification:
Firstly in order to have interoperability among real systems on all the three levels
of interoperability (technical, semantic and organisational) should be effectively
achieved (EIF 1.0, 2004). In some cases also a fourth level, the legal level (EIF 2.0,
2010), has to be considered, like in PEPPOL project. On the contrary not all the
specifications cover all the levels.
Secondly there is a dichotomy between the need for generality and the need for
specialisation: supporting as much as possible scenarios (or requirements) against
maintaining an acceptable level of complexity of the specifications.
The 80/20 Pareto’s principle is largely applied to standardisation: satisfying the
20% of the requirements, usually leads to support 80% of the cases. In fact there are
always unsupported cases that lead to misrepresent specifications, and innovative or
3. www.w3.org/TR/xmlschema11-1
4 Standards Ensuring Enterprise Interoperability
niche services (that are a pillar in the Internet diffusion) are the most periled to this
risk.
Thirdly, despite many specifications deal with the semantic aspects of
interoperability, very often they do not achieve complete semantic interoperability
but leave some degrees of freedom to the implementer that causes uncertainty and
redundancy in the exchanged data; in the first case. For example, we can have
different containers or representations for the same information; in the second case
many information have to be managed to be compliant while they should not be
necessary for a specific case (De Sabbata P. et al., 2010).
This problem leaded to define restrictions of the specifications that are related to
a domain or a sub-domain (namely customizations).
Fourthly, we observe that a specification defines some static constraints for a
document model, like the OrderResponse, through XML Schema representation that
are always valid but that, in some circumstances have to be restricted, depending on
a dynamically changing context (due, for example, to the progression in a
workflow). This case could be considered as a sub-case of the previous one but here
we report it separately to put the case in evidence.
This could be considered as a short list of the potential sources producing lack of
interoperability between systems implementing the same documental specification.
The possible countermeasures are many and different according to the given
requirements and policies adopted by the standard developers.
3. Documental formats and their limits, role of customizations
Documental specifications for eBusiness can be reduced to two different macro-
categories: vertical standards and horizontal standards4. In the first case
vocabularies define a lot of domain specific terms (patient record, textile darning
commission, vehicle certificate insurance, hotel availability request..), in the second
case terms are defined to be understood and used in any domain (order,
catalogue,…). In the second case the constraints are less compulsory and the risk of
non interoperable implementations is higher.
A good approach to understand the effectiveness of a specification in order to
assure interoperability is to identify a list of the requisites that are related to the
domain. Each requisite that cannot be satisfied by the original specification should
be translated in (or related to) a customization rule (Bausà, 2010).
The result of the application of customization rules to a specification is a use
profile that modifies some characteristics in order to reduce the uncertainty and
redundancy in its implementation on a given domain; this approach is applied, for
4. Examples of vertical standards are HL7, ACORD, CIDX; examples of horizontal standards
are EDIFACT, UBL, GS1 XML;…
Standard in SMEs networks: customisation and conformance 5
example, to horizontal specifications to achieve the same performance of a vertical
one as described in (De Sabbata P. et al., 2010).
What is important to observe is this approach is usually based on human readable
user guides or, in the best cases, on XML Schemas that restrict the general Schemas
to a subset; they are valid for all the transactions of the domain and are usually the
only weapon available for automatic (low cost) conformance testing.
In the next paragraph we will analyze two different customizations of the same
horizontal standard to put in evidence that further tools can be used beyond XML
Schemas. Furthermore, we will observe that interoperability achievement is
jeopardized also by requirements that change dynamically in the context domain (for
example, according to the workflow progression).
The standard specification we analyze is UBL: produced by OASIS, based on
XML, is a good example of horizontal specification for eBusiness; it defines a
library of terms and a set of generic business document models, not tailored for a
domain.
UBL has been customized within two European projects, eBIZ-TCF and
PEPPOL, to implement flows of data in two relevant domains.
The projects appear to have extremely different contexts although they based
their implementations on the same common UBL specification.
A short summary of the two projects features is in tables 1 and 2.
Table 1. The contexts of eBIZ-TCF and PEPPOL according to the classification
proposed by the Core Component Technical Specification (CCTS, 2003) adopted by
UBL.
ContexteBIZ‐TCFPEPPOL
GeopoliticalEuropeEurope
IndustryTextile,clothing,
footwearindustry
All
Official
constraints
NoneEuropeandirective
BusinessprocessProductsupplyand
production
Publicprocurement(Publication,Tendering,
Sourcing,Ordering,Billing)
6 Standards Ensuring Enterprise Interoperability
Table 2. Other features of eBIZ-TCF and PEPPOL domains.
4. Different types of customization rules
Customization rules are applied upon the specification (UBL in this case) to be
customized that supplies a syntax that cannot be broken; the customization rules can
be grouped according with the different origin of the constraints they express:
A first group of customization rules is dedicated to identify the subset of
information elements that must be supported in the domain.
For example, the product identification is supported by UBL with different
structures (Buyers Item Identification, Sellers Item Identification, Manufacturers
Item Identification, Standard Item Identification, Catalogue Item Identification,
Additional Item Identification) and both eBIZ-TCF and PEPPOL choose the same
pair of elements (Sellers Item Identification and Standard Item Identification)
discarding the others. This means that, although humans could understand the
discarded structures, they have been excluded by the scope of the IT systems in
order to keep the implementations cheaper and simpler.
A second group of rules define coding and ranges of allowed values for the
information. For example, for product identification, eBIZ-TCF exclusively accepts
GS1 GTIN (Global Trade Item Number5) coding while PEPPOL doesn't make
restrictions (GS1 GTIN is ‘suggested’ only).
5. www.gs1.com
RequirementseBIZ‐TCFPEPPOL
ActorsSMEnetworkspublicadministrationtowardsSMEsas
wellaslargefirms
ArticleidentificationGS1GTINis
required
Norestriction;
GS1GTINissuggested.
PartyidentificationGS1GLNisrequiredCodeissuedbyagencieslistedinISO6523
Nationallocalizationnoyes
Invoicehaslegal
value
noyes
Standard in SMEs networks: customisation and conformance 7
A third group of rules declares some optional data structures as mandatory in
the domain. For example, to satisfy legal requirements, PEPPOL eInvoice requires
always the full name and address of the taxable person and of the customer, on the
contrary in eBIZ-TCF they are not allowed. In this case the two customizations,
although UBL conformant, express opposite and incompatible requirements.
A fourth group declares co-constraints, constraints arising from dependencies
between data in the same document (Jelliffe, 2001), that must be always satisfied in
the domain. For example in Invoice, invoice total amount must equal the sum of the
line totals.
Finally, there are two last groups related to constraints depending on dynamic
execution of the data exchange:
A fifth group of rules declares constraints related to the context or the roles of
the actors involved in the transaction. An example comes, in PEPPOL, from national
requirements: some information must be provided depending on the country of the
issuer.
A sixth group of rules declares constraints related to the position of the current
transaction in the running business process. For example in eBIZ-TCF the dispatch
advise can adopt a ‘delivery based’ structure or a ‘package based’ structure
according to the current workflow.
5. Conformance test tools: Schematron based implementation
In order to reach a good level of interoperability between the systems adopting
customized specifications, it is important to make available, to all the involved
parties (developer and users), conformance test tools that can provide an objective
and unbiased verification of the conformance of the electronic documents being
exchanged (CEN BII WG3, 2010).
Conformance tests are relevant in two distinct situations having different
objectives and actors:
– at development/implementation time, to help software vendors and
implementers to test whether software components are able to generate, manage
and understand conformant document instances;
– the actors performing test are the software developers/vendors.
– at run-time, to give the final users a way to check the goodness of the exchanged
instances;
– the actors performing the validation are the final users of systems.
Test tools are implementations of the customization rules that can automatically
check if document instances satisfy them. Usually the tools are based on two kinds
of elements: a software engine for document validation and the rules that can be
8 Standards Ensuring Enterprise Interoperability
represented through different syntaxes: the most diffused are XML Schema and
Schematron6.
The approach followed by eBIZ-TCF is based on:
− XML Schemas representing subsets of information elements from UBL that
supply the basic data structure; one XML Schema for each document model
plus a library of common terms;
− Schematron rules expressing all the other types of customization rules;
− a web application as software engine that is public, available for any user
and embedding the XML Schemas and Schematrons (that are not public).
The main functionalities of the web application7 are uploading an instance of
XML document of the user, choosing the reference transaction to be supported,
applying the corresponding XML Schemas and Schematron set of rules and
producing a response. The answer of the system is related to syntactic conformance
(towards UBL) and conformance towards the customization rules.
In this approach the developers and users have at their disposal the web
application as a black-box for manual testing of XML document instances. Since the
eBIZ-TCF systems implement a complete automation of the document flows, it
follows that the tool is addressing mainly ‘test’ rather than ‘validation’ activities.
Differently, PEPPOL bases its approach on:
− original UBL XML Schemas that supplies the basic data structure;
− public Schematron rules expressing all the customization rules;
− a set of web applications as software engine that are public, available to any
user and based on the XML Schemas and Schematrons.
The main functionalities of the reference web application8 are uploading XML
code of the user representing the document instance, choosing the couple reference
transaction/set of rules to be applied (they can refer to different countries), applying
the corresponding Schematron set of rules and producing a response. The answer of
the system is only about conformance towards the customization rules.
The developers and users have the possibility to develop their own tools using
the public Schematrons as well as to rely on the public ones. The approach is to
supply artifacts that can be used to perform both test at development time as well as
run-time validation on the real data flows.
6. www.schematron.com
7. winter.bologna.enea.it/eBiz-TCFValidator/
8 www.invinet.org/recursos/conformance/invoice-validation.html
Standard in SMEs networks: customisation and conformance 9
To obtain some figures about the customization rules that are necessary to
implement a ‘real’ customization, the eInvoice document model has been examined
both in PEPPOL and eBIZ-TCF and classified according with the kinds of rules
identified in paragraph 4 (table 3).
In PEPPOL, excluding national requirements, rules related to the Invoice, are
more than 4509, in eBIZ-TCF they are more than 12010, the largest part belongs to
the first type of customization rules (400 and 90 respectively).
These figures point out the complexity of the development and maintenance of
the customizations: the number of rules is very high and represents still an open
challenge.
TypeofrulesPEPPOLeBIZ‐TCF
1.datastructure80%
(the‘core’ofthedatastructure)
75%
2.codingandranges4%
(75%expressedascodelists)
6%
3.mandatoryelements5%8,2%
4.content(co‐)
constraintsalwaystrue
8.4%10%
5.(co‐)constraints
dependingonroleor
content
2.4%
(accordingtothedifferent
countries)
‐
6.rulesrelatedtothe
workflow
0.2%0,8%
Table 3. A compared .classification of the different types of rules involved in the
customization of a sample business document model, the Invoice.
9. www.peppol.eu/work_in_progress/wp5-einvoicing/results
10. www.moda-ml.net/ebiz-retail/repository/TCF-UseProfile/v2008-
1/en/default.asp?nomenu=1
10 Standards Ensuring Enterprise Interoperability
6. Conclusions
Causes of the lack of interoperability that can be found even between
applications that are conformant to a common documental specification have been
analyzed. The scope and the different types of customization rules have been
presented with the conclusion that they can play a relevant role to improve
interoperability. These rules are the basis for automatic tools aiming to check the
conformance of an implementation to a specific customization.
Nevertheless the analysis has evidenced two problems:
− different customizations of the same specification could result in non
interoperable applications;
− in some cases the validity of a document against a customization rule
cannot be assessed only by examining the single document instance,
because aspects related to the external context must be evaluated.
Two different cases of customization, eBIZ-TCF and PEPPOL, have been
compared, their different approaches have been evidenced as well as their common
root in UBL. The complexity of the construction of such set of rules, like in the
examined cases, put in evidence that a huge effort is required to set up the testing
tools and some kind of automatic support will be necessary to reduce it.
Bibliography
Hourcade J-C., Neuvo Y., Posch R., Saracco R., Wahlster W., Sharpe M., “Future Internet
2020, Vision of an industry expert group”, report for DG Information Society and Media,
May 2009, EC, ISBN 978-92-79-11320-8
Papadimitriou D., “Future Internet, the Cross ETP vision document, white paper”. January
2009, Future Internet portal, www.future-internet.eu.
De Sabbata P., Gessa N., Brutti A., Novelli C., Frascella A., D'Agosta G., “Standard creation
and adoption for SME networks", in Interoperability for Enterprise Software and
Applications, proceedings of the Workshops and the Doctorial Symposium of the I-ESA
International Conference 2010, Coventry, pp. 41-51, edited by Hervè Panetto, Nacer
Boudjlida, ISTE/Wiley, June 2010, ISBN 978-1-84821-270-1
CEN BII WG3, “Business Interoperability Interfaces for Public procurement in Europe - Part
3: Toolbox Requirements”, in CWA 16073-3: Toolbox Requirements from CEN WS BII,
Brussels, 2010, www.cen.eu/cwa/bii/specs/Tools/documents/CWA_CEN_ISSS_BII_
Part3.pdf
Bausà O., Kingstetd A., Forsberg M., Frade J., Birgisson G., Fromyr J., Rasmussen S.,
“Conformance and interoperability testing”, in CWA 16073-3, Annex B on Conformance
Standard in SMEs networks: customisation and conformance 11
Testing, from CEN WS BII, Brussels, 2010, www.cen.eu/cwa/bii/specs/Tools/
documents/BII3-B-ConformanceTesting_d09.doc
EIF 2.0, “Annex II - EIF (European Interoperability Framework)” of the Communication
“Towards interoperability for European public services” on the 16th of December 2010,
European Commission, 2010
EIF 1.0, “European Interoperability Framework for pan-European eGovernment Services”
IDABC project, 2004, Belgium, ISBN 92-894-8389-X, ec.europa.eu/idabc/servlets/
Docd552.pdf?id=19529
Bosak J., McGrath T., Holman G.K., “Universal Business Language v2.0, Standard”, OASIS
Open, December 2006; docs.oasis-open.org/ubl/os-UBL-2.0/
CCTS, UN/CEFACT “Core Components Technical Specification, Part 8” of the ebXML
Framework in Version 2.01, UN/CEFACT, November 2003
www.unece.org/cefact/ebxml/CCTS_V2-01_Final.pdf
Jelliffe R., “The Current State of the Art of Schema Languages for XML”. 2001,
www.planetpublish.com/pdfs/RickJelliffe.pdf.
