Analysis of a potential use of middleware technologies for railway domain C. Gransart 1, J. Billion 2, D. Van den Abeele 2 1 INRETS, Villeneuve d Ascq, France; 2 ALSTOM Transport, St Ouen, France 1. Introduction The European research project InteGRail (Intelligent Integration of Railway Systems) aims to create a holistic, coherent information system, integrating the major railway sub-systems. In this context, a framework for intelligent communication is under development (named ICOM). For this framework, we are evaluating current middleware technologies coming from IT projects in order to apply them in the context of railway applications and/or to adapt the way such middleware are built. 2. Generalities on middlewares The word middleware can be defined as the software between application software and operating system software and related low-level drivers (communication, input/output, ). The main goals of the middleware are: To hide the heterogeneity (of computers and systems); To hide distribution of data and processes; To offer standardized interfaces (API + network protocols). Figure 1 represents a generic view of the middleware on top of the operating system and associated communication layer and below the applications. The applications located on different hosts are able to communicate together thanks to the interfaces offered by the middleware layer. Figure 1: Generic view of a middleware To create an interoperable system, the current trend is to use an interface definition language, which allows to describe the relations between client applications and server applications and this independently from the implementation languages on either side. For most middleware technologies, a specific language is defined to meet this requirement. This interface between a client and a server is also called a contract. This contract specifies what functional services a client may call on a server and also what is the minimum that a server must furnish as functionalities to its clients.
Standardized Interface Definition Languages (IDL) are the basis to build interoperable services/applications. By using appropriate IDLs, the railway world will be able to specify clearly interfaces between applications. These interface specifications will then be shared among partners and allow applications using these interfaces to interoperate seamlessly. Moreover, the interfaces are described independently of the implementation code. This permits different partners to choose different implementation technologies and to be still interoperable! 3. Railway communities with different middleware needs There are three segments where middleware can be used: for on board embedded applications, for train to ground applications and for ground core applications. Each of these communities has its own specificities: On board applications communicate through a real time network. Currently, this network is wired. During the train inauguration phase, the configuration of connected train nodes is established. It remains stable until the next coupling/uncoupling operations. Some applications have real time constraints and/or produce data periodically (e.g. every 200 millisecond). Train to ground applications may use several kind of wireless bearers with various quality of service. Applications may have different requirements for the IT traffic between the train and the ground: from few sporadic data up to continuous data stream. Moreover, the communication between the train and the ground could be sometimes broken; for example a network disconnection due to an out of coverage event. If several communication channels are available, the system must choose the best one according the current context (vertical handover). Core applications are similar to distributed applications on local/wide area network. The main focus is on interoperability between railway actors. 4. Requirements and good qualities needed for the middleware Transversally to the railway communities, we specified a list of requirements and functionalities needed by railway applications at different levels. 4.1. Services inside the middleware Messaging management This service defines a generic interface for point-to-point communication between 2 applications. This is the basic service to be able to construct distributed applications. The service is directly manipulated by applications based on the asynchronous communication model (for the MOM) and not directly visible by applications using the synchronous communication model. Fault management This service allows to control operations in normal and degraded modes. Any faults may trigger some actions and should be recorded with contextual variables in order to be later analyzed. Fault tolerant middlewares are rarely compatible with real-time middlewares. For example the OMG started a new work on lightweight real-time fault tolerant CORBA. Because current solutions to solve the problem of fault tolerant real-time systems are poor and rarely used. Fault tolerant systems consume CPU time and
network bandwidth to check if all the nodes are up; this is sometimes not compatible with real-time constraints. Event management This service allows each application to define its own set of relevant events. Once this dictionary of events is configured, applications can generate one of those events during operation. Timer management This service offers the possibility to trigger periodic events. 4.2. Services on top of the middleware Life cycle management This service is in charge of start up, execution and shut down of the basic applications taking into account dependencies between these applications. It will define the sequence of platform start up and shut down and monitor status of applications during their lifetime. Data repository management This service centralizes a dictionary for all the data that may be exchanged between applications. This service manages concurrent access to those data. Network management This service intends to implement access to the network, through standardized interface. Specific hardware management This service allows to access specific hardware through generic interface. Time management This service is in charge of time consistency between applications, in particular for event time stamping. 4.3. Tools for the deployment The deployment tools permit to easily deploy a distributed application on a set of nodes interconnected by a network. Some technologies offer deployment facilities, others don t. For this last case, deployment must be made by hand or new tools have to be developed. 5. Middlewares studied Next, we compared our requirements with the functionalities offered by several categories of middleware: middleware based on synchronous communication models like CORBA, SOA and ESB, middleware based on asynchronous communication models like message queuing systems, Data Distribution Service (DDS), component based solutions like CORBA Component Model, PECOS. We also had a look at projects like DECOS and TMO. We only discuss in this paper about synchronous, asynchronous communications models and DDS.
5.1 Middleware based on synchronous communication models CORBA based middleware CORBA (Common Object Request Broker Architecture) is a standard defined by the OMG consortium (Object Management Group). It provides a distributed object environment in which objects are made available transparently from location and implementation[1]. A CORBA environment is composed of different parts: An ORB (Object Request Broker). The ORB is responsible of the transport of requests 1 between CORBA objects. It hides to the application part the location of the distributed object servers. An IDL (Interface Definition Language). IDL is a declarative specification language that provides basic and constructed data types and permits to define object interfaces. The IDL specification for an application is compiled by an IDL compiler to generate stubs (client part) and skeletons (server part) for a particular programming language. Implementation of the client and server parts can be done using different programming languages (C, C++, Java, Ada, COBOL, ). The low level part of the ORB uses a standardized message format, which is common to all the CORBA product implementations. Application objects, which will use the IDL language to describe their interfaces and the ORB to communicate. The Figure 2 presents the CORBA architecture. Clients and servers can be implemented using different programming languages. CORBA permits to build n-tier applications: a program can be simultaneously a server for several application clients and be a client of another server. Figure 2:CORBA architecture 1 A request can be defined as the message sent by a client on the network to call and execute a piece of code (method, subroutine, function, ) located on a remote server.
The CORBA standard defines some extensions for the real-time or fault tolerant applications. Service Oriented Architecture A SOA consists of clients and servers (services) connected by a communication subsystem known as a service "bus" (Figure 3). Services are defined using formal interfaces (contracts) that hide away implementation details from the client. The bus supports both point-to-point and messaging styles of communication, and supports enterprise qualities of service like security and transactions. SOA related solutions often offer both synchronous and asynchronous interactions. Figure 3: SOA service bus IONA Technologies 2005 Services are often reused by a number of applications. Their interfaces are defined using a formal contract (for example, WSDL, or IDL) The service implementation details are unknown to the client; the only connection (or coupling) between the client and server is the contract. The service is self-contained, and can be run with or without other services present. Services may be used by other services. The interfaces are stored in a well-known repository that prospective users can browse. Formal contracts, loose-coupling and abstraction of implementation details are key features of a SOA. Let s note that the properties above are almost identical to the properties of an object in object-oriented architecture (like CORBA for example). SOA associates new terminology with concepts that have been around for some time. The key idea of separating service semantics from service implementation using welldefined contracts was already used by CORBA, DCOM, DCE and.net. Around 2002-2003 SOA concept became more prominent along with the rise of (WS) Web Services and (ESB) Enterprise Service Bus approaches. Web services technologies (including a new interface definition language called WSDL) are the most famous SOA-based approach (but not the only one). It has been widely adopted lately in IT systems related to the internet. Note that these Web Services have been introduced at a fast pace, solutions being developed and deployed before full stabilization of underlying technology specification. There is still no clear consensus today on what consistent set of specifications should constitute the 'canonical' Web Services definition. An ESB is a software product that provides underlying communication infrastructure for software components. ESBs provide support for contract-based services using direct (synchronous point-to-point) and indirect (asynchronous messaging)
communication paradigms. The "enterprise" in ESB stresses that the product has features like security and transactions and is suitable for use in a large-scale enterprise. ESB features An Enterprise Service Bus offers: Data modelling with XML Schema; Interface modelling with WSDL (Web Service Definition Language); Client and server development tools (code generation from WSDL, libraries, IDE support, etc.); Synchronous point-to-point communication using SOAP/HTTP; Asynchronous messaging using SOAP as a payload over a messaging protocol that supports persistence of messages; Message payload transformation using XSLT. Communication protocol SOAP "wraps" XML messages in an XML wrapper; as a result SOAP messages are self describing. Messages are transmitted as plain text. Payload is transmitted over HTTP or JMS. Let s note that for reliable communications, JMS (Java Messaging Service) is used. JMS is a MOM (Message Oriented Middleware) described in the next section. Relative slowness of Web Service comes in part from the fact that with XML the detailed format of exchanged information can be modified at run-time until data is actually sent. A receiver has to recognize and adapt itself to the dynamic type of all received data. Tradeoff should thus be made between performance of CORBA like solutions and the flexibility of Web Services late-binding of interfaces definition. 5.2 Middleware based on asynchronous communication models The asynchronous communication model is opposite to the previous one. The principle is very simple: the communication between emitter and receiver is carried by messages. The messages can be stored into message queues or communication channels and delivered later to the receiver. In this section, we present two solutions: Message Oriented middleware and Data Distribution Service. Message Queue - Message Oriented middleware MOM (Message Oriented Middleware) is built to work on connectionless environments: there is no requirement to impose that the emitter and the receiver of a message must be up at the same time. We can say that the Internet mail system is a kind of MOM. Applications communicate through message queues (see Figure 4). When an emitter produces a message, it is sent to a message queue. Later, a receiver can pick up the message and perform some processes on it. Message queuing may have several levels of Quality-of-Service: reliable (no packet loss), guaranteed delivery and message delivery one and only once.
Figure 4: Asynchronous communication with message Point-to-point model The point-to-point communication model allows communications between two applications. Messages stored into a queue are extracted by one and only one receiver. However, this model permits to have several emitters generating some messages for the same queue. Generally, this communication mode has a reliable delivery quality of service: an emitter sends a message into a queue, if the receiver is not available due to a failure or a network disconnection, the queue retains the message until the receiver is available again. Figure 5 describes an example of bidirectional communications between two applications (A and B) using two message queues. Figure 5: Point-to-Point communication[3] Publish-subscribe model The publish-subscribe communication model (Figure 6) allows communication between one emitter (publisher) and several receivers (subscribers). The message sent by the emitter is delivered to all the receivers running at this time. If some receivers are not running when a message is sent, they will not receive this message when they will be running later.
MOM and Web Services Figure 6: Publish/Subscribe communication[3] Messaging service in Web Services can be implemented using such MOM. In this case, the transport protocol for the requests is based on JMS (Java Messaging Service) instead of HTTP. Remarks on MOM In MOM architecture, emitters and receivers only know the existence of the queues. They don t know the existence of the other end point. This fact allows the creation of loosely coupled architectures and permits to add new applications without impact on the existing applications. This kind of middleware may be well adapted for event based systems. Message marshalling and unmarshalling, connection/disconnection to the queues must be written by programmers. The low level communicating protocol is not standardized. So two MOM products cannot interoperate together without the development of a dedicated gateway. Deployment applications must be made by hand or using proprietary tools. Data Distribution Service The DDS (Data Distribution Service) is a specification of a publish/subscribe middleware taking into account QoS properties[4]. This specification has been defined by the OMG during 2004. DDS can be used independently from CORBA. DDS General Architecture This new service is suitable for a new class of applications that require real-time Quality of service. The DDS features include: A vendor-neutral API Support for typed interfaces Applications developers deal only with native types on each platform Provide a strict separation of publisher and subscriber roles Optimal efficiency and predictability Minimized dynamic resource allocation
The avoidance of unbounded or hard-to-predict resources Minimize data copying Control of service behaviour through QoS properties Characterize what the system must do, and not how it does it Being a service that is complementary to the existing CORBA services Suitable for use in Real-Time Systems and other applications that need high volume, robust, fault-tolerant data distribution The main idea of the DDS specification is that a Global Data Store is accessible by applications to read and write data (see Figure 7). Figure 7: DDS global data store (from [6]) DDS provides flexibility, power and modular structure by decoupling: Application location through anonymous publish/subscribe Redundancy. A system can have any number of readers and writers Quality of service: asynchronous, disconnected, time sensitive, scalable and reliable data distribution Platform and protocols. Decoupling platform and protocols permits to add more easily existing transport protocols. The DDS specification is composed of two majors parts: The DCPS (Data-Centric Publish-Subscribe) that is the basis of a DDS system (and is mandatory). DCPS contains the lower layer API that applications can use to exchange topic data with other DDS applications. The DLRL (Data Local Reconstruction Layer) that is an optional part of the specification. DLRL is the upper layer API of DDS. It defines how to build a local object cache so that local applications can access topic data as if it were local. DCPS provides an efficient publish/subscribe system Information consumers subscribe to information of interest. Information producers publish information. DDS matches and routes relevant information to interested subscribers. DDS furnishes QoS suitable for real-time systems: deadline, levels of reliability, latency, resource usage, time-based filter. Different programming styles are allowed based on listener or wait-based data access.
The DDS specification solves some problems explained in the section related to MOM on marshalling/unmarshalling and on the lack of high level specification language. Currently, interoperability between various implementations of DDS is not clear. The specification does not define an interoperable transport protocol between different DDS implementations. Some work is currently done at the OMG to solve this problem. 6. Choices and where As conclusion of this work, we selected some technologies to evaluate deeper and chose to develop real prototypes using the following middlewares: On board applications will use real-time CORBA and DDS middlewares. These two middlewares offer functionalities similar to TCN (process data and message data). Contracts are defined using the OMG-IDL language; implementation will be done with C++. We choose the TAO product as the CORBA middleware and OpenDDS [5] as DDS implementation. We also implemented a part of the prototype using a proprietary middleware from Bombardier (IPTCom). This last middleware offers functionalities for both asynchronous communications and process variables. Train to ground applications will communicate through an ESB based on HTTP transport layer. Contracts are defined using the WSDL language. This middleware is the support of the FCA (Flexible Communication Adapter), a key building block of InteGRail system design. Moreover, Web Services and ESB are good candidates for railways subsystems that are not resource constrained like IGR portal or central server for operational control. 7. Current feedback of the integration Several companies involved in this subproject are participating to the integration of software components developed as examples of TCMS applications (brake system, on-board diagnostic,...). The integration of TAO, OpenDDS and IPTCom simultaneously on the same nodes has been achieved. Integration difficulties: We had to juggle between several threading models between the windows GUI and the different middleware communication event loops; Even using the same compiler (VC6) and operating system (XP), integration of the development done by different teams was difficult because of the need to merge compilation and linking options of library models. We are now working on the integration of this train borne system with the web services and ESB tools used to realize the train to ground communication sub system. 8. Conclusion Middlewares allow to solve problems like high scalability of applications, hardware/software heterogeneity, resources location and need to increase interoperability. They reduce deployment time of applications thanks to their capacities to integrate/ distribute application computation amongst a set of servers to increase availability, interoperability and performance. They also reduce development time by reuse of COTS (Components off-the-shelf) developed by third parties. All of this is true if you use one type of middleware. But middlewares introduce a new kind of heterogeneity: the heterogeneity (and then incompatibility) between middlewares themselves. So that two middlewares based on different distribution models cannot interoperate. That s the middleware paradox! InteGRail will have to deal with this problem because one technology will not fit all the requirements.
Several solutions may be studied: Development of specific gateways. This solution implies that a dedicated code able to communicate with several middleware technologies must be written. This code translates requests/messages from one middleware to another one. Applying a MDA (Model Driven Architecture) approach. MDA permits to design applications independently of the target implementation technologies. That is the PIM (Platform Independent Model). Next with tools and transformation rules, this model is mapped to a particular technology. That is the PSM (Platform Specific Model). One PIM can be mapped to several PSMs. If the transformation rules exist for several target technologies, it is possible to generate automatically the transformation code between PSMs. The problem currently is that the MDA approach is still in development and few tools exist to make transformations between different middlewares. Tuned middleware. The idea is to construct a dedicated middleware starting form basic middleware blocks of code. This would avoid to take a monolithic implementation of a middleware that would only be used partially. Acknowledgement This research work is partially funding by the European Commission FP6 framework. References [1] Common Object Request Broker Architecture: Core Specification V3.0.3, OMG, document formal/04-03-01, 2004. [2] Web Services Description Language (WSDL) 1.1, W3C, http://www.w3.org/tr/wsdl, 2001. [3] IBus programming manual, Softwired Inc, 2002. [4] Data Distribution Service V1.0, OMG, document formal/04-12-02, 2004. [5] Object Computing Inc, DDS for TAO, http://ww.ociweb.com, 2006. [6] D.C. Schmidt, J. Parsons, Overview of the OMG Data Distribution Service Author s Biography Christophe GRANSART received the M.S. and Ph.D. degrees in computer science from the University of Lille France in 1991 and 1995, respectively. Since 1991, he is working in the field of distributed systems, mainly with middleware like CORBA. His research interest is on communicating mobile objects: design of middleware solutions dedicated to transportation systems using wireless communications. Since 2002, he is full time researcher at INRETS-LEOST. Christophe.gransart@inrets.fr Jerome BILLION, an Expert in System Architecture for ALSTOM, is the lead architect of the sub-project of InteGRail dedicated to advanced system communication. Before, Jerome was technically managing collaborative research on secure communications for automotive telematics. Jerome s expertise in the field of transport information systems is focused on product line architecture and top-down integration of software intensive distributed systems at the convergence of embedded, telecommunication and Internet-based systems. Jerome.billion-ext@ transport.alstom.com Didier VAN DEN ABEELE is in charge of the Collaborative Projects in ALSTOM Transport Information Solutions. He is also in charge of relationship with Research Centers and Universities. Before, Didier was a Senior Expert in System Architecture, and was managing of a group of multi-domain experts in charge of ALSTOM product lines federation. Up to 2001, Didier was mainly involved in System Engineering applied to Communication systems, to Electronic Warfare system and Naval Combat systems. Didier.van-den-abeele@transport.alstom.com