Horizontal IT Gap: Canonical Application Communication

already discussed in Sect.2.

In Sect.3.2the business-IT gap is closed on data level by mapping the business view of BOs to its IT view. Then Sect.3.3closes the business-IT gap on activity level, where domain tasks are mapped to IT system APIs if they can be automated- manual tasks remain. Section3.4finally connects all aspect on the business process level and summarizes the argumentation.

3.1 Horizontal IT Gap: Canonical Application

Communication

Logistics services or applications like a warehouse management system, a transport management system or an ERP (enterprise resource planning) systems and even smaller logistics modules and services, which we call apps, are all seldom used stand-alone—they have to cooperate, e.g. by exchanging messages. Interoperation is needed for the different applications of a customer all available via the Logistics Mall (i.e., in the Cloud) and for the apps of his cooperation partners in the Mall Cloud, but also between applications in the Cloud and applications the customer already uses and still wants to use on premise. This requires a common data model to reduce integration efforts.

The Logistics BO model is canonical [27] and independent of any software product or software provider. Even more, it is based on accepted technical stan-

dardsconstructed in decades by technical (and domain) experts from the standards

organizations and their supporters, and it has an abstract domain view constructed and discussed by logistics domain experts from two Logistics project clusters.

Therefore, it supports the integration of different applications in an optimal way: For every application, only one business model adapter has to be developed, independent of the number of its communication partners, as shown in Fig.13on

1 _{canonical means conforming to accepted principles or standard practice, i.e. being harmonized,} agreed on, minimal, standardized, reusable, but also extensible [27].

the right side. This contrasts with the left side, where for each communication partner a different interface has to be provided and maintained, and different lan- guages are used and many mappings are needed, since same things are named and structured differently.

3.1.1 Selecting a Base Standard

Widely accepted e-business standards are central for interoperation of applications, and they are used on top of technical interoperation standards. Not only the business objects exchanged need to be standardized to ease communication with different kinds and instances of other applications, the protocol steps have to be considered as well.

Today, many e-business standards exist, as described in Sect.5. We compared and evaluated different transaction standards and selected OAGIS [15], the Open Application Group Integration Specification. The reasons are:

• it is a powerful, adaptable and extensible horizontal standard, based on Core Component Technical Specification CCTS [13] and many other standards

• it is mature (first version in 1996—pre-XML, we used version 9.5.1) and in real use (broad industrial support in many countries)

• a logistics module and many logistics-related definitions already exist (e.g. container, shipment, item, pick list), only few extensions are needed for logistics

• it is technology-neutral, but includes Web service definitions, and there are OAGI working groups on Cloud, Mobile and BPMN support.

• UN/EDIFACT [20] formats (in widespread use) are convertible to OAGIS. 3.1.2 Benefits of Using Canonical Standardized Communication

The benefit of using such a widely accepted standard for canonical communication is that the format of most messages ever needed is already defined based on the long experience of a large expert group. Only few definitions have to be added, based on Fig. 13 Canonical communication via standard business objects

the standard’s extension mechanism. These definitions are in turn based on CCTS [13] and its Core Component Library CCL, a mature reservoir of components used as semantically described building blocks in OAGIS and several other standards. Thanks to its many optional attributes, even simple messages can be exchanged conformant to the standard. If special information is needed, its position and format is already defined, thus minimizing data mapping needs.

This enables stable, standards-based interoperation interfaces of applications or services, initially implemented as needed (filling only needed data elements) and subsequently completed as needed in a downwards-compatible way. The same standardized interface can be used for many different partners, and additionally EDI converters can be provided: as OAGIS itself is based on UN/CEFACT standards, transformation to its grandpa UN/EDIFACT still widely in use in logistics is possible and supported.

As depicted by Fig.14, when using a canonical model, the cost for integrating a small number of apps is initially higher, but only increases linearly with the number of interoperating apps. Especially when modifications of apps occur over time, the canonical communication is beneficial.

3.1.3 Technical Communication via BODs

OAGIS defines several BODs (business object documents) exchanged between applications. Each BOD is composed of anApplication Area(the document header) and aDataArea, consisting of a verb and one or more nouns. The verb defines the action to be performed on the nouns or data, which represent the main BOs, visible in the application or service interface.

For each noun, there is a service having methods representing meaningful verbs of that noun. This service can be implemented by various technologies, e.g. RMI (Java Remote Method Invocation), REST or as a Web Service. BODs are used as message formats for these methods, regardless of the technology used. OAGIS itself comes with sample WSDL definitions (the OAGIS services), but we added and implemented services for RMI and REST.

Each application or service running in or outside of the Logistics Mall requires a Mall interface consisting of its required OAGIS services in a technology. This interface has to be implemented towards the enterprise service bus (ESB) used in Fig. 14 Cost benefits of

the Mall or towards the BO Repository. It can then communicate with other application also implementing such standard interfaces. Besides this standard communication, peer-to-peer-communication using other formats is still allowed to smooth the integration curve, e.g. by using EDI converters.

For efficiency reasons, the Logistics Mall internally often uses call by reference. For this purpose, we defined MiniBODs, which are normal BOD, but mainly contain identifiers of BOs instead of copies of BOs. These MiniBODs uniquely reference BOs stored in the BO Repository.

3.1.4 Communication Protocols

To orchestrate the application or app communication, different scenarios and pro- tocols can be realized based on the asynchronous exchange of BODs, as depicted by Fig.15, an UML sequence diagram. Here, some customer orders goods from a supplier, and for the shipment, a logistics carrier is used. The process starts by

sending aProcessPurchaseOrderBOD message from customer IT to supplier IT, and the latter acknowledges the order using a BOD. Communication proceeds as needed, untilfinally the invoice is sent to the customer IT and acknowledged. Such diagrams will soon be available in BPMN from OAGi.

As stated above, these BODs are message formats in OAGIS services, which constitute the OAGIS application interface services of involved parties. Such pro- tocols are often hard-coded in the applications, where receiving a BOD will even- tually result in sending the answer BOD, either synchronously or asynchronously.

A moreflexible and more abstract orchestration of services can be defined using business process models, as described in Sects.3.3and3.4. As a preparation, we need a mapping of the domain business objects model to its technical representations.

3.2 Vertical Data Gap: Mapping the Domain Model