[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Orekit Developers] Is serialization of propagators really useful

Hi all,

From the very beginning of Orekit (back in 2002), some basic priciples have been applied throughout the library. These principles are based on the rationale that the library is a middle level one and can be used in very different context and hence must be as robust as possible. One of these principles is to have immutable objects as much as possible (orbits, dates, transforms, attitudes, all of these are immutable and will stay immutable). Another of these priciples was that all objects should implement Serializable if possible. The rationale for this later principle was that users of the library may need to store reference to Orekit objects in their own classes, and they may need to have these classes serializable (for example to transfer them to a remote server using a message-oriented middleware in a distributed application).

As many Orekit are defined using top level interfaces, the "implements Serializable" declaration was done at the interface level. This is what happens for the Propagator interface or for the AttitudeProvider interface. For now, all propagators at least at the language level are serializable. In fact, this does not work well since about three years for numerical propagator due to a change in Apache Commons Math (see <http://svn.apache.org/viewvc?view=revision&revision=786881>) released with version 2.0 of the library, which implied a corresponding change had to be introduced in Orekit (see <https://www.orekit.org/forge/projects/orekit/repository/revisions/e49df7c6460576f46993558389b10a6b74b11430>). Since this change, when a numerical propagator was serialized and deserialized, the new propagator had no integrator anymore. So the user was required to reset a new integrator using the new setIntegrator method. This was not really satisfying.

We are now facing worse problems as there are more places were objects cannot really be serialized. As an example, force models may require a celestial body such as the Sun, which is provided as a PVCoordinatesProvider, which is not serializable. Even if the providers available in Orekit such as CelestialBody could be serialized, it would be a very bad idea to do so as they can have huge datasets.

There were several (heated) discussions about serialization a while ago in the Apache Commons Math (see <http://markmail.org/thread/26zmab5xo2rr4eap> for the last one). The outcome was that basically serialization must not be a general rule and should be done properly and one a case by case basis. One of the interesting outcome of these discussions is a trick that allows users of a non-serializable class to still use serialization in their top level class as they requires it using proxy objects to replace the non-serializable ones (the use can be because they have a non-serializable field in their class or the extend a non-serializable class). This is used in Apache Commons Math at a few places (see for example PointValuePair, which is a case where the serializable class extends a non-serializable one). We also have started using this trick in Orekit as well (see for example the DataTransferObject inner class in the InterpolatingTransformProvider class in the frames package).

So our basic principle about serialization is difficult to manage, and thanks to the proxy objects trick it is in fact not really needed anymore. I would propose to follow Apache Commons Math policy and limit our use of Serializable to some basic classes where it makes sense (typically data containers like orbit, attitude, date, transforms, body shapes, geodetic point ...) and remove it for complex cases like Propagator or AttitudeProvider.

What do you think about this change?

best regards,

This message was sent using IMP, the Internet Messaging Program.