ARTICLE

Service-oriented computing and model-driven developmentas enablers of port information systems: an integrated view

Maria A. Lambrou & Ørnulf Jan Rødseth &

Howard Foster & Kay Fjørtoft

Received: 26 March 2012 /Accepted: 10 October 2012 /Published online: 27 October 2012# World Maritime University 2012

Abstract Port information management is considered a critical instrument towardsenabling international transport and trade; thus, various forms of Port InformationSystems (PORTIS) have been developed today, namely Port Community Systems,Terminal Operating Systems and Single Window systems. In Europe, the nauticalinformation system SafeSeaNet is viewed as an important e-infrastructure. PORTISsystems are expected to evolve into next-generation technological platforms in orderto offer a fully integrated digital environment to a multitude of maritime businessactors and public authorities towards more efficient, safe and environment-awaretransport and trade infrastructures and services. We propose service-oriented com-puting and model-driven development techniques as a robust PORTIS modelling anddevelopment approach. We present a reference model of PORTIS and a particularenabling methodological and technological framework. The proposed approach hasbeen tested in a maritime single-window case.

WMU J Marit Affairs (2013) 12:41–61DOI 10.1007/s13437-012-0035-0

M. A. Lambrou (*)Department of Shipping, Trade and Transport, University of the Aegean, 2A Korai Street, Chios 82100, Greecee-mail: mlambrou@aegean.gr

Ø. J. Rødseth : K. FjørtoftDepartment of Maritime Transport Systems, MARINTEK, Otto Nielsens Veg 10, 7052 Trondheim,Norway

Ø. J. Rødsethe-mail: OrnulfJan.Rodseth@marintek.sintef.no

K. Fjørtofte-mail: Kay.Fjortoft@marintek.sintef.no

H. FosterDepartment of Computing, City University London, Northampton Square, London EC1V 0HB, UKe-mail: Howard.Foster.1@soi.city.ac.uk

Keywords Information systems . Service-oriented computing . Port communitysystems . Single window

1 Introduction

Building upon the argument of Crainic et al. (2009), “transport systems devel-opment proceeds along three major, parallel and complementary directions, namely:a) terminal equipment and infrastructure; b) information processing technology—hardware and software; and c) the methodology—models and algorithms—requiredto process the information and transform it into useful actions and advice”. Whilst theadvancement of the field depends on the integration and co-evolution of all the threedirections, Crainic further argues that “the physical aspects (equipment, software andhardware) seem to be prioritized over the methodological ones, to the possibledetriment of the overall efficiency of the transport systems”.

A similar pattern can be observed in the development of Port Information Systems(PORTIS), in particular. In our paper, a PORTIS is defined as a set of informationmanagement and communication systems and associated applications that support thebroad range of port operations such as rule compliance, logistics and insuranceprocesses. PORTIS are transformed today by employing new software developmenttechniques together with pervasive computing and automation technologies thatfacilitate the materialization of network forms of agile port organizations, integratedinto extended supply chains.

Our proposition consists in applying, testing and adapting emergent computerscience theory and techniques to the contextual underpinnings of PORTIS develop-ment and management. Next-generation PORTIS performance levels are targeted. Weconsider a particular methodological and technological framework as a robust engi-neering approach to the formal elaboration and analysis of functional and qualityrequirements as well the implementation and testing of emerging PORTIS applica-tions and supporting software architecture solutions. Thus, we enable the materiali-zation of innovative port strategies and operations based on PORTIS e-infrastructuresand e-services. We claim that by focusing on the PORTIS development methodology,we offer an important, missing methodological component to the academic andprofessional maritime transport community.

2 Rationale of PORTIS

2.1 Efficiency and quality in transport and trade

The mainstream rationale for implementing a PORTIS is to make transport and tradeprocesses, port-centred operations in particular, more efficient and improved in terms ofthe quality of the offered e-services (Kia et al. 2000; Mostafa et al. 2010; Keceli 2011).Yang (2009) claims that Korean firms save about 2,600 billion won (US $2.3 billion)yearly by utilizing their integrated e-trade system which is mainly supporting importand export by ship. Yearly savings of GBP 163 million are estimated for businesses(Linnington 2005) as a result of UK authorities’ trade single-window operation.

42 M.A. Lambrou et al.

2.2 Innovation and e-business models

The innovation advantages gained by PORTIS implementation are often considered.Technological developments facilitating ubiquitous ship-to-shore communicationsand automatic tracking of ships and freight, alongside policy and economic develop-ments—namely strict security regimes, emphasis on corporate social responsibilityand an increased demand for transparency—change the prevailing business models inmaritime transport.

The formation of virtual enterprises and the smart, agile configuration of end-to-end transport and trade business processes, also paperless trade and transport, areenvisaged as a future business model, to be technologically enabled by pervasivecomputing and autonomous systems, situation and context awareness, standard dataformats and interoperability, and secure, ubiquitous data availability; thus, maritimetransport entities are envisaged to participate in various business networks and supplychains, dynamically, according to their competitive or cooperative strategies (Rodsethet al. 2011; Marianos et al. 2011; Fjortoft et al. 2011; Lambrou and Foster 2010).

2.3 Transparency and security

Paperless trade and transport, in particular, is envisaged in order to reach security andtransparency goals set by policy-making institutions and national governments.Electronic documents are formally structured, reliable, and are easier to process anduse, e.g. in harmonized and redundancy-free business processes and automated riskanalysis. Electronic data and their traceability over emerging information systems andapplications hinder fraud and illicit trade (UN/CEFACT Report 2005a, b, c), thus alsocontributing to improved associated efficiency and cost goals.

2.4 Green transport

Innovation in business models is envisaged in order to realize the energy savingspotential of shipping. There is still up to a 75 % CO2 emission savings potential (IMOReport 2009) for maritime transport. Significant parts of this potential savings dependon more efficient port operations both to reduce idle berth or anchorage times and tooptimize voyage execution. Thus, measures that improve the efficiency of trade willalso contribute to the greening of transport operations.

Ship speed as well as arrival/departure time optimization are today difficult toimplement due to a prescriptive contract regime between the parties of the transportoperation (charterers, ship operators and ports). New business models, depending oncoordination via improved information exchange, are expected to emerge (FlagshipDeliverable 2011; Paixao and Marlow 2002).

2.5 Standards

Maritime transport entities operate upon many well-established standards, i.e. UN/EDIFACT standards that need to be considered in emergent PORTIS systems devel-opment. Ship clearance as defined in the IMO FAL compendium (IMO Report 2011a,b, c), port logistics and a multitude of commercially oriented messages are covered.

Service-oriented computing as enabler of port information systems 43

Increased regulatory and legal compliance needs along with supply chain integrationand the diffusion of global commerce standards, such as World Customs Organization(WCO) standardization efforts (WCO Report 2007) and Global Standards One (GS1Report 2010) works, are forcing maritime stakeholders to reconsider their standard-ization harmonization efforts to ensure interoperability for service integration anddata quality.

3 A PORTIS taxonomy

Today, a PORTIS is typically composed of a number of public and privately operatedinformation systems with different operational scopes ranging from the managementof ship movements, port resource management to cargo import and export processes,and varying degrees of functional and technical integration of its components andconstituent applications.

Different viewpoints and terminologies of these integrated systems have beenformulated in the academic and professional communities as well as in policy andstandards development forums. We propose a unifying taxonomy for PORTIS com-ponents and present a reference model for PORTIS development. The taxonomyemploys a number of criteria/dimensions, the more significant of which are detailedin the following subsections.

3.1 Authority of operation: A2B or B2B

A distinguishing factor of PORTIS components is whether they are intended tosupport the commercial operations in ports (business to business—B2B) or theauthorities’ enforcement of regulations, taxes and tariffs (authority to business—A2B).

Public authority systems are designed according to statutory regulations that inturn are aligned with international conventions, e.g. from the United Nations, WorldTrade Organization (WTO) or WCO. Recommendations and guidelines towardsimplementation have been devised (UN/CEFACT Report 2005a, b, c; WCO Report2012; IMO/FAL/36/1 Report 2010; IMO/FAL/36/2 Report 2010).

International regulations define important constraints for PORTIS A2B systemsthat differ substantially from those of B2B systems:

& A2B systems are based on legislation or statutory regulations that inherently areconservative in nature. Thus, A2B systems can be more difficult to change orupdate and may lag in functionality.

& Legislation may also limit the system’s information availability, accessibility anduse. This may restrict the functionality of the A2B system.

& Legislation is normally used to force behaviour that is not ‘natural’ from acommercial or efficiency perspective. Thus, A2B systems are often perceived asobstacles to commercial users rather than as of value and assistance.

These features are envisaged to improve in the near future, in conjunction withchanges in regulations, policies and in system implementation architectures andtechnology.

44 M.A. Lambrou et al.

A PORTIS component that performs public authorities’ e-services may be operatedby a private party and vice versa. This may be due to the outsourcing of services or toagreements between private port operators and the authorities. In the taxonomy, theauthority of operation only reflects the type of service performed or facilitated by thePORTIS. If the performance of the service is directly mandated by legislation, aPORTIS component is categorized as an A2B system; otherwise, it is understood as aB2B system.

In some cases, a PORTIS system supports authority-to-authority (A2A) operations.These are of limited interest to the private users of port services and are included forcompleteness.

3.2 Operational domain: trade or nautical

The taxonomy considers the difference between nautical- and trade-related systems asthe second main classification dimension.

Management of complex cargo shipments requires considerable information ex-change, which is difficult to handle without electronic data interchanges. For thisreason, there has been a long-term and strong drive in the trade sector to useelectronic documents. For nautical operations, the amount of information is generallymuch lower. Full clearance of the ship according to the FAL convention can typicallybe achieved with 6 one-page forms, whilst a full cargo manifest for a large containership is measured in megabytes.

Different sets of international instruments that respectively regulate ship move-ments and trade exist. Except from UNCLOS (UN Convention 1982), most nauticalregulations stem from the IMO or from special regional legislations such as from theEU or US legislative regimes. These regulations are mostly related either to the freemovement of ships, such as UNCLOS and the IMO FAL Convention (IMO Convention1965)—also the environmental effects, such as MARPOL (IMO Convention 1973)—or to the general safety and security of shipping, such as SOLAS (IMO Convention1980) and other related conventions. International trade regulation is mainly handledthrough the United Nations Commission on International Trade Law, the WTO andthe WCO. A large number of conventions and standards are in force, but much of theactual policy and details in procedures are still decided on a national level. Thus, onecan argue that shipping is much more a standardised business domain than trade. Thisdifference has a significant impact on both PORTIS A2B and B2B systems’ func-tionality and technology.

The differentiation between nautical and trade PORTIS systems is also explainedas stemming from their scope difference. With reference to the high-level buy–ship–pay model for international trade proposed by UN/ECE (Fig. 1), the ship and portoperations systems only correspond to a small part of the ‘ship’ processes. Trade

Buy Ship Pay

Intermediary

AUTHORITY

CustomerSupplier

Fig. 1 UN/ECE buy–ship–pay model

Service-oriented computing as enabler of port information systems 45

support functions are much more extensive as they cover a larger part of the completeset of buy–ship–pay processes.

Trade regulation and procedures are also generally independent of the transportmode; thus, trade-related information systems were not expected to be specificallytargeted to maritime transport, up to now, as the nautical domain systems needed tobe. Thus, trade and nautical PORTIS systems have been developed, up to now, asbased on substantially different policies, professional and technical regimes, normsand approaches that need to be reconsidered and harmonized.

3.3 Geographic scope

In addition to the two functionality-orientated criteria, it is also useful to consider thegeographic scope of a PORTIS component as a classification criterion. The geograph-ic scope may be as follows:

& Terminal: a PORTIS component is used only in a part of the port.& Port: a PORTIS component is used only in one port.& Regional: a PORTIS component is common to a group of ports.& National: a PORTIS component is used nationally for all or most ports in the

nation.& International: a PORTIS component is used in a group of nations.

In the subsequent section, the first two main classification criteria are employed inorder to describe a set of ‘stereotype’ PORTIS components which, together with thetaxonomy, constitute the PORTIS reference model.

4 A PORTIS reference model

As discussed in the previous section, a PORTIS is composed of a number ofcomponents, whereas a variety of terminologies are used to address them. To enable amore structured discussion on the PORTIS component functionality and modulariza-tion evolution, in this section, we propose a unifying terminology based on a limitednumber of ‘stereotype’ PORTIS components and link this to the taxonomy summar-ised in Table 1. The taxonomy, together with the stereotype systems, is proposed as aPORTIS reference model and is illustrated in Fig. 2. The term ‘stereotype’ is adoptedas used in the Unified Modelling Language (UML) in order to refer to a newcomponent model for a specific domain, here the PORTIS. The UML typographicalstandard of enclosing the stereotype name in guillemets («») has been adopted.

Table 1 PORTIS taxonomyCriterion Values

Authority ofoperation

A2B, B2B

Operational domain Nautical, trade

Geographic scope Terminal, port, regional, national,international

46 M.A. Lambrou et al.

We use the following graphical nomenclature: rounded rectangles for the stereo-type PORTIS components and circles to show associated port parties and their useupon the components. The model is restricted to operational scope covering themovement of cargo in and between ports and does not include other specializedsystems for managing, e.g. intermodal logistics, supply chains or cargo communities.Neither does it include ship operation systems such as electronic charts or weatherforecast distribution or fleet management systems.

In the framework of taxonomy, the reference model contains five stereotype PORTIScomponents. Future PORTIS applications can be modelled as being of a specific typeor a combination of several types. As an example, the Next Generation SingleWindow (NGSW) application, which is examined in Section 5.2, is envisaged tointegrate both trade and maritime administrative functions in one single window,possibly on a Central European level (Directive 2010/65/EU 2010) or on a nationallevel. The realization of this could be approximated and modelled as a combination ofthe «MSW» and «TSW» model types.

In the following, we define and describe the five basic PORTIS stereotypes, primar-ily in terms of their functional/service orientation. We also discuss two other PORTISconcepts that are commonly used in the literature, namely the general Single Window(SW) and the Maritime Information Management Systems (MIMS), which areindicated with a dashed line in Fig. 2 and are treated as grouping two or more ofthe model components.

4.1 The Single Window

An important PORTIS concept is the SW. It is defined as “a facility that allows partiesinvolved in trade and transport to lodge standardized information and documents witha single entry point to fulfil all import, export, and transit-related regulatory require-ments. If information is electronic, then individual data elements should only besubmitted once” (UN/CEFACT Report 2005a, b, UN/CEFACT Report 2005c). Thus,a SW is a targeted business-to-administration (B2A) system for trade and transport. In

Shipping Agent

Coast and Port State Authorities

Trade Single Window «TSW»

ForwarderStevedoorConsignee/Consignor

Ship

Import/Export

Authorities

Port Community System «PCS»

A2B

B2B

TradeNautical

Maritime Single Window «MSW»

MIMSSW

A2B

B2B

TradeNautical

Vessel Traffic Information System

«VTIS»

Port Management Information System

«PMIS»

Fig. 2 PORTIS reference model

Service-oriented computing as enabler of port information systems 47

the reference model, the single window is split into two model components: themaritime and trade single window.

4.2 Maritime Single Window «MSW»

In the reference model, the «MSW» is defined as a reporting gateway for the ship orthe ship’s agent based on the reporting requirements from the FAL Convention (IMOConvention 1965) and similar national or international legislation. In Europe, theFAL requirements have been incorporated in Directive (2010/65/EU) that also requiremember states to implement an electronic «MSW» by May 2015.

The «MSW» is a single window for the clearance of ships to enter or leave a state’sport or ports, including general safety- and security-related properties of the cargothey carry (whether intended for import, export or transit). This does not includeclearance of cargo for import or export, which again may be related to the levy ofcustoms duties and other taxes. The latter functions are handled in the «TSW». The«MSW» is concerned with maritime safety and security.

Compared to the «VTIS», the «MSW» will be based on data collection from stand-ardised written or electronic reports (FAL forms) and will distribute the collectedinformation to many more shore authorities than the «VTIS» (see VTIS and MIMSbelow). The information, up to now, is not typically collected in real time or automat-ically, and the purpose is mostly pre-arrival or pre-departure clearance. However, the«MSW» will be one important data source for the national interface to SafeSeaNet.

4.3 Trade Single Window «TSW»

This is the ‘traditional’ single window for clearance of cargo and is the main focus ofthe UN/CEFACT SW Guidelines (UN/CEFACT Report 2010). It is an authority-operated single window that caters for document flows related to import, export ortransit clearance of cargo. This SW will usually be operated in order to handle alltransport modes and not only ships. It is most often initiated and operated by thecustoms authorities as they normally have the most demanding information require-ments in conjunction with import and export clearance as well as for payment oftariffs. These are also the main reasons why it is not integrated with the «MSW», inthe current situation.

This is probably the most common type of SW. In the UN/CEFACT report on SWcase studies (UN/CEFACT Report 2005a, b, c), ten national single-window systemswere discussed, of which one was a «MSW», one is a «PSC» and eight were «TSW».Typical functions supported by the «TSW» are customs clearance, including tariffpayments, export or import documentation and certificates related to agriculture orveterinary clearance.

4.4 Maritime Information Management Systems «MIMS»

The term ‘Maritime Information Management Systems’ was given an official mean-ing in Europe by Directive 2009/17/EC (2009). According to article 22a-1, “MemberStates shall establish maritime information management systems, at national or locallevel, to process the information referred to in this Directive”. The information

48 M.A. Lambrou et al.

referred to is that required by the European SafeSeaNet system which is mainly a shipmonitoring, safety and security system, including some of the pre-arrival require-ments from the IMO FAL convention as well as various other real-time monitoringand reporting information directly from the ships. Most of this information is todaycollected by the «VTIS» as well as from the «MSW» (see below). This means that theMIMS is partly acting as a single window and partly as a real-time data acquisitionsystem. The MIMS is currently not included as a stereotype component in thereference model as it can be treated as an integration of the «MSW» and the «VTIS».

4.5 Vessel Traffic Information System «VTIS»

The «VTIS» is defined as an integration mechanism for data acquired directly fromthe ship either through automatic transponder systems such as Automatic Identifica-tion System (AIS) and Long Range Identification and Tracking, satellite-basedautomatic reporting system, from surveillance systems including radar, CCTV orsatellite or information reported in real time from ship to the authorities—typicallyover VHF voice channels. This will also include data collected in any coastal or portVessel Traffic Services (VTS) and reported directly from the ship to the authorities.These types of ship reporting and VTS functions are mainly regulated throughSOLAS Chapter V, Regulations 11 and 12 (IMO Convention 1980). This type ofPORTIS component will typically be implemented on a national level to aid in themonitoring and management of ship traffic along the coast.

Some form of «VTIS» is implemented by most developed coastal states and isused in maritime safety and security functions as well as in search and rescueoperations. In Europe, the «VTIS» will be an important data feed to the EuropeanSafeSeaNet system (see MIMS above).

The «VTIS» may in some cases be used for business purposes in the port, in particularin conjunction with early arrival notification based on AIS. The system may also handleinformation related to particular ship services, e.g. pilotage, icebreakers or tugs.

4.6 Port Management Information Systems «PMIS»

The «PMIS» represents the integration of commercial nautical operator systems in theport. This typically handles the allocation of resources such as tugs, linesmen and berths aswell as other service functions such as fresh water, power supply or waste disposal. Oneshould note that some systems of the «PMIS» type may be implemented by authorities,in particular in ports or countries where authorities have operational responsibilitiesfor ports and/or resources used to assist the ship during port approach and berthing.

The «PMIS» stereotype is defined as a PORTIS component that caters for shipservices in port beyond those covered by international agreements or legislation. Thelatter are covered by systems of the «MSW» and «VTIS» type.

4.7 Port Community Systems «PCS»

The term ‘Port Community System’ is today in common use and as old as the earlyelectronic data interchange systems in ports, introduced in the 1980s, where systemssuch as DAKOSY (Port of Hamburg) and FCP80 (Port of Felixstowe) were started.

Service-oriented computing as enabler of port information systems 49

According to the definition of the European Port Community System’s Association(EPCSA), “A Port Community System (PCS) is a neutral and open electronic platformenabling intelligent and secure exchange of information between public and privatestakeholders in order to improve the competitive position of the sea and port commu-nities; optimises, manages and automates port and logistics efficient processes through asingle submission of data and connecting transport and logistics chains”.1

However, this definition blurs the distinction betweenB2A andB2Boperational profiles,as apparent in the current state of play. In large ports, the above definition will, in manycases, make sense as it recognizes that the port information systems are advanced enough tonaturally take on some of the reporting formalities on behalf of the authorities. However,even in this case, the «PCS» will typically interface to the «MSW» and the «TSW» ratherthan taking on these systems’ functions. In smaller ports, the picture may be very different,as is exemplified, e.g. by PortNet in Finland (Hautala et al. 2003). Here, the situation isthe opposite: the authorities operate a portal of the «MSW» type with functions alsoimplementing much of a «PCS» as well integration to the national «TSW».

The «PCS» stereotype is defined as a PORTIS component that provides integrationamong any collection of PORTIS systems that support cargo and trade operations inthe port. This may include logistics, payments, maritime or trade operations software.It does not include functions associated with the «MSW» or «TSW» other than theability to automatically transfer information to and from these systems.

A number of currently operated PORTIS components are analysed in Table 2.The first example is FCPS in Felixstowe which is a typical «PCS» with very

limited nautical functionality. The original function was to act as a gateway to thecustoms-operated «TSW», but this has since been extended to an integrating functionfor more than 650 customers (Long 2009).

Other commercially available PCS include more maritime-oriented systems suchas TSB PLUS (Ports Logistics Unifying System).2 This system includes nauticaloperations in the «PCS» framework, making use of AIS data.

Phaeros3 offers the Cargo Terminal Management System (CTMS) that is a typicalexample of a Terminal Operation System (TOS). ATOS will typically offer a similarfunction to the PCS, but is usually limited in geographic scope (one or more terminalsof the port) and further specialized in functionality for cargo and terminal equipmentmanagement (Keceli 2011; Mostafa et al. 2010). Phaeros’ Harbour View Plus (HVP)is an example of a «PMIS» system that is used to manage nautical operations in ports.

A selection of the single-window systems, as described in theUN/CEFACTcase studyreport (UN/CEFACT Report 2005a, b, c), is also included in the table. Most of theseare generalised as ‘TSW’, with the exception of the Finish system (PortNet) which ismainly a «MSW» system and the German system (DACOSY) which is mostly a«PCS» system. Finally, the European SafeSeaNet (SSN) system has been listed toillustrate how it could be covered by the reference model (one should note that SSN isactually an A2A system and is not directly considered by the reference model).4

1 http://www.epcsa.eu/port-community-systems/pcs-definition.2 http://www.tsb.co.kr.3 http://www.phaeros.com.4 http://www.emsa.europa.eu/.

50 M.A. Lambrou et al.

The above example use of the PORTIS model is intended to demonstrate the actualoperationalization of the reference model towards supporting normative descriptionsand formal specifications of future PORTIS, as is further explained in the next-generation single window case study (Section 5.2).

We postulate that future e-business models and therefore emergent PORTIS applica-tions will evolve upon the functional basis illustrated in the PORTIS reference model,as above analysed (Fig. 2). The proposed PORTIS reference model can be viewed as atechnology-neutral, logical and service reference model. Next-generation PORTISwill evolve and be harmonized with paperless trade and transport business modelsand supporting platforms, as well as ‘Internet of Cargo’ and pervasive computing-based systems that are expected to be engineered upon the above-described prototypecomponents. The PORTIS reference model can support stakeholders, decision mak-ers, application designers and technological platform vendors to structure and for-mally define their expectations, requirements and service evolution interests upon afuture PORTIS system, in a specific setting (Lambrou and Foster 2010).

5 PORTIS development framework

The driving factors of PORTIS evolution, discussed in Section 2, imply that futurePORTIS evolve towards a higher degree of coordination and interoperability betweenmaritime and multimodal transport and trade parties, supporting more integrated,agile business processes.

To address the emergent PORTIS service development complexity, there is a press-ing need to employ a systematic yet flexible approach to building PORTIS systemcomponents by thoroughly addressing policies, strategy and business relationshipsand associated e-services requirements along with system and technical requirements.

Service-Orientation, as related to software services development, requires that the soft-ware engineers in the domain of discourse formally and in a tractable manner addresspertinent policies, strategy and business relationships to be embedded in the designed system.

Service-oriented computing (SOC) demands an interdisciplinary approach towards theanalysis, design and reengineering of core business processes and the life cycle ofdeveloping software as services (Papazoglou and Heuvel 2006; Zimmermann et al.

Table 2 Example use of the reference model

PORTIS system Stereotype Authority of operation Operational domain Geographical scope

FCPS PCS B2B Trade Port

PLUS PCS and PMIS B2B Trade and nautical Port

CTMS PCS B2B Trade Terminal

HVP PMIS B2B Nautical Port

PortNet MSW A2B Nautical National

DACOSY PCS B2B Trade Port

TSW TSW A2B Trade National

SSN VTIS A2A Nautical International

Service-oriented computing as enabler of port information systems 51

2004). To this end, today, a multitude of concepts, models and techniques are tightlyintegrated and are further supported by robust service engineering tools adhering toopen standards.

The distinguishing characteristic of e-service engineering and SOC is their holisticapproach. Policies, business relationships between different parties, and associatedfunctional and quality elements of e-services are integral to service orientation; tosystematically associate these aspects for consideration, the W3C proposed theservice-oriented model (SOM), illustrated in Fig. 3. Software services and the archi-tecture and computing infrastructure to provide these software components areviewed as reusable and flexible assets.

SOC and service-oriented architectures (SOA) is a new paradigm for softwaresystems development that focuses on e-services as encapsulated software function-alities with standardized interfaces to be composed and orchestrated/choreographedin order to provide applications, namely PORTIS applications, offering services suchas ship formalities reporting e-services (Lambrou and Foster 2010). SOC can providee-services being developed as autonomous, platform-independent computationalentities. These entities need to be described, published, categorized, discovered anddynamically assembled to offer large-scale, integrated digital environments.

The benefits of a SOC approach to PORTIS applications, e-services and softwarearchitecture development can be viewed as follows.

Fig. 3 W3C service-oriented model. www.w3c.org

52 M.A. Lambrou et al.

5.1 PORTIS organisational support

Service orientation allows different, complex policies and business relationships to beapplied to different service provider and service requester real-life situations. A futurePORTIS application should embed aspects and peculiarities and cover requirementsfrom a multitude of stakeholders, eventually offering service capabilities to exchangeinformation, for instance between a private to a public domain party. The publicentities of a PORTIS application in the near future will expect advanced legislations,traffic control, reporting and safety and security support, whilst private entities aremerely expected to focus on the commercial aspects and associated innovationmanagement. The essence and mere applicability of the aforementioned serviceorientation features result in the actual technical feasibility of PORTIS e-servicesbeing offered to different service users, whilst their policies are distinctly encoded,reflecting on local, national and international, also pertinent professional or politicaland cultural, requirements. PORTIS need to cater for a large number of very differentparties. For instance, the requirement specifications for a new Indian PCS list 19specific user groups with widely differing operational profiles and business models(Crimson Logic Report 2007). Different companies within the same group of usershave different internal procedures and systems. Furthermore, a PORTIS need to caterfor a large number of different applications (components). Thus, service orientationoffers the alignment of complex strategic and organizational capabilities within aPORTIS architecture, supporting envisaged business relationships for the configura-tion of maritime business networks (strategic layer). The inter-organizational coordi-nation (process layer) by means of agile and interoperable processes of a PORTIS isalso supported. Enhanced technical architecture capabilities that support inter-organizational integration are enabled by the information technology layer.

5.2 PORTIS operational and technical support

A critical challenge in future PORTIS development is software evolution for meetingthe changing requirements of its stakeholders over time (Nehaniv and Wernick 2007)and achieving sustainable business and service evolution. In this context, buildingupon the thesis of Rowe et al. (1998), PORTIS software evolution emerges as afeature that “bears on the ability of a system to accommodate changes in its require-ments throughout the system’s lifespan with the least possible cost whilst maintainingarchitectural integrity”. Thus, robust PORTIS development techniques are of centralimportance (Breivold et al. 2011).

5.2.1 Service-oriented computing and model-driven development as enablersof PORTIS development

SOC and SOA capabilities are managed through the service engineering life cycle.More specifically, model-driven development (MDD) (Mueller et al. 2010; Lycett etal. 2007; Lin et al. 2007; Ledeczi et al. 2001) entails the consideration of a multitudeof concepts within SOA and SOC. This includes models and methods across a servicedevelopment life cycle and the tools to construct software systems in a systematic andefficient manner (Papazoglou and Heuvel 2006; Zimmermann et al. 2004).

Service-oriented computing as enabler of port information systems 53

SOC and MDD approaches are typically undertaken with some form of businessprocess management (Arsanjani et al. 2007; Bell 2008; Qing et al. 2010; Gasevic andHatala 2010) to ensure that applications (i.e. PORTIS applications) do not only meetfunctional capabilities but also support non-functional requirements such as quality ofservice criteria. Applications must also be performed as specified in certain policy,strategic and business process-level key performance indicators. Business rules andsemantics can provide an efficient way of expressing business requirements of aPORTIS application, architected as a SOA. SOC and MDD approaches and tasksensure the efficient integration of pertinent policies and business rules into the overallservice engineering life cycle and programming model (Zhao 2007).

The service-oriented analysis and design methodology of IBM developed byZimmermann et al. (2004) and the service-oriented design and development meth-odology proposed by Papazoglou and Heuvel (2006) are both representative ofcontemporary service engineering frameworks. Foster et al. (2010) also developeda formal, integrated service engineering framework as part of the EU SENSORIAproject approach, illustrated in Fig. 4, which we have specifically adopted.

The SENSORIA framework provides mechanisms to develop future PORTIS andtherefore reengineer legacy PORTIS components by modelling associated policiesand resulting e-services in a MDD notation, such as UML, BPMN and IDEF, andcombine intended uses of their services for appropriate deployment models andmechanisms.

5.2.2 The NGSW case study

As explained in Section 4, the Single Window business model, today, appears in anumber of forms, whereas it primarily addresses the need for collaborative, efficientelectronic transactions between governmental and business trade and transport enti-ties and as mainly directed by international and EU policy initiatives. Ship formalitiesreporting, cargo declarations, and safety and security e-notifications are all e-servicesthat should be rationalized and offered in a harmonized manner by a transport and

Fig. 4 SENSORIA service engineering approach. www.sensoria-ist.eu

54 M.A. Lambrou et al.

trade NGSW PORTIS application. A robust, combined approach is necessary in orderto design a Next Generation Single Window application as a service-oriented systemin the maritime transport context where policies emphasizing safety and security,environmental responsibility, cost efficiency and transparency, along with redefinedcollaboration strategies and business relationship patterns among multimodal trans-port and trade users, emerge (Rodseth et al. 2011).

Against this background, applying SOC principles and MDD techniques toNGSW application design, as pilot tested in the EU e-Freight project,5 enabled us to

(a) Effectively collect and communicate expectations and requirements of maritimetransport business users as well public authorities users, industry associationsand policy makers.

(b) Leverage associated human-understandable business vocabularies, machine-understandable business rules, process models and an ontology into a unifieddesign realm with ancillary software development artefacts for service-orientedsystems.

(c) Support automatic generation of high-quality NGSW service compositions frombusiness process models capturing rich and interoperable maritime e-services.

We tested and propose a model-based framework with semantics as the integrationtechnology. A NGSW ontology model has been developed as the common MDDbasis of service scenarios and NGSW e-services and as the shared data model forfuture PORTIS applications. The devised MDD framework (Fig. 5) provides a unifieddevelopment environment whilst further contributing towards the homogenization ofthe disparity of underlying approaches, modelling notations and tools (Valente andMitra 2007; Katsoulakos et al. 2011a, b).

More in particular, articulating NGSWrequirements, as enabled by the expressivenessof IDEF, UML, BPMN and a BPEL-based SOA development approach (Papazoglou andHeuvel 2006; Bell 2008; Foster et al. 2010), consisted an efficient engineeringapproach. Once created, NGSW process models are either offered as blueprints forthe construction of customizable NGSW systems or are automatically further trans-lated into implementation artefacts, namely executable service compositions in BPELformat, to be deployed and be fully operational in a particular PORTIS instance (i.e.NGSW of Latvia). The described development environment is depicted in Fig. 5.

The development approach covers software engineering steps comprising thephases of requirement engineering, application design, implementation, testing andmaintenance (Bell 2008). In particular, the following phases were appropriated in theNGSW case of PORTIS:

Requirement analysis A top-down approach to the NGSW application domain anduser requirements elicitation is undertaken. This is based on implementing the NGSWas a combination of the «MSW» and «TSW» stereotypes. The particular NGSWPORTIS application and the associated business processes were decomposed intotheir subprocesses using scenarios and high-level business use cases that enableidentifying the required functionalities as services (IDEF, UML and BPMN models).In the pilot case of the e-Freight NGSW application, we formally decomposed port

5 http://www.efreightproject.eu/.

Service-oriented computing as enabler of port information systems 55

call processes into FAL forms formalities and SSN-related e-notifications. Also,customs processes were analysed. Complementary, a bottom-up analysis of theexisting infrastructure and legacy systems (SafeSeaNet) took place that served as abasis for providing reengineered service functionality.

Service design Service design refers to formal service definition, specification andimplementation towards deciding software components that implement the applica-tion business logic required for identified services. During a formal service specifi-cation phase, in terms of the employment of dedicated formal languages and tools(Qing et al. 2010; Gasevic and Hatala 2010), the internal structure, the messaging andinteractions, events specification, and further service and component interdependen-cies are given. SOA services are defined as exposed on a service registry. Servicebinding that deals with the assignment of service requests to offers using the requestand offer specification is decided.

Designers, given a set of NGSW interaction requirements, specified a series ofUML sequence diagrams and message sequence charts (MSCs) to describe howthe services will be used (i.e. NGSW IMO FAL form submission and policeservices) and to model how each service interacts (i.e. invokes, receives orreplies) in a given service scenario. The resulting set of scenarios is composedand synthesized to generate a behavioural model. The service implementation isundertaken by a WS-BPEL engineer who builds the WS-BPEL process directlyfrom either specification or requirements. The WS-BPEL implementation and itssemantics were used to generate a second behavioural model by a process ofabstracting the WS-BPEL with respect to data and to yield a model of interactionbased upon specified semantics applied to WS-BPEL through a specified algebra(Fig. 6).

Fig. 5 Service-oriented development framework for PORTIS

56 M.A. Lambrou et al.

Verification and validation (Canfora and Di Penta 2006) consists of comparing andobserving traces of these two transition systems. The approach can assist in deter-mining whether the implementation contains all the specified scenarios of the designacceptable to NGSW PORTIS users, namely master, port agent and port authorityusers. The approach allows hiding the underlying notational representations andletting the user view only the WS-BPEL specifications or the MSCs as a simpleintuitive and visual formalism accessible to most developers.

Service implementation We have employed a combination of MDD techniques andSOA technology (Ledeczi et al. 2001) for managing a complete NGSW PORTISapplication development and operation environment.

The presented approach can be implemented, and it has been originally testedwithin the EU e-Freight project in a number of tool-based environments such as theEclipse-based, LTSA WS-Engineer environment,6 providing tools for specification,formal modeling, verification and validation (Fig. 7), or AppQuiver,7 an integratedenvironment for developing software systems consisting of modeling tools, codegeneration tools and application runtime tools.

We also adopted a particular SOA-compliant technological platform (Fjortoft et al.2011; Foster and Lambrou 2010; Meng et al. 2006; Nitto et al. 2007; Paschke andBichler 2008; Foster and Spanoudakis 2011; Katsoulakos et al. 2011a, b) depicted inFig. 8.

Testing and validation The constructed system architecture is evaluated in terms offunctionality as well non-functional or qualitative characteristics, namely robustness,reliability, security and usability. Additional criteria and respective enabling techni-ques are important, such as testing reusability of services, simulating and testing theservice performance of different providers. In NGSW PORTIS, important are thereliability and real-time adaptation requirements to be ensured by dedicated SOCtesting and validation protocols (Canfora and Di Penta 2006). Various simulationmodels can be integrated into such a unifying development framework in order to test

6 http://www.fosterevolution.net/index.php/toolssection.html.7 http://www.clmsuk.com/.

Fig. 6 NGSW service engineering approach

Service-oriented computing as enabler of port information systems 57

and validate different port operational and control strategies of complex, integratedmaritime optimization problems.

Fig. 7 Tool support of PORTIS service development

Fig. 8 NGSW SOA architecture and technology platform

58 M.A. Lambrou et al.

6 Conclusions

A critical challenge to emergent PORTIS development is software evolution towardssatisfying the changing requirements of its stakeholders over time and achievingnext-generation performance levels. We examined a service-oriented computing andmodel-driven development framework as a robust engineering approach to theelaboration and formal analysis of functional and quality requirements as well theimplementation and testing of emerging PORTIS software solutions. The alignmentof strategic and organizational capabilities of a future PORTIS application, supportingenvisaged policies and business relationships of a multitude of maritime as well asintegrated supply chain stakeholders, is envisaged. To this end, inter-organizationalcoordination by means of adaptive and interoperable business processes, as encap-sulated in reusable and modular software services and software architectures’ capa-bilities, is addressed. Future PORTIS development is enabled by the presentedmethodological approach. In particular, we contribute with a proposed PORTIS logicalreference model and a service-oriented and model-driven development methodolog-ical framework and technical platform solution, both being necessary and sufficientenablers towards the sustainable evolution of PORTIS. The PORTIS reference modelcan support stakeholders, decision makers, application designers and technologicalplatform vendors to structure and formally define their expectations, requirementsand service evolution interests upon a future PORTIS system, in a specific setting.The proposed unified development environment for PORTIS solutions enables theharmonization of the disparity of approaches, models and technologies.

Acknowledgments This work has been partially funded by the EU e-Freight 7FP DGTREN Project(www.efreightproject.eu) and the Norwegian Research Council MIS project (Maritime Information Centre,http://www.sintef.no/Projectweb/MIS/).

References

Arsanjani A, Zhang LJ, Ellis M, Allam A, Channabasavaiah K (2007) Design a SOA solution using a referencearchitecture. IBM developer Works, IBM Corporation. http://www.ibm.com/developerworks/library/ar-archtemp/. Accessed 20 January 2012

Bell M (2008) Service-oriented modeling: service analysis, design, and architecture. Wiley, New YorkBreivold HP, Crnkovic I, Larsson M (2011) A systematic review of software architecture evolution

research. Inf Softw Technol 53(4):363–387Canfora G, Di Penta M (2006) Testing services and service-centric systems: challenges and opportunities.

IT Professional 8:10–17Crainic TG, Gendreaub M, Potvinb JY (2009) Intelligent freight-transportation systems: assessment and the

contribution of operations research. Transportation Research Part C 17:541–557Crimson Logic Report (2007) System requirements specification for Port Community System (PCS).

Release No. 3.0. http://ipa.nic.in/pcs/documents/IPA%20PCS%20Software%20Requirements%20Specification%20V3.pdf. Accessed 22 March 2012

Directive 2009/17/EC (2009) On establishing a community vessel traffic monitoring and informa-tion system. http://www.imo.org/KnowledgeCentre/InformationResourcesOnCurrentTopics/InformationResourcesOnCurrentTopicsArchives/Documents/EU%20LEGISLATION%20_28%20January%202010.pdf. Accessed 22 March 2012

Directive 2010/65/EU (2010) On reporting formalities for ships arriving in and/or departing from ports ofthe Member States. Official Journal of the European Union. http://eurlex.europa.eu/LexUriServ/LexUriServ.do?uri0OJ:L:2010:283:0001:0010:EN:PDF. Accessed 22 March 2012

Service-oriented computing as enabler of port information systems 59

Fjortoft KE, Lambrou MA, Hagaseth M, Baltzersen P (2011) Maritime transport single windows: issuesand prospects. Proceedings of the 9th International Symposium on Marine Navigation and Safety ofSea Transportation—TransNav 2011, Gdynia, Poland, 15–17 June

Flagship Deliverable (2011) Demonstration of KPIs used in performance based contracts. EUProject TIP5-CT-2006-031406. Internal Deliverable. http://www.flagship.be. Accessed 26 March2012

Foster H, Spanoudakis G (2011) SMaRT: a workbench for reporting the monitorability of servicesfrom SLAs. Proceeding of the 3rd International Workshop on the Principles of EngineeringService-Oriented Systems (PESOS), the IEEE International Conference on Software Engineer-ing, Honolulu, HI, USA

Foster H, Uchitel S, Magee J, Kramer J (2010) An integrated workbench for model-based engineering ofservice compositions. IEEE Transactions on Services Computing, IEEE computer Society DigitalLibrary. IEEE Computer Society. Accessed 20 January 2012

Foster H, Lambrou MA (2010) SLA based federated e-maritime services. Proceedings of the 5th Mediter-ranean Conference on Information Systems (MCIS2010), Tel-Aviv, Israel, 12–14 September

Gasevic D, Hatala M (2010) Model-driven engineering of service-oriented systems: a research agenda. Int JServ Sci Manag Eng Tech 1(1):17–32

GS1 Report (2010) GS1 General Specifications, version 10: Global Standards One. http://www.autoid.org/GenSpec_v10_i1.pdf. Accessed 27 March 2012

Hautala R et al. (2003) PortNet impact evaluation. FITS Publications, Ministry of Transport and Commu-nications Finland. http://partnet.vtt.fi/evaserve/evaserve_tool/aineisto/portnet_english.pdf. Accessed26 March 2012

IMO Convention (1965) The Convention on Facilitation of International Maritime Traffic (FAL Conven-tion), 1965 as amended

IMO Convention (1973) International Convention for the Prevention of Pollution From Ships, 1973 asamended. IMO, London, UK

IMO Convention (1980) International Convention for the Safety of Life at Sea (SOLAS Convention), 1980as amended

IMO/FAL/36/1 Report (2010) Electronic means for the clearance of ships: the use of the Single Windowconcept. Internal Report. www.imo.org. Accessed 26 March 2012

IMO/FAL/36/2 Report (2010) Electronic means for the clearance of ships: justification for Single Windowguideline for maritime transport. Internal Report. www.imo.org. Accessed 26 March 2012

IMO Report (2009) Maritime environmental protection committee, prevention of air pollution from ships.Second IMO GHG study, MEPC 59/INF.10. www.imo.org. Accessed 26 March 2012

IMO Report (2011a) Guidelines for setting up a Single Window. http://www.imo.org/blast/blastDataHelper.asp?data_id030924&filename036.pdf. Accessed 26 March 2012

IMO Report (2011b) International maritime organization—international shipping and world trade,facts and figures. http://www.imo.org/KnowledgeCentre/ShipsAndShippingFactsAndFigures/Statisticalresources/Documents/December%202011%20update%20to%20July%202011%20version%20of%20International%20Shipping%20Facts%20and%20Figures.pdf. Accessed 26 March2012

IMO Report (2011c) IMO compendium of facilitation and electronic business. IMO-360E, ISBN92-801-5112-6. http://www.imo.org/blast/blastDataHelper.asp?data_id030862&filename035.pdf. Accessed 24March 2012

Katsoulakos T et al. (2011a) D2.1 e-Freight platform specification. Internal deliverable of eFreight Project.www.efreightproject.eu. Accessed 26 March 2012

Katsoulakos T et al. (2011b) D2.2 e-Freight workflow, simulation, analysis toolset. Internal deliverable ofeFreight Project. http://www.efreightproject.eu/default.aspx?articleID018896&heading0Deliverables.Accessed 23 March 2012

Kia M, Shayan E, Ghotb F (2000) The importance of information technology in port terminal operations.Int J Phys Distrib Logist Manag 3:331–344

Keceli Y (2011) A proposed innovation strategy for Turkish port administration policy via informationtechnology. Maritime Policy & Management 38(2):151–167

Lambrou MA, Foster H (2010) Next generation e-maritime systems engineering. Proceedings of 12thWorld Conference on Transport Research Society WCTR 2010, Lisbon, Portugal, 11–15 July

Ledeczi A, Bakay A, Maroti M, Volgyesi P, Nordstrom G, Sprinkle J, Karsai G (2001) Composing domain-specific design environments. IEEE Comput 34(11):44–51

Lin Y, Gray J, Jouault F (2007) DSMDiff: a differentiation tool for domain-specific models. Eur J Inf Syst16:349–361

60 M.A. Lambrou et al.

Linnington G (2005) International trade Single Window and potential benefits to UK business. SITPRO Ed.www.sitpro.org.uk. Accessed 26 March 2012

Long A (2009) Port community systems. World Customs Journal 3:1Lycett M, Marcos E, Storey V (2007) Model-driven systems development: an introduction. Eur J Inf Syst

16:346–348Marianos N, Lambrou M, Nikitakos N, Vaggelas G (2011) Managing port e-services in a socio-technical

context. International Journal of Shipping and Transport Logistics 3(1):27–56Meng WJ, Rilling J, Zhang Y, Witte R, Charland P (2006) An ontological software comprehension process

model. Proceedings of the Third International Workshop on Metamodels, Schemas, Grammars, andOntologies for Reverse Engineering (ATEM 2006), Genoa, Italy

Mostafa J, Taghi TM, Saeed R, Morteza M (2010) E-commerce development experiences in world’s leadingcontainer ports and offering a model for Shahid Rajaee Port. Maritime Policy &Management 37(1):53–72

Mueller B, Viering G, Legner C, Riemp G (2010) Understanding the economic potential of service-orientedarchitectures. J Manag Inf Syst 26(4):145–180

Nehaniv CL, Wernick P (2007) Introduction to software evolvability. Proceedings of International Workshopon the Principles of Software Evolution (IWPSE07)

Nitto E, Penta Di M, Gambi A, Ripa G, Villani ML (2007) Negotiation of service level agreements: anarchitecture and a search-based approach. Proceedings of ICSOC 2007. LNCS, 4749 (edited byKraamer BJ, Lin K-J, Narasimhan P). Springer, Heidelberg, pp 295–306

Paixao AC, Marlow PB (2002) Strengths and weaknesses of short sea shipping. Marine Policy 26(3):167–178Papazoglou MP, Heuvel WJ (2006) Service-oriented design and development methodology. Int J Web Eng

Technol 2(4):412–442Paschke A, Bichler M (2008) Knowledge representations concepts for automated SLA management. Decis

Support Syst 46(1):187–205Qing L et al (2010) Business processes oriented heterogeneous systems integration platform for networked

enterprises. Comput Ind 61:127–144Rodseth OJ, Fjortoft KE, Lambrou MA (2011) Web technologies for maritime single windows. Proceed-

ings of the 3rd International Maritime-Port Technology and Development Conference—MTEC 201,Singapore, 13–15 April

Rowe D Leaney J Lowe D (1998) Defining systems evolvability: a taxonomy of change. Proceedings of theInternational Conference and Workshops on Engineering of Computer-Based Systems (ECBS98)

UN Convention (1982) United Nations Convention on the Law of the Sea (UNCLOS). Signed 10thDecember 1982, Effective 16th November 1994

UN/CEFACT Report (2005) Recommendation No.33. Recommendation and guidelines on establishing aSingle Window. http://www.unece.org/fileadmin/DAM/cefact/recommendations/rec33/rec33_trd352e.pdf. Accessed 22 March 2012

UN/CEFACT Report (2005) Case studies on implementing a Single Window to enhance the efficientexchange of information between trade and government. Working Draft 16. September 2005. http://www.unece.org/fileadmin/DAM/cefact/single_window/draft_160905.pdf. Retrieved July 2012

UN/CEFACT Report (2010) Recommendation no. 34. Data simplification and Standardization for inter-national trade. CEFACT/2010/IT008. http://www.unece.org/fileadmin/DAM/cefact/recommendations/PublicReview/Rec.34_Draft_Publication_20100310.pdf. Accessed 22 March 2012

UN/CEFACT Report (2005) A roadmap towards paperless trade. Outcome of the 3rd Executive Forum onTrade Facilitation, Paperless Trade in International Supply Chains: Enhancing Efficiency and Security.www.unece.org. Accessed 26 March 2012

Valente P, Mitra G (2007) The evolution of web-based optimisation: from ASP to e-services. Decis SupportSyst 43:1096–1116

WCO Report (2007) Data model and Single Window data harmonization guidelines. World CustomsOrganization. http://www.wcoomd.org/sw_guidelines.htm. Accessed 27 March 2012

WCO Report (2012) Single Window guidelines. http://www.wcoomd.org/sw_overview.htm. Accessed 15January 2012

Yang J (2009) Small and medium enterprises (SME) adjustments to information technology (IT) intrade facilitation: the South Korean experience. ARTNeT Working Paper Series no. 61. http://www.unescap.org/tid/artnet/pub/wp6109.pdf. Accessed 26 March 2012

Zhao H (2007) Semantic matching across heterogeneous data sources. Commun ACM 50(1):44–50Zimmermann O, Krogdahl P, Gee C (2004) Elements of service-oriented analysis and design—an inter-

disciplinary modeling approach for SOA projects. IBM DeveloperWorks. http://www-128.ibm.com/developerworks/library/ws-soad1/. Accessed 20 January 2012

Service-oriented computing as enabler of port information systems 61