[Insight-developers] ITKv4 / ITK Factories and CppMicroServices library

[Matt McCormick]

Hi Jc, Sascha, Nolden,

Thank you very much for the link and discussion!  Very interesting!
The library appears to solve many issues we have been struggling with
or need to solve.

The fact that it is small, C++, Apache 2.0 licensed, compact, tightly
focused, feature-rich, and well vetted are all pluses.

I would be interested to get your opinion on the following issues:

1) Could we maintain a backwards compatible API with the ObjectFactory?

2) Would we *need* to use shared libraries?  Could be maybe use some
CMake magic instead/as an alternative?  Maybe it would be an option
for packages like Slicer to use the shared libraries.  As it stands,
ITK can be built with all static libraries, which is a feature would
want to keep (nice for clusters, etc).   Also, the only Module on
Windows that is built as a shared library is ITKCommon.  I am not sure
how feasible it is to get all the IO modules to be shared....

I will add it to the agenda for the Montreal, Hackathon tomorrow.

  https://docs.google.com/document/d/1i2ibaZMS_vxzLocGVeElz6t5DVF7CWHfyFrB2WldF1c/edit#heading=h.r7h4uqn8p8ld

I am also CC'ing the itk-developers mailing list.  There are many
smarter people than myself that may have more ideas on this ;-).

Thanks,
Matt

On Mon, Dec 17, 2012 at 6:22 PM, Jean-Christophe Fillion-Robin
<jchris.fillionr at kitware.com> wrote:
> Hi Matt,
>
> Attending the CTK Hackfest in Bologna, I discussed with MITK folks about
> their experience with the ITK (IO) Factories. While the system in place gets
> the job done, they shared with me some of their concerns and helped me
> redacting the following text:
>
> Registering new overrides involves quite a lot of boilerplate code (the
> object plus a factory) and the usage is non-intuitive for beginners (this
> could be improved by more detailed Doxygen documentation for the
> ObjectFactoryBase::RegisterOverride method and a code example.
> The handling and prioritisation of multiple overrides for the same class
> type is difficult. ITKv4 seems to have added a position argument to the
> RegisterFactory method but the order returned by e.g. CreateAllInstance
> still depends on the registration order.
> Type checking must be done by the user. Object factories registered as
> overrides for certain class names may return any subclass of LightObject.
> Typos in the class name are hard to debug and actual class names and their
> override strings may get out-of-sync.
> The life-cycle of registered object factories is not communicated. While
> probably not in the original scope of ITK object factories, notifications
> about registered/unregistered factories at runtime would make sense for some
> use cases.
>
>
> While discussing, they introduced me with the cross-platform C++ library
> named “CppMicroServices”[1] that could help addressing some of the
> challenges encountered while using the current ITKIOFactory system.
>
> From the website:
>
> “The C++ Micro Services library provides a dynamic service registry based on
> the service layer as specified in the OSGi R4.2 specifications. It enables
> users to realize a service oriented approach within their software stack.
>
> The advantages include higher reuse of components, looser coupling, better
> organization of responsibilities, cleaner API contracts, etc.”
>
> This is a pure C++ implementation of the OSGi service model and does not
> have any third-party library dependencies.”
>
> The idea would be to leverage this library to provide either a replacement
> or an alternative system to register ITK IOPlugin. The following code
> snippets show the different approaches taken by ITK and CppMicroServices for
> “overriding” a class type :
>
>
> General (using itk::ImageIOBase as the “interface”)
> =======================================================
>
> namespace itk {
> class ImageIOBase : public LightProcessObject
> {
>  // public interface
>  // ...
> }
> }
>
> // The following macro allows type-safe APIs in CppMicroServices plus
> // the handling of versions for evolving interfaces
> US_DECLARE_SERVICE_INTERFACE(itk::ImageIOBase,
>                             “org.itk.ImageIOBase/1.0.0”)
>
> class MyImageIO : public itk::ImageIOBase
> {
>  // implementation details
>  // ...
> }
>
>
> ITK
> ===========================================================
>
> // usually one factory for each registered override
> class MyImageIOFactory : public itk::ObjectFactoryBase
> {
>  typedef MyImageIOFactory Self;
>
>  virtual const char* GetITKSourceVersion() const { … }
>  itkFactorylessNewMacro(Self);
>  itkTypeMacro(MyImageIOFactory, itk::ObjectFactoryBase)
>
>  static void RegisterOneFactory()
>  {
>    MyImageIOFactory::Pointer myFactory = MyImageIOFactory::New();
>    // Try to give it top priority
>    itk::ObjectFactoryBase::RegisterFactory(myFactory,
>                                            INSERT_AT_FRONT);
>  }
>
> protected:
>
>  MyImageIOFactory()
>  {
>    // use strings for class names
>    this->RegisterOverride(“itkImageIOBase”, “MyImageIO”,
>                           “My custom image IO”, 1,
>                     itk::CreateObjectFunction<MyImageIO>::New());
>  }
> };
>
> // Make sure to call
> // MyImageIOFactory::RegisterOneFactory()
> // somewhere. Can lead to subtle (de)initialization ordering
> // problems, especially in the context of static initializers.
>
>
> CppMicroServices
> ========================================================
>
> // One “activator” per shared library
> class MyActivator : public mitk::ModuleActivator
> {
>  MyImageIO::Pointer m_MyImageIO;
>
>  void Load(us::ModuleContext* context)
>  {
>    m_MyImageIO = MyImageIO::New();
>    us::ServiceProperties props;
>    // Give this service a ranking (priority) of “100”.
>    // This can still be overridden, but does not depend on
>    // the registration order.
>    props[us::ServiceConstants::SERVICE_RANKING()] = 100;
>    // No factories, register an instance of MyImageIO as a
>    // a “singleton”. Service factories may also be used.
>    context->registerService<itk::ImageIOBase>(m_MyImageIO, props);
>  }
> }
> US_EXPORT_MODULE_ACTIVATOR(MyLib, MyActivator)
>
> Let’s also note that the library is API complete and is now used in projects
> like [2] and [3] and companies like [4]. The library also provides full
> life-cycle notifications for registered objects, an auto-load mechanism
> roughly similar to ITK, powerful service object queries, and puts an
> emphasis on the separation of interface and implementation.
>
> It would  be great if we could engage discussion with the rest community
> regarding the current system and the possible adoption of a different
> mechanism. Considering that a ITK Hackfest dedicated to factory will happen
> later this week on Dec 19, it could be a good opportunity to discuss it.
>
> I will let you forward this email to the ITK developer list if you think it
> applies.
>
> Thanks,
> Jc
>
>
> [1] http://cppmicroservices.org/
>
> [2] http://www.mitk.org
>
> [3] https://github.com/Global-Vision-Systems/Ds4Cpp
>
> [4] http://www.global-vision-systems.com/index.php?Home
>
> --
> +1 919 869 8849
>