Empty Container Relocation: Businesscase

empties_businesscase_report.doc Page 1 of 1

GILDANET gildanet.paradigma.net

Implementing the Empties Business Case using ebXML

Paradigma Unternehmensberatung

Vienna, December 2004

Mariahilfer Strasse 47/1/3

1060 Vienna, Austria

www.paradigma.net


Introduction The aim of this short report is to show the usage and benefits of the ebXML architecture and the UN/CEFACT Modelling Methodology with a real-world example: the empties supply chain.

Within GILDANET this example can be used to demonstrate an electronic document exchange application, explain (real) interoperability and the reusability of its components. The implementation of this application can be used to build an ebXML framework (architecture), demonstrate the functionality, and build reusable blocks that help other customers to create service oriented applications in the logistic sector.

Business Case Overview This simple case study deals with the transport and management of empty containers. Since controlling and financial services are beyond the scope of this model, it can be best described in relation to an empty container’s lifecycle. An empty container "is created" when a full container is emptied of the goods it carried. Normally this occurs either in a container terminal or at a client's location. The next step may involve a movement of the container, which can be taken to another terminal (port terminal or inland terminal); the container could even stay at the same location (no relocation) in case the unloading were performed is be stocked. Subsequent movements to different terminals are possible; until finally an empty container is filled with goods. This is the end point of an empty container's lifecycle.

Among others, the following agents are involved in the supply chain of empty containers:

• Customer: An enterprise or person demanding a transport service from the shipping line.

• Shipping line: A shipping line manages a fleet of vessels. Vessels carry full and empty containers from a departure port to a destination port. Normally it owns a certain amount of containers.

• Multimodal transport operator (MTO): The multimodal transport operator takes care of the transport of containers between different locations, organizes the transport of all modes and conducts the transportation by truck himself.

• Container terminal: A container terminal handles container flows within a port or dry port area (loading, unloading, stocking, charging, discharging, repairs, inspection, etc.).

The process chain starts with a container being emptied at a customer’s site. The latter communicates this to the shipping line, which in turn provides this information (basically the container’s location) via its web service to a set of multimodal operators. In order to be able to exploit the potential for optimization in this chain, the MTOs are given the opportunity to decide within certain constraints on their own which orders they would like to fulfil. This is done by the MTOs’ legacy route planning systems, which calculate the dates of pick-up at the client and dates of delivery to the container terminal. Pick-up and delivery dates are sent to the client and container terminal, respectively. After the MTO has carried out the transport to the container terminal, the empty container is released for future use. The container terminal inspects the containers and if necessary conducts repair and maintenance operations. The container’s status as well as tracking information is provided via web service to the shipping lines.

The detailed flow of information can be seen in Figure 1: the initial message sent out by the client (1) is a simple notification (cf. Appendix). Its addressee is the shipping line where the message is received, pre-processed and provided to the Web Service at the Shipping Line (6). In their operations planning process MTOs look for open orders as clients of the shipping line’s service. This transaction (2) is best depicted by a query/response pattern (cf. Appendix figure). On a MTO’s query, the shipping line’s system responds by supplying the necessary information.

The acceptance of an order (3) triggers the MTO’s detailed planning process. Routing and scheduling decisions concerning the means of transport result in pick-up and delivery dates.


The former are communicated directly to the client (4), the latter to the receiver of the delivery, the container terminal (5). Since neither of them needs to react to this information, this process is again modelled by a notification pattern (for an example see Appendix, figure ). Finally the container terminal provides the status of any particular container as well as relevant tracking information via web service (7). The shipping line may use this Web Service provided by the Container Terminal at any time to request information concerning their containers (8) and (9).

Customer

ShippingLine

Container readyfor pickup

Multimodal Operator Container Terminal

accept order

open Orders

Container Pickup Notification Container arrival notification

1

2

3

4 57

6

Container Status Information

Container Tracking Information

9

8

Activity (manual orautomated)

Web Service

Caption:

Figure 1: Business Case Overview

Logical Architecture Based on the business process analysis and technical environment we decided to implement the communication between Shipping Line and MTO and Container Terminal and Shipping Line as Web Services. In particular, the MTOs looking up open orders and the Shipping Lines requesting information about containers at the terminal. The technical environment suggests an ebXML-conformant service-oriented approach so the selected transactions are implemented as Web Services and SOAP messages.

MultimodalOperator

LegacySystem

ShippingLine

ContainerTerminal

WebService

WebService

Customer

SOAP Message

Container pickup notification

Container delivery notification

WebServiceClient

SOAP Message

Container ready for pickup

Figure 2 Logical Architecture


Physical Architecture (focus on the Container Terminal)

Role: Shipping Line

WebService (Client)

Role: Container TerminalRole:MultimodalOperator

BusinessSoftware

BSIBusiness Service Interface

WebService (ContainerStatus)

requestCSI(Cont.ID) { code code code return(Cont.Data)}

SOAP Message

Spec

ified

by

Sequ

ence

Dia

gram

m

For completeness only.(The Role Multimodal Operator is not

covered in detail by this example)

codeRPC-CallcodecoderequestCSI(Cont.ID)code


1) The ClientSW at the Shippingline requests forContainerStatusInformation (CSI)by calling a WebService with theContainerID as a parameter.


MessageHandling

3) The BusinessSoftware of the

Shipping Line requestsfor container status

information.

This SOAP messageinvokes the process atthe Terminal Container

service.

MessageHandling

SOAP Messages

BusinessSoftware orLegacyApplication

Database

Glue Code

The status information aboutthe Container is stored here.

It can only be accessedthrough a legacy application.

This part of the SW retrives theinformation about the Containerfrom the Legacy Application

T&TDatabase

WebService(ContainerTracking)


2) The Business Service Interfacehandles this RPC by packing it intoan SOAP message direct

access

This ContainerTracking examplifiesapplications build upon WSA(WebServiceOriented Architectures)

The Container Status WebServiceexamplifies an interface applicationto a legacy system.The behavior is specified in thesequence diagramm

Figure 3 The Physical Architecture


Using ebXML The business and the functional model are results of UMM. The business model contains information like requirements for the collaboration, i.e. when and where certain business information is needed in the business process. On the other hand, the functional model contains a detailed technical specification of the collaboration that will be implemented using ebXML and was derived from the prior analysed business processes. Also the technological environment imposes constraints on the implementation, which in our case are: using ebXML, the interoperability with legacy systems, and the use of Web Services. In this case ebXML suggests a service-oriented architecture (SOA). This facilitates the integration of existing business software (legacy systems) and external Web Services described below (see section Physical Architecture).

The functional model (in UMM terms the ‘Functional Service View’) delivers two essential results: the class diagram provides the common data basis for all services, but one service may only use parts of it. Sequence diagrams, which exist for each transaction, provide the specification for a particular service. Both together determine the choreography of business processes and the information exchanged between all partners. If each of the partners adheres to these outlines in his implementation, interoperability will be guaranteed.

The technical system specification contains all information needed to implement the business choreography. While the functional service specification and the class diagram are derived from the functional model the project definition is taken directly from the business model. Finally, the Business Service Interface depends on the particular legacy system in use.

The development process usually has five phases: analysis-, specification-, implementation- testing- and rollout phase. The analysis phase is extended by UMM to analyse not only the messaging layer to derive requirements also the business layer to ensure interoperability. So with UMM the requirements of a detailed technical analysis phase and the requirements of interoperability for that phase can be accomplished. The specification phase can be supported by standardised material from UMM described above. The additional architectural descriptions (logical or physical component diagrams, describing the building SW or HW blocks and their interfaces) can be derived from SOA and adopted to the individual needs of the business partners.

BusinessModel

Patterns(Collaboration)

UseCaseDiagram

FunctionalModel

SequenceDiagram

ClassDiagram

Technological Environment(Requirenments from:)

External WebServicesto be used: - WSDL

ebXMLservice oriented approach

Legacy Systemsdescription about: - Interface and - Data (Information Model)

Technical System Specification

Specifications for all

Services:Sequence(Choreography) ofFunction Calls (RPC)

Class Diagram

Architectual Model

Project Definition

Decision whichand how

collaborations areimplemented

The BSI implements the interface toexisting applications (Legacy Systems)

One sequencediagramm per

service

WSDL provides all informationneeded to call such a service

The Class Diagramprovides an overviewabout all used dataitems in the wholebusiness case

One Business Model (per BusinessCase = EmptiesCain) defines thescope where all subsequentcreated objects relate to

BSIBusiness ServiceInterface = LegacySystem Interface

The specificationfor the servicescan be deriveddirect from the

funcional modell

Figure 4 Software Development Workflow


Advantages of the this approach The combination of UMM, a standardized analysis methodology, and ebXML, a collaborative business framework, implemented by a service oriented approach makes the whole approach modular, reusable, and interoperable.

Reusability of the components

• Not only SW components: UMM Artefacts (BPSS) can be reused, the Class Diagram should be used by every partner, all collaboration information can be used by both partners.

Interoperability in the sense of ebXML is achieved by:

• "Common Business Processes - Both entities involved in the exchange of data MUST be engaged in executing the same transaction in the context of a business process": Achieved by using UMM to analyzing and documenting business processes and representing key attributes in an XML document (BPSS).

• "Common Semantics - Common meaning, as distinct from words, expression, or presentation": Achieved by the use of core components

• "Common Character Encoding”: UNICODE, which is specified in the W3C XML Version 1.0 technical specification, provides this.

• Document business and application (technical) layer by using standardized methodologies. First with UMM, second with WSDL and finally publishing those in the Registry

o Make this documentation readable (and accessible) by everyone / partners (Registry)

• (Re-)Using existing systems by connecting them to a SOA

Core Components

• Core Components specify the semantics of data attributes. Use these core components in the Class Diagram to arrive at commonly understood business documents.

UNeDocs

• Mapping of real world standard documents in the logistic field to XML structures by adding (the needed) semantic notation.

Question section-explained by fictive examples The aim of this section is to show the previously promised features with “real world” examples:

What if: a new actor joins the collaboration? The interface tasks and communication with its partners must be analysed and documented using UMM (or a similar methodology). The pertinent interactions (the business) with its partners can then be formulated (based on the business process description) within a contract.

The decision which of the above-described interface will have to be implemented electronically is done (see Software Development Workflow). Existing Web Services of the partners can be reused; the interface (Web Service) of the new partner has to be implemented (reusing components of the ebXML framework).


The compliance with the contractually specified choreography, validity checks of the transmitted data and any required mappings to legacy applications will be part of this interface component (BSI).

The specification for this component is an important result of UMM. The process must be integrated in the processes of the partners (this is achieved by virtue of the choreography of UMM); components must be able to communicate (this is assured by the Class Diagram).

… a new document should be integrated (used). The new document exchange will be added to the Business Model (by changing the BPSS of the involved partners) if needed (see below). The implementation of the new document depends on the needed mapping functionality (see Appendix).

If the new document is a standard document in the logistic field (covered by UNeDocs) or the document can be described by an XML structure (by definition almost every document can) the two needed tasks can be done with minimum effort.

Example:

We assume that for security reasons every container that arrives at the CT must have an document with an security ID. The CT provides a Web Service where such documents can be requested and the MTO needs to equip every container with such a security document.

In the following every step necessary for such a change is described

1. CT and MTO formulate the new transaction with a pattern in the Business Model. (SL is not involved in any change). This pattern describes the information which has to be sent by the MTO to eventually receive the security ID. As no other interaction is involved the existing business model may remain unchanged.

2. Subsequently the two trading partners can express their changed collaboration within a new version of the previously shared BPSS. If they agree on the new business process (BPSS) they will sign a new contract (CPA) based on the new BPSS.

3. The new transaction results in additional Web Service functionality which must be described in the technical specification. In particular a new sequence diagram describing the methods invoked and the data elements which are transmitted to implement the security ID service at the CT.

4. The CT may implement the new service using the same methodology as they used to based on the same kind of specification. Their development process will benefit from the reusability of many components of the already implemented Web Service. The effort and costs of this extension will be minimal because of the modular design and the independency of each individual service.

5. The final output of the Web Service is a document described in XML downloaded by the MTO, which can be easily converted into a paper document by an “XML to PDF” conversion and by printing out the PDF.

Figure 5: new security document


Container Arrival Notification



Container Security Information


… a business process changes ? As described above the Partners must agree on new interaction process (collaboration). This is done by a standardised method: First, a common BPSS is formulated, and stored using registry functionality. Second, a new contract based on the new BSPP is signed. The new process can be then integrated supported by the flexibility of the SOA: No other service have to be changed, adopted or rewritten. The new functionality can be easily integrated using existing components into the set of Web Services.

Example:

We assume that because of efficiency reasons the MTO–CT communication is redesigned so it can be integrated into and benefit from the service oriented approach: The message of the container arrival is no longer sent by email, fax, or whatever it is sent by; the information is now direct input of the MTO and can be aligned with the information the MTO has to send to receive the security ID.

1. The pattern of the security ID transaction will be changed by adding the data formally sent by the container arrival notification.

2. The new version of the BPSS will again be signed by the partners using their CPP and a new CPA as a contract.

3. The Web Service of the CT will be extended by a method that is similar to the security ID method. Additionally it will update the container arrival information and subsequently the container status data in the tracking application.

4. Maybe not all MTO are able to change the business process. In the old version the information received from the MTO have to be manually inserted into the tracking database. The new process makes it possible, that the input of the MTO can be used to update the tracking database automatically. Because of the fact that in a SOA the services can coexist independently the old and the new version will coexist as long as needed.

… one of the involved actors is not equipped with appropriate IT ? If for one of the partners is not feasible to implement SW clients on their IT environment, the previous described architecture cannot be implemented as described. One possible solution may be a “Web Service to Web Application” – service, a Web Client. This Web Client is a client to a given Web Service, but serves the business logic of the collaboration via HTML so a simple web browser can be used as an interface to the Web Service.

Such Web Clients have been described in several GILDANET discussions about architecture as a possible role of “the Portal”, and is identically used in the ebXML Registry client.

Example:

We assume that the Shipping Line’s IT environment of the agents at the ports does not allow any thick clients, only web browsers are feasible to access the CT’s services.

1. It is important that the services or any other component of the SOA has to be changed. The Web Client must only use the same Web Service Interface as any other client would do.


Cont. Arrival & Security Info.



Container Security ID

Figure 6 Container Terminal establishes a new Web Service


2. The CT (or anyone else who is capable) now operates such a Web Client so that the Shipping Line is able to access the Web Services of the CT via web browser-based technology.

3. The business logic, in particular the workflow management and the data input and output interface, which is normally managed by the SLs business software is now implemented in the Web Application logic of the Web Client.

The requirements to implement such a Web Clients are:

• Use exactly the services that are provided by the Web Services. This interface can be seen as an API for the Web Client, described in the WSDL of the Web Service.

• The needs of the Shipping Line at the client side. In particular the workflow management needs to be implemented aligned to the requirements of the user. These requirements are partially described in the business model.

Where does the mapping between different business documents happen? To answer this question it is expedient to firstly describe the concept of “mapping” itself (see Appendix). Secondly XML is not a file format like CSV, it is a data description language. It contains per definition not only data but semantic information about the data also. This makes mapping where either source or target is specified using XML much less complex than between other file formats.

1. “Medium transformation”: UNeDocs provides appropriate Web Services, which can be used to map a UNeDocs XML-structure to a printable PDF format. Or the same method can be used as a local Web Service.

2. “Format Mapping”: such mapping is best implemented at the message-handling component of the BSI and in the code that communicates with the legacy application (Figure 3 The Physical Architecture), because it requires intimate knowledge about the legacy application. By the same token this prevents any outsourcing venue. In case different mapping needs arise, they can be addressed by reusing the BSI code for a template.

3. “Information Mapping”: a SOA can perform this task by defining a Web Service designed to perform the mapping itself. This scenario assumes, that a single point of maintenance has been defined

Appendix

Output from UMM: Business process models describe business processes that allow business partners to collaborate. Business process models for e-business must be turned into software components that collaborate on behalf of the business partners. The UMM Meta Model is a description of business semantics that allows trading partners to capture the details for a specific business scenario (a business process) using a consistent modelling method and a standardized language. A Business Process describes in detail how trading partners take on shared roles, relationships and responsibilities to facilitate interaction with other trading partners. The interaction between roles takes place as a choreographed set of Business Transactions. Each Business Transaction is expressed as an exchange of electronic Business Documents. The sequence of the exchange is determined by the Business Process, and by messaging and security considerations. Business Transactions are subdivided into groups of patterns. The following six conventions for business transaction patterns have proven useful in the application of existing business requirements:

• Query/Response


A query for information that a responding partner already has available. This pattern depicts the exchange of static information, such as product catalogues. There is no need for receipt or acceptance acknowledgements.

o Query against a fixed data set

o Query to obtain a catalogue

• Request/Response

Similar to Query/Response; however, an additional activity from the responding partner is needed to gather the demanded information. This pattern is used to map the exchange of dynamic information such as requests for quote or availability checks. There is no need for receipt or acceptance acknowledgements.

o Price Request

• Request/Confirm

This pattern is for obtaining status information and involved business documents for request and response. There are no economic commitments after this interaction and no business acceptance or receipt conformation.

o Request to obtain order status

• Commercial Transaction

This pattern is used for interactions that result in economic commitments among business partners. Thus, non-repudiation and authentication are essential.

o Place order

• Notification

This pattern specifies the exchange of a notifying business document and a receipt acknowledgment business signal. This pattern models a formal information exchange and therefore has non-repudiation requirements. It is a non-repudiation exchange of business documents.

• Information Distribution

Similar to notification, except that it is about informal information exchange, and therefore has no non-repudiation requirements. It is a “repudiatory” exchange of business documents.

Such a classification into six patterns also provides additional information about the communication process itself. Business requirements and information about the role of the two partners are therefore stored within the model.

In the above example the Container Terminal receives a message from the MTO stating when an empty container is scheduled to arrive as seen in figure

Class Diagram of the Business Model

A class diagram shows the static structure of the information model, in particular, the things that exist, their internal structure, and their relationships to other things. A class diagram is direct related to the sequence diagram and the business transaction patterns via the business information objects which are included in all of these diagrams. Through this link, the static information is linked to the dynamic process described in the process model.

The class diagram for the example in this report is given below.


TruckDriverAuthentication : StringLicencePlateNumber : IntegerTruckID

TrainTrainIDLocationOfTrackedTrain : StringWagonCount : Integer

VesselVesselID

MultimodalOperator

(from act...

TransportMedium

1..n

1

1..n

1

provide

Informati on* Fi rst Info* Second Info* Third info

OpenOrderQuery

(from WebServi...

Infor mation* Fir st I nfo* Second Info* Third inf o

OpenOrderResponse

(from WebServi...

I nformat ion* First I nfo* Second Inf o* Thi rd inf o

OrderNotification

(from WebServi...

MeansOfTransportMT_IDAuthentication

TerminalContainer(from act...

ShippingLine(from act...

0..n 0..n0..n 0..nAuthorizedToRepair

Informati on* Fi rst Info* Second Info* Third info

ContainerArrivalNotification

(from WebServi...I nformat ion* First I nfo* Second Inf o* Thi rd inf o

ContainerPickUpNotification

(from WebServi...Infor mation* Fir st Inf o* Second Info* Third info

ContainerReadyForPickUpNotification

(from WebServi...

RepairReparationIDConditionOfDamagedContainerDamageSpecificationRepairCostReparationStatus

0..n

1

0..n

1

carry out

OrderOrderIDDate : DateAmountOfContainerBooked : Integer

0..n

1

0..n

1

0..n

1

0..n

1

TransportTransportOrigin : StringTransportDesti nation : Stri ngTransportArrivalTime : DateLoadTime : Date

0..1

1

0..1

1

0..n

1

0..n

1is delivered to

0..n

1

0..n

1

organise

I nformat ion* First I nfo* Second I nfo* Thi rd info

ContainerStatusQuery

(from WebServi...

ContainerContainerType : Stri ngContainerWeight : IntegerContainer IDAmountOfContainer

0..n

1

0..n

1

0..n

1..n

0..n

1..n

1..n

0..n

1..n

0..n

Informat ion* First Info* Second I nfo* Thir d i nfo

ContainerStatusResponse

(from WebServi...

Figure 7 The class diagram of the empty container example


Sequence diagram.

The sequence diagram is used primarily to show the interactions between agents in the sequential order that those interactions occur. An organization’s business staff can use sequence diagrams to communicate how the business currently works by showing how various business objects interact. Besides documenting an organization’s current affairs, a business-level sequence diagram is used as a requirements document to communicate requirements for a future system implementation. In addition to their use in designing new systems, sequence diagrams can be used to document how objects in an existing (“legacy”) system currently interact.

Information Mapping Mapping deals with information, attributes or data elements transmitted via document, file, or message.

• Mapping between document, file, and messages (medium transformation)

o Examples: Fill out a form, print a file, send content of file via message

o By mapping to a message we mean a mapping to an XML “stream”, ready to be sent via a SOAP message.

o Physical transformation is needed, content remains the same.

o Existing Applications: UNeDocs (transform paper documents to XML structure and vice versa.

• Mapping from one format to another (format mapping)

o XML to XML (using DTD’s), CSV to XML, …

o Semantic information about the content of both the source and the target document is needed

o Implemented via COTS Software, or a piece of software, which provides a parser to read the source document, logic, which does the semantic mapping, and a component that, formats the output.

• Mapping of information from different schemata (information mapping)

o Different actors use different ID’s to describe identical facts and store these different attributes in their databases.

o For example: the car producer identifies cars with a chassis number or VIN (vehicle identification number); the carrier via a combination of order number and part number, and the yard operator via a RFID.

o Implementation is only possible with an additional mapping table.

Glossary Business Software Interface (BSI)

The BSI connects the Business Software to the messaging layer of the network. In particular the SOAP message from the network is decrypted and validated, the header information is compared to business information (BPSS) and the content is subsequently passed to the business software. Required mapping and transformation processes may be included.

Whatever the “Business Software” is (by the means of its architecture), if it is a legacy system (see below) the BSI can be interpreted as SW which includes the Message handling, an Web Service, and Glue Code which implements the transformations needed to access the data in the Legacy System.

In general the business logic is implemented in the Web Service, therefore the BSI does the message handling part for the Web Service.


Legacy System

Systems, which already exist and are not “aligned” to the needs of an SOA. In particular, the needed information (specified in the BPSS) cannot be direct accessed by a procedure/method call (specified in the Sequence Diagram).

Simple Object Access Protocol (SOAP)

SOAP is a lightweight protocol for exchange of information in a decentralized, distributed environment. It is an XML based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined data types, and a convention for representing remote procedure calls and responses.

SOAP provides the framework by which application-specific information may be conveyed in an extensible manner. Also, SOAP provides a full description of the required actions taken by a SOAP node on receiving a SOAP message.

http://www.w3.org/TR/soap

Service Oriented Architecture (SOA)

A service-oriented architecture is essentially a collection of services. These services communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is needed.

The technology of Web services is the most likely connection technology of service-oriented architectures. Web services essentially use XML to create a robust connection.

http://www.w3.org/TR/ws-arch/