AB Controls | SL Controls | PS Controls | LHC-CP | ST Controls

Home
News
Architecture
Documents
Minutes
Technology
Industrial
Activities
The team
Development

Middleware Architecture

The Middleware architecture has been explained in the Whitepaper. The original architecture drawing presented in this paper is still valid. The API's and components which will be developed by CMW project until the end of the year are depicted in another architecture drawing with the user written parts in blue, the middleware parts in green and commercial parts in brown. It has to be stressed that the middleware user sees only the public API's: the client API and Device Server Framework API.

The middleware project is promoting three tier architecture - as  shown in both drawings. The resource tier which provides access to equipment is particular in the sense that programming in Front-End computers can be tedious and should be reduced to a minimum. It is the industry trend that the "business logic" is separated from the resource tier and from the GUI tier. In our case the middle tier would implement the operation view or the physics view of the equipment.

When the middleware project was launched it has been asked to support the Object-Oriented paradigm and in particular the Device/Property model. This is a simple model, similar to Java Beans which allows definition of device contracts for both C and Java programs. As the middleware will be based on CORBA and JMS for transport, it will enable using of Object-Oriented communication in other areas of control system.

One of the most important goals of the middleware project was the introduction of the publish/subscribe paradigm. Although this can be be achieved with traditional means (callbacks on top of sockets or CORBA), industry is delivering specialized publish/subscribe systems. These systems offer superior scalability and additional features such as guaranteed delivery. We decided to employ both ORB and MoM technology as shown in the drawings for three-tier and two-tier architecture.

The device server API should allow integration of user-written device servers in the Middleware. This is achieved by providing a Server Adapter Framework which supports both synchronous operations (get/set) as well as publish/subscribe. For subscription two types of devices are supported: Passive Devices which are polled by the Server Framework and Active Devices which can push data spontaneously (e.g. on change) to the Server Framework.