This website is no longer maintained. Its content may be obsolete. Please visit http://home.cern for current CERN information.
Very good comments Niall and a very good insight into what one can do with Corba. I basically agree with all you are saying. No plans to join the CMW project?;-)
Some additional points on why CORBA and why this kind of API and implementation. Some of this has been saind before but maybe hidden in various papers
. - We wanted (have been asked) to create an OO communication infrastructure. CORBA is the only product which allows this given the required language and platform mix. We will install and support CORBA and the device/property model and DB access. Other uses can follow but I am against proliferation: it is not a tool to put in the hands of a person which primary concern is electronics or accelerator operation. Yes, CORBA is a hairy beast but you will not have to touch it.
- The device/property model (narrow API) is a strong reduction of what you can do with CORBA. On the other hand it is similar to what we have been doing for years. You have to look on the standards which we have or which people are creating: they are very similar: SL-Equip, Bicsoto device access, PS equipment modules, OPC (Microsoft). Compared to SL-Equip it is much cleaner and much more typesafe (runtime not compile-time). We have just improved existing ways of making device access, made an OO API and added subscription. It is a deliberate compromise. It provides structure and the required functionality + enaugh of checking and remains very simple to use. Having said this I will add that if I would make an API just for me it would never look like this.
- Using CORBA for Quentin's power converters looks like an overkill. But have a closer look on this argumentation: I designed my controllers such that I can talk to them through a teletype, hence I should not use CORBA. This is the argumentation the wrong way: Using strings is unefficient as everybody knows - at the source there are floats and bits. But this is not a problem for me. The advantages of having a common communication infrastructure goes far beyond the question whether we should convert strings to floats on the client or on the server side.
- Last point is on the hypothetical Alarms API which you mention. I believe there should be one. But I hope the code sequence which you shown is not something an avarage user has to write. You will have to wrap it and provide a simple and implementation. I am not saying that it does not have sense to define it as an IDL. When Corba is there anybody can use it. But I would also consider using the device/property model as well - not because of it's beauty but because it already solved many problems which you may have to solve like handling of disconnections or the problem of alarm avalanche. The data typing by the way is far from being as ugly as you proposed - your Message object can be typed safely as Data object (runtime checked but you would provide a wrapper anyway). And since you making this API and you can extend your data object, backward compatibility can be easily ensured.
I could go forever on this but my time is limited ...