OSGi(1) and the JSR 291(2) represent an emerging technology, which is widely adopted in various industries. Although, this new environment is more restrictive than plain Java, it is extremely rewarding in terms of lifecycle management, software reuse, modularization and dynamism. Out of the box UIMA is not capable of running in pure OSGi environment and benefit from its features. To leverage the usage of UIMA even in such an environment, IBM has published an adaptor project on AlphaWorks(3), which enables the use of UIMA in any OSGi environment (like Apache Felix, Knopflerfish or Eclipse Equinox) or OSGi based products.

The introduced approach maintains the current UIMA programming model, so that the learning effort is considerably low. Even the migration of existing analytics towards OSGi-Bundles is (for well written code) fairly easy. However, to speed up the process of getting started, additional videos are provided (under Demo) to explain each step in detail. Questions concerning the usage or concrete implementation should be addressed in the designated forum(4) on AlphaWorks. General architectural discussions are more than welcome on the uima mailing list.

(1) Open Service Gateway initiative: http://www.osgi.org
(2) JSR 291 - Dynamic Component Support for JavaTM SE: http://jcp.org/en/jsr/detail?id=291
(3) Dynamic Module Enabler for Unstructured Information Management Architecture Component Analytics: http://www.alphaworks.ibm.com/tech/dmeuima/
(4) DME-UIMA Forum: http://www.alphaworks.ibm.com/tech/dmeuima/forum

  • No labels

5 Comments

  1. Thilo Goetz

    Let me kick this off by asking: why a service adapter? We may want to aim higher and OSGi enable the UIMA core, without an adapter. I'm probably not the first one to raise this point. Any known pros and cons?

    1. Yurdaer Doganata

      In general, adapters are used to keep the existing framework and the associated programming model the same while adding new capabilities. Adaptation through a service bridge may be the preferred approach for systems and models that are already penetrated into the market place and there is a need to make the paradigm shift transparent to the user community. Other advantage is the separation of core framework development and maintenance from componentization layer. This way two teams can work independently on the core framework and componentization aspects.

      The main disadvantage of using service adapter is that the core framework cannot take advantage of OSGi's modular approach in managing software life-cyle through a service-oriented, component-based approach. If we may want to aim higher for OSGi enabled UIMA, then we have to consider migrating the core architecture model to OSGi. This may require a complete software redesign since in OSGi world everything are bundles interacting with each other through OSGi specific wiring. In such a system global class space dissappears and clossloaders are dynamically changed as new bundles are invoked.

      1. Mirko Jahn

        I just want to add some of my thoughts and experiences I gained with OSGi and be more specific what made us choosing an adaptor instead of aiming at core uima.

        First, in my opinion OSGi is a great technology, which would be worth being added to the core of UIMA. The guys from the consortium are refining the spec since over 7 years now and a first draft of the JSR 291 (the formal JCP version of dynamic component support) is already out, which may make it an official standard maybe even supported by future JVMs. The "concurrent" JSR 277 (java component support) however is creating a spec in secret, which doesn't address half of the issues OSGi does and even worse, does several mistakes, OSGi already did and learned from. Until now I wasn't taking about backwards compatibility, which is not given in the 277 proposal due to the extensive use of super packages, which will be introduced in later JVMs.

        The service layer and based on this the service based programming model (a sort of SOA, even though it has a very specific flavor) offers great opportunities for separating interfaces and API definitions from concrete implementations. This makes it easy to verify, if several implementations fulfill the requirements of the API. As we will show later on this page our latest architecture has an interface of this adapter and an implementation, which can be exchanged at any time. UIMA for instance may benefit from this by separating the OASIS specification of the interfaces from the concrete implementations. A componentized UIMA may also be assembled according to the distinct needs and reduced in size (OSGi core is pretty small, too), which may make it interesting for embedded devices as well. An OSGi based UIMA may also be easily included in an OSGi based Application Server like Websphere or IONA.

        Second, all provided benefits of OSGi don't come for free. OSGi defines its own class loading mechanisms, which makes it incompatible to regular Java class loading approaches. The code isolation based on class loaders destroys the idea of a global class space, which is a necessity for the UIMA (JCas) type system. In fact the concept of different class loaders for each component breaks UIMA in several situations. The type system and its view via JCas is the weakest spot, we discovered during our experiments, but there are more things needed to be done in order to switch to OSGi in the core of UIMA. The Adaptor approach however is a convenient tradeoff. It doesn't offer all the flexibility OSGi is capable of, but gives the developer an impression of what it might be like. The first experiments can be done and even productive setups are possible with it, because the performance impact is pretty small as far as we looked into this aspect. Especially the handling of analytics and type systems is improved dramatically (in my opinion).

        Third and last, OSGi is hot and not just a hype. It is a well developed technology used in many domains. However, the migration to OSGi is costly, as soon as you have to change the main architecture, which is the case for UIMA. An adaptor based approach gives you the opportunity of a slow and smooth migration, without breaking user code at once. The user can decide, if he wants to use the OSGi based version or the traditional framework. Of course, there are a lot of more possibilities, like changing the core and offering a wrapper interface for users, which makes them OSGi based UIMA look like the traditional one, if he doesn't want to use OSGi. There are many other opportunities as well and I would like to discuss all of them here or on the uima mailing list. Decisions we make here may heavily impact UIMA so I would appreciate having many parties participating on this. However, in my opinion an adaptor is a good first step towards componentization and asset reuse in UIMA. Yurdaer explained that pretty good I think.

        1. Thilo Goetz

          Hi Mirko, thanks for your long answer. I think I'll follow up on your suggestion and post my next question on uima-dev. It would be great if you could put your design proposals on the Wiki, though.

          1. Lev Kozakov

            I believe, Yurdaer and Mirko gave enough details answering your question about justification of the adaptation method. I just wanted to add one small point to this discussion. We believe, the OSGi adaptation of UIMA framework through our OSGi Service Adaptor is the lightweight alternative for complete UIMA migration to a service-based OSGi compatible framework. At the same time, this adaptation can be considered as the first step in UIMA migration to OSGi environment. This step does not require a lot of efforts, but may clearly demonstrate the advantages of moving to a component based development environment. It also gives us significant practical experience that will be useful when we decide to completely migrate UIMA to OSGi environment.