New and enhanced features in Rhino 2.4
Rhino 2.4 builds on the previous 2.3.x releases from OpenCloud. The main enhancements in Rhino 2.4 are:
- Linked Components & Shadows — Rhino provide the ability to "replace" installed components, in a virtual sense, with other components, ie. if something refers to component X then it is redirected to really use component Y.
- Dynamic component bindings — a more dynamic approach to dependency specification and binding of components dynamically, post install
- CMP Field Enhancements — array support, serialization enhancements, pass-by-reference, and extension interfaces
- SBB part component type — a sub-component of a JAIN SLEE SBB (Service Building Block)
- SBB child relations — an alternative mechanism Rhino provides to declare and use SBB child relations (child relations are still declared in the deployment descriptor, but the SBB accesses the child relations using a child relation facility provided by the SLEE).
Linked Components & Shadows
A linked component is a virtual component that redirects any incoming reference to an alternative component. A shadow hides an already installed component, again redirecting any incoming references to an alternative component.
Component X can be "linked" to component Y. Component X must not previously exist, and component Y must already exist. Component Y could be a real component, or itself another "link", or shadowed component. A component that depends on X is resolved to depend on Y, or what Y links to if it's not a real component (and so on, until a real component is reached). A dependency relationship from X to Y is created as a result of the linking, such that Y cannot be uninstalled or removed without first removing X. Links may be updated in place, ie. equivalent to a remove then recreate but bypasses the incoming dependency check a remove would involve. Component metadata for X simply reports that it is a linked component and what the target of the link is.
Component X can be "shadowed" by component Y. Both components must already exist. Component Y could be a real component, or a link component, or itself shadowed. A component that depends on X is resolved to depend on Y, or what Y links to if it's not a real component (and so on, until a real component is reached). A dependency relationship from X to Y is created as a result of the shadow, such that Y cannot be uninstalled or removed without first removing the shadow on X. Support for updating a shadow in place is not strictly necessary, as the underlying component still exists if a shadow is removed. A component can have at most one shadow at any given time. Component metadata for X contains the information about the real component, and includes state that indicates that it has been shadowed by another component.
Dynamic component bindings
The JAIN SLEE specification states that every deployable component has an identity specified by a name, vendor, and version tuple. This identity must be unique within the scope of a given component type. A component may reference other components of various types by specifying their type and identity in the component deployment descriptor.
These references are static; that is, they are defined prior to installation in the SLEE, and once the component is installed the references cannot be changed. Static references in general function adequately; however they can make the application upgrade process more complicated that it need be. For example, if a library component used by an application has a bug fixed and a new version of the library is produced, then all dependent components such as SBBs and profile specifications need to have their references updated and new versions released; and all components dependent on those, such as other SBBs and service components, also need updating and releasing; and so on through the chain of dependencies.
A more dynamic approach to dependency specification and binding would help make the upgrade process easier. Rhino provides such an approach, which is supported by the following concepts:
- multiple install levels for components
- virtual copy of installed components
- dependency specification and application.
CMP field enhancements
Rhino 2.4 introduces several CMP field enhancements, including:
- array support — as an extension to the JAIN SLEE specification, supports CMP field declarations of arrays
- serialization enhancements — significantly more control and flexibility over how CMP field values are serialized
- initial values — an annotation that can be used to specify the initial value for a CMP field
- pass-by-reference — the option to declare pass-by-reference semantics to CMP fields, providing three reference scopes: `TRANSACTIONAL`, `WHILE_READY`, or `PERMANENT`
- CMP extension interfaces — SBB CMP fields that can be defined in separate CMP extension interfaces (a CMP extension interface is simply an interface that declares methods related only to CMP fields).
SBB part component type
An "SBB part', as its name implies, can be thought of as a sub-component of a JAIN SLEE SBB (Service Building Block). An SBB part is an installable SLEE component in its own right. It may have dependencies, and other components may depend on it.
The concept of the SBB part component was borne from a use case where the developer wanted to put a number of common shared classes into a library-type component; but the classes had dependencies on various profile specifications, event types, and resource adaptor types —-- all of which a standard JAIN SLEE library component cannot provide (a library component may only depend on other library components).
We thought it might be desirable to extend the definition of the standard library component with the option to declare these other types of references, mainly because a library component was always seen as a passive "primitive" type of component that sat at the top of the dependency hierarchy.
Adding dependency links to other component types would significantly complicate the SLEE component dependency hierarchy. In particular, it would create the possibility of cyclic dependencies between different component types — which must be avoided, as in practise they cannot be mapped to a realistic runtime class loader hierarchy. So instead, a new component type was created to fulfill this need: the SBB part.
SBB child relations
The JAIN SLEE specification defines that an SBB child relation requires an abstract get child relation method declared in the SBB abstract class; and a <get-child-relation-method> deployment descriptor entry that binds the get child relation method to a particular SBB type.
The get child relation method returns a ChildRelation object, which the SBB developer uses to create, remove, or manage the SBBs in the child relation.
A difficulty with this approach is that child relations cannot be added to an SBB without code changes to the SBB abstract class. For example, consider an SBB that delegates call processing to different child SBBs based on the protocol in use for the call (CAPv2, CAPv3, ETSI INAP CS1, and so on). Since the child SBB for each protocol needs its own get child relation method in the SBB abstract class, it's not easy to decide at build time what protocols will be supported without modifying the SBB abstract class and recompiling. Code changes are also extremely undesirable when service bindings are used to change the child relationships of the SBB after the SBB has been installed in the SLEE.
Rhino provides an alternative mechanism to declare and use SBB child relations, which eliminates the recompilation part of the build cycle in these types of use cases. Child relations are still declared in the deployment descriptor, but the SBB accesses the child relations using a child relation facility provided by the SLEE.