Middleware and communication layers

An overview

The section introduces the idea of an European Textile Clothing and Footwear Network (ETCFN), a virtual eBusiness network, where the business level communication is based on the harmonised standards specifications (described above), and for which we make some recommendations regarding physical communications in order to achieve an optimum mix between flexibility and interoperability.
The network is made of eBusiness partners (various actors in the TCF supply chains) and connectivity service providers (Hubs) or application service providers (ASPs) (the last ones provide various business logic services in addition to the connectivity services).
As specified in section 2 the methodology that we have followed is based on standards specifications on 3 distinct layers: business layer, middleware layer and communication layer. This section is dedicated to the middleware and communication layers.

The purpose of the eBusiness Middleware layer is to formalise the agreements between collaboration partners in such a way to allow for automatic configuration of the underlying Messaging Middleware Layer. The eBusiness Middleware layer can provide also for additional services on top of the Messaging Middleware, such as data format and content transformations, business process management (process integrity control, exception handling, error handling).
The Messaging Middleware allows for automatic configuration of the communication layer and provides for additional services on top of it (such as routing, message reliability, security-related services, etc.).
The communication layer’s function is to physically transport the messages and is based on Internet protocols (HTTP for synchronous communication and SMTP for asynchronous communication).

The approach of eBiz-TCF project

The middleware and communication layers are not sector-specific, they concern the communication systems and applications in general. It is out of the scope of the project eBiz-TCF to harmonise the existing standards at these levels, as well as to define precise guidelines of how to use existing standards in order to obtain interoperability (standard profiling).
However, eBusiness is not possible without implementation of software and communication systems that can exchange and proceed the standard business documents. Therefore we have decided to recommend a set of standard specifics on the middleware layer and basic guidelines for their use, with the point of view of creating the ETCFN basis.
The approach that is adopted within each pilot project is based on the use of the same middleware within the pilot, so that interoperability on middleware level can be achieved. The middleware used in each pilot follows the specific of a recognised middleware standard, but the way such standards are used can differ from pilot to pilot (and thus middleware level interoperability is not guaranteed across pilot projects).

It is out of scope of the project eBiz-TCF to analyse such standards and to delimit interoperable profiles from them that apply to the requirements of the Textile/Clothing and Footwear sectors. Still, if true interoperability is to be achieved, the more detailed development of the ETCFN should be re-considered in a successive Europe-wide reseach and development effort. Here our goal is to put the base for the creation of ETCFN by:

  • Selecting the standards on which the middleware solutions are to be based;
  • Providing descriptions for best practices and data models regarding each standard-based approach.
  • Providing for first harmonisation attempts of data models based on best practices and experience from pilot projects. Due to their immaturity such data models are not mandatory for the project pilots, but are only setting the base for the future ETCFN.

The schema below shows which standards are recommended within the project. The following three basic approaches have been adopted:

  • SMTP/POP-based approach implementing full EDI over Internet
  • ebXML-based approach corresponding to XML (instead of EDI) eBusiness.
  • Web Servics-based approach, corresponding to advanced distributed computing paradigms in the context of eBusiness.

Abstract content models, best practices and examples are presented for each of the three approaches in Appendices D and E . The SOAP-based data models for the ebXML and SMTP/POP-based approaches have undergone a first harmonisation, and have the same content. Note that FTP protocols are not included in the communication layer of the architecture, due to the difficulties related to them in tracking message sending and receiving.

eBusiness and Messaging middleware, a vision

As a first step it is appropriate to analyse which kind of software components are necessary in order to implement eBusiness between two enterprises. The figure below shows the basic software systems/components corresponding to the three standards layers identified within section 2. (Methodology).

We assume that at the premises of each trading partner, there is a system which handles the various business data (usually an ERP or MIS- Management Information System,). Often the trading partners use pre-existing software for these business functions, which is configured and adapted for their needs. In order to implement eBusiness according to the standards-based approach of the project eBiz-TCF, it is necessary to provide for a software interface (typically a software component with the fucntion of data adapter) that is doing the translation between proprietary data formats and data models into those recommended as standards within the project.

We assume that at the premises of each trading partner, there is a system which handles the various business data (usually an ERP or MIS- Management Information System,). Often the trading partners use pre-existing software for these business functions, which is configured and adapted for their needs. In order to implement eBusiness according to the standards-based approach of the project eBiz-TCF, it is necessary to provide for a software interface (typically a software component with the fucntion of data adapter) that is doing the translation between proprietary data formats and data models into those recommended as standards within the project.

At the middleware layer, there can be software components and/or systems which perform functions such as:

  • Configuration of collaboration partners agreements, as far as collaboration business processes are concerned, or characteristics of the underlying communication channel, related to its security and reliability features. (eBusiness middleware).
  • Message Handling systems (transaction management, security management, reliabilit, and error handling).

It is not necessary that such middleware systems are implemented, any kind of information (including business transactions) can be transferred directly via e-mail or web, but in this case the partners should be aware that these communication channels do not provide for proper security and reliability mechanisms, and if something goes wrong, could be hard to handle eventual disputes between trading partners. In fact, it depends on what are the requirements of each business partner with respect to security and logistics of services and what are their agreements regarding these aspects, in order to handle and solve any future disputes.

In the end at the communication layer, we have software systems typical for Internet: web server and client, e-mail server and client, etc. The communication software could be configured via the middleware, or alternatively, the collaboration partner agreements and message handling functionalities could be fixed within the business level software or within non-automatic procedures of the partners. In the reality we do not recommend the option of implementing the middleware functions within the business level software, due to the fact that it is inflexible and would require software re-writing in order to include new partners or to change agreement rules.

(More details in the report)


Risorse

DOC - Connessione ebBP - ebMS, breve guida all'uso WP510-066
Descrizione del collegamento che sussiste tra lo standard ebBP e lo standard ebMS in un contesto di scambio messaggi secondo un predefinito processo di business. (msword, 401597 bytes, v1, 8/3/2010)
DOC - Esempio di busta ebMS da eBIZ
Una busta ebMS (basata su SOAP) contenente un documento UBL di ordine, scambiato nel corso di un processo Cyclic Replenishment Process dove le parti sono identificate con codice di identificazione GLN.
DOC - Reference Architecture Report (con Annessi) OF510-010
Architecture Report for eBusiness harmonisation in Textile/Clothing and Footwear sectors D3.5 - Final Report (December 2009).
Zipped PDF versions (pdf, 2184621 bytes, v2, 27/1/2010)