The K2 Container is the server's runtime environment for a CORBA® component implementation. K2 Container is based on the Component Implementation Framework (CIF) which defines the programming model for constructing component implementations. K2 Container uses Component Implementation Definition Language (CIDL) for describing implementations of component and component homes, as well as their abstract states.

CIDL compilers use CIDL descriptions to generate implementation skeletons that automate many of the basic behaviors of components such as navigation, identity, inquiries, activation, state management, lifecycle management, etc.

  Need for CORBA Component Architecture

CORBA's principal strength is that it is an object middleware. In CORBA there is a clear distinction between the interfaces and their implementations. Moreover the interface is specified using IDL (Interface Definition Language), the implementation can be done on any language for which a mapping exists for IDL. The core of CORBA architecture is called ORB (Object Request Broker) that abstracts object location, networking issues, request dispatching and delivering to target objects and activation issues.

The traditional CORBA object model provides a standard middleware framework that enables CORBA objects to interoperate with each other. CORBA defines a software bus that allows clients to invoke operations on objects that can reside locally or remotely. Moreover, to provide higher - level reusable components, the OMG also specifies a set of CORBA Object Services that define the standard interfaces to access common services, such as naming, trading, and event notification. By using CORBA and its Object Services, programmers can integrate and assemble large, complex distributed applications and systems using features and services from different providers. However, the traditional CORBA object model culminating in CORBA 2.3 (OMG,1999a) failed to address the following important design forces:


No standard way to deploy object implementations:

The CORBA specification does not define a standard way to deploy object implementations in server processes, i.e., there is no standard way to distribute object implementations, install those implementations in their execution context, or activate the implementation in a particular ORB. Thus, system designers must use adhoc strategies to instantiate all objects in a system. Moreover, since objects may depend on one another, instantiating objects in a large-scale distributed system can become complicated.

Lack of support for common programming idioms for CORBA servers:

The CORBA family of specifications provides a rich set of features to implement servers. In many application domains, however, only a limited subset of those features are ever used. Consequently, it is desirable to support subsets of necessary features via tools that can generate CORBA code automatically to implement common application use-cases. For example, the CORBA 2.2 specification introduced the Portable Object Adapter(POA), which is the ORB mechanism that forwards client requests to concrete object implementations. The POA specification provides standard APIs to register object implementations with the ORB, to deactivate those objects, or to activate object implementations on-demand. The POA is a flexible component of the CORBA programming model and provides numerous policies to configure its behaviour. However, an important class of applications only use a subset of the possible configurations of a POA, yet server developers must learn how to configure many POA policies to obtain their desired behaviour.

Difficulty extending object functionalities:

In the traditional CORBA object model, objects can be extended only via inheritance. To support new interfaces, therefore, application developers must:

1) Define a new IDL interface that inherits from all the require interfaces,
2) Implement the new interface,
3) Deploy the new implementation across all their servers.

However, multiple inheritance in CORBA IDL is fragile since overloading is not allowed in IDL due to languages like C that lack overloading. Therefore, the techniques described above have only limited applicability. Moreover, applications may need to expose the same IDL interface multiple times to allow developers to either provide multiple implementations or multiple instances of the service through a single access point. In contrast, multiple inheritance makes it impossible to expose the same interface more than once, or to determine which is the most derived interface available to clients.

Availability of CORBA Object Services is not defined a prior:

The CORBA specification does not mandate what Object Services are available at run-time. As a consequence, object developers must use adhoc strategies to configure and activate these services when planning a system.

No standard object lifecycle management:

Although the CORBA Object Service defines a Lifecycle Services, its use is not mandated. Therefore, clients often require explicit knowledge to manage the lifecycle of an object in adhoc ways. Moreover, the developers of CORBA objects controlled through the LifeCycle service must be aware of this fact, and must define auxiliary interfaces to control the object life cycle. Defining these interfaces is a tedious process, and should be automated when possible, but the earlier CORBA specifications lacked the features required to implement such automation.

  The inadequacies of the CORBA specification, prior to and including version 2.3, outlined above often lead to tightly coupled, ad-hoc implementations of objects that are hard to design, reuse, deploy, maintain and extend.

The CORBA® Component Model (CCM) adresses all these problems.

  Introduction to Components

In this document we must define the concept of a component attending to requirements it must address. A component can be defined as:

Binary interchangeable unit that could be installed everywhere. Interchangeably enables graceful software evolution, as it can be substituted by another effective one without affecting others.
Building applications by assembling components. Components must state what they need and what do they offer. The deployment of application must be flexible enough to allow both initially distributed components and subsequent adoption to topology through application's lifetime.
Automatic code generation based on common design and implementation patterns: code for factories, code for assemblies and code for storing and retrieving persistence object's states.
A standard development, implementation and deployment environment covering whole application's deployment lifecycle.

The CORBA component architecture consists of several interlocking conceptual pieces that enable a complete distributed enterprise server computing architecture. These includes an abstract component model, a container model, component implementation framework - component implementation description language (CIDL), packaging and deployment model, integration with persistence, transactions, events and interworking with EJB 1.0.

  CORBA® is a Registered Trade Mark of Object Management Group,Inc. in USA and other countries
Copyright 2008 iCMG. All rights reserved.
Site Index | Contact Us | Legal & Privacy Policy