CSP channels for CAN-bus connected embedded control systems

Closed loop control system typically contains multitude of sensors and actuators operated simultaneously. So they are parallel and distributed in its essence. But when mapping this parallelism to software, lot of obstacles concerning multithreading communication and synchronization issues arise. To overcome this problem, the CT kernel/library based on CSP algebra has been developed. This project (TES.5410) is about developing communication extension to the CT library to make it applicable in distributed systems. Since the library is tailored for control systems, properties and requirements of control systems are taken into special consideration. Applicability of existing middleware solutions is examined. A comparison of applicable fieldbus protocols is done in order to determine most suitable ones and CAN fieldbus is chosen to be first fieldbus used. Brief overview of CSP and existing CSP based libraries is given. Middleware architecture is proposed along with few novel ideas

Comparative Analysis of Business Object Approaches

This paper presents a comparison of several technologies for developing distributed applications. The specific technologies into consideration are: one focused on COM/DCOM/COM and Microsoft technologies, Internet Explorer and ActiveX - and the other focused on Netscape, CORBA, JAVA/J2EE solutions.integrated technologies, interoperability, distributed systems, components, distributed architecture

A scalable application server on Beowulf clusters : a thesis presented in partial fulfilment of the requirement for the degree of Master of Information Science at Albany, Auckland, Massey University, New Zealand

Application performance and scalability of a large distributed multi-tiered application is a core requirement for most of today's critical business applications. I have investigated the scalability of a J2EE application server using the standard ECperf benchmark application in the Massey Beowulf Clusters namely the Sisters and the Helix. My testing environment consists of Open Source software: The integrated JBoss-Tomcat as the application server and the web server, along with PostgreSQL as the database. My testing programs were run on the clustered application server, which provide replication of the Enterprise Java Bean (EJB) objects. I have completed various centralized and distributed tests using the JBoss Cluster. I concluded that clustering of the application server and web server will effectively increase the performance of the application running on them given sufficient system resources. The application performance will scale to a point where a bottleneck has occurred in the testing system, the bottleneck could be any resources included in the testing environment: the hardware, software, network and the application that is running. Performance tuning for a large-scale J2EE application is a complicated issue, which is related to the resources available. However, by carefully identifying the performance bottleneck in the system with hardware, software, network, operating system and application configuration. I can improve the performance of the J2EE applications running in a Beowulf Cluster. The software bottleneck can be solved by changing the default settings, on the other hand, hardware bottlenecks are harder unless more investment are made to purchase higher speed and capacity hardware

Using real options to select stable Middleware-induced software architectures

The requirements that force decisions towards building distributed system architectures are usually of a non-functional nature. Scalability, openness, heterogeneity, and fault-tolerance are examples of such non-functional requirements. The current trend is to build distributed systems with middleware, which provide the application developer with primitives for managing the complexity of distribution, system resources, and for realising many of the non-functional requirements. As non-functional requirements evolve, the `coupling' between the middleware and architecture becomes the focal point for understanding the stability of the distributed software system architecture in the face of change. It is hypothesised that the choice of a stable distributed software architecture depends on the choice of the underlying middleware and its flexibility in responding to future changes in non-functional requirements. Drawing on a case study that adequately represents a medium-size component-based distributed architecture, it is reported how a likely future change in scalability could impact the architectural structure of two versions, each induced with a distinct middleware: one with CORBA and the other with J2EE. An option-based model is derived to value the flexibility of the induced-architectures and to guide the selection. The hypothesis is verified to be true for the given change. The paper concludes with some observations that could stimulate future research in the area of relating requirements to software architectures

A Comparative Evaluation of .net Remoting and JAVA RMI

Distributed application technologies such as Micrososoft.NET Remoting, and Java Remote Method Invocation (RMI) have evolved over many years to keep up with the constantly increasing requirements of the enterprise. In the broadest sense, a distributed application is one in which the application processing is divided among two or more machines. Distributed middleware technologies have made significant progress over the last decade. Although Remoting and RMI are the two of most popular contemporary middleware technologies, little literature exists that compares them. In this paper, we study the issues involved in designing a distributed system using Java RMI and Microsoft.NET Remoting. In order to perform the comparisons, we designed a distributed distance learning application in both technologies. In this paper, we show both similarities and differences between these two competing technologies. Remoting and RMI both have similar serialization process and let objects serialization to be customized according to the needs. They both provide support to be able to connect to interface definition language such as Common Object Request Broker Architecture (CORBA). They both contain distributed garbage collection support. Our research shows that programs coded using Remoting execute faster than programs coded using RMI. They both have strong support for security although implemented in different ways. In addition, RMI also has additional security mechanisms provided via security policy files. RMI requires a naming service to be able to locate the server address and connection port. This is a big advantage since the clients do not need to know the server location or port number, RMI registry locates it automatically. On the other hand, Remoting does not require a naming service; it requires that the port to connect must be pre-specified and all services must be well-known. RMI applications can be run on any operating system whereas Remoting targets Windows as the primary platform. We found it was easier to design the distance learning application in Remoting than in RMI. Remoting also provides greater flexibility in regard to configuration by providing support for external configuration files. In conclusion, we recommend that before deciding which application to choose careful considerations should be given to the type of application, platform, and resources available to program the application

Deploying a middleware architecture for next generation mobile systems

Although 2G systems quite adequately cater for voice communications, today demand is for high-speed access to data centric applications and multimedia. Future networks have been designed to provide higher rates for data transmission, but this will be complemented by higher speed access to services via hotspots using secondary wireless interfaces such as Bluetooth or WLAN. With a wide range of applications that may be developed, a growing number of short range wireless interfaces that may be deployed, and with mobile terminals of different capabilities, a means to integrate all these variables in order to facilitate provision of services is desirable. This paper describes an architecture involving the use of middleware that makes software development independent of the specific wireless platfor

Supporting Live Development of SOAP and CORBA Clients

We present middleware for a Client Development Environment that facilitates live development of client applications for SOAP or CORBA servers. We use JPie, a tightly integrated programming environment for live software construction in Java, as the target platform for our design. JPie provides dynamic classes whose signature and implementation can be modified at run time, with changes taking effect immediately upon existing instances of the class. We extend this model to automate addition, mutation, and deletion of dynamic server methods within dynamic clients. Our implementation simplifies distributed application development by masking technical differences between local and remote method invocations. Moreover, the live development model allows server-side changes to be dynamically integrated into a running client to support simultaneous live development of both the client and server