Subject: Minutes of the Middleware Project Meeting Date: Mon, 25 Jan 1999 13:34:24 +0100 From: Vito BAGGIOLINI Organization: CERN To: Andy Butterworth , Etienne Carlier , Pierre Charrue , Jan Cuperus , Jean-Jacques Gras , Quentin King , Julian Lewis , Pierre Ninin , Pedro Ribeiro , Peter Sollander , Pierre Strubin , Mark Tyrrell , Arend Dinius , Mike Clayton , Frederic Momal , Claude-Henri Sicard CC: Kris Kostro , Franck Di Maio , Marc Vanden Eynden , Alessandro Risso Hello, enclosed please find the minutes of the middleware meeting of Jan 15. It takes into account the remarks I have received from some of you regarding their "Tour de Table" statement. Feel free to send me questions or further remarks... Best regards, Vito Baggiolini ------------------------------------------------------------- Dr. Vito A. Baggiolini, SPS+LEP Controls Group, CERN 1211 Geneva 23, Switzerland Tel. +41/22/767.34.01 Vito.Baggiolini@cern.ch http://venice.cern.ch/~vbaggiol --------------------------------------------------------------------- Minutes of the Middleware Project Meeting Jan 15 1999 Present: All members of the core team; Andy Butterworth SL/RF, Etienne Carlier SL/BT, Mike Clayton SL/CO, Pierre Charrue SL/CO, Philipp Cregeen SL/CO, Jan Cuperus PS/CO, Arend Dinius SL/PO, Jean-Jacques Gras SL/BI, Quentin King SL/PO, Julian Lewis PS/CO, Pierre Ninin ST/MO, Pedro Ribeiro SL/CO, Peter Sollander ST/MO, Pierre Strubin LHC/VAC, Mark Tyrrell SL/CO. Goal of this meeting o Present the middleware project and its background to the potential members of the client and soft team. o Receive first feedback from the audience, and answer questions. o Obtain a first statement about people who want to participate in the project. 1. Presentation by Kris Kostro Kris first recalled the background of the Middleware (MW) project (PS/SL Convergence, SPS-2001). Then, he introduced the JavaAPI and the Device Model, and gave an overview over candidate MW solutions. Finally, he briefly presented the "Goal Directed Project Management" method that shall be used for this project. The slides of the presentation will be soon available on the Web. 2. Feedback from the Audience This section is presented in a Q&A fashion. The questions were asked by the audience, the answers partly came from the MW core team, partly from the audience. We reorganized questions to their subject. This is the basis for the MW FAQ that will be extended in future. Device Model & JavaAPI + Q: In which machines is the device abstraction layer located? + A: Anywhere: Front-ends, ROCS, HP's. + Q: Are you going to use the same device model in PS and SL? Shall there be a common implementation also "below" the MW? + A: The device model shall be the same, but the class hierarchy that represents the devices and its implementation shall be different between PS and SL. + Q: What do you provide in addition to the MW? + A: On the client side the JavaAPI will be implemented on top of the MW; on the server side, we will provide support to the equipment groups for facilitating server integration. + Q: What kind of software shall run on top of the JavaAPI? + A: Any new program should access the equipment and the control system through the new JavaAPI. Old systems will of course continue to be supported by SL_Equip. Performance + Q: Are you sure that a MW solution will provide the necessary performance? + A: We need performance requirements from the users. Anyway, the new system is expected to have at least the performance of the present SL_Equip solution. The publish-subscribe facility of the new system is expected to further enhance performance. Performance shall be practically validated through the implementation of prototypes. CORBA + Q: Is CORBA stable? Is the market ready? Is there a risk that CORBA is going to disappear or become a dead end in 15 years time? + A: It is difficult to predict 15 years. But it is unlikely that CORBA disappears, since it is supported by a consortium of 800 firms, and founded 1989. In any case, in PS/SL there is an important move towards object-oriented techniques which has to be supported by suitable MW. + Q: Are the different implementations of CORBA compatible? And what about interoperability with COM/DCOM? + A: CORBA version 2 claims to be compatible, and there is support for DCOM. However, that has to be verified. Java + Q: Does Java have a fundamental role in the MW project? Isn't there a risk that it fractions? What about it's performance? + A: Java is an important language, but this project is not restricted to Java. Languages can be changed relatively easily; what is important is that we have a stable (device) model on which all agree. Naming and addressing databases + Q: How do databases fit into that? Where is the low-level information about addressing, etc. stored? + A: Addressing should be transparent to the client (JavaAPI) side, so that low-level equipment can be exchanged without the clients noticing. However, the technical realization of this issue has to be further studied. It must be investigated how the general databases and database services provided by MW solutions (e.g. naming and trading) can be used for that purpose. Industrial systems + Q: What about industrial systems? + A: The communication with industrial systems (String 2) is part of this project. OLE for process control (OPC) is being studied in the JCOP project. Their results shall be integrated with our work. Migration + Q: What about migration? + A: Migration is an important issue, which has to be addressed during the project. One of the effects of this is that for a certain time a dual infrastructure has to be in place. It has to be investigated how this additional load affects the front-ends. + Q: What percentage of software has to be rewritten? + A: The new API's only concern new software. MW does not address rewriting of applications. However, CORBA made for integration of legacy, which should allow for a gradual migration. Organizational Issues + Q: How does this integrate with other MW activities at CERN, namely the LHC Systems Data Interchange WG (LDIWG)? + A: The LDIWG studies the inter-data exchange between accelerators, experiments and services. It will identify what data has to be exchanged, its direction and frequency, etc. The MW project provides mechanisms for data exchange and control within the accelerator control system. We shall collaborate with them in order to coordinate our activities. A member of the MW core team is also a member of the LDIWG, thus acting as a link person. + Q: It seems that this working group makes technology choices before having requirements… + A: JavaAPI already defines an important number of requirements. But we continue to gather requirements and users are encouraged to contribute. We have to get acquainted with commercial MW solutions that are around. At a certain point, an unbiased match will be made between requirements and available MW solutions. 3. Tour de table Every person present was asked how they saw their role in the MW project: whether they wanted to participate in the definition of the project strategy, the gathering of requirements and in implementation. Which (if any) of the three project teams (core, soft, client) they wanted to join. Andy Would like to participate in strategy and Butterworth requirements, as a member of the client team. However, as he still works in LEP, he must either get a mandate or motivate his colleagues to participate in the MW project. Etienne Joins the client team, wants to ensure Carlier compatibility of the MW with the part of the system he is responsible for (Kickers SPS/LHC). Does not participate in strategy definition. Pierre Is the project leader of SPS-2001, and Charrue participates in the client team. Mike Clayton Would like to participate in the application of the middleware project to the SPS Experimental Areas, but will not be able to do this until after the startup. Jan Cuperus As a member of the Java API project, he wants to follow closely the work done in the MW WG, and actively participate in the implementation of the JavaAPI generic layer on top of the MW. Jean-Jacques Wants to actively participate in project Gras strategy, BI requirements gathering, and also in testbedding on a BI instrument. Joins the client team. Quentin King Contributes a paper from which requirements can be derived. Does not participate in strategy definition. Would like to participate in checkpoints to make sure that MW is compatible with his work. Julian Lewis Wants to participate in strategy and requirements gathering, especially for the event distribution and change/subscription work. Is already strongly involved with convergence, where he participates in the timing WG. Pierre Ninin Wants to make sure that the new MW integrates well with their current system. Participates in strategy and in requirements gathering for this integration part. Pedro As a responsible of the FE section, he wants to Ribeiro make sure that the MW is compatible with the front ends. Participation in the soft team. Peter Sees himself as a link person with ST/MO, to Sollander ensure compatibility with their systems. Pierre Is interested in the outcome of the project Strubin rather than in actively participating in it. Sees himself as an end user. Mark Tyrrell Is interested in a middleware facility to 'publish' & 'subscribe' alarm information at the 'atomic' & 'abstraction' level. Participates in: definition of project strategy; input to requirements; implementation & testing. Joins the 'soft' & 'client' teams. 4. Actions The core team has to prepare a working meeting in which the milestone and activity plans shall be established together with the members of client team and soft team. Vito Baggiolini SL/CO