Empty Container Relocation: Businesscase
0 likes658 views
The report details the implementation of an ebXML-based framework for managing the lifecycle of empty containers within the logistics supply chain. It outlines various agents involved, including customers, shipping lines, and multimodal transport operators, while emphasizing the benefits of modularity, reusability, and interoperability achieved through a service-oriented architecture. Additionally, it discusses the streamlined communication processes and the potential for optimizing container transport and management via web services.
Empty Container Relocation: Businesscase
- 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 empties_businesscase_report.doc Page 1 of 1
- 2. 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. empties_businesscase_report.doc Page 2 of 2
- 3. 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). Shipping Line 1 Container ready for pickup Multimodal Operator Container Terminal 6 2 Customer open Orders accept order 3 Container Pickup Notification Container arrival notification 4 5 Container Status Information 7 8 Caption: Container Tracking Information Web Service Activity (manual or automated) 9 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. Multimodal Operator Container pickup notification Customer Container ready for pickup Legacy System Web Service Client Container delivery notification Shipping Line Web Service SOAP Message SOAP Message Container Terminal Web Service Figure 2 Logical Architecture empties_businesscase_report.doc Page 3 of 3
- 4. Physical Architecture (focus on the Container Terminal) For completeness only. (The Role Multimodal Operator is not covered in detail by this example) Role:Multimodal Operator This SOAP message invokes the process at the Terminal Container service. The Container Status WebService examplifies an interface application to a legacy system. The behavior is specified in the sequence diagramm 3) The Business Software of the Shipping Line requests for container status information. Business Software This part of the SW retrives the information about the Container from the Legacy Application Role: Container Terminal WebService (ContainerStatus) BSI Business Service Interface BSI Business Service Interface SOAP Message Message Handling Role: Shipping Line Specified by Sequence Diagramm requestCSI(Cont.ID) { code code Glue Code code return(Cont.Data) } Message Handling SOAP Messages WebService (Client) 2) The Business Service Interface handles this RPC by packing it into an SOAP message WebService (ContainerTracking) BSI 1) The ClientSW at the Shipping line requests for ContainerStatusInformation (CSI) by calling a WebService with the ContainerID as a parameter. direct access Business Service Interface This ContainerTracking examplifies applications build upon WSA (WebServiceOriented Architectures) Figure 3 The Physical Architecture empties_businesscase_report.doc Data base The status information about the Container is stored here. It can only be accessed through a legacy application. BSI code Business Service Interface RPC-Call code code requestCSI(Cont.ID) code Business Software or Legacy Application Page 4 of 4 T&T Database
- 5. 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-, implementationtesting- 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. Business Model One Business Model (per Business Case = EmptiesCain) defines the scope where all subsequent created objects relate to The Class Diagram provides an overview about all used data items in the whole business case UseCase Diagram Patterns Technical System Specification Functional Model Project Definition Architectual Model (Collaboration) Decision which and how collaborations are implemented Technological Environment Class Diagram Class Diagram Sequence Diagram Specifications for all Services: (Requirenments from:) ebXML service oriented approach One sequence diagramm per service The specification for the services can be derived direct from the funcional modell Sequence (Choreography) of Function Calls (RPC) Legacy Systems BSI description about: Business Service Interface = Legacy System Interface - Interface and - Data (Information Model) The BSI implements the interface to existing applications (Legacy Systems) External WebServices to be used: - WSDL WSDL provides all information needed to call such a service Figure 4 Software Development Workflow empties_businesscase_report.doc Page 5 of 5
- 6. 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). empties_businesscase_report.doc Page 6 of 6
- 7. 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. Multimodal Operator 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 Container Terminal Container Arrival Notification Container Security Information Container Status Information Container Tracking Information Figure 5: new security document 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. empties_businesscase_report.doc Page 7 of 7
- 8. … 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. Multimodal Operator Container Terminal Example: Cont. Arrival & Security Info. Container Security ID 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. Container Status Information Container Tracking Information Figure 6 Container Terminal establishes a new Web Service 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. empties_businesscase_report.doc Page 8 of 8
- 9. 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 empties_businesscase_report.doc Page 9 of 9
- 10. 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 o • Query against a fixed data set 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. empties_businesscase_report.doc Page 10 of 10
- 11. I f r an om o n ti nom n I f r ao i t noao I f mn r t i * Fr I f i sno t * ScnI f eodno * Tr nf hi i o d * r sf i to FI n * ecnI f Sodno * hr no Ti i df OpenOrderQuery Multimo dalOperator 1 * Fi t f sI o r n * S odno cn f e I * Thr no i df i OpenOrderResponse (from WebServi... OrderNotification (from WebServi... (from WebServi... (from act... Train TrainID LocationOfTrackedTrain : String WagonCount : Integer Order OrderID Date : Date AmountOfContainerBooked : Integer provide 1..n TransportMedium 0..n Truck DriverAuthentication : String LicencePlateNumber : Integer TruckID I f r ao om n n ti * Fi t f rI o s n * Seodf cnI o n * Thr n i df o i ContainerStatusQuery 0..n MeansOfTransport MT_ID Authentication Containe StatusResponse r (from WebServi... 1..n 1 ShippingLine organise * Fr I f i sno t * ScnI f eodno * Tr nf hi i o d (from act... 1 TerminalContainer is delivered to 1 ContainerArrivalNotification (from act... carry out I f r ao om n n ti * Fi t f s n rIo * S odno cn f e I * Thr no i df i (from WebServi... ContainerPickUpNotification (from WebServi... noao I f mn r t i * r sno i tf FI * ecnI f Sodno * hr nf Ti i o d 0..1 0..n Transport 0..n 0..n Container Containe Type : Stri n r g Containe W ht : Integ e r eig r Containe ID r A untOfCo n mo ntai er 1 1 0..n A uthorizedToRep 0..n air Vessel VesselID nom n I f r ao i t 1 1 1..n 0..n 0..n Repair ReparationID ConditionOfDamagedContainer DamageSpecification RepairCost ReparationStatus Transp ortOrigi n : S ng tri Transp ortDe na sti tion : Stri ng Transp ortArrival Time : Date Lo adTi me : Da te ContainerReadyForPickUpNotification (from WebServi... Figure 7 The class diagram of the empty container example empties_businesscase_report.doc nom n I f r ao ti * Fi t f sn rIo * S odf c n enI o * Thdn ri f i o (from WebServi... 0..n Page 11 of 11
- 12. 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 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 • Examples: Fill out a form, print a file, send content of file via message Existing Applications: UNeDocs (transform paper documents to XML structure and vice versa. Mapping from one format to another (format mapping) o o Semantic information about the content of both the source and the target document is needed o • XML to XML (using DTD’s), CSV to XML, … 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. empties_businesscase_report.doc Page 12 of 12
- 13. 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/ empties_businesscase_report.doc Page 13 of 13