"+ !!,;

+# * + "# +!- . " " # -
!"! $$+ -#*;

* ! !" %)# +!- . ) -* -
!" ) EF ;,7<#F J" I,#!!
G ##!<# "# "" ")
")! $8EH;" + #!J,
G! ) EF % !"EF ;
$F +EF "+0 ) EF B /C6 =# / 6
, $G ) EF B /56 #! " G 8 B /46 #! =#
#! $G #! " B /D6 #! ,E ,EF
!" ;

<# "#"$G G : !"K+,$ <#
<# "#"$G G ;
,#"+ !;

# ## "#" "####?!"#!"!
#!;

#! "# !" "#"#+
$7 $"<#!)#7;
) + 777, ""7;7! : )=+O"77 !; *
7$!"# )# 7 <##:"#N!#
# 7 !"<#! # O "7)7 : ?"<#
!"? $ 77 $NO" " );
?!": , 7" # 7 , >#: "#
"" 6: # !) ,$ ? $77 " # O "7)7 77
+7:#*O"77?7#7;" " ! 7 + !
7#? ) +: # * 7 !<# " # # # 7 = 0
P#0 # , ! 7 !<# 7# ) %
,; !" ? 77!A /26# ,!$: # !!#
7 <# "! $ " B /&6 # , 7+ $
#!=#+,B/D6#,O7,# "+ !;
O###;

- . !"!*# )$ !"#
$$;

#" - ." # ! + "##
2 + , !"#$/ 6&''S:"A00 +; !"#; $00&''S &##,*% + # $$ 9 C---;%!% ; ! 5---;! ; $ U " ="##"")- #$# $+
/ :: 6 ;
6B ?/ !X6B +/"0 #$6B $
/ #$6B / #$0Y6B $ /0 #$6B # / !X0 6B #!
/ 6B)!/0 #$6B !/"6B ?/ *0 #$6B
# ; B ) /186B = : * / #!)6B
/"0 #$6B / !06B!*1 ++ ! , # "B
!*++ !1#AY: : ;








? ; ?!" + "# )#)!)* +$

448-(!%9 44:*++5-(&06 445-
(;44+- (< 03*++-
*++1- ' % $
*;;=<




& !
!
-
% !
!



# "
" !
!
# !
+ )

! # ! ! !




&
"


"

! !
! "
(

#

# ( "
7 7 77
9*;;@<

*;

5 3 3*3 -
++ *
#
!
./


*



8
0)

)


2)1QR*.TS


# 3 -
% >3
!!!
! !-!

=


**!>7 + !

Networked Environment
The aim of this chapter is to introduce the concept of interoperability in a CNE. Main
barriers towards seamless interoperability are presented. A holistic approach on
interoperability based on four views is introduced: technical, information/ knowledge,
business/ economic, and semantic. Relevant developments that are being pursued by industry
and interest organizations are then described. Concerning business interoperability, a three
dimensional model for CN performance assessment supporting a Join/ Leave/ Remain (JLR)
decision is described. A set of requirements identified for the development of an
interoperability framework in a CNE are presented, and a gap analysis is performed.
3.1. Introduction
Interoperability, in a broad sense, refers to the use of computer-based tools to facilitate the
coordination of work and information flow across organizational boundaries, focusing on
distributed inter-enterprise collaborations and flows. It emerged from the need to harmonize
the operational heterogeneous networked environment, real time information sharing, and the
necessity to improve task coordination.
Definitions
According to the IEEE [1990], the interoperability represents the capability of two or more
systems to exchange information and to use the information exchanged. For Chen and
Doumeingts [2003a], the interoperability implies that one system performs an operation on
behalf of another. Thus, the interoperability can be achieved on multiple levels: inter-
enterprise coordination; BP integration; semantic application integration; syntactic application
integration; and physical integration.
The International Standard Organization (ISO) standards [ISO 14258, 1998] imply that
interoperability may occur between two (or more) entities that are related to one another in one
of the three ways: (a) integrated, with a standard format for all constituent systems; (b) unified,
where a common meta-level structure across constituent models provides means for
establishing semantic equivalence; (c) federated, where models must be dynamically
accommodated rather than having a predetermined meta-model.
As illustrated in Pollock [2001], interoperability solutions consist of both application
integration (e.g., the technology solution: message, process, transport and interface) and
information integration 1 (e.g., the linguistic, social and philosophical solution).
Research domains
Three main research domains to address interoperability have been identified by Chen and
Doumeingts [2003a]: architectures and platforms; enterprise modeling; and enterprise
ontologies. Relevant European initiatives towards enterprise applications interoperability (e.g.,
1Integration refers here to the cooperation of processes and applications at the event and message levels, multiple systems within the same organization becoming one logical unit.
32
R&D projects under the EU Six Framework Programme) are presented by Chen and
Doumeingts [2003b]. Aiming at attaining seamless interoperability in a collaborative
environment, several tools and infrastructures have been developed. The most relevant
advancements refer to reference models, architectures, frameworks, standards, industry-neutral
and industry-specific initiatives. Concerning semantic interoperability, important to mention
are: OASISs Universal Business Language 2 development to provide a library of XML
schemas, and a set of XML schemas for common business documents; the development of
industry-specific specific dictionaries (e.g., RosettaNet Business and Technical Dictionaries),
or ontologies.
A holistic approach (considering technological, semantic, and business challenges) on
CNss interoperability and business alignment is available in Chituc and Azevedo [2005b] and
Chituc, Toscano and Azevedo [2007e]. An analysis of interoperable enterprise systems based
on system engineering principles is presented by Vernadat [2007], who indicates essential
components to build interoperable enterprise systems: enterprise portals, single sign-on
identity management, workflow engines, service registry, and message and service buses. A
roadmap of enablers and technologies supporting interoperability in a CNE has been presented
by Chituc and Azevedo [2005a]. An overview of the most relevant elements for VE
infrastructures can be found in Camarinha- Matos and Afsarmanesh [2003], who also identify
major directions requiring further development in this area, such as: CN formalization,
conceptual development and semantic integration (namely concerning the formal description
of the domain or ontology).
Main obstacles
Despite the high number of projects and initiatives targeting the CNs, the goal of achieving
collaborative environments of fully interoperable heterogeneous entities is still not fully
achieved (e.g., [Camarinha-Matos & Afsarmanesh, 2003], [Pollock, 2001]). Causes are
diverse, e.g., culture and language barriers (e.g., [Whitman & Panetto, 2006]), lack of a
generally accepted definition of interoperability (e.g., [Molina et al., 2007]), heterogeneity and
lack of resources (e.g., [Jardim-Goncalves et al., 2006]), inadequate implementation, poorly
managed risks and requirements, human errors, the heterogeneity of the systems, applications,
or methods to organize and formalize knowledge. This is also due to the fact that research in
the area of integration and interoperability is focusing mainly on technological, physical and
syntactic aspects. Recent research approaches on semantic issues (e.g., [Sheth et al., 2005],
[Klein, 2001]) illustrate its potential and benefits for seamless connectivity. Interoperability, in
this sense, refers to solutions (e.g., infrastructures, applications), which assure the exchange of
minimal meaningful context-driven data and information between autonomous and
heterogeneous systems.
The European Commission [EC, 2006b] has identified challenges which constitute long-
term strategic directions for research on enterprise interoperability in the EU, such as: policy
challenges, business-economic challenges, knowledge research challenges, generic modeling
interoperability, semantic and ontology research challenges, ICT systems, architectures and
platforms challenges, interoperability service utility, which is envisioned to provide
interoperability as a technical, commoditized functionality, delivered as services; Web
technologies for enterprise interoperability; knowledge-oriented collaboration (e.g., knowledge
sharing in a VO for the mutual benefit of all partners); a science base for enterprise
2 http://www.oasis-open.org
interoperability (e.g., by combining and extending the findings from other established and
emerging sciences). These challenges represent in fact a vision towards achieving
interoperability.
However, current research and developments in the area of interoperability in a CNE do
not promote a holistic view on interoperability, but they focus on specific aspects.
3.2. A Holistic View on Interoperability
In this research work, seamless interoperability refers to the use of computer-based tools to
assure the exchange of information and the use of this meaningful information exchanged or
shared between heterogeneous and geographically distributed organizations in a CNE in order
to achieve value added by attaining a set of objectives, and where the systems are added and/
or removed without requiring reconfiguration, and an organization, CN, or sub-CNs decision
to join, leave or remain in a CN or community is based on an economic analysis.
Towards seamless interoperability in a CNE, four main views on interoperability have
been proposed by Chituc, Toscano and Azevedo [2007e]. They concern Technical aspects
(e.g., messaging infrastructure), Information/ knowledge (e.g., information sharing,
publication and retrieval), Business issues (e.g., strategic, operational, and economic aspects),
and Semantic aspects (e.g., common dictionary, common set of business documents-BDocs).
The authors have argued that these four aspects should be tackled by an interoperability
framework simultaneously. These directions have been also referred in two EU funded
projects 3 . However, this approach differs by considering these views as concentric (as
illustrated in Figure 3.1).
3 ATHENA (http://www.athena-ip.org) and IDEAS (http://www.ideas.roadmap.net) EU projects. For these projects, the technical, information and business interoperability dimensions are represented as layers, which are vertically crossed by a semantics dimension. Another relevant
EU project in this area is INTEROP (http://interop-noe.org). However, it focuses on three knowledge components: architectures and
technologies to provide implementation frameworks; enterprise modeling to define interoperability requirements; ontology to identify interoperability semantics in an enterprise.
interoperability assure information/ knowledge exchange and management, providing a base
for analyzing business/ economic interoperability aspects, while the semantic focus assures a
common understanding of the information exchanged and/ or shared. This is also portrayed in
Figure 3.2, which gives the big picture on the interoperability between two organizations
considering these dimensions.
Figure 3.2. Inter-organizational interoperability
This vision for seamless interoperability relies on a set of attributes to be considered in the
development of an interoperability framework and ICT platform. The selection of these
attributes is the result of an in depth literature review, analysis of available frameworks,
operational infrastructures, independent and industry-specific initiatives, and the experienced
gained by participation in national and European R&D projects in this field. These attributes
are: reliability; time (e.g., to set-up or reconfigurate a CN); cost (e.g., to set-up or operate a
CN); openness or extensibility (e.g., the use of open-source software); transparency (e.g., of
the messages exchanged); scalability, traceability (e.g., of BPs, BDocs), and other non-
functional properties (e.g., security) [Chituc, Toscano, Azevedo, 2007e].
The next sections present more in detail these four views on interoperability.
3.3. Technical View on Interoperability: Approaches and Developments
This sub-section addresses technical aspects on interoperability. Relevant reference
models, standards, architectures, frameworks, independent and industry-specific initiatives,
and technologies developed in order to support enterprise integration and interoperability are
presented.
3.3.1. Reference Models
In this research work, the term reference model refers to models or blueprints which can be
used to develop or evaluate specific models. Dominant reference models that are being
pursued by industry and interest organizations are presented below.
35
Supply Chain Operations Reference Model 4 (SCOR) is a process reference model
developed by the Supply-Chain Council as cross-industry standard for supply-chain
management. It is used to describe, measure, and evaluate supply-chain configurations. SCOR
model is organized around five primary management processes: plan, source, make, deliver
and return. It is composed by a hierarchic architecture of four level details: Top level (Process
Types), Configuration level (Process Categories), Process Element level (Decompose
Processes), and implementation level (Decompose Process elements).
Workflow Reference Model [Workflow Management Coalition, 1999] provides the general
architectural framework that identifies interfaces and covers broadly five areas of functionality
between a Workflow Management System (WfMS) and its environment: process definitions
import and export; interaction with client applications and work-list handler software; software
tools or applications invocation; interoperability between different WfMSs; administration and
monitoring functions.
Purdue Enterprise Reference Architecture (PERA) [Li & Williams, 2000] provides the
reference model for physical and informational interactions in enterprises. An extension of the
model for a distributed enterprises environment (e.g., VEs) is presented by Li and Williams
[2003], where the BPs in a group of enterprises are synchronously and simultaneously
executed via information exchange.
GRAI Integrated Modeling Methodology (GRAI-GIM) [Doumeingts et al., 1993] includes
the GRAI conceptual model, which is a representation of basic concepts of a manufacturing
system decomposed into physical, decision and information sub-systems; GIM modeling
framework, which comprises three dimensions: views, life cycle, and abstraction level; GIM
structured approach, and GIM modeling formalisms (e.g., GRAI grid, GRAI nets for decision
system modeling, IDEF0).
Computer Integrated Manufacturing Open System Architecture 5 (CIMOSA) supports the
description of an enterprise, from the management level to the shop floor level. It consists of
an enterprise modeling framework, enterprise modeling language, and integration
infrastructure.
Generalized Enterprise Reference Architecture and Methodology (GERAM) [IFAC/IFIP,
2000] defines a tool-kit of concepts for designing and maintaining enterprises for their entire
life-history. GERAM refers to the methods, models and tools, which are necessary to build and
maintain the integrated enterprise, a single enterprise, or a network of enterprises. GERAM
encapsulates and orders previous architectures (e.g., CIMOSA, PERA, GRAI/GIM), providing
an overall structure to use these methods and modeling techniques. However, GERAM is not a
reference architecture; it is aimed at organizing enterprises existing integration knowledge. It
has the potential for application to all types of enterprises by describing the components
needed in all enterprises engineering and integration processes. GERA (Generalized Enterprise
Reference Architecture) is GERAMs most important component; it identifies basic concepts
to be used in enterprise engineering and integration.
3.3.2. Business-to-Business Integration Standards
In this research work, the notion of standard follows Cargills definition [Cargill, 1989].
Thus, standards can be considered objects (e.g., hardware, software, processes, functions,
protocols), which are accepted and shared within a community (i.e., business unit, value chain,
sector or geographic region).
4 http://www.supply-chain.org 5 http://www.cimosa.de
In a broad sense, the term B2B integration refers to electronic message exchange among
trading partners. It includes issues such as product catalogues, classification systems, B2B
protocol standards, synchronous/ asynchronous communication, or back-end integration.
According to Bussler [2003], B2B integration is the enabling technology and the necessary
infrastructure to perform different operations: e.g., automated supply chain integration, to send
XML-formatted messages over the Internet, to send messages in a Peer-to-Peer (P2P) pattern
to trading partners, to exchange messages with marketplaces.
Dominant B2B standards that are being pursued by industry and interest organizations are
presented below. They have been grouped considering their scope, as follows 6 :
Catalogue systems and classification standards, including: BMEcat 7 ,
Electronic Catalog XML 8 , Open Catalog Protocol
9 as catalogue systems, and
eCl@ss 10
as
(EDIFACT), eXtensible Markup Language 12
(XML), XML Common Business
(cXML), Open
(OAGIS), RosettaNet
;
(ebXML),
collaborations, BP activities or workflows. Business Process Modeling
Language (BPML), Business Process Query Language (BPQL), Web Services
Flow Language (WSFL), Business Process Execution Language for Web
Services (BPEL4WS), XML Processing Description Language (XPDL),
Unified Modeling Language 21
are only some examples of modeling languages dealing with BPs.
Other relevant developments for enterprise integration should also be mentioned: Open
Buying on the Internet 22
(OBI), Bolero.net 23
, eCo framework 24
(XAML).
3.3.3. Architectures
In this research work, the term architecture refers to the structure and relationships among
functional units in a system or ICT infrastructure describing a current and/or future structure
and behavior of the BPs in an organization or CN. An architecture may also include the
systems interfaces with its environment.
Dominant architectures that are being pursued by industry and interest organizations are
presented below. They have been grouped into 27
: model-driven and adaptive interoperability
workflow architectures.
The Model-Driven Development 28
well-defined models between different abstraction levels. Important is to define the models
and semantics of the different abstraction models, the relationships between them, and the
tools and methodologies associated. In the MDD, models are not used only as blueprints, but
as primary artifacts from which implementations are generated.
The OMGs Model Driven Architecture 29
covers a set of specific OMG-based technologies
to support the MDD, aiming at achieving portability, interoperability and reusability. It
separates the specification of the operation of the system from the details of the way the
system uses the capabilities of its platform. It provides an approach and tools for: specifying a
system independent of the platform it supports; specifying platforms; choosing a particular
platform for the system; transforming the system specification into one for a particular
platform 30
.
Three main abstraction levels exist for the OMGs Model Driven Architecture instantiation
of MDD:
composition independent model (CIM), which describes the systems
requirements and the business context in which the system will be used. They
are often expressed in business or domain-specific languages, and refer briefly
to the use of the IT systems when they are part of the business context;
platform independent model (PIM), which describes how the system will be
constructed, without any reference to the technologies used to implement the
model;
platform specific model (PSM), which describes a solution from a particular
platform perspective. It includes details on how the CIM can be implemented.
25 http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=business-transaction 26 http://msdn2.microsoft.com/en-us/library/ms752059.aspx 27 The selection of these architectures has been made considering their acceptance and implementation status, and the aim of this research work. For this reason, the architecture for industrial automation prepared by the International Electrotechnical Commission, IEC 61499, has
not been included. IEC 61499 [IEC, 2005] is a component-based open architecture for distributed industrial process management and control
systems. 28 http://www.ibm.com/developerworks/library/ar-mdd3/ 29 http://www.omg.org/mda 30 OMGs notion of platform refers to interfaces and usage patterns by a set of subsystems and technologies, which can be used by an application without implementation details.
Metamodel 31
.
The Organization for the Advancement of Structured Information Standards 36
(OASIS)
defines the Service Oriented Architecture (SOA) as a paradigm for organizing distributed
capabilities, which may be under the control of different ownership domains, and provides
means to offer, discover, interact with and use capabilities to produce desired effects consistent
with measurable preconditions and expectations.
The service-oriented development aims at supporting the loose coupling of system parts in
a better way than existing component-based technologies. Having systems composed of
services offered by various service providers gives the basis for supporting the emergent forms
of organizations, such as the CNs.
SOA is a way of reorganizing software applications and infrastructures into a set of
interacting services [Papazoglou, 2003]. A service, as defined by Talevski et al. [2005], is a
unit of work done by a service provider to achieve desired end results for a service consumer
(e.g., a SME).
The basic SOA involves three kinds of participants [Papazoglou & van den Heuvel, 2003]:
a service provider, a service discovery agency (e.g., a service broker), and a service requester
(client). The fundamental logical view of a service for the basic SOA is represented by a
service interface and implementation. The interaction with the services is performed, in fact,
over well defined interfaces.
The guiding principles for the development, maintenance and usage of the SOA are: reuse,
granularity, modularity, componentization, interoperability, compliance to (common and
industry-specific) standards, services identification and categorization, provisioning and
delivery, monitoring and tracking. The SOA principles for achieving autonomy and
interoperability have been presented by Jammes and Smit [2005].
As emphasized by Papazoglou [2003], the SOA does not address issues like management,
service orchestration, service transformation management and coordination, security. Thus, an
extended layered-architecture of the SOA (ESOA) has been developed by Papazoglou and
Georagakopoulos [2003]. Accordingly, a service composition layer allows the consolidation of
multiple services into a single composite service, which may be used by service aggregators as
components (e.g., basic services) in further service compositions, or by clients, as application/
solution.
A service-oriented environment is expected to support different basic activities
[Tsalgatidou & Pilioura, 2002]: service creation; service description; service publishing to
intranet or Internet repositories for potential users; service discovery for potential users;
service invocation, binding; service un-publishing in case the service is no longer available or
needed, or in case it has to be updated to satisfy new requirements.
The SOA attempts to promote software development in a way that leverages the
construction of dynamic systems which can easily adapt to volatile environments and be
maintained. The decoupling of system constituent parts enables the reconfiguration of system
31 http://www.www.omg.org/cwm 32 http://www.sun.com/products/jmi 33 http://www.omg.org/mof 34 http://www.omg.org/docs/ptc/03-10-14.pdf 35 http://www.omg.org/docs/formal/03-05-02.pdf 36 http://www.oasis-open.org
Furthermore, the use of the XML-based widely accepted standards and protocols, which
operate above Internet standards (e.g., HTTP 37
, SMTP 38
) enhances interoperability.
Standards and technologies for the SOA
Web service technologies (e.g., BPML, ebBPSS, SOAP, UDDI, WSCI, WSCL, WSDL)
represent the current state of practice for the SOAs (and they are presented more in detail in
section c) Web Service Architectures). The SOA may be built on Web service standards (e.g.,
using SOAP) that have gained broader industry acceptance. The SOA is often defined as
services exposed using the Web Services Protocol Stack.
The Service Component Architecture 39
is an initiative advocated by major vendors of Java
Enterprise Edition technology. Its proponents claim it is more natively suited for the delivery
of applications that conform with the principles of the SOA, and its components are more
technologically agnostic.
The services, which can be simple or composite, are offered by service providers to the
clients of services (e.g., applications within or outside an enterprise). As emphasized by
Papazoglou and van den Heuvel [2003], to satisfy these requirements, the services should be:
technology neutral, loosely coupled, and they should support location transparency.
Service-based application and infrastructures may be developed as independent groups of
interacting services providing well-defined interfaces to their potential users. According to the
same authors, while services encapsulate the business functionality, an inter-service
infrastructure is required to facilitate the interaction and communication of services. Services
may be implemented on a single machine, distributed over a set of computers on a local area
network, or distributed across several networks. The services may use the Internet as
communication enabler, and may make use of Internet-based standards.
A Web service is a specific kind of service identified by a URI, which exposes its features
programmatically over the Internet (e.g., by making use of standard Internet languages and
protocols), and can be implemented via a self-describing interface based on open Internet
standards. Although Web services share the characteristics of more general services, they
make use of public, insecure, low-fidelity mechanisms for inter-service interactions.
Grid services may be used to provide the functionality of the ESOAs service management
layer (e.g., [Papazoglou, 2003], [Foster et al., 2002]). They provide a set of well-defined
interfaces and follow specific conventions to facilitate the coordination and management of
sets of Web services providers/ aggregators, by indicating how a client may interact with it by
making use of the WSDL.
Grid services provide the grid infrastructure (called the service grid bus- SGB) over which
the services interact, aggregate, and coordinate through a distinct architectural tier. The SGB
provides a high-level architecture and management facilities to allow services to function as an
integrated unit, and collaborate with other services. The SGB architecture provides facilities
for registration, discovery, selection/ routing, business rules, filtering, routing, aggregation,
and fail-over.
While the Web services focus on platform-neutral description, discovery and invocation,
the grid services focus on the dynamic discovery and efficient use of distributed computational
resources. This complementarily of Web services and grid services has determined the Open
Grid Service Architecture (OGSA), which makes available the functionality of grid services
through Web services [e.g., Foster et al., 2002].
37 HyperText Transfer Protocol, http://www.w3.org/Protocols/ 38 Simple Mail Transfer Protocol, http://www.ietf.org/rfc/rfc0821.txt 39 http://www-128.ibm.com/developerworks/library/ specification/ws-sca/
c) Web Services Architectures
The Web service architecture provides the global network elements of the global Web
services network that are required in order to ensure interoperability between Web services. It
describes three roles: service provider, service requester, and service broker, and three basic
operations: publish, find and bind. A network component can play any or all of these roles.
The Web services provide standard means of interoperating between different software
applications, running on a variety of platforms and/or frameworks 40
. They are self-contained,
modular applications which can be described, published, located, and invoked over a network.
They aim at supporting EAI, and enable the integration and interoperability of heterogeneous
systems and components.
Web services are interfaces to components, and are intended to expose higher level BPs
whereas components tend to expose lower level business objects and processes [ATHENA
D.A6.1, 2005].
Relevant Web service technologies are:
Business Process Management Language 41
(BPML) is a meta-language for
the modeling of abstract and executable BPs. It provides a grammar in the
format of an XML Schema for enabling the persistence and interchange of
definitions across heterogeneous systems and modeling tools. It also supports
Web services orchestration and multi-partner collaboration choreography.
ebXML Business Process Specification Schema 42
(ebBPSS) is part of ebXML
framework suit of specifications. Using XML syntax, ebBPSS describes public
BPs as collaborations between roles, where each role is an abstraction of a
trading partner. It also defines relationships. Being abstract, a definition is
reusable as it only defines the exchange of information between two or more
partners – business documents and business signals. A BP includes
collaborations, which are a choreographed set of business transaction activities.
Simple Object Access Protocol 43
(SOAP) provides an XML-based protocol for
structured message exchanges. It relies on existing transport protocols, such as
the HTTP and MQSeries. The SOAP features document-based communication
among Web services, thus allowing the integration of loosely coupled services.
It consists of three parts: an envelop which defines a framework for describing
what is a message and how to process it, a set of encoding rules for expressing
instances of application-defined data types, and a convention for representing
remote procedure calls and responses.
Universal Description Discovery and Integration 44
(UDDI) is a specification
of a XML-registry for Web services. It defines an interface for advertising and
discovering Web services. The UDDI information model, defined through an
XML schema, identifies three types of information: white pages, yellow pages,
and green pages. It is used to publish a Web service in terms of its ports, port
types, and bindings.
(WSCI) is an XML-based language for
describing the observable behavior of a Web service during a message
exchange in the context of a collaborative BP. It gives the ability to describe a
sequence of Web service invocations, e.g., the conditions under which an
operation can be invoked. The specification is mainly concerned with public
messages among Web services and supports message correlation, sequencing
rules, exception handling and transactions.
Web Services Conversation Language 46
(WSCL) is a XML vocabulary which
offers the ability to define the services external behavior by specifying the
business level conversations between the Web services. In order to reflect
simplicity, it provides a minimal set of concepts required to specify the
conversations. A WSCL document specifies three parts: a XML schema, which
corresponds to the XML documents being exchanged as part of the
conversation; the conversation description, which reflects the order in which the
documents are exchanged, and the description of the transactions from one
conversation to another.
(WSDL) is an XML-based language for
describing functional properties of Web services. It aims at providing self-
describing XML-based service definitions which can be easily understood by
applications and people. A service consists of a collection of message exchange
end-points, which contain abstract descriptions of a service interface and
implementation binding. The abstract description of a service contains
definitions of messages which are consumed and generated by the service, and
signatures of service operations. The implementation binding provides a means
to map abstract operations to concrete service implementations.
Business Process Execution Language for Web Services 48
(BPEL4WS)
[Andrews, Curbera et al., 2003] has been developed as an attempt to unify
IBMs Web Services Flow Language 49
(WSFL) and Microsofts Web Services
Description Language 50
(WSDL). It supports complex BPs description, which
can both consume and provide Web services. The language uses a graph based
or algebras representation, and offers the ability to manage abstract and
executable processes. It provides constructs to handle long running transactions,
compensation, and exception using related standards. Information about Web
services composition is available in Aalst [2003]. BPEL4WS is intended to
support the modeling of both executable and abstract processes. A BPEL
process is a flow-chart, where each element in the process is called an activity,
which can be either primitive or structured. Its major limitations have been
identified by Mandell and McIlraith [2003]. BPEL4Peolpe 51
is an extension of
BPEL developed with the aim of supporting a broad range of scenarios
involving people within BPs. BPEL4People is defined in a way that is layered
on top of BPEL so that its features can be composed with the BPEL features
whenever needed.
notation for drawing BPs in a workflow.
Proof Markup Language (PML) is described by Silva, McGuiness and Fikes
[2006] as an interlingua representation for justification of reasoning results
produced by Semantic Web services. The PML is an ontology added to W3Cs
OWL Semantic Web representation language.
d) Component and Message-Oriented Architectures
Component- and message-based architectures are the foundation of several distributed and
programming environments, and ICT platforms.
Component Architectures
and Internet applications fit the requirements of the emerging networked information-based
organizations. They consist of software components, which may exist autonomously from
other components in an application.
Component-based software encompasses different disciplines and application domains,
e.g., groupware, distributed object-oriented software development, multimedia, computer-
supported collaborative work, distributed simulation.
Relevant component technologies are:
software and technologies for building, deploying, and running Web
applications, smart client applications, and XML Web services applications that
expose their functionality programmatically over a network using standard
protocols, such as SOAP, XML or HTTP.
Common Object Request Broker Architecture 54
(CORBA) is an industry
standard that defines a higher level facility for distributed computing. It allows
applications to communicate with one another without being aware of the
hardware and software systems or the location of the application. A client can
transparently invoke a method on a server object. The object can be on the same
machine, or on a remote machine on the network.
Distributed Internet Architecture 55
solution to the development, deployment and management of multi-tier
enterprise solutions (before Microsoft .NET). It relied on COM+, a language-
independent technology used to build re-usable components.
52 http://www.bpmn.org BPMN has been approved as standard in 2005. 53 http://www.microsoft.com/net 54 http://www.omg.org/corba 55 http://www.microsoft.com/dna
(J2EE). The J2EE Framework has been designed
to provide server- and client-side support for developing enterprise multi-tier
applications, which are typically configured as client tiers.
Message-Oriented Architectures
A message-oriented approach allows a more loosely coupled connection between various
system parts and independent systems. The focus is on asynchronous message passing versus a
synchronous request-oriented style of component-oriented computing. This is supported by
message queuing with guaranteed delivery, and potential for priority setting.
Relevant message-oriented technologies include:
development of XML-based messaging solutions built upon standards and
Internet technologies, e.g., HTTP, MIME, XML, SOAP.
ebXML which aims at creating an infrastructure for a single global electronic
market.
e) Agent Architectures
Agent architecture is a blue print for software agents and intelligent control systems,
depicting the arrangement of components. As emphasized by Scheutz and Andronache [2004],
besides the functionality of its control components, an agent architecture determines the
representational repertoire available for data structures and information processing in the
system, and the structural modifications which can be made to components and their
connections.
Individual agents represent the primary focus of the research in the area of artificial
intelligence, which is dominated by two main schools: the cognitive school, which regards
agents as intelligent entities, and reactive school, which considers agents as very simple
entities, which react directly upon environmental changes or stimuli created by other agents.
The single agent architectures can be:
reactive, when agents respond to environmental stimuli. The agent does not
contain any internal model of its environment and does not deliberate on its
actions.
deliberative, when an agent contains an internal model of its environment,
and reasons about its world to decide upon its actions.
hybrid, which is a combination of reactive and deliberative agent
architectures. In this case, the agent is able to behave reactively and reason
about its environment.
A multi-agent system is a set of intelligent agents interacting in a common environment in
order to fulfill a set of goals or accomplish a set of actions. It is not dedicated to the resolution
56 http://java.sun.com/j2ee 57 http://microsoft.com/biztalk
goal to act. The data is decentralized (e.g., distributed among agents).
The methods and platforms based on software agents and multi-agent systems can be used
for advancements towards inter-enterprise collaborations in the following areas: modeling
(e.g., methods extending current modeling methodologies with concepts such as beliefs, goals,
intensions, roles; agent technology has the potential to improve the automation of routine
processes); simulation (e.g., multi-agent supply chain management simulation; multi-agent
simulation of economic models); execution (e.g., event-based workflows); and management.
f) Peer-to-Peer and Grid Architectures
P2P Architectures
The term P2P denotes a class of systems and applications, which employ distributed
resources (e.g., data, computers) to perform a function (e.g., data sharing, communication) in a
decentralized manner. Decentralization may apply to algorithms, data, or meta-data. However,
parts of the systems or applications may be centralized.
The P2P architecture is a type of network in which each workstation has equivalent
capabilities and responsibilities. The main types of P2P networks are: collaborative computing
(e.g., Grid MP platform), instant messaging (e.g., MSN Messenger), and affinity communities
(e.g., Napster). A P2P approach could provide a cost-effective solution for small businesses,
e.g., sharing files with geographically distributed co-workers and clients.
A P2P architecture for dynamic workflow management has been proposed by Fakas and
Karakostas [2004], which allows peers to register with the system and offer their services and
resources to other peers over the Internet (similar to Napster and Gnutella), and advances a
notification mechanism to facilitate distributed workflow administration and management.
The P2P approach for B2B integration across enterprises described in Bussler [2003] relies
mainly on message exchange among peers. The focus is on the architecture for a Business
Integration Server (BIS), which provides accumulated message transfers from enterprise
applications to business partners who also run a BIS. The BIS works as a gateway to business
partners via the Internet, providing workflow management, a B2B protocol engine, assures
security, and runs application adapters to integrate the corporate application and services.
However, the BIS could be regarded as a solution for connecting existing corporate processes
with external partners.
Grid Architectures
The term Grid refers to a system concerned with the integration, virtualization and
management of services and resources in a distributed heterogeneous environment which
supports collections of users and resources. An analysis of the Grid concept in terms of its
support for the VOs is available in Foster [2001]. The author emphasizes specific problems
underlying the Grid concept, e.g., coordinated resource sharing and problem solving in
dynamic, multi-institutional VOs. Grid architecture is regarded as a protocol architecture, the
protocols defining the basic mechanism by which VO users and resources negotiate and
operate. It consists of Resource and Connectivity protocols, which facilitate the sharing of
individual resources, a Fabric layer which can be used to construct global services, and a
Collective layer which involves the coordinated use of multiple resources.
45
represents an evolution towards a grid system
architecture based on Web services concepts and technologies.
g) Business Process Management and Workflow Architectures
Business Process Management (BPM) and workflow architectures address issues related to
inter-enterprise collaborations. The BPM systems are related to the design, development, and
deployment of collaborative BPs. Workflow technologies are related to the BP orchestration
and choreography.
Architecture of Integrated Information Systems 59
(ARIS), which is a business
modeling method providing documentation of existing BP types, blueprint for
analyzing and designing BPs, and support for designing information systems.
Business Process Modeling Notation 60
(BPMN) specifies a graphical notation
to serve as a common basis for different BP modeling and execution languages.
Mappings from the BPMN to other languages (e.g., BPEL4WS) can be defined.
Integrated Computer-Aided Manufacturing DEFinition 61
(IDEF) is the name
of a family of languages used for enterprise modeling and analysis.
Java Business Process Management 62
(JBPM) project aims at providing a
flexible and extensible Java WfMS.
XML Process Definition Language 63
(XPDL) has been designed to exchange
the process design of workflow BPs. It defines a XML schema for specifying
the declarative part of a workflow.
Yet Another Workflow Language 64
(YAWL) was aimed at overcoming the
limitations of previous WfMSs and workflow languages in modeling workflow
patterns.
Protocol (ASAP) with workflow functionality. Wf-XML 2.0 is defined using
the WSDL.
is a Microsoft technology defining,
executing and managing workflows. It is part of .NET Framework 3.0.
58 http://www.globus.org/ogsa 59 http://www.pera.net/Methodologies/ARIS/ARIS.html 60 http://www.bpmn.org 61 http://www.idef.com 62 http://www.jbpm.org 63 http://www.ebpml.org/xpdl.htm 64 http://www.citi.qut.edu.au/members/research_areas/bpm/projects/yawl 65 http://www.wfmc.org/standards/docs.htm#WfMC%20General%20Publications 66 http://msdn2.microsoft.com/en-us/netframework/aa663328.aspx
3.3.4. Frameworks
In this research work, the term framework represents a fundamental structure which allows
the definition of a set of concepts to model and build an organization or a network of
organizations. It consists of a collection of elements (e.g., principles, methods, tools) put
together for a certain purpose relevant for a given domain of application.
Dominant frameworks for e-business that are being pursued by industry and interest
organizations are presented below.
Electronic Business XML 67
terms, and define and register inter-organizational BPs among heterogeneous and
geographically distributed enterprises of all sizes.
RosettaNet Implementation Framework 68
routing, and transport of RosettaNet Partner Interface Process (PIP) messages and business
signals. It provides implementation guidelines for the creation of software applications
components, which facilitate the execution of PIPs.
Web Service Resource Framework 69
(WSRF) is a set of Web services specifications
developed by OASIS, which describe how to implement OGSA capabilities using Web
services. The Globus Toolkit 4.0 70
and later versions provide an open source WSRF
development kit and a set of WSRF services.
Zachman’s Framework for enterprise architecture [Zachman, 1987] describes a holistic
model of an enterprise information infrastructure from six perspectives: planner, owner,
designer, builder, subcontractor, and working system. It strives to ensure that all aspects of an
enterprise are well-organized and exhibit clear relationships.
eCo Framework 71
of multiple databases, trusted open registries, and agent-mediated buying. eCo Framework
specifications include an architecture for businesses. The specifications divide up the space of
e-business into the following hierarchy: networks, markets, businesses, services, interactions,
documents, and information items. The framework addresses each of these levels, adding at
each level the notion of a type registry, in which item-types are stored. These varying levels of
complexity allow businesses to get involved in an eCo marketplace at a level appropriate to
their current resources.
(DoDAF) supports the development
of a system or enterprise architecture. It is organized around a shared repository to hold work
products, which is defined by the Core Architecture Data Model and the DoDA Repository
System. Interoperability is organized as a series of levels, called levels of information system
interoperability. It comprises an operational view, systems view and technical standards view.
The UK Ministry of Defence Architectural Framework 73
(MODAF) provides means to
defines architectural views covering the strategic goals of an enterprise, people, processes and
systems that deliver those goals. It also includes capability management and programmatic
aspects.
framework which provides a comprehensive approach to the design, plugging,
implementation, and governance of enterprise information architecture. The architecture is
typically modeled at four levels or domains: business, application, data, and technology.
Microsoft’s BizTalk Framework 75
provides a set of basic mechanisms required for most
B2B electronic exchanges. It is an XML framework for application integration and e-
commerce. It includes a design framework for implementing an XML schema and a set of tags
used in messages sent between applications.
ISO 15745 – Open System Application and Integration Framework 76
has been elaborated
by ISO TC 184 SC5/WG5. It consists of four parts: generic reference description; reference
description for ISO 11898 based control systems; reference description for EN 50170 and EN
50254 based control systems; reference description for Ethernet based control systems. It
defines elements and rules which facilitate the system organization and representation and the
development of interface specifications.
IDEAS Interoperability Framework 77
interoperability issues: business layer, focusing on the business environment and BPs;
knowledge layer, focusing on organizational roles and skills, the employees competences, and
knowledge assets; ICT system layer focusing on applications, data, and communication
components; semantic dimension, supporting the mutual understanding of all layers.
ATHENA Interoperability Framework 78
each layer of the IDEAS Interoperability Framework, as follows:
for the business layer: process modeling interoperability, and modeling cross-
organizational BPs;
for the ICT layer: cross-organizational BPs execution, autonomous
architectures, Web service discovery, and model-driven SOAs;
for the semantic dimension: semantic annotation, mapping and mediation,
otology authoring, and management system.
3.3.5. Infrastructures and Technologies
An overview of the current approaches and trends towards the establishment of flexible
and configurable infrastructures for VEs is presented by Camarinha-Matos and Afsarmanesh
[2003]. Emerging technologies for VE infrastructures are grouped as follows:
open inter-operable underlying network protocols (e.g., TCP/IP, CORBA-IIOP,
HTTP, RMI, SOAP);
CORBA Framework, Active X Framework);
74 http://www.opengroup.org/togaf 75 http://www.microsoft.com/biztalk 76 http://www.iso.org 77 It has been developed within the scope of IDEAS EU funded Project (http://www.ideas-roadmap.net). 78 It has been developed within the scope of ATHENA EU funded Project (http://www.athena-ip.org).
WSDL);
standardized modeling of business components, processes and objects (e.g., EJBs,
OAG and OMGs Business Objects and Components);
BP modeling tools and languages (e.g., UML, UEML, PSL);
open and standard BP automation and workflow management system (e.g.,
WfMC, OMG-JointFlow, XML-WfMC standards);
open and standard distributed messaging middleware systems (e.g., JMS, MS-
Message Server, MQSeries, FIPA-ACC);
OBI, WIDL 79
Concerning the infrastructures supporting the VEs, two main approaches are presented by
Camarinha-Matos and Afsarmanesh [2003], from the software engineering perspective:
transaction oriented layer, and agent-based infrastructures. Considering the current trend
towards developing service-oriented infrastructures, three main types of infrastructures
supporting the CNs have been identified in this research work:
transaction-oriented layer infrastructures add a cooperation layer to enterprises
existing IT platforms 80
agent-based infrastructures, where enterprises are represented as agents and the
inter-enterprise cooperation is performed through interactions in a distributed
multi-agent system 81
paradigm (e.g., [Papazoglou, 2003], [Papazoglou & van den Heuvel, 2003]) which
uses services for developing applications/ solutions. Services are self-describing
computational elements supporting rapid and low-cost composition of distributed
applications. The services perform specific functions (e.g., a request, choreography
of inter-organizational BPs). They allow organizations to divulge their capabilities
programmatically over the Internet (or intra-net) by making use of standard
79 http://www.w3.org/TR/NOTE-widl-970922 80 Two relevant projects are: National Industrial Information Infrastructure Protocols80 (NIIIP, http://www.niiip.org) and Production Planning and Management in an Extended Enterprise (PRODNET II, http://www.uninova.pt/~prodnet). 81Two relevant projects are Multi-agent Manufacturing Agile Scheduling Systems for Virtual Enterprises (MASSYVE,
http://www.cordis.lu/esprit/src/962219.htm), and Dynamic Forecast for Master Production Planning with stock and capacity constraints (DAMASCUS, http://www.damascos. com).
languages and protocols. Services may be implemented via a self-describing
interface (e.g., based on open standards).
The Electronic Data Interchange (EDI) [Sokol, 1995] has been used for more than 30
years in automating the interchange of business transactions between large corporations and
their trading partners (e.g., concerning pre-purchasing, purchasing, shipping, recycling,
warehouse, billing, payment information). As emphasized by Segev et al. [1997], despite its
long tenure and potential benefits, the EDI has been slow; one of the most cited reasons being
the prohibitive implementation cost. Significant obstacles in the adoption of the EDI are also
described by Chau [2001].
UN/EDIFACT 82
focuses on the exact definition of widely used BDocs, without providing
any BP specifications. ASCII and EDIFACT formats are designed to fulfill the requirements
imposed by specific industry sectors, impeding cross-industry communication.
The eXtensible Markup Language 83
(XML) is a recommendation standard established by
the World Wide Web Consortium in 1998. It is a metadata format for structured documents
exchanged on the Web, which allows developers to create their own markup languages, by
defining specific DTDs. It has been adopted by several enterprises and industries to perform e-
business since its release. As emphasized by Li [2000], industry standards are enthusiastic
about the XML due to the fact it offers a „common ground for independent entities to
exchange data in order to conduct business. However, the trading partners would still have to
agree on a format before they can actually start exchanging XML files. Unlike EDI, XML data
representation is intuitive and easy to read; it is cheap to implement, and cheaper to deploy via
the Internet.
Other relevant enterprise modeling languages/ technologies are: Information Exchange
Modeling (IEM); Metis ITM, BPM and UML, Mathematics Education Markup Language 84
(MeML), and Process Interchange Format 85
(PIF).
Few studies focus on industry-specific initiatives. The role of industry-based standards
development organizations for inter-organizational system standard diffusion is analyzed in
Nelson and Shaw [2005], and Nelson, Shaw and Qualls [2005]. The authors analyze the
practices used to develop and deploy inter-organization standards throughout an industrial
group, discriminating factors, and antecedent conditions towards their implementation and
diffusion. However, this study is focusing on the process of diffusion of inter-organization
industry standard solutions, and diffusion measures. The study does not tackle interoperability
aspects, nor their limitations or challenges.
The following paragraphs briefly present ebXML as major independent approach, and
relevant industry-specific initiatives. The decision to analyze these initiatives relays in their
capabilities, adoption status, and potential in supporting seamless interoperability in a CNE.
82 http://www.unece.org 83 http://www.w3c.org/XML 84 http://wme.cs.kent.edu/meml.html 85 http://ccs.mit.edu/pif/
(ebXML) is a modular suit of specifications aimed at enabling
e-business over the Internet. Its mission is to provide an open, XML-based infrastructure that
enables the global use of e-business information in an interoperable, secure and consistent
manner by trading partners.
The ebXML provides a standard method to exchange business messages, conduct trading
relationships, communicate data in common terms, and define and register BPs. It does not use
its own e-business vocabulary (BVs) to describe business documents. Instead, ebXML
document types are assembled from core components, which are syntax-neutral descriptions of
semantically meaningful business concepts.
Process Specification Schema (BPSS), Collaborative Partner Profile/ Agreement (CPP/A), and
Core Components 87
. BP and information modeling is not mandatory in ebXML. However, if
implementers and users select to model BPs and information, UN/CEFACT Modeling
Methodology (UMM) should be used.
ebXML Messaging Specifications (ebMS) incorporate most of the requirements for XML-
based application-to-application messaging over the Internet. The ebMS uses the SOAP. ebMS
defines a standard communication protocol for the reliable and secure exchange of messages
between two e-business partners over the Internet. The protocol assures a „once-and-only-
once delivery of the messages, and their confidentiality, authentication and privacy. The non-
repudiation of the messages transmitted or received is another characteristic of this protocol.
ebXML messages are XML-based and contain a payload part where any kind of data contents
(e.g., pdf, xml, text binary) can be encapsulated, without size restrictions. The messages are
transported over the Internet through SMTP (e-mail) or HTTP/ HTTPS 88
protocols.
The CPP/A specifications provide definitions of the documents that describe the
commercial/ business and technical capabilities of the e-business partners, and the agreed
interactions between their profiles. The message exchange capabilities of a trading partner are
described by a CPP document and the message exchange agreement between two trading
partners are described by a CPA document.
An approach to complement ebXML initiative aiming at specifying a methodology to
represent syntax-neutral core components in targeted e-BVs is presented by Hofreiter and
Huemer [2002]. The framework developed extends ebXML by ontology concepts, in four
steps, to describe semantically equivalent document types in different e-BVs for the same
activity in a well-defined BP. However, the first three phases are done manually, and this
represents a major limitation of this approach.
ebXML offers a strong conceptual base and the number of implementations is relatively
high 89
.
86 http://www.ebxml.org This initiative was started in 1995 and is supported by OASIS and UN/ECE agency CEFACT. 87 In 2004, the ISO has approved a suite of four ebXML OASIS Standards that enable enterprises in any industry, of any size, anywhere in the
world to conduct business over the Internet, published as ISO technical specifications, ISO/TS 15000, which includes four parts, each corresponding to one of the ebXMLs modular suite of standards, as follows: ISO 15000-1: ebXML Collaborative Partner Profile Agreement;
ISO 15000-2: ebXML Messaging Service Specification; ISO 15000-3: ebXML Registry Information Model; ISO 15000-4: ebXML Registry
Services Specification. 88 HyperText Transfer Protocol Secure, http://www.ietf.org/rfc/rfc2660.txt 89 Some examples of relevant developments are: Hermes MSH (http://www.cecid.hku.hk), Oracle A/S suite (http://www.oracle.com), Web
Sphere 6.1 (http:(//www.ibm.com), ebBP Editor and freebXML Registry (http://www.freebxml.org), Monteverdi framework (http://www.monteverdi.com.au ).
electronics industry global supply chain, and supports their implementation and adoption. The
standards are XML-based, and define message guidelines, BP interface, and implementation
frameworks for the interactions between trading partners.
It consists of four main elements: Multiple Messaging Service, which addresses XML-
based business messages exchange and B2B collaboration over horizontal message handling
systems; PIPs and PIP Directory; Dictionaries, and RosettaNet Implementation Framework
(RNIF) Core Specification.
A RosettaNet PIP defines specific BPs between trading partners. The PIPs fit into seven
clusters or groups of core BPs, which represent the backbone of the trading network. Each
cluster is broken into segments, which are cross-enterprise processes involving more than one
type of trading partner. The PIP Directory has been replaced by a document that lists the
different PIP specifications. RNIF is the packaging, routing, and transport of all PIPs messages
and business signals. For RosettaNet, business semantics interoperability is achieved through
its dictionaries: business and technical, which designate the properties used in basic business
activities.
A major drawback towards achieving integration and interoperability results from the
variations in syntax and semantics of the PIP action message structures. RosettaNet previously
did not establish rules to describe how one supply chain company can modify a PIP through
the implementation guidelines that are specific to that company or by changing the Document
Type Definition (DTD). This generated a large number of varying message semantics for the
same PIP, impeding implementation.
A complement to RosettaNet specifications which enables Semantic Web Service
environment to automated mediation of messages is illustrated by Katinurmi and Vitvar
[2006].
papiNet
papiNet 91
is an international paper and forest industry e-business initiative. It is a set of
standard electronic business documents which enable information flow among parties engaged
in buying, selling and distributing paper and other forest products.
It is a set of common electronic format terminology for the paper and forest products
industry, designed to facilitate application-to-application information exchange. Its
interoperability guidelines are based on the ebXML message service specification, being
designed to facilitate system-to-system information exchange. The messages have a very
uniform structure with common definitions contained in the file that is shared amongst all the
messages schema files, avoiding in this way semantic conflicts. papiNet is also offering a
Trading Partner Agreement (TPA) template , which is currently available only in Word format.
The papiNet standard includes a common terminology and standard business documents
(e.g., purchase order, shipping notice, invoice) for use in both domestic and international
electronic transactions. By using the XML and the Internet, papiNet standard provides a digital
infrastructure, which can be used by businesses to automate the business information
exchange.
papiNet standards are compatible with the ebMS, even thought it supports the FTP
protocol.
(CIDX) is a non-profit organization aiming at
improving the ease, speed, and cost of securely conducting business electronically in the
chemical industry. Its focus is on XML-based e-business standards development, called Chem
eStandards, which have become the de facto standards to electronically transact business in
this industry.
The Chem eStandards comprise specifications around BP guidelines, message, envelope
and security specifications and various implementation tools. For long term, the aim is to
develop and maintain message standards and BP guidelines for common BPs, which are
expressed in DTD format. The technology is platform independent and vendor-neutral.
Although the messages are modularized around discrete shared BPs, a single data dictionary is
used through CIDX to guarantee that there is a consistent use and interpretation of the business
terms.
Aiming at achieving a more effective and efficient cross-industry trading, CIDX is
working with other industry trade associations and standardization bodies (e.g., RosettaNet).
Agriculture sector
) is a not-for-
profit organization formed by leading agricultural companies. It supports the agriculture
community so as to take advantage of new developments in electronic communication. It
makes us of EDI, XML, Bar Coding, Sales Reconciliation Format, unit measure conversion,
and it also endorses Web services interoperability profile concept. Some XML transaction
schema files were developed in collaboration with CIDX. It also provides a Data Dictionary.
AgXML 94
is an organization of grain and processing companies, and related entities,
committed to develop standards for the electronic efficient and effective information
communication through the entire agribusiness supply chain.
Petroleum Industry
enterprise-wide integration of BPs through seamless electronic business communication based
on EDI and XML technologies. In order to tackle semantic interoperability, PIDX is pursuing
efforts towards the development of a Petroleum Industry Data Dictionary that meets this
industrys needs.
Automotive Industry
Several initiatives are available for the automotive industry. The aim is to develop tools,
standards, guidelines, and recommendation in order to improve the flow of goods, services,
product data and business information through the automotive supply chain. Some of the
examples are: the Automotive Industry Action Group 96
, Odette 97
, which have jointed their forces with the Japanese
Automotive Parts Industry Association, and the Japanese Automotive Manufacturers
Association in order to build a global Joint Automotive Data Model (JADM). The JADM is
intended to be the foundation for the enabling of common, consistent business vocabularies at
the data level, thus allowing various enterprises to retain their existing infrastructure and BPs.
This is, in fact, an attempt to synchronize global XML standards, automotive BPs and
associated data entities. The first version of the JADM is expected to be released during the
year 2007.
The Standardization and Interoperability in the Textile Supply Chain Integrated
Networks 99
(TexWeave) is a standardization initiative aiming at providing an interoperability
framework for the textile/ clothing sector. The business documents are specified through
XML-schema and the companies exchange them through the Internet. The results achieved so
far comprise business models for fabric and clothing supplying, XML templates for document
exchange and a common dictionary.
The Middleware tOols and Documents to enhAnce the textile/ clothing supply chain
through the XML 100
ebXML, to enhance collaboration and interaction inside the textile/ clothing supply chain.
Currently, TexWeave specifications have been adopted, and are subject to the on-going work.
Footwear Industry
has been developed within the scope of Shoenet European
project. It comprises two main elements: a messaging platform able to integrate through the
Internet ERP-like systems of SMEs participating in the shoe value chain, which allows a
secure exchange of business documents and the traceability of the operations performed; a set
of 17 XML-based business documents especially designed for the targeted sector. The
platform is based on the SMTP.
CEC-made-shoe EU Integrated Project 102
and ShoeBiz@PT 103
represent the most
BP layer assuring BP coordination and choreography [Chituc, Toscano, Azevedo, 2007b].
The ShoeBiz@PT ICT platform 104
is the result of a Portuguese project whose aim is to
promote the electronic integration of the companies in the footwear industry through the
development and deployment of a secure and Internet-based communication infrastructure. It
allows the exchange of Shoenet business documents between companies, and uses the ebMS
as the main communication protocol [Chituc, Toscano, Azevedo, 2007d]. The platform is
currently installed in Portugal, and is complaint with Shoenet platform.
97 http://www.odette.org 98 http://www.starstandard.org 99 http://www.texweave.org TexWeave is a standardization initiative of the European Committee for Standardization (CEN/ISSS,
http://www.cen.eu). 100 http://www.moda-ml.org 101 http://www.shoenet.info 102 http://www.cec-made-shoe.com 103 ShoeBiz@PT is developed at national level in partnership between the Portuguese Shoe Technological Center (CTCP) and INESC Porto. 104 http://svr-shoebiz.ctcp.pt:8080
The Association for Cooperative Research and Development 105
(ACORD) is a non-profit
association aiming at facilitating the development and use of standards for the insurance,
reinsurance, and related financial services industries. By 1999, ACORD started migrating its
body of forms and EDI standards to XML. Currently, ACORD provides standards for paper
and electronic forms, as well as for data stored as XML.
The Society for Worldwide Interbank Financial Telecommunication 106
(SWIFT) is an
to financial institutions.
Tables 3.1 and 3.2 present the main characteristics of the ebXML and relevant vertical
approaches, emphasizing their advantages and main drawbacks.
105 http://www.acord.org ACORD is operating since 1970. 106 http://www.swift.com
Initiative Web site Start Focus Aim Promoters/ Supporting bodies Versioning
ebXML www.ebxml.org 1999 SMEs in general To provide specifications that enable enterprises of any size and in any geographical location to conduct business over the Internet.
OASIS, UN/CEFACT Core Components Technical Specifications of ebXML Technical Framework v2.0.1; ebBP v2.0.4; Messaging
Service v3; Registry Service v3.0; Registry Information
Model v3.0; ebXMl CPP/A v2
RosettaNet www.rosettanet.org 1998 High-tech and
electronics industry
supply chain, supporting their implementation and adoption.
Founded in Silicon Valley, it has
currently affiliates in Europe,
v2.1
products industry
To provide a set of standard electronic documents that facilitate
the flow of information among parties engaged in buying, selling and distributing paper and forest products.
More than 80 companies from 4
continents (e.g., CEPI, GCA)
Standards
www.cidx.org 1985 Chemical industry To improve the ease, speed and cost of securely conducting
business electronically in the chemical industry.
Chemical Industry Data
Guidelines v1.0; Implementation Accelerator v1.2;
RAPID www.rapidnet.org
1995 Agriculture
economic and stewardship benefits of e-business; to facilitate
effective and efficient implementation of e-business among its members.
Agriculture companies RAPID v3
AgXML www.agxml.org Grain processing To develop standards for efficient and effective communication throughout the entire agribusiness supply chain.
Grain and processing companies, and related entities
AgXML v2
PIDX http://committees.api.or
BPs through seamless e-business communication.
American Petroleum Institute,
JADM Automotive industry Provide international standard direction in order to develop
business content, seamless interactive business communication for the automotive industry.
AIAG; AutoDESA; CCAQ;
V1 (expected in 2007)
TexWeave www.texweave.org 2005 Textile industry To provide the textile/ clothing sector with a framework for interoperability based on standardized electronic document
exchange over the Internet, and to foster its adoption in business
communities.
Cec-made-
shoe
www.cec-made-
shoe.com
2004 Footwear industry To achieve seamless interoperability in the footwear industry. EU consortium partners V1 (expected in 2007)
ShoeBiz@
PT
http://svr-
shoebiz.ctcp.pt:8080
2006 Footwear industry To achieve seamless interoperability in the footwear industry. CTCP and INESC Porto V1 (March 2007); V2 (2008)
Initiative Main elements/ layers Approach towards semantic
interoperability
ebXML Messaging/ Transport; Registry/ Repository; Business Documents; Business Process Specification Schema;
Collaboration Protocol Profile/ Agreement; Core
Components.
components)
Lack of semantic support Enrich its semantics with the use of ontologies (e.g., OWL at Registry/ Repository level) or e-vocabulary and
development of a semantic framework.
RosettaNet Multiple Messaging Service (3 predominant messaging
systems: ebMS, Web services, AS/2), PIPs & PIP
Directory; Dictionaries (Business & Technical); RosettaNet Implementation Framework.
Business Dictionary - Variations in syntax and semantics of
PIP action message structure;
Combination with other technologies (e.g., Semantic
Web Services)
- TPA in Word format; - No support to automatically establish
collaboration agreements.
Chem e - Standards
RAPID
collaboration agreements.
collaboration agreements.
- No support to automatically establish
collaboration agreements.
JADM Common Vocabulary Needs further development (still in incipient phase).
TexWave Messaging
High diversity of internal applications used by community members
Automate the setting of collaboration agreements.
CEC-made-shoe Messaging; BPs Common set of XML-based Business
Documents
collaboration agreements.
communication. Use of SHOENET proprietary messaging platform, not
compliant with ebXML messaging specifications.
ShoeBiz@PT v2 Messaging; CP/ADM service; Repository; BDocs and supporting documents; CBA clusters
Common set of BDocs The CP/ADM service is currently under implementation.
57
technologies and frameworks defining the basic mechanisms and specifications by which
organizations communicate, negotiate, establish, manage and exploit business relationships.
A standard-based open architecture facilitates extensibility, interoperability, portability,
and code sharing. Standard protocols make it easy to define standard services which provide
enhanced capabilities.
the collaboration partners independently. The Model Driven Architecture provides model
representation and transformation of concepts.
The areas of component- and message-oriented computing serve as an implementation
basis for interoperability architectures. The SOAs, for example, may make use of these
technologies. The SOAs represent a step forwards towards achieving seamless interoperability
in a CNE. Firstly, a service-oriented approach can be regarded as a generic model which can
be supported by many different ICT platforms. Secondly, there is a current trend towards the
convergence of different Web service technologies.
Agent technology addresses inter-enterprise interoperability issues through:
standardization efforts; the integration of concepts (e.g., ontologies, by the use of agents to
provide mappings between ontologies); modeling, simulation, execution and management of
inter-enterprise collaborations. There is considerable interest in developing methods and tools
for analyzing and designing complex agent-based software systems, including approaches to
formal specifications.
The e-business requires a relatively high level of agreement and shared context among
business systems from different organizations. The current trend is towards flexible systems,
loosely coupled, dynamically bound components. Thus, a service oriented approach which is
based on the composition and choreography of services is more likely to solve current
interoperability gaps. Service integration/ interoperability may characterize the next generation
of e-business, as businesses move more of their existing IT applications to the Web, taking
advantage of portals and e-marketplaces, and leveraging new technologies, such as the XML.
The Web services and SOA architectures may be the next generation of e-business
architectures. However, they describe the principles of achieving interoperability among
heterogeneous systems, but without providing implementation specifications. Various
implementation techniques can be used to describe and implement platforms based on these
architectures, considering different aspects, e.g., security.
The main benefits provided by the Web services architecture are: it promotes
interoperability by minimizing the requirements for shared understanding; enables just-in-time
integration; reduces complexity by encapsulation; enables interoperability of legacy
applications.
standards are presented in Annex A.
58
This section addresses aspects related to business interoperability. The main methods for
performance assessment in a CNE are presented. A three-dimensional model for CN
performance assessment to support a join, leave, remain (JLR) decision is described.
3.4.1. Overview
In this research work, the notion of business interoperability addresses interoperability
issues between two or more systems from a business/ economic perspective, as opposed to
technical aspects related to interoperability. However, there might be applications, tools and
technical methods to implement and run business interoperability concepts.
Business/ economic interoperability comprises aspects such as:
the ability to collaborate across organizational boundaries, and to establish
advantageous inter-organizational collaborations and flows (e.g., in terms of
cost, payoff, time, level of quality), which are seamlessly integrated in a way
that organizations boundaries are imperceptible from inter-organizational
collaborations perspective;
the ability to set-up, change and remove inter-organizational collaborations in
a profitable manner (e.g., considering aspects related to the report between costs
and payoffs);
organizations and CNs performance assessment;
an organization, CN or sub-CNs decision to Join, Leave, or Remain in a
certain CN or community - that is the JLR decision defined by Chituc and Nof
[2007] 107
for cost and payoff, performance assessment;
elements of the coordination theory (as described by Malone et al. [1994]).
Related to business interoperability are also the following issues: the definition of the goals
and strategy of a CN; streamlining of inter-organizational collaborations in order to eliminate
redundancies; the alignment of the individual goals and strategies with those of the CN.
Business interoperability describes the ability of an organization (CN or sub-CN) to join,
leave or remain in a CN, and to establish and remove inter-organizational collaborations and
relationships considering economic aspects.
107 The JLR decision problem in collaborative networked organizations has been defined by Chituc and Nof [2007]. The decision to join a CN
is related to the motivation of a given organization to join a certain CN considering the quantification of the advantages or payoffs gained and
the costs associated with the participation in a certain CN, and agility. The decision to leave or remain a CN is based on aspects such as: costs associated with the disengagement; CN reorganization in order to yield a positive balance between the benefits (payoffs) and costs incurred
while achieving global goals and strategic objectives; potential conflicts that may appear between the CNs global objectives and those of
each individual member organizations. The JLR decision problem may be analyzed at different levels, e.g., at CN level, individual CN member organizations level, inter-organizational collaborations level.
59
3.4.2. Performance Assessment in a Collaborative Networked Environment
Despite the relatively high number of research projects in the area of CNs, analytical tools
are still needed to support CNs and their member organizations to perform an economic
analysis. Few studies analyze the economics of CNs.
The few existing studies are focusing on specific aspects, e.g., partner selection. An
analysis of CN reconfiguration considering manufacturing cost and time as decision factor is
presented in Wu et al. [2005]. However, this study is focusing only on partners selection in
VEs. And so does the study performed by Yigin et al. [2007]. Characteristics, models and
performance measures of collaborative e-Work organizations are described by Nof [2003,
2006]. A performance measurement system for extended enterprises and VEs, built on the
concepts of trust and equity, has been developed by Saiz et al. [2005]. The focus of the
framework, however, is not on economic aspects; its basic components are goals, objectives,
strategies, plans, policies and critical success factors.
Walters [2005] identifies contributions towards a planning, performance and control model
for evaluating different alternatives and strategic issues. The focus is on the implications of
integrating and coordinating the operating and cash cycles of component firms of virtual
business organizations, from an operational and strategic perspective. This is one of the few
economic analysis for VEs. However, the emphasis is on cash flows, performance planning
and management, management of working capital and fixed assets, and not on CNs
performance assessment.
Azevedo et al. [2006] underline the necessity of elaborating a framework, which gives
input to a networks global performance management system in CNs, and simultaneously
provides the necessary partners alignment. The authors propose an approach to develop such
a framework, which comprises two layers: a data and information layer, and a functionality
layer. However, further R&D work needs to be pursued to fully specify such a framework and
performance management system.
to develop performance indicators. Preliminary results have been presented by Camarinha-
Matos and Abreu [2005], where metrics referring to “task level” are proposed, with emphasis
on social networks related to a business collaborative environment. More elaborated outcomes
and experimental results based on data from two existing CNs are discussed by Camarinha-
Matos and Abreu [2007]. The role of value systems in the virtual organization breeding
environment, under the assumption that the cooperation is based on a reciprocity mechanism,
is discussed by Abreu and Camarinha-Matos [2008].
ATHENA EU project 109
developing an interoperability framework. However, no (economic) model for performance
assessment is proposed; five theories which can be useful to analyze business interoperability
are briefly presented. A proposal for an interoperability management system is also made.
Main theories which could support business interoperability are available in [ATHENA
B3, 2006]. These theories and their usefulness to analyze different aspects related to business
interoperability are presented in Annex B.
Brost et al. [2005] describe an approach for defining performance indicators for policy
chains, which are understood as CNs in the government sector. Their approach relies on two
existing methods, which have been tailored to CNs: one for defining performance indicators
for traditional (e.g., non-virtual) public organizations, and another to support the analysis of a
108 http://www.ecolead.org 109 http://www.athena-ip.org
defense organizations.
Profit allocation in distributed chains under decentralized control has been analyzed by
Guardiola et al. [2007]. However, the authors study the particular case in which a single
supplier supplies several non-competing retailers with goods for replenishment of stocks.
As presented by Chituc and Nof [2007], aspects related to performance appraisal and
economic justification for the JLR problem for a CN, a group of organizations within a CN, or
for an individual organization are of utmost importance to managers. Challenges in
overcoming the difficulties to quantify investments in, or benefits from joining, leaving or
remaining in a CN emphasize that traditional methods need to be enhanced and new
paradigms, methods, frameworks and models aiming at CN performance assessment need to
be developed. They may not necessarily be completely different from those of the existing
organizational paradigms and economics, since some measures do not necessarily negate any
of the earlier traditional economic measures. Thus, it is required to analyze and synthesize
traditional, existing paradigms, methods, frameworks and models and apply or map them to
CNs.
Attempting to answer to questions such as: “If I (we) decide to join, leave or remain in a
network, will the difference between the total costs and payoffs be in my (our) favor?”, “How
can such balance be evaluated?“, “How is it possible to assess CNs performance?” as
foundation for the JLR decision for CNs, groups of organizations within a CN, or individual
organizations, three main ways for CN performance assessment have been identified by Chituc
and Nof [2007]. They concern performance indicators, benchmarking methods, and
frameworks.
Performance indicators are quantitative measures of a specific characteristic or aspect
related to CNs, e.g., cost, payoff. They can support an analytical comparison, obtained by
calculating different indices. The indicators aimed at assessing CN performance must consider,
among others, the strategy and vision of the entire CN and of their member organizations.
Different benchmarking models, su