Improvement of GVSRM with Addressing the Interoperability Issues in Global Village

Published Online October 2014 in MECS

Global village, has established a new innovation called ‘globalization’. In such environment, collaboration is getting increasingly important, so the global village organizations have to react to this innovation force and prepare flexible collaboration on a worldwide scale by aligning their business processes. “The opening of the organizations’ ‘borders’ is no longer regarded as a necessary evil, but rather as a chance with strategic importance [1]”. Such collaborative synergy may lead to value-added and innovative services that would have otherwise been difficult to achieve if organizations work in isolation. Collaboration allows organizations to explore one another's core competencies, improve services to their customers, allow efficient use of resources, and increase information sharing. Also With growing complexity of Today's business processes, the creation of effective business process models requires the presence of several, potentially spatially distributed stakeholders.

“On the other hand, competitiveness has driven enterprises towards specialisation. Particularly, SME (Small/Medium Enterprises) business providers want to expand their solutions, maintaining the focus on their core competences and getting support from a network of specialised partners. Hence, business success now depends on the sum of both the SME’s and its partners’ performances. Enterprises are thus developing dedicated business areas to manage the current partnerships and the search for new partnerships that are more aligned to their business needs. This leads to an inherent need for interoperation between all the involved parties [2]”. So, in the current era, the effective cooperation between organizations is a necessity. The key to a successful cooperation is based on the establishment of proper interoperability levels among the collaborative computing entities.

Although the GVSRM (Global Village Services Reference Model) is a reference model for global village services realization, in this model, the subject of ‘interoperability’ has not been mentioned. In this paper, we are going to propose a federated approach for global village Services Interaction and then by adding the corresponding interoperability components to GVSRM, start the discussion about it.

The rest of the paper is structured as follows: firstly, the literature related to interoperability efforts are discussed. In section III, we define the VHG (Virtual Holding Governance) as a building block of global village grid and its structure. We first propose an approach for VHGs interoperability in section IV and then improve the GVSRM by adding the corresponding interoperability components to it. Finally, section V proceeds with the conclusions and recommendations for further research. The paper has an appendix in which the full model of GVSRM is presented.

• II.    L ITERATURE R EVIEW

The interoperability of ICT systems and applications has been prescribed by numerous frameworks and methods. Several holistic frameworks for enterprise interoperability have already been proposed [3]. Some of the most well-known are:

LISI (Levels of Information Systems Interoperability). In the field of enterprise interoperability, it is worth noting the first significant initiative: the LISI approach developed by C4ISR Architecture Working Group (AWG) during 1997. The purpose of LISI is to provide the US Department of Defense (DoD) with a maturity model and a process for determining joint interoperability needs, assessing the ability of the information systems to meet those needs, and selecting pragmatic solutions and a transition path for achieving higher states of capability and interoperability [7].

INTEROP Interoperability Framework. INTEROP (Interoperability Research for Networked Enterprises Applications Software) was an excellence network funded by the European Union from an IST action in the Sixth Framework Programme (FP6) (INTEROP Network 2003). The interoperability framework proposed by INTEROP, which now has been standardised (ISO/DIS 11345–1,  2011), is shown as a cube with three dimensions that represent: (1) interoperability barriers, which may be conceptual, organisational and technological; (2) interoperability aspects that have to be present at all levels in the enterprise: business, processes, services and data; (3) interoperability approaches to solve interoperability barriers, which are federated, unified and integrated [4].

The ATHENA Interoperability Framework (AIF). This framework was developed as part of the European project Athena (IST-2001-507849 2004). It adopts an integrated business and technology perspective to analyze interoperability problems and proposes a set of solutions on different levels, which are essentially based on models that facilitate or guide the exchanges [5]. The AIF is structured in three parts: conceptual integration (oriented towards concepts, meta-models, languages and relationships among models), application integration (oriented towards methodologies, standards and domain models) and technological integration (oriented towards technological developments and environments) [6]. Moreover, it includes a generic procedure of how to apply AIF. The strong point of AIF is that it is general enough to be applied in any company. But if the users are not familiar with it, they may find it difficult to apply [4].

The European Interoperability Framework (EIF). EIF (European Commission 2005) supports the European Union’s strategy of providing user-centered eGovernment services by facilitating, at a pan-European level, the interoperability of services and systems between public administrations, as well as between administrations and the public (citizens, businesses). It defines a set of recommendations and guidelines for interoperability services. According to the EIF there are three areas that are fundamental for identifying and analyzing interoperability problems: organisational interoperability, which contemplates process modelling and collaboration between the authorities; semantic interoperability, which contemplates not only the information resources that might be connected, but also the possibility of interpreting the information automatically so that it can be reused by computer applications that were not involved in its creation; and technological interoperability, which concerns the interconnection of applications through a number of different technological components [4].

IDEAS (Interoperability Development for Enterprise Application and Software). The IDEAS interoperability framework was developed by IDEAS project on the basis of ECMA/NIST Toaster Model, ISO 19101, and ISO 19119 and augmented through the quality attributes. The framework also intended to reflect the view that Interoperability is achieved on multiple levels: interenterprise coordination, business process integration, semantic application integration, syntactical application integration and physical integration [7].

• III.    V IRTUAL H OLDING G OVERNANCE

• A.    Definition

In order to (1) avoid dispersion and fragmentation of services; (2) rapidly offer several instances of a value-added service in response to the various created opportunities; (3) help the stability and continuity of providing value-added services through long-term cooperation of trustee members, GVSRM introduced a new concept called VHG. A VHG is a temporary, scalable, dynamic cluster/association comprising of existing or newly service provider organizations which its aim is satisfying the requirements of global village actors through electronic processes (eProcesses) [8].

The eProcess is a chain of activities each of which is realized by one or more services and/or each service may realize several activities in an eProcess. The eProcess defines the rules, constraints and status of activities forming the work which is the outcome of executing eProcess as well as message exchanges among these activities. The eProcesses are often as hierarchy of sub eProcesses and activities.

A VHG, as a building block of the global village grid, must be the aggregation of different service provider organizations to be able to offer a variety of electronic processes which are combination of different services. In other words, the grid of global village is comprised of VHGs.

• B.    The Structure of a VHG

According to Fig. 1, we consider three abstraction layers for a VHG:

• 1.    Service layer: the middle layer in which the atomic services related to different organizations of VHG is offered. This layer is based on SOSA (Service Oriented Strategies and Architectures) ontology that this ontology has been argued in [8].

• 2.    VAS (Value-Added Services) layer: in the highest level of abstraction, the value-added services which use the lower layer services as their constructing components are provided. “In the SOSA ontology, the added-value global village services are as repeatable task could be compiled as atomic or composite, and they could be collected from the public or private global village services [8]”.

• 3.    Resource layer: The physical resources that provide the necessary platform for service implementation.

In the case of eligibility, any service of any organization and with any service description language is acceptable in the VHG. However, in order that the services be able to collaborate with other services to create complex processes simply and effectively (concerning the top layer), a unified layer such as WSCI is defined on top of existing service stack by Interface

Unifying component. Services can be implemented with any programming language. Other components in this layer are related to the discovery, publish and register the services.

VASs are realized using an ‘eProcess’. The eProcess is an instrument for managing the coordination of individual services into more complex interactions. An eProcess uses a meta-model for expressing its activities and defining concepts and notations used for its description.

Regarding to Fig. 1, a VHG comprises the following components:

• (1 ) organizational management tools for accepting new partners, and controlling the access rights; (2) tools for the management of internal eProcesses related to VASs as well as the external eProcesses which agree with the other VHGs (eProcess managing and eProcess orchestrating components); (3) collaborative eProcesses designer among VHGs; (4) local catalog: a list of existing services in VHG; (5) catalog management tools for registering, publishing and discovery of services; (6) interface unifying tools for unifying interfaces of accepted services; (7) interoperability knowledge base (the knowledge of consistency of a service with other services as well as the knowledge of utilizing service in different collaborative models).

WSCI

S1 from O2

urce1 from

R2 from O1

Discovery Engine

Interface Publishing

Local

VHG Registry

Interface Unifying

Controlling the Access Rights

Accepting New Partners

Process

Managing

Process

Orchestrating

Legal IOP llllll

Process IOP

Service IOP

Pragmatic IOP

Semantic IOP

Syntactic IOP

ТТТГ

Technical IOP

Fig. 1. The abstraction of a VHG

• IV.    T HE P ROPOSED A PPROACH FOR G LOBAL V ILLAGE S ERVICES I NTERACTION AND I MPROVEMENT OF GVSRM

  The GVSRM was developed with the aim of providing a reference model for the global village services (Hashemi, 2011). There is the holistic information about this model in reference [8]. Despite relative completeness of this model, one of its obvious shortcomings is lack of attention to the crucial issue of interoperability in the global village. In this section, we will propose a federated approach for interoperability among the VHGs of the global village and then improve the GVSRM with addressing the corresponding interoperability components to it.

• A.    The Proposed Approach for Interoperability among the VHGs of the Global Village

  Concerning interoperability, many noticeable results have been achieved since 1990. The primary reason for the need to interoperability is distribution of information processing workload among involved partners. Since in the current competitive era, there is a great deal of hustle on organizations to accelerate in cooperation, interoperability and shared business processes with other organizations in a shared network is a main necessity. The global village ecosystem is labeled with cross-border organization collaborations and computing based on global village services. The key to a successful cooperation is based on the establishment of proper interoperability layers among the VHGs of the global village.

Vernadat (F. B. Vernadat 2007) defines interoperability as “The ability to exchange or share information (wherever it is and any time) by two or more business entities […] and to use functions or services of one another in a distributed and heterogeneous environment [9]”. The main goal of interoperability is to cover the incompatible and heterogeneous aspects of collaborative entities.

According to [10-12] references, there is various approaches for ensuring interoperability: integrated, unified and federated. Each approach focuses on a different method of ensuring achievable interoperability.

The integrated approach ensures interoperability by using a common format for all models, shared execution environments and shared communication conventions. In this approach, interoperability methods are injected into the internal implementation of components. The unified approach ensures interoperability by using shared metamodels and concepts. In federated Approach, the involved partners exploit from a shared ontology or a meta-model which is established ‘dynamically’ through negotiation mechanisms (not pre-defined). In other words, the interoperability is based on negotiation mechanisms and contract-based solutions.

“As we go from integrated to federated approaches, the scale of dynamicity of the collaboration and use of metalevel infrastructure services for maintaining the interoperability increase. The focus of methods used for integrated and unified architectures is in the modelling, design and deployment phases of the system; while the focus for federated approaches by necessity is moved towards an operational time management environment [10]”.

The ability of a system to interoperate with others is a complex and multi-dimensional concern which must be considered simultaneously from different perspectives to cover all the concerns relevant to different stakeholders [13]. For decreasing design complexities, layering design is a proper approach for ensuring interoperability among systems. For interoperability of global village VHGs, we propose the layering model that is depicted in Fig. 2. According to the layering interoperability model (Fig. 2), the proposed approach for interoperability of global village VHGs is depicted in Fig. 3. In sections A.1 to A.7, we will briefly explain the selection logic, goals, approaches and implementation of each layer as well as the details of Fig. 3.

Prior to starting the discussion, it is necessary to illuminate two points:

As it has been stated in [14], based on the OSI reference model, each layer is responsible for providing services to the next higher layer. Whereas the layers of technical, syntactic, semantic, and etc. do not provide services to legal provisions, considering of legal issues as a separate layer is wrong. Legal issues are cut across layers, because they relate to legislation, contracts, and agreements and must be observed by all other layers.

The other necessary point is that the issues related to some interoperability layers, such as process, pragmatic and semantic layers depend on current contract context, so, in Fig. 2 this has been considered as ‘Contract Context’.

A.1. Process Integration Layer

According to Fig. 3, in this layer, the shared business processes among the VHGs interested in collaboration with process choreography details is defined and established. So the functional and non-functional tasks can be understood and implemented by all partners.

The shared business process is an instrument for managing the coordination of individual eServices belong to various VHGs into more complex interactions. The eServices can be composed through choreographies or orchestrations. “A service choreography describes the interactions between services participating to the business process from a global perspective [15]”. Service choreographies are not executed, they are enacted. At run-time, each VHG in a service choreography executes its part of it (i.e. its role) according to the behavior of the other VHGs. A choreography's role specifies the expected messaging behavior of the participants that will play it in terms of the sequencing and timing of the messages that they can consume and produce [16]. A service orchestration is related to executing of each role by each VHG (called the orchestrator).

The proposed approach is that the logic of the agreed choreography is modeled with a computing platform independent manner as a workflow in which the activities represent the message exchanges among the participants.

Fig. 2. The layering interoperability model among the VHGs of the global village

Also, controls and synchronizations is defined to enable seamless integration of distributed roles among VHGs.

‘Contract-based interoperability’ is a platform independent approach which provides a proper environment for intertwining the non-functional aspects of collaboration such as strategic, operational, and tactical guidance into the functional basic models [10].

This contract is similar to a comprehensive plan which defines the functional and non-functional behavior of VHGs involved in executing the shared process:

From functional view, the partners must agree on following aspects in contract context: choreography, assigning the various sections of process to capable VHGs, partners’ tasks in the form of activities, exchanged information in the form of document flow, calls and eventually termination.

The non - functional provision of the contract covers across the interoperability scope and relates to governmental tasks of VHGs, So all partners must share visions, agree on objectives, align priorities, provide sufficient resources to their respective interoperability efforts and progress towards agreed goals, within agreed timeframes.

In implementation phase, the contract-based process model is developed using BPMN concepts and the functional and non-functional aspects of that model are described using proper ontologies such as ‘contract ontology’ and ‘DP ontology’ (Fig. 3). The components such as ‘accepting new partners’, ‘controlling the access rights’, ‘process managing’ and ‘process orchestrating’ are deployed in this layer.

A.2. Service Interoperability Layer

In this layer, the interconnection among autonomous services running the process of the higher layer is established and the continuity of their collaboration is managed using federated approaches. With the federated approach, it is possible to truly address the dynamic nature of collaboration and evolution requirements [1].

Service Oriented Strategies and Architectures (SOSA) approach is proposed to isolate the local implementation of services from corresponding local processes. This approach covers the following aspects:

VHG1

Role1

Accepting New Partners

Controlling the Access Rights

Role3

Process

O1

Unifying

Pragmatic IOP eProcess Orchestrating eProcess Managing

Discovery Engine

Local

VHG    •

Registry

VHG2

Contract Document

Interface Publishing

Contract-based Process Model:Detailed Collaboration and Choreography

Global Village Registry

Fig. 3. The proposed approach for the interoperability among the VHGs of the global village

Creating a proper interface for the accepted services by the VHG in order to facilitate the implementation of choreographies (such as WSCI). This interface can: (1) propose a computer interpretable description of services and their capabilities; (2) provide facilities for understanding how to interact with services in the context of a specific business process; (3) anticipate the expected behavior of services at any point in the process’ lifecycle;

Providing tools for service publishing, discovering, calling, composing and continuous monitoring;

Mapping the exchanged information described in the process model into perceptible and real messages between services;

Conformance of the quality requirements of a service requestor and the quality properties offered by the service provider.

To implement the above aspects, the components such as the ‘interface publishing’, ‘discovery engine’, ‘local VHG registry’, and ‘interface unifying’ are deployed in this layer. The ‘global village registry’ exists in the global village grid level.

A.3 . Pragmatic Interoperability Layer

The compatibility between the intended versus the actual use of received message within a relevant shared context is the aim of this layer [17].

Negotiation and agreement between partners on the compatibility of their rules and business policies is proposed using the same contract-based interoperability approach in the process layer. This approach not only encapsulates the rules and policies, but functional and non-functional properties of the collaboration as well as [10].

A.4. Semantic Interoperability Layer

Understanding the precise meaning of exchanged information by partners involved in cooperation is the aim of this layer (e.g. definitions, relations and structure of terms used to describe data).

Developing vocabularies corresponding to the interaction domain for information description is the common approach to ensure semantic interoperability.

The definition and providing of common required terms for each upper layer is implemented using ontologies mechanism. In Fig. 3, have been used two different ontologies in this layer: one for describing the terms in the contract (‘contract ontology’) and other for describing the details of the distributed agreed process (‘DP ontology’).

A.5. Syntactic Interoperability Layer

The aim of this layer is to introduce a common structure to exchange information (messages). To implement, we can use standardized data exchange formats such as XML, EDIFACT, and ANSI.12.

A.6. Technical Interoperability Layer

This layer covers the technical aspects of linking information systems. To implement this layer, we can use the data transfer protocols such as TCP/IP, HTTP and FTP.

A.7. Legal Interoperability Layer

(1) Shared interpretation, understanding, and respecting of laws originating from interaction and cooperation by all involved partners; (2) remedying of incompatibilities which might exist in laws, policies, strategies and culture about shared issues of partners involved in the interaction, are the aims of this layer.

Adaption and harmonization of existing laws and/or issuing new legislation are the approaches to ensure the interoperability in this layer. In implementation phase, we can use standards and languages, such as ‘legal XML’.

• B.    Improvement of GVSRM with Addressing the Interoperability Issues in Global Village

In Fig. 4 and according to the topics discussed in section IV, the yellow classes are cases that have been added to the GVSRM. Note that in Fig. 4, only that part of the GVSRM has been shown which is related to the interoperability issues. You can see the complete model of GVSRM in appendix A.

For any shared external business process, a choreography among VHGs involved in the process is enacted. At run-time, the roles in an enacted choreography are played by the services of VHGs. Each role consists of activities and interactions (choreography, role, activity and interaction classes in Fig. 4).

The local VHG registry and distributed global village registry classes have been considered for local (in VHG) and global (in global village) registry of services, respectively. For each enacted choreography, the interoperability requirements are provisioned by various interoperability layers (based on the proposed model in Fig. 2).

• V. C ONCLUSION AND F UTURE W ORKS

The condition for the survival of service provider organizations in a competitive environment such as the global village ecosystem, is cross-border cooperation with other organizations and use of the service-based computing. The key to a successful cooperation is based on establishment of proper interoperability layers among the collaborative computing entities. The main goal of interoperability is to cover the incompatible and heterogeneous aspects of collaborative entities and solve the challenges of this domain. In this paper by considering the VHGs as the building blocks of the global village grid, we proposed a federated approach to ensure successful cooperation among them. So, we used contract-based method in process layer, the SOSA approach in the service layer and ontology mechanism in semantic layer. Other layers of the model provide necessary facilities for proper message exchange between cooperative services. In the end, with regard to proposed layering model for interoperability in the global village, we sought to improve the GVSRM by addressing the necessary components at interoperability field. Discussion about the efficiency of this model can be studied in a separate paper.

Fig. 4. The improved model of GVSRM (the classes with yellow title have been added)

APPENDIX A: the GVSRM [8]