LegORB is a reconfigurable component-based reflective ORB. All the standard pieces of the ORB (Core, Object Adapter, Invocation Interfaces, etc.) have been componentized, in such a way that the functionality required by applications determines which components of the ORB are required. This approach is one of the principles of our 2k operating system: "What You Need Is What You Get".
LegORB is reflective because it allows inspection of its internal structure, supports dynamic reconfiguration and allows developers to define the policies to safely perform the reconfiguration. The policies are encapsulated in specialized subclasses of the component configurator class, which is associated to every component.
The design of LegORB is based on the requirements of clients and servers. That is, it is possible to choose a minimum configuration that includes client-side functionality only, server side functionality only or both. It is also possible (depending on the LegORB version) to change that functionality on the fly. Applications can customize LegORB by introducing new components with specialized behavior.
LegORB is low-level CORBA compatible, that is, it implements both GIOP and IIOP therefore allowing communication with any CORBA compatible implementation. From the point of view of CORBA defined, high-level interfaces, our current components do not implement them. The reason is that we are using CORBA in resource limited devices such as Palm Size / Handheld devices where memory and computation power is scarce. However, thanks to the reconfigurable nature of LegORB, it is possible to implement a fully CORBA compliant version on top of the proposed architecture. It is simply a matter of implementing a specific set of components.
There are two basic LegORB configurations: static and dynamic.
In the static version, developers can choose the components they want at compile time and then create a library or link the code to the final application. This configuration does not allow dynamic reconfiguration but offers the best size results. We have been built a Windows CE DLL (SH3 processor) for the clients side that requires 22.5KB of memory while in PalmOS, a static library takes 20KB though for the applications we have developed, only 6KB of the library were used. The static configuration is recommended for devices with really limited resources or when run-times changes in the ORB are not required.
The dynamic version requires each component to be a DLL so it can be "plugged" and "unplugged" on the fly. For this configuration we are using our 2k Component Model (a link to information about it will be provided soon) which allows dynamically loading / unloading components as well as creating/deleting new hooks, hooking/unhooking components and inspecting the dependencies of the components. In this configuration every component can be loaded/unloaded and has an attached component configurator to manage its dependencies. This extra functionality introduces overhead in terms of size. The total size of the client-side for Windows CE (SH3 processor) is 87.5 KB for LegORB and 54KB for the component model infrastructure. Therefore, it is possible to have a fully reconfigurable client-side ORB for 141.5KB.
The code we provide can be compiled either in static of dynamic version by defining a specific macro at compile time.