WRITING TINE SERVERS IN JAVA

Abstract The TINE Control System [1] is used to some degree in all accelerator facilities at DESY (Hamburg and Zeuthen) and plays a major role in HERA. It supports a wide variety of platforms, which enables engineers and machine physicists as well as professional programmers to develop and integrate front-end server software into the control system using the operating system and platform of their choice. User applications have largely been written for Windows platforms (often in Visual Basic). In the next generation of accelerators at DESY (PETRA III and VUV-FEL), it is planned to write the TINE userapplications primarily in Java. Java control applications have indeed enjoyed widespread acceptance within the controls community. The next step is then to offer Java as a platform for front-end servers. In this paper we present the TINE Java server API and first results using TINE Java servers. In particular we shall discuss the pros and cons of using Java as a platform for front-end and middle-layer servers and present timing results concerning Java servers using native Java, Java plus JNI, and native TINE servers. The TINE Control System is a distributed, objectbased system which runs on most platforms (legacy as well as modern) offers numerous services (both central and distributed) and enjoys a widespread use in the accelerator facilities at DESY. The TINE protocol offers high performance under extreme circumstances, such as transmitting large video frames at many hertz to multiple clients via multicast. Historically, no matter what platform or what language is being used for TINE clients or servers, the core TINE kernel has been written in C. Thus clients and server using say Visual Basic in WINDOWS make use of ActiveX controls (or VBX controls) or direct DLL calls which themselves call into the TINE kernel. Likewise, clients or servers written in LabView make use of VIs which interface to either TINE DLLs or shared TINE libraries, and so on. The Java TINE client API on the other hand interfaces to tine.jar, which is written entirely in Java. Certain aspects of the TINE C kernel were ported to Java, but to a larger extent, the TINE kernel was simply rewritten in Java, taking full advantage of the Java language where possible. All efforts were made to maintain as many similarities in the basic TINE API as possible. This does not mean that they are identical. Calls such as "AttachLink()" and "ExecLink()" are represented by the methods "attach()" and "execute()" of the representative TLink Object. Note that the TINE protocol does not deal so much with 'puts' and 'gets' as with data 'links'. One's first inclination when offering Java in the Control System's portfolio is to say that we don't need to worry about a Java Server API since front-end servers will always have to access their hardware and that is best left to code written in C. Furthermore, if there are realtime requirements, Java would not be an acceptable platform owing to Java's garbage collection kicking in at indeterminate intervals. Nevertheless, Java is a powerful language and offers numerous features and a wonderful framework for avoiding and catching nagging program errors. Thus there does in fact exist a strong desire to develop control system servers using Java. If these are to be middle layer servers, which manage and interpret data from front end servers, then the hardware issue is moot. Even front end servers can be written in Java when the hardware IO is made available by other means, such as a JNI or a CNI interface to the C libraries which do the 'dirty work'. It still remains to clarify whether issues of performance or garbage collection preclude writing effective servers in Java. A first effort has now been made to include the TINE server API within the tine.jar Java archive, so that we can make the initial performance tests. We shall report on these below. The current Java TINE server prototype offers approximately 75 percent of the functionality of a standard TINE server. Missing are such subsystems as the local alarm system and the local history system. Furthermore the current prototype does not offer initialization via a configuration database. For our purposes at this juncture however, these are trivial points. The server developer will not deal directly with these aspects in any case. The fundamental server management kernel and API are available, and it is primarily these which we present here. We first compare several Java Virtual Machines (JVMs) with regard to fairly general concerns, not specifically related to a TINE server. Then we shall turn our attention to the performance of our TINE server prototype. collection might have on our test server application by having a look at the repetitive instantiation of objects. By instantiating objects in a tight loop we notice that there are occasional delays on the order of 10 to 100 milliseconds, depending on the Java Virtual Machin