A COLLABORATIVE RESOURCE-BASED CLOUD

ARCHITECTURE FOR FREIGHT LOGISTICS

Bill Karakostas

Centre for HCI Design, School of Informatics, City University, London, U.K.

Takis Katsoulakos

Inlecom Ltd., Rotherfield, U.K.

Keywords: REST services, Web oriented architecture, Collaborative cloud, Single window.

Abstract: Collaborative Cloud is the set of Cloud infrastructure, processes and standards, that allows companies to

expose data and information as virtual resources, and manage them in collaboration with their partners and

customers. The concept of Collaborative Cloud is realised with technologies such as global identifiers, data

oriented services and content based messaging. The paper illustrates the application of Collaborative Cloud

to a shipping logistics business to government (B2G) scenario called Single Window.

1 INTRODUCTION

In today’s IT, the Cloud is better known as a

paradigm for utilising distributed computing

resources to meet elastic demand (Armbrust et al,

2010).

A less well understood application of Cloud is as

a tool for collaboration between organisations

through the sharing of Cloud based resources. The

Cloud, thanks to its elastic capacity allows

companies to share resources while controlling what

and with whom it will be shared, at the same time

without worrying about the up or down-scaling of

the shared resources availability, as this is taken care

by the Cloud infrastructure.

Sharing of resources first requires the ability to

locate them. Unlike with older Web based

collaboration approaches, in Cloud based

collaboration, shared resources do not ‘live’ in a

particular Web address or server, i.e. their location is

virtualised. Thus, resources need to be referenced in

a location independent way, using methods such as

universal identifiers (UUIDs) and symbolic URIS

that do not necessarily resolve to a network address .

In this paper we consider the problem of

independent entities (business organisations and

government authorities) that use the collaborative

Cloud to carry out business transactions. Previously,

such business to business (B2B) and business to

government (B2G) interactions were described using

sequences (or choreographies) of message

exchanges. Messages are typically described in an

XML based language such as OASIS ebXML, while

the choreographies of messages in a web service

language such as BPEL. Such approaches however,

requires tight integration between the two

transacting parties, in the sense that the different

parties not only must agree on the messages that will

be exchanged, but also on the sequence of such

exchanges.

Our approach has been influenced by web based

architectural concepts and styles such as WOA

(Hinchcliff, 2008) and REST (Fielding, 2000).

In the remaining of this paper we illustrate our

collaborative Cloud approach, by first introducing its

main concepts and features. Next, we demonstrate

the application of the approach in a transport

logistics Business to Government (B2G) scenario

called Single Window. Finally, we analyse the cost

and other benefits of the proposed approach and

identify areas for future research.

141

Karakostas B. and Katsoulakos T..

A COLLABORATIVE RESOURCE-BASED CLOUD ARCHITECTURE FOR FREIGHT LOGISTICS.

DOI: 10.5220/0003372301410144

In Proceedings of the 1st International Conference on Cloud Computing and Services Science (CLOSER-2011), pages 141-144

ISBN: 978-989-8425-52-2

 2011 SCITEPRESS (Science and Technology Publications, Lda.)

2 CONCEPTS AND FEATURES

OF THE COLLABORATIVE

CLOUD

Cloud has recently started to move from its original

purpose as a vehicle for sharing computing resources

to a platform for collaboration. For example, Cloud

as a technology for supply chain management has

started to emerge in many industries (Gardner,

2009).

The Collaborative Cloud shares its foundations

with other service computing paradigms such as

REST (Fielding, 2000) and WOA (Hinchcliff,

2008). Both REST and WOA put emphasis on

services as resources not as computation.

2.1 Accessing and Manipulating

Resources on the Cloud

To be uniquely identifiable, Cloud resources have

globally unique identifiers (UUIDs). A resource

factory is responsible for generating a UUID upon

request from a client to create a resource. Below is a

UUID for a business resource of type Shipping

Notice

ShippingNotice6E09886B-DC6E-439F-82D1-

7C83746352B

As proposed by the REST approach, resource

representations can be manipulated using standard

HTTP commands. In short, the HTTP set of

operations: PUT, DELETE, POST, GET is used for

retrieving and manipulating resource information.

Resources can be updated using HTTP POST

commands and created using PUT. The following

HTTP operation updates the property Estimated

Time of Arrival (ETA) for a resource of type

shipping notice with unique

identifier:

ShippingNotice6E09886B-DC6E-439F-82D1-

7C83746352B

POST ShippingNotice6E09886B-DC6E-439F-

82D1-7C83746352B?{“ETA” :

{“21/1/10:21:40”}

The above operation may require authorisation;

if the client was not authorised, a

‘not authorised

error (like HTTP 401) would be produced upon

issuing the above command.

3 APPLYING THE

COLLABORATIVE CLOUD TO

SINGLE WINDOW

Logistics companies are tasked with transporting

shipments (cargo) between locations by air, sea or

land. Movements of vehicles and cargo are restricted

by international and national rules and legislations

that specify the documents that need to be submitted

at the different legs of the journey depending on the

type of cargo, arrival and departure points and so on.

The single Window concept refers to the ability

of a logistics company to submit a single document

regarding a voyage, to a single authority that

receives information, either on paper or

electronically, disseminates this information to all

relevant governmental authorities, and co-ordinates

interactions. The traditional approach to the

International Trade Single Window has been to think

of it as a centralised IT application, capable of

accepting single submissions from industry users

and then distributing them to all Government

agencies concerned. This would be in conformance

with UN/CEFACT Recommendation 33 on Single

Windows (UN/CEFACT, 2004).

However, there are several practical problems

with this approach, especially in countries where

already many different systems are in existence. The

cost of integrating such systems is likely to be

greater than the resulting benefits. There are also

technical obstacles with the timing of submissions

relative to the availability of data, and the sheer

scope and transaction volumes. Also, reporting

regulations change quite frequently, making the

updating a centralised system a daunting task.

Figure 1: Cloud for single window concept.

We propose therefore, that the concept of Single

Window can be better realised by a distributed

collaborative Cloud approach. The shared Cloud

resource in this context corresponds to the multiple

physical documents that a ship needs to submit to

various authorities as it approaches or departs from

ports. We call this resource Single Window

Document (SWD), as in Figure 1.

Single

Window

Document

Cloud

CLOSER 2011 - International Conference on Cloud Computing and Services Science

142

SWD is created prior to, or upon the start of a

voyage and shared from then on amongst the ship

and the various authorities and agencies. A SWD is

a resource that has several properties describing the

ship, voyage and cargo. It is important to ensure that

the properties values are described according to

particular reporting requirements

Currently, as a ship enters different national

waters in its voyage, it typically has to prepare and

submit several documents for each different country

or authority it approaches. In the Cloud approach,

the ship master or other agent creates a new single

SWD resource that contains information meeting all

reporting requirements.

A Cloud notification service then informs the

different authorities/agencies that are interested in

this resource. Validation services assist the ship

users in complying with the different reporting

requirements.

To achieve that, a Cloud service analyses the

ship’s voyage plan (a property of SWD) and

identifies the calling ports. This is possible because

names of ports is standardised using the

UN/LOCODE (Code for Ports and other Locations)

recommendation. For each port of call the reporting

requirements can be established.

For example, the above structure states that the next

leg of the journey is from Abu Dhabi (“AEAUH”) to

Zeebruge, with an estimated time of arrival 21.40 on

21/1/10. Based on the ETA and the port of arrival,

the Cloud service establishes the reporting

requirements for Zeebruge Port Authority, as well as

for other related authorities (e.g. Customs). A

validation function is carried out by the Cloud on the

submitted SWD. The validation function compares

the value of the document properties with the

expected value of the property based on the schema

of the report expected by the relevant authority, The

validation returns the list of properties that do not

meet the reporting criteria, as well as missing

properties.

Missing properties from SWD needs to be added,

by perhaps inferring them from other available

information. If, for example, hazardous information

needs to be notified (see Figure 2), it can be inferred

from the goods description property of SWD. If

some goods carried are defined as belonging to

Class 2.1 (flammable gases) of the International

Maritime code (IMO) then hazardous cargo report

must be submitted. If the goods status cannot be

inferred from existing data, this will get flagged and

notified to a human operator for further action.

3.1 Push vs. Pull Mode of

Collaboration

The Cloud approach described here allows a mixed

push/pull approach where the different parties take

the initiative to submit and validate documents. A

ship can operate a monitoring application that

checks if its submitted documents are in a valid state

(e,g “approved”, or “submitted for approval”). The

authority or agency can employ monitoring

applications that check new ship documents as they

are submitted and validate or reject them. A ship can

proactively check the validity of a document by

accessing the validation functions of the different

ports and authorities it plans to visit. If a port or

other authority provides online schemas for the

various reports it requires, the whole reporting

process can be automated. A Cloud service can

access the port report schema(s) and modify parts of

the SWD, based on the schema, to create a port

compliant report. For example, If the next port of

call is Antwerp (unique identifier: BEANR) a Cloud

service will get information about port arrival notice

resource schema by

GET BEANR\port-arrival-notices

A comparison service can compare the current port

arrival notices with the ship’s current SWD

(SWDxxxx ) and return any discrepancies as

follows.

Periodic updates to the status of the journey must

be made available to different parties. These updates

can be in pull or push mode. Pull can be based on

periodic requests initiated by various participants

requesting updates about the transport progress. Pull

notifications can use resource filtering however,

because of latency issues it is best not to be used for

time sensitive notifications.

4 FINDINGS AND

CONCLUSIONS

The Cloud can provide an ideal platform for online

collaboration, as it allows resources to be totally

validate? SWD=SWDxxxx&port-arrival-

notices= BEANR\port-arrival-notices

“movement” : [{“from” : {“UNLOCODE”:

“AEAUH”}, {“to” : {“UNLOCODE”:

“BEZEE”}}, {“ETA” :

{“21/1/10:21:40”}]

A COLLABORATIVE RESOURCE-BASED CLOUD ARCHITECTURE FOR FREIGHT LOGISTICS

143

virtualised both in terms of ownership, content as

well as in terms of location. A Cloud infrastructure

can allow resources to be referenced using virtual

names and addresses and to be manipulated using a

small and universal set of operators. Finally,

resources can be collaboratively edited without

reference to an underlying physical infrastructure,

such as server address or names of the physical

databases that contain the resources. Thus, the idea

of collaborative Cloud as described in this paper is

summarised as follows:

• Reporting procedures can be streamlined;

• documents can be submitted once

• documents can be automatically modified

to comply with reporting requirements

• once a document is submitted the decision

of who needs to be notified lies with the

Cloud than the sender (client). This

simplifies the need to maintain business

logic to support different applications and

workflows.

There is a minimum set of requirement for

coordination between the different parties. A

minimum requirement, Is to maintain a set of

common names for the different business documents

and their properties.

A rough estimation of the cost advantages of this

approach, can be gained by considering the annual

traffic of about 70000 ship calls to Finnish ports

(UN/CEFACT, 2005). If we put the cost of filling in

and submitting a single form at 1 person-hour, and

by assuming an average of 10 forms per ship per

voyage, this can amount to 700000 hours or

approximately 120000 working days or 400 person

years of effort. If the number of forms is reduced to

a single document, there can be savings of 90% or

up to 360 person years, just in a single country.

Also, these savings represents only the ship side and

does not take into account any savings made in the

administrative (port and agencies) side.

In addition to cost, there are other types of

benefits for government agencies such as more

effective and efficient deployment of resources,

correct and increased revenue yield , Improved

compliance, enhanced security and Increased

integrity and transparency

From the users perspective, apart from the

financial (cost cutting) benefits

, the Single Window

can realise benefits such as faster clearance and

release for entering and leaving ports, easier

compliance with rules and regulations and more

effective and efficient deployment of resources and

Increased transparency.

ACKNOWLEDGEMENTS

Work reported in this paper was supported in part by

the Project e-Freight (European e-Freight

capabilities for Co-modal transport) under Grant

agreement no.: 233758, as part of the Seventh

Framework Programme SST–2008–TREN–1

(SST.2008. 2.1.5)

REFERENCES

Armbrust, M, Fox, A, Griffith, R, Joseph, A.D., Katz,R,

Konwinski,A, Lee, G, Patterson, D, Rabkin, A, Stoica,

I, and Zaharia. M. (2010) A view of Cloud

Computing. Communications of the ACM , vol. 53, no.

Fielding, RT (2000) Architectural Styles and the Design of

Network-based Software Architectures PhD Thesis,

University of California, Irvine.

Gardner, D. (2009). How the Cloud Aids Supply Chain

Recalls Cloud computing uniquely enables product

and food recall processes across supply chains.Cloud

Computing Journal AUGUST 25, 2009

Hinchcliff, D (2008). What Is WOA? It's The Future of

Service-Oriented Architecture (SOA). Available from

http://hinchcliffe.org/archive/2008/02/27/16617.aspx

UN/CEFACT (2004). United Nations Centre for Trade

Facilitation and Electronic Business (UN/CEFACT)

Recommendation and Guidelines on Establishing a

Single Window, ECE/TRADE/352.

UN/CEFACT (2005). United Nations Centre for Trade

Facilitation and Electronic Business Case Studies on

Implementing a Single Window to enhance the

efficient exchange of information between trade and

government.

CLOSER 2011 - International Conference on Cloud Computing and Services Science

144