![](bg3.png)
on the Cloud, and by utilising Cloud based
integration services. This will result in typical Cloud
derived benefits such as efficient utilisation of
computing resources and reduction in IT costs.
Type B collaboration leads more naturally to a
service oriented (SOA) solution. Dynamic
collaboration and coordination of transport chain
participants requires a service architecture,
comprising service registries and a service discovery
facility, to allow respectively the publication and
discovery of transport related services.
Service matchmakers are required to match
transport service supply with demand. A service
matchmaker must be able to understand concepts in
the service description, such as price and location,
i.e. the start point and destination of the requested or
offered service). Such capabilities go beyond the
abilities of conventional web services (i.e. WSDL
service descriptions) and into the realm of semantic
web services.
Ontologies are essential in service match making
and interoperability, as they serve to integrate the
different standards and formats that are used in the
freight sector and to achieve semantic
interoperability.
A Cloud architecture needs therefore to address
the problem of standard heterogeneity. For example,
there are several data and document standards
employed in the transport sector such as GS1, CEN,
UN/CEFACT, UBL/OASIS and others.
Finally, a Cloud architecture needs to address the
problem of dynamic interoperability of
heterogeneous systems such as port systems, internal
transport planning and operation systems, safety and
information systems for sea transport and others.
In the next section we explain how the
coordination and interoperability is manifested in
transport planning, execution and monitoring
activities.
2.3 Collaborative Transport Chain
Planning
In transport network planning, collaboration
involves all participants exposing their internal
resource availability, plans and other
requirements/constraints to other participants in the
transportation network, in order for a transportation
plan to be established, that contains an accurate and
mutually agreed plan of responsibilities, deadlines
and actions for transporting the cargo from origin to
final destination. A transport plan can undergo
several iterations during which it is usually
optimised in terms of duration and resources. At this
stage, costs and payments are also established and
negotiated. A Cloud approach to transport chain
planning needs to leverage service oriented concepts
to expose internal databases and systems of the
participants in a controlled manner. Internal booking
systems of shippers need for example to interoperate
with pricing systems of service providers. Such
operations need to be carried out according to the
security and other controls of the different
participants, as confidential data about the cargo
may not be revealed until the time is appropriate. In
some cases, even the identities of the participating
organisations may be kept confidential until
contracts are exchanged.
2.4 Collaborative Transport Chain
Execution
During this stage, information generated at any point
of the transportation chain must be easily accessible
by all interested parties. A Cloud infrastructure can
allow such information to be replicated across cloud
storage systems, and its existence to be notified to al
interested parties, through reliable event based
notification mechanisms. In this approach, the Cloud
can become a high performance message relay that
transcends the communication and other networks
used by the transport chain participants. A typical
Cloud application for transport chain execution is
meeting the mandatory reporting requirements as the
cargo carrying vessels arrives at different ports and
terminals. Cloud, for example, can be used to
implement the concept of Single Windows
(UN/CEFACT, 2005) which refers to the
streamlining of cargo and traffic information
exchange between authorities and between
authorities and other stakeholders. Services can be
deployed on the Cloud for 'one stop reporting',
allowing operators to submit a single report, which
is then relayed to all relevant authorities.
3 A CLOUD ARCHITECTURE
FOR E-FREIGHT
Based on the requirements for collaboration and
system interoperability in e-freight identified in the
previous sections, in Figure 1 we provide a
conceptual architecture for Cloud based freight
collaboration. Such architecture can be utilised by
the combination of several commercial and open
source Cloud technologies. Our aim is to define an
collaboration architecture for e-freight using Cloud
concepts that remain stable even when the
CLOUD ARCHITECTURE FOR E-COLLABORATION IN THE INTERMODAL FREIGHT BUSINESS
269