[Orekit Developers] Is serialization of propagators really useful

[MAISONOBE Luc <luc.maisonobe@c-s.fr>]

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,
Luc

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