Benefits of multi-model architecture-based development for railway applications

Transcription

1 Benefits of multi-model architecture-based development for railway applications Aurelien Bocquet, Christophe Gransart INRETS-LEOST, Villeneuve d Ascq, France Abstract Software design is now a main part of railway research. To ensure sufficient usability and efficiency, software becomes more and more complex to design and implement; new railway applications must answer to requirements like system interoperability, heterogeneity management. To achieve these goals, software designers may use middlewares. In this paper, we will present different existing types of middlewares, and the benefits of using a multi-model architecture-based development to improve the efficiency and safety of railway applications. We will thus present our multi-model architecture, supplying a generic programming model and a combination of communication models. Introduction Current railway related research fields aim at providing more safety, efficiency and services to existing transportation systems. But more and more of projects in these fields have to use software components in order to supply complex and efficient functionalities. And if a single component may supplies some interesting services, several interoperable components supply more constructed and complex processing; that is the reason why railway research must design and use communicating software components. The main problem is to find the best way to make components communicate. Actually, many communication systems exist, from basic inter-process communication [1] to complete designintegrated communication middleware like CORBA [2], and designers have to choose the best system, considering the communication behavior they designed their components with, and the kind of context they will be deployed in. In this paper, we will first expose the specific problems related to designing and deploying railway applications. Second, we will describe the main existing middlewares currently used to make components communicate. Then we will present our multi-model approach, based on these previous problems and means. To validate this approach, we designed a multi-model system to prove the interest of our works on a real problem related to railway services. Our multi-model software infrastructure is a complete application and implementation of this approach. We will thus present and detail it. The current state of our work and first evaluations we made on it will follow, and we will present related works to position ourselves in the research field. Then, we will finally conclude on this subject. Railway applications related problems Railway context needs software applications, which are able to communicate without suffering of problems on the communication link. Indeed, the reliability and quality of this link cannot be established once for all. For railway applications, the communication link can be either GPRS, GSM-R, UMTS, WiMAX, or Satellite, but in every case, the quality and the availability of the signal may vary : gap between access points or antennas coverage, ability to switch lossless while handovers occur, reliefs or tunnels, and so So on one hand, railway applications design needs a communication system able to dynamically adapt to context variations and changes, handling disconnections and change of signal quality. On the other hand, it needs enough efficiency to fill requirements of railway

2 applications, such as synchronicity between embedded components, and it has to be able to adapt to the heterogeneousness of the various used components. Existing communication middlewares Several middlewares currently provide turnkey solutions to make software components communicate. However, as we will see, none of them is able to fulfill the railway applications requirements. Communication middlewares can be separated in two main categories: synchronous and asynchronous ones. The synchronous middlewares are able to be deeply integrated into the design of applications. Indeed, they provide a powerful programming model, based on Remote Procedure Calls like RMI does [3]. This programming model is almost transparent to the designers, who call remote procedures like local ones. These designers just have to specify if the object is distant or not when they instantiate it, and it must inherit from a special middleware-defined class, in order to be able to adopt a remote behavior. CORBA is one of the most used synchronous communication middleware, because of its ability to be deployed on heterogeneous components, coded in different languages (currently C, C++, Ada, Java, and several other languages are implemented and compatibles in CORBA) on different platforms. It presents a programming model based on inheritance and centralized on an Object Request Broker. The description of remote objects is done in separated description files, in a platform-independent language (IDL), in order to be handled and understood on every execution platform. RMI is another synchronous communication middleware, based on the same principle, except that the description of remote objects is directly done inside the Java code, which simplifies the work of designers, but makes the portability on other languages more difficult. The asynchronous middlewares cannot be as deeply design-integrated as asynchronous ones, because their programming model is not as complete. But if designers must work harder to integrate these middlewares into their design, they however provide more flexible and processindependent communications. Indeed, where synchronous middlewares make components wait for each other during a communication, asynchronous ones allow every component to go its own way, and to communicate independently from the others. JMS [4] is one of the most widely used asynchronous communication middlewares. This Java Message Service presents a basic programming model (middleware-specific classes and procedures), making designers able to establish communications between components following two schemes: - The Publish/Subscribe scheme consists in a system of topics, in which publishers can put messages, and then components, which subscribed to them, get these messages. This kind of communication introduces a new possibility for a component to send to a group of components, which do not know each other. - The Message Queuing scheme consists in a system of queues, in which components can put and get messages. JavaSpaces [5] is a more exotic communication middleware, based on a principle of shared space. In this virtual global space, every component can put and get objects, to create, modify, or remove them. This system can be seen as a sort of improved database. Each type of communication middleware also supplies a naming service, i.e. a way to assign a symbolic name to every component, in order to provide a simple system for contacting remote components. Thus, an object or a message queue can be found by looking for its name in the middleware s naming service. If asynchronous middlewares seem to be more reliable and useful, they however don t provide as much efficiency and speed as synchronous ones. This is essentially due to the use of an intermediate server, charged to bufferize the exchanged messages and data.

3 Synchronous middlewares thus provide faster communications, but cannot ensure as safe data delivery as asynchronous ones. Multi-model approach Noting that no current middleware is able to provide fast and reliable communications between heterogeneous components, and that railway applications need adaptation and reliability, we present our multi-model approach. Even if RPC is the fastest and easiest way to make components communicate, they may need to asynchronously send or receive data (e.g. if they cannot afford to wait for a blocking procedure call). Designers, as well, may want to use asynchronous ways to communicate if their design needs it. Clearly, no programming model is well-suitable for every situation of design. Synchronous communication models (e.g. RMI) provide quick and dependent communications, able to hardly couple components on a reliable network, but they need the components to be accessible and available at the same time, and the network to be enough efficient not to slow down the exchange of data. Oppositely, asynchronous models provide a safe communication system in any context, but because of their use of intermediate servers, they cannot ensure as fast and direct communications as synchronous ones. Application Multi-model programming Communication model 1 Communication model 2 TCP IP MAC PHY Figure 1 OSI scheme including the multi-model approach. We thus propose an approach based on a combination of the existing programming and communication models (as schematized on Figure 1), consisting in a complete and well-suitable generic middleware, able to adopt every kind of behaviour: - Its generic programming model provide quick and powerful tools to make components synchronously and asynchronously communicate, via RPC, Message Queues, Topics or Shared Spaces. This allows designers not to choose only one model, making them able to change the kind of communications they use, everytime they need.

4 - Its generic communication model consists in a combination of the existing models, choosing the most appropriate model, considering the current context and the needs of the application. Basically, it allows to use asynchronous communication models when synchronous ones fail, but it also enables heterogeneous components, with different available models, to communicate via their common models (these points will be explained later on). As we will present in the Related Work section, this approach tends to be the most preferred one in order to obtain a context-aware design of communicating applications. Validation of the approach Figure 2 Schematic overview of the Internet access in trains. To prove the real interest of our multi-model approach, we applied it to a current technical challenge in railway transport applications: providing reliable Internet access to customers in trains (as shown on Figure 2). Indeed, based on a satellite communication link, trains cannot guaranty a continuous connection from end to end, all over the railway network (as we explained in the Railway applications related problems section); however customers do not want their Internet session to be disconnected at every tunnel (as it will actually be in a usual system). Figure 3 Previous schema with multi-model add-on. To be able to reuse current existing web proxy, we designed a multi-model add-on [6], able to be grafted on any already existing Java web proxy. Actually, rather than modifying the web proxy in order to adopt the multi-model behavior, we preferred to modify the Java Virtual

5 Machine itself, allowing any communicating application to adopt this behavior, without redesign it. This add-on has been designed in order to use a standard Socket-based communication when direct connection between the train and the infrastructure can be established, and an asynchronous communication (using JORAM [JRM], an implementation of JMS) when disconnections occurs (as we can see on Figure 3). To diagnose the reliability of the connection, a ping-pong process periodically tries to send and receive data between the train and the infrastructure, and switches to asynchronous communication when it fails. Moreover, to be more reactive, a direct diagnostic is also included in the standard Socket system, to immediately switch to asynchronous communication when an operation fails. Our multi-model software infrastructure Once this validation work designed, we defined a whole multi-model software infrastructure, in order to provide a complete solution to designers composed of a programming model and a communication model, as our multi-model approach propose it. This infrastructure composed of several parts, as shown on Figure 4. LocalObject Method1 Method2 AnnotatedObject AnnotatedMethod2 Mechanisms of combination of communication models (Manager) CORBA JMS Web Services JavaSpaces Programming model Models combination Communication models Observer 1 Observer 2 Context observers Figure 4 Global overview of the multi-model software infrastructure. The programming model provides an ensemble of annotations [8] to describe the distribution of the application. The choice of annotations has been done for several reasons: mainly, they are sufficiently integrated into the Java programming language not to force designers to learn a new language, and sufficiently distinct from the code of the applications itself to allow a great differentiation between business and repartition code. When we started these works, no other middleware used annotations, but currently an annotation support for Web Services in Java exists [9], consolidating us in our opinion. An example of use of our programming model is illustrated on Figure 5. An alternative programming model is provided, to allow designers to make components behave a more specific way: dedicated objects and methods give more control on communication between components, as some current middlewares already provide (e.g. CORBA).

6 public class name = "*server*" ; location = null ; ) private Server myserver ; public Client() /* Nothing to do here */ /* Automatic resolve type = "RPC" ; ) public class name = server_001 ; registered = true ; ) public static Server = new Server() ; public Server() /* Initialisation stuffs */ public void dosomething() /* implicit remote call */ myserver.dosomething() public void dosomething() /* do something */ Gray and italic = optionnal parameters, default values Figure 5 Basic use of the annotation-based programming model. Adaptation policies have also to be defined by designers (or deployment architect) in an XML file, describing what communication model(s) has to be used considering the current context. This reference to the context can be done grateful to context observers, which inform the infrastructure of any change. Basically, it observes communication systems, e.g. the communication models themselves, the physical communication layer, the IP error diagnostic, and so But designers may also define their own observers, to answer their special needs. Adaptation policy Context information Manager Choice of model Inter-manager communication Figure 6 Overview of the inputs and outputs of the central manager. These adaptation policies and context observers are useful to the Manager to select to best communication model(s) to deliver data, as illustrated on Figure 6. This manager catches remote calls from the programming model, and sends corresponding data via the chosen communication model(s) to the remote object. The manager on the remote object catches those data and executes the procedure call (or data delivery, depending on the kind of programming model the designer used). The resulting data are sent back to the first component, via chosen communication model(s), which may be different from the first one(s). An inter-manager communication also takes place, to make managers able to match their behavior, by optionally combining their adaptation policies, or at least consider only their communication models in common. This communication uses the same models combination as the programming model; managers are thus shown as standard remote objects to each other.

7 CORBA Reference CORBA Naming Server component JMS Reference JMS Naming Model Y Reference Y Naming Client component CORBA Model Y Figure 7 Example of use of the combined naming service. An important part of this multi-model software infrastructure is the naming system. Indeed, every middleware owns its naming system, so it would have been useless to design our own one. To enable our system to include the reference to remote objects via every communication model, we concatenate every reference to the standard one of the models, as explained on Figure 7. Evaluation of the multi-model proxy and main state of work The validation work, i.e. the multi-model add-on for the web proxy, has been defined and implemented, and is fully functional. Its evaluation is running and precise results will be available soon. We can however right now expose the first noticed results. Indeed, this system clearly cannot match a simple Socket system s performances, simply due to the use of an asynchronous communication model, which is using an intermediate server to bufferize data during disconnections. But if our multi-model add-on is 10 to 20% slower than direct Socket connection, it makes the whole architecture able to handle disconnections and network congestions, which adds a non negligible reliability to the system. Worst results also show a 1000% ratio between Socket communications and our add-on while forcing the use of the asynchronous communication model. But this case only occurs when disconnections appears, so our system is slower, but a standard Socket system would just disconnect and throw errors to both web servers and clients. Our multi-model software infrastructure is currently under implementation. Some steps have been defined in order to result in a full infrastructure. Among these steps, a first functional infrastructure proposes an offline multi-model version, i.e. annotations and adaptation policies are evaluated while compiling the application, and the resulting executable package adopts the described multi-model behavior. This first infrastructure provides multi-model functionalities and context-adaptation, but it is not the final purpose of our works. The final version of our multi-model software infrastructure is able to evaluate distribution annotations at loadtime, by the use of a Java Agent, which supervises the Java class loader. This technique brings several benefits, including the ability to add a multi-model behavior in a class which is loaded during runtime (e.g. an on-the-fly downloaded OSGi package). Moreover, the manager of this version evaluates the adaptation policies at runtime, and re-evaluates them every time they change, which enables auto-reconfiguration of any multi-model infrastructure, or global reconfiguration of a whole distributed network (online deployment reconfiguration). These two versions will coexist; the first version being more efficient in terms of load time and execution time, it is more dedicated to embedded platforms and real-time executions. JMS Reference

8 Related work Based on the same state that one single middleware cannot answer every context s needs, some projects aim at combining several communication paradigms, to be able to adapt their behavior to the changes of design or deployment context. V. Budau and G. Bernard from the INT, Evry [10] propose a system, which changes the communication model when it becomes necessary. When a Remote Procedure Call (RPC, in this case RMI) thus fails because of a network problem, the procedure call is packed in a message, which is delivered via an asynchronous model (JMS). The answer of this invocation follows the opposite way, i.e. goes via a JMS message then comes back to the requesting object, as if it was a directly received answer. The opposite behavior is also possible, indeed when it can be, a JMS message goes via a Remote Procedure Call to save the cost of a JMS communication, which would have to go through an intermediary server. If this middleware allows to use multiples programming and communication models, it presents some limitations. Indeed, if a call is initially done via JMS, the answer will necessarily be sent back via the same model, which prevents fine optimizations, and the opposite is also true, if the RPC is done via RMI, the answer will be sent via RMI, and then if an error occurs, no information will be available about the state of the requested operation. P. Grace and G. S. Blair from the Computing department of Lancaster University [11] propose a programming model, which is based on Web Services, called ReMMoC. It is thus based on the WSDL Description Language, which enables this middleware to discover services supplied by servers using different communication models, and to use them. When an application needs to know what services are available, ReMMoC ask the different discovering models (upnp, SLP) and then returns the different available services in WSDL. This representation of the services and of their invocation allows the create on-the-fly the corresponding request, either in RMI, or in CORBA, or in any other communication model. Based on OpenCOM, ReMMoC is a reflexive middleware, i.e. it is able to introspect its behavior in order to modify it. In this case, it modifies the way to translate the WSDL description into the chosen communication model when needed. If this middleware enables to communicate with heterogeneous components, it however does not allow to dynamically switch the communication model according to the network capabilities. Moreover, the internal communication paradigm (the Web Services) forces the way of designing the application, which prevents from using other paradigms (like direct-rpc, message queuing and so on). T. Vergnaud et al. from the ENST, Paris [12] present a complete infrastructure called PolyORB, including a programming model, which can be either CORBA or DSA, and using existing communication models, like CORBA, JMS, SOAP. On the one hand, this infrastructure allows to choose the programming model to use, and on the other hand it allows to choose the model(s) which ensure the communication. The choice of these personalities is done at the startup of the application, which enables it to talk its whole running time with applications that natively use these communication models, or with others multiple-personalities applications. This middleware illustrates quite well the power of the multi-model approach : multiple programming models, using multiple communication models. But, like ReMMoC, the communication-model-combination cannot handle the change of network capabilities, which removes a part of the benefits of a multi-model approach as we conceive it. The other defect of PolyORB is that its dynamic properties of reconfiguration are not that dynamic, indeed the choice of the communication model(s) to be used is done at startup. Service Component Architecture [13] proposes to completely separate the effective code development and deployment. Several programming languages are possible, Java, C++, PHP, COBOL, SQL, and several programming models, synchronous and asynchronous by RPC, asynchronous by messages queues, and also several communication models, Web Services (via SOAP) and CORBA (via GIOP).

9 The aspect of programming model and integration into the programming language is much more thorough here than in the other projects, because of the investment of big development companies like IBM, RedHat, Siemens, or Sun Microsystems. If programming is the main asset of this project, communication isn t as well. Indeed, if the specifications of SCA present a large diversity of possible communication models, only Web Services and CORBA are exploitable. The asynchronous aspect which is present in the programming model cannot be fully used yet. Conclusion We presented in this paper our multi-model approach, and how railway applications design may be improved using it. Until now, software design was static, the choice of the programming model and the communication model was done once for all; but the needs of distributed software components may change, as well as the conditions in which they are executed, especially for railway applications. Our approach introduces an efficient way to combine several kinds of programming models, and communication models, to enable designers to use the best communication paradigm according to the current context, anytime it changes. To validate our approach, we designed a multi-model add-on, able to be grafted on any Java application. We thus grafted it on a web proxy, to ensure safe and reliable Internet connection in trains; this add-on diagnoses the state of the connection, and switch to an asynchronous communication model when disconnections or congestions occur. Based on this approach, we presented our multi-model software infrastructure, composed by a generic programming model based on Java annotations, a combination of communication models, and a central manager, charged to evaluate the adaptation policies considering the current context, to choose one or several adapted communication models. If multi-model middlewares begin to emerge, until now they don t provide both programming and communication models with as improved dynamic adaptation functionalities as our software infrastructure, which seems to be a good answer to adaptation needs of railway applications. Acknowledgements These research works have been made in the context a PhD thesis tutored by the LIFL (Lille University, France) and the INRETS-LEOST (The French National Institute for Transport and Safety Research, Electronic, Waves and Signal Processing Research Laboratory for Transport, Lille, France), and financed by the INRETS and the Region Nord-Pas de Calais. They are also part of a national project called REVE (for safe Reuse of Embedded components in heterogeneous environments), financed by the French National Agency for Research (ANR). The validation part of these works has been done in cooperation with Train-IPSat, a PREDIT project (Research and Innovation Program for Terrestrial Transports). References [1] J. S. Gray. Interprocess Communications in Linux, Prentice Hall, (2003). [2] J. M. Geib, C. Gransart, P. Merle. CORBA: des concepts à la pratique, Dunod, (1999). [3] Sun Microsystems. RMI, java Remote Method Invocation, (2003). [4] Sun Microsystems. JMS, Java Message Service, (2002). [5] E. Freeman, S. Hupfer, K. Arnold. JavaSpaces Principles, Patterns, and Practice, Pearson Education, (1999). [6] A. Bocquet, C. Gransart. Communication everywhere: Internet proxy adapted to satellite communication defects for railway transport application, Intelligent Transport Systems and Services, (2007). [7] R. Balter. JORAM: Java open Reliable Asynchronous Messaging, (2004). [8] Sun Microsystems. Annotations in Java 5, (2005).

10 [9] BEA Systems, Borland, IONA Technology, Sun Microsystems. JSR 181: Web Services Metadata for the Java Platform, (2005). [10] V. Budau, G. Bernard. Auto-adaptation to communication environment through dynamic change of communication model, Distributed Computing Systems Workshops, Proceedings, pp , (2003). [11] P. Grace, G. S. Blair. ReMMoC: A Reflective Middleware to Support Mobile Client Interoperability, International Symposium on Distributed Objects and Applications, (2003). [12] T. Vergnaud, J. Hugues, L. Pautet, F. Kordon. PolyORB: A Schizophrenic Middleware to Build Versatile Reliable Distributed Applications, Ada-Europe, (2004). [13] Open Service Oriented Architecture. SCA: Service Component Architecture, (2007). Author s biography Aurelien BOCQUET received the M.S. degree in 2005 and is currently a Ph.D. student at the University of Lille France since Studying in the field of distributed systems and multimedia, he is working on his Ph.D. thesis at INRETS-LEOST, tutored by C. Gransart. Contact : aurelien.bocquet@inrets.fr 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 1999, 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. Contact : christophe.gransart@inrets.fr