Keywords

1 Introduction

An increasing pressure for organizations to participate in collaborative business processes has created new research challenges on how to adapt the IT-systems to effectively cope with this fast emerging dynamics. This trend is observed in diverse domains, including manufacturing supply chains, services sector, and also logistics networks. For instance, a collaborative logistics framework for the integration and collaboration among stakeholders in logistics chains is proposed in [1]. A particularly relevant sector, due to its economic relevance, is the logistics ecosystems associated to ports. Stakeholders in this area are under the pressure to adopt electronic data exchange with peers, private or governmental, while at the same time their success depends on their strategies regarding business partnerships.

The difficulties here are related to the large number of services each partners has to offer/participate in, associated to the adoption of a total electronic data management and exchange. The electronic data exchanges can take many forms in terms of protocols and technologies (e.g. HTTP, FTP, SOAP, RESTful, WCF/.NET, JEE, DNS), and data models structure and semantics (e.g. STEP, HL7, DATEX, SWIFT, IMO, GS1), to mention only a few. Furthermore, business requirements are commonly directly mapped to software development needs without strong enough component models. This is recurrently identified as a process to technology “gap”, representing the lack of well-founded approaches to automatically manage all steps from the inception/design of new business services/processes to their execution, management and evolution.

This challenge requires multi-disciplinary contributions from processes/business to technology/engineering domains. Although modularity is recognized as of paramount importance to reduce lifecycle complexity, promote collaborative developments, and allow competitive complex IT-systems composed of components supplied by diverse software developers, typical software systems lack sufficient adaptability to the world diversity [2], i.e. generated solutions tend to be specific. As a result, making adaptations is a needed time consuming process, aggravated by the associated risks of potential errors that might be introduced through changes. The research community is for long tackling this problem from complementary approaches. One of those approaches is the component-based software engineering (CBSE) initiative [3], focused on efficiency issues like performance and reliability. The certification of components is argued as a valuable contributor to the increase of reusability, and model behaviour prediction. Another approach is related to a formal modelling, using domain analysis (FORMULA) [4, 5]. The establishment of model driven strategies to address formal structuration of the complex technology bindings were since long proposed by the Object Management Group (OMG). A concretization of the OMG’s Model Architecture (MDA) vision, where platform independent models (PIM) are automatically mapped to platform specific models (PSM), is proposed and discussed in [5]. Nevertheless, given the underlying complexity, the proposed modelling approach and tools offer only partial specialized automation, lacking a whole and consistent integrated development workbench (e.g. popular frameworks/tools like OSGi, Maven, Eclipse and interdependent plug-ins, are not consistently integrated).

Considering this context, this paper presents and discusses the ECoNet platform [7], and its application to support a port community business case. Unlike an initial suite of concepts to model collaborations in the context of the Logistics Single Window (LSW), introduced and demonstrated in our previous research [7], in this paper we enhance the ECoNet platform with the concept of Virtual Collaboration Context (VCC). The experience with the development of a PCS demonstrator, involving the integration of a large amount of heterogeneous open source code, is discussed. It further argues for the need to move towards a total coordinated collaboration integration, and discusses the strengths, weaknesses and needed further research.

2 The Port Community System Business Case

The MIELE project has established the strategy to develop a Port Community System (PCS) as an enhanced version of the existing port single window (in Portuguese, Janela Única Portuária - JUP). The PCS, as defined by the EPCSAFootnote 1 association:

  1. (i)

    “a neutral and open electronic platform, enabling intelligent and secure exchange of information between public and private stakeholders in order to improve the competitive position of the sea and air ports’ communities”, and

  2. (ii)

    “it optimises, manages and automates port and logistics efficient processes through a single submission of data and connecting transport and logistics chains” [6].

The Portuguese port single window (PSW/JUP) system is developed based on the National Reference Model (NRM) [12], a set of business processes models associated to its offered services, and their supporting functionalities. The NRM processes, while following a model-driven approach, soon became outdated in relation to the operating PSW/JUP. This is a common problem as it is difficult to maintain the models updated along the lifecycle (inception, design, development, operations/maintenance, evolution) of complex IT-system. A suite of good practices regulating the changes required during the development and evolution, based on the operation experience and the identification of required changes, is necessary. The difficulties to maintain the consistency of the mapping between the platform independent model (PIM) and the platform specific model (PSM) are recognized and commonly associated to the weakness of the supporting tools. Existing development tools (e.g. Eclipse, Maven, plugins) are not complete enough to manage changes (refactoring at any level) and maintain the consistency of all supporting models (and meta-models).

This is a common situation considering that the implementations usually have to adopt specific approaches in order to answer requirements not identified during the design phase. Furthermore, the PSW/JUP system has different implementations for at least the Lisbon and Leixões ports. In fact one identified difference is the approach to manage the port gates. A port gate is a physical place where freight trucks or trains are registered and controlled. In Leixões there is an automated and reliable gate that registers all freight/transport flows using road transportation (trucks). On the other hand, in Lisbon the role of the gate is played by the IT-system of the port operator (concession managed under a pubic private partnership). This situation makes us to question the current PSW/JUP system and identify the need to rethink its architecture in order to promote similar computational responsibilities for all the ports.

3 ECoNet Platform Concepts, Services and Validation

The Enterprise Collaborative Network (ECoNet) platform supports preserving electronic relationships between an organization and its partners [7]. It follows an analogy with the classic correspondence management department, responsible to manage the inbound/outbond surface mail. The Enterprise Collaborative Manager (ECoM) IT-system is the component of the ECoNet platform responsible to manage the electronic exchanges. It can be seen as a formal abstraction for the current panoply of adapters necessary to support business message exchanges specific needs. For such abstraction, the ECoM implements a suite of Collaboration Contexts (CoC) specialized in managing the semantics of specific electronic message exchanges (EDIFACT, GS1, STEP, and HL7) developed to support distinct application domains. The ECoM component has therefore the following main computational responsibilities:

  • Based on the Collaboration Context zero (CoC0), a common secure and reliable communication infrastructure is made available to be shared by the other collaboration contexts;

  • The other collaboration contexts {CoC1, …, CoCN} are responsible to manage specific electronic data exchanges, share common services with the CoC0 (also representing system collaboration context) and might establish secure direct communication links depending on specific communication requirements (e.g., fast FTPS large files exchange);

  • The collaboration context might evolve to incorporate standard messaging (MOMFootnote 2) with publish/subscribe capabilities, transactions management for atomic (reliable) coordination, and other specialized mechanisms depending on specific requirements of a particular message exchange.

By computational responsibility we define the abstraction that models a mapping between requirements and capabilities that are (completely) fulfilled by an IT-system (made of software or software and hardware, under a unique supplier responsibility).

In the ECoNet platform model, the ECoM component plays a core role as the unique IT-system of the organization responsible for the coordination of the electronic message exchanges. In fact, ECoM is the inbound/outbound endpoint of an ECoNet-enabled organization (or ECoNet node). The proposed approach adopts a unified coordination of message exchanges between an organization and its peer partners (other ECoNet members). This raises two complementary concerns: i) the establishment and lifecycle management of the ECoNet network, and ii) the relations to the IT-systems of an ECoNet member.

Current approaches in this sector are based on proprietary architectures, usually positioned as B2B integration platforms associated to specialized services to access existing repositories in a diversity of formats to make effective the exchange of business messages (e.g., GXS platform). Depending on the scale/complexity, large business companies commonly establish their own standards for business partners to access electronic exchanges (INTTRA, DHL). Also large logistics and transport companies usually hold expensive enterprise resource planning IT-systems already embedding the capabilities to manage business messages exchange in a diversity of formats. The (Enterprise Application) IT-system to IT-system data exchange faces three main concerns:

  1. (i)

    How can an IT-system data be retrieved/stored (outbound/inbound);

  2. (ii)

    What is the format of the exchanged data (payload) and;

  3. (iii)

    What is the transport protocol, Fig. 1.

    Fig. 1.
    figure 1

    Exchange of data between organizations

    Full size image

This scenario establishes a complex distributed system where a source IT-system needs to be accessed to generate the payload message. If the IT-system has B2B data exchange embedded capabilities, the adapter might not be necessary. Nevertheless the question is what should be the adopted format (e.g. EDIFACT/X.12, GS1) considering that the potential partners might have adopted different IT-systems and so different data formats.

The fast growing of business exchanges makes interoperability, maintenance, and adaptability to a new business partner, a difficult and error prone process, not only at setup time but along the overall life cycle. Furthermore, as legacy IT-systems are usually not prepared for cooperation, the integration of B2B adapters or platforms requires, in most of the cases, a tight integration process by accessing internal data models to retrieve/store data. This process contributes to potential problems (and additional costs) when integrated systems are updated or new versions are installed, [13]. The growing complexity associated to the number and diversity of specialized IT-systems (adapters, B2B platforms), contributes to increase costs and the operational risks. Figure 2 illustrates a group of organizations linked by such adapters or B2B integration platforms as a traditional approach to establish B2B relations among organizations.

Fig. 2.
figure 2

Current B2B interoperability based on adapters

Full size image

Some of the main problems associated to the current B2B data exchange are:

  • Existing enterprise IT-systems, at least cheaper ones mostly adopted by medium and small enterprises (SME), are not prepared for B2B data exchange;

  • Adoption of adapters establishes strong dependencies on the legated systems. They generate a web of interdependent IT-systems difficult to maintain and evolve;

  • There are diverse standards for data modelling/format (e.g. EDIFACT, GS1), transport protocols (e.g. AS2, FTPS), security frameworks, and coordination frameworks, which might be adopted by a potential business partner, making the joining process of a new business partner a complex endeavour;

  • A new collaborative business partner might require changes to the installed B2B adapters if adopting different payload or transport formats.

The ECoNet collaboration platform aims to answer to the formulated weaknesses of existing approaches. Instead of putting pressure on unification of existing standards or proprietary models and protocols, ECoNet assumes diverse cultures (processes or technology), establishing a unified adapters framework, the collaboration context (CoC). In fact a collaboration context provides a unified framework for the adapters/B2B platforms as shown in Fig. 3. Instead of specialized adapters, vendors are invited to adopt the open specification of the ECoNet collaboration context mechanism and publish the newly created CoC at the ECoNet root portal (providers of certified CoC as products). In this way, any organization that decides to initiate a business relationships with new business partners, if they are ECoNet-enabled (if they have a certified ECoM instance installed or accessible through a cloud provider) they only have to install an interoperable collaboration context. At a higher abstraction level, the ECoNet establishes a kind of unified B2B logical bus. As such, ECoNet contributes to the collaboration preparedness of the members of the business ecosystem [8].

Fig. 3.
figure 3

The ECoNet collaboration platform as a unified B2B bus

Full size image

Based on these principles, a prototype of a generic file/message exchange and a Port Community System IT-system were developed. The file/message exchange system was the first reference implementation of the ECoM subsystem. The collaboration context zero is based on the CIPA reference implementation of the PEPPOL EU project as already discussed in [7].

Considering the complexity of the PEPPOL approach, a simpler generic secure and adaptive communication management is currently being evaluated. An alternative reference implementation was studied, OXALIS, promoted as an open source by DifiFootnote 3. Nevertheless, there is a significant conceptual different between PEPPOL, OASIS/Business Document Exchange Architecture [9] and the ECoNet strategy. In PEPPOL, the access points need to expose compatible transport protocols (START, LIME, AS2) while for ECoNet nodes, the transport protocol is internal to ECoM. The transport protocol is transparent for the IT-systems and also for the collaboration contexts (CoC), considering it is abstracted by the collaborative context zero (CoC0). The CoC0 maintains the concept of access point (AP) as defined by OASIS/BusDox [14]. The plans are to (re)implement a simplified secure and reliable message exchange mechanism between ECoNet nodes eventually reusing some parts from the PEPPOL reference implementation but based exclusively on ECoNet requirements. There is a common idea about the simplicity to use nomadic commodities (smartphones or tablets) and the Web Services technology to support collaborations. In fact, those facilities offer services to the users of some organization of some service provider (e.g., Facebook). The ECoNet infrastructure addresses the business data exchange needs, but only those with origin in the IT-systems that automate the enterprise’s business processes. Those IT-systems in fact are being enhanced with new communication channels beyond classic user interfaces (web based or not), to support nomadic and things (Internet of Things) interactions, e.g., a transponder (thing) in a container to support real-time tracking.

Introduction of the Virtual Collaboration Context (VCC) concept

A collaboration Context was defined in [7] as:

  • Collaboration Context (CoC) – abstracts a specific collaboration and is made of one or more collaboration context services (CCS), where CCSA = {CCS0, CCS1 … CCSk}, for k > 0, is the set of the CCS of the collaboration context CoCA. The collaboration context service zero (CCS0) is a mandatory (system) service and establishes the CoC entry point.

It establishes a bounded collaboration semantics as far as data formats and semantics of source and target IT-systems are concerned. As mentioned, it plays a similar role to a specialized adapter for the management of the exchanges of data between IT-systems in two organizations. Nevertheless, in the initial model, if an IT-system that accesses peer IT-systems through an interoperable CoC needs to establish multitenant spaces for groups of ECoNet nodes (partners), there was no mechanism available. To solve this weakness, the model was improved to support the concept of Virtual Collaboration Context (VCC). A VCC establishes one or more groups (multitenant spaces) from the ECoNet ecosystem members able to establish restricted view only accessible to nodes that joined the VCC. It is important to clarify here that a VCC is to be managed by IT-systems that access one or more CoC to exchange business date with a peer IT-system (from a business partner). For an ECoNet node (from the initiative of an IT-system) to join a VCC it needs to be accepted by the VCC owner, i.e. the node that created it. Formally this new concept enhances the CoC with the newly created virtual collaboration context (VCC):

  • Collaboration Context (CoC) – also abstracts one or more virtual collaboration context services (VCC), where VCCA = {VCC0, VCC1… VCCm}, for m > 0, is the set of the VCC of the collaboration context CoCA

  • A Collaboration Context (CoC) is therefore (e.g. for the collaboration context A):

    • CoCA = CCSA U VCCA; i.e., the set of all the CCS and VCC of the collaboration context CoCA;

  • The Virtual Collaboration Context zero (VCC0) exists by default and includes all the ECoNet nodes that have the respective collaboration context installed and belongs to the same business partnership.

The visibility of an ECoNet node is restricted to the peer ECoNet nodes that accepted to be business partners (same business partnership). This means that each ECoM instance maintains a list of the ECoNet nodes that were trusted to be considered as business partners. The ECoMsgExchange reference implementation already supports the virtual collaboration contexts making possible for ECoNet members to establish restricted file or message exchange share spaces, Fig. 4.

Fig. 4.
figure 4

A snapshot of the ECoMsgExchange ECoNet reference IT-system

Full size image

From the ECoMsgExchange web interface a user from the organization can create and invite ECoNet members to join a VCC. For a selected VCC, a user can share files or messages (currently limited to 10 Kb). For both the ECoMsgExchange and PCS IT-systems, presented in the next chapter, two distinct specialized CoC were developed: (i) the CoCECoMsgExchange, and (ii) the CoCPCS.

4 The PCS Validation Business Cases

The Port Community System was developed as a complement to the current PSW/JUP system. The objective is to develop a wider port community of service providers with a single access point for both electronic exchanges and web access. A snapshot of a transportation container tracking inquire is shown in Fig. 5. The proposal of an extended approach to the management of formalities in a sea port, as worked in the MIELE project are related to the application of the Directive 2010/65/EUFootnote 4 and the need for an enhanced collaboration among EU ports promoting, in this way, single procedures for stakeholders and thus simplify processes while maintaining the required security. A first prototype implementing container tracking as an initial service for the new a PCS was developed, Fig. 5.

Fig. 5.
figure 5

A snapshot of the PCS ECoNet demonstrator IT-system

Full size image

One of the main challenges in this domain is related to the need for a generalized cooperation among a panoply of IT-systems supporting transport and logistics processes from business stakeholders and interactions with customs and other authorities. By establishing a unified adaptive business collaborative framework, the ECoNet infrastructure is expected to make easier the adaptation of the participating IT-systems from a diversity of (with multiple cultures) stakeholders on answering the requirements established by Directive 65 for single authorization/control procedures inside Eurozone. The port community system is from inception integrated to ECoNet being this way interoperable with port administrations and other regulators IT-systems along the transport chain. Such common interoperable platform plays a key role for the agility of door-to-door integrated transport and logistics services offered by the concept of logistics single window (LSW) as discussed in [7].

The need for efficiency on the exchange of logistics information between information systems is discussed in [10] by proposing guidelines to promote collaboration processes among stakeholders of maritime transport and regulatory procedures for Single Window Systems. In fact, the ECoNet open specifications aim at contributing to establish a structured multi-supplier technology landscape able to reduce costs and risks associated to existing models to make effective electronic data exchanges.

The ECoNet proposal emphasises a separation between intra-organization and inter-organization issues. While focused on the inter-organization perspective by postulating a well-founded model (a common virtual breeding environment - VBE) to manage collaborative relations among groups of organization with different organizational, processes, and technology cultures, the intra-organization is also being considered. The difficulty to adapt complex legacy IT-systems to the newly proposed ECoNet services has motivated the (re)construction of PCS as a wrapper of JUP, Fig. 6. Nevertheless, further enhanced integrated models and validations are necessary, namely a high level modularity abstractions in line with the Cooperation Enabled System [11] as a strategy to contribute for a reduction of the growing technology dependencies (vendor lock-in situations).

Fig. 6.
figure 6

The new PCS IT-system wraps the legated PSW/JUP

Full size image

5 Conclusions and Further Research

The collaborative logistics and transport involves large-scale complex distributed systems that must be reliable, maintainable (panoply of technology suppliers), competitive, auditable, and secure. Additionally, it is necessary to get the confidence of all stakeholders for the management of their critical business processes. The ECoNet platform is developed in support of a holistic framework able to speed up the adoption of competitive business collaborative networks and at the same time it contributes to a new generation of dynamic and agile IT product and services. Unlike the first prototype of ECoNet focused on demonstrating the potential of a unified coordination of B2B exchanges, as discussed in our previous research [7], in this paper both an enhanced model of the ECoNet platform as well as a reference implementation for its PCS prototype were presented. Furthermore, the complexity of adopting the open source PEPPOL/CIPA reference implementation and the need for a simple approach to the communication layer was discussed.

The need for novel distributed systems technology able to cope with the growing complexity of collaborative logistics and transport was confirmed by a great level of adherence of stakeholders to the ECoNet proposition. Further validation of the implemented system regarding the exchange of traffic data involving DATEX2 format and payment security enforcement for a competing gas distribution networks (forecourts) is now under planning and development. Nevertheless, some weaknesses can be identified in the current implementation, namely:

  • The proposed model is not yet validated for large data sets under diverse formats and semantics. Existing approaches while proprietary are quite complete and credible to manage complex exchanges;

  • The ECoNet strategy might challenge the value of well-established business platforms (or products) considering that with the adoption of ECoNet by main stakeholders such unique solutions might have to move to the open ECoNet environment. Nevertheless this change needs to get the approval and confidence of stakeholders about its competitive advantage against current proprietary approaches (even if they adopt existing standards).

The EcoNet infrastructure is to underlie professional business to business data exchanges. While possible, it is not expected to be installed in a personal laptop or in a nomadic (smartphone or tablet) to support the establishment of personal or even business data exchanges. For those case other simple technology approaches are available (from single Web Service mechanism to platforms specialized for personal interactions support). Nevertheless, it is expected that through the new enhanced ECoNet enabled IT-systems (integrated to the ECoNet platform) a suite of new APP based services indirectly using the ECoNet infrastructure, might be available.