K2 is an application server, which provides a server side Component Development Model in addition to support for messaging. K2 currently implements a subset of the CCM specification.

CCM (CORBA Component Model) is a Server Side Component model for developing CORBA Components. The CCM Model provides a Component Model and mandates availability of a set of Enterprise Services such as Security, Transactions, Persistence and Notification/Messaging.

Component Software consists of components, a component runtime and a set of tools to expedite the process of component software development. The next set of FAQ will explain them in detail.

The CORBA Object Model lacked a life cycle manager for CORBA Objects. These were addressed by using proprietary means by application developer. With the CCM, CORBA objects called Component Homes were introduced to manage components. Component instances are created and destroyed by these homes. Also, user defined operations can be defined in addition to the standard operations that are provided by the CCM.

Components are a physical, replaceable part of a system that packages implementation and provides the realization of a set of interfaces. By terming them physical, we intend to identify them as individual units that offer support for packaging and in this process composing with other components to form a complete application. Components are replaceable units that adhere to its interface which make them replaceable. The client of the component is bound to the interface and not to the implementation.

A component runtime defines an executing environment or context for the components. Central to the concept of a component runtime environment is the concept of a Container. A container offers a programmatic access to the components for them to decide their behavior. The component container interaction is referred to as the Container Programming Model. The Container API type is a framework made up of internal interfaces and callback interfaces used by the component developer.

With the intend of seamless interoperability between EJB and CCM, the CCM development team decided to introduce the basic component model, suitable for interoperation with EJB components. Also, Basic components provided a shorter path in the migration of existing CORBA applications to the CCM platform.

Extended Components were introduced in CCM to provide a complete component model for CCM. Extended components provided extensibility by providing additional ports called facets for components. They also offer components the ability to declare receptacles or required interfaces for the component. This way, a component can specify what is provided and what is required in explicit terms. In addition to these ports, event ports are also defined. The purpose of event ports is to provide a component the ability to publish and subscribe for events. The publishes and emits ports are used to declare the events that can be published by a component. The consumes ports are used to declare that a component can receive events of a particular type. All the ports defined in CCM are type safe.

Both publish and event ports are known to be event sources that produce events to consumers. Publish port are used by multiple subscribers, where as emit port can be connected to at most one proxy consumer client provided by container. The former uses private notification channel to publish events and the later uses shared notification channel. In general emitters are not exposed to client rather they are intended for configuration purposes during assembly phase. In contrast publish port are intended to provide direct client access for particular event type being generated by component.

CCM event model can be integrated with Notification Service to provide highly scalable and available asynchronous messaging infrastructure to CORBA components. The event sources known as emitter and publisher port may use notification channel as explained in previous FAQ to produce events. The consumer port can be configured to be proxy consumer to receive event from arbitrary number of event sources. Container uses subset of Notification Service APIs to integrate with Notification Service and generates context APIs to push or receive events. The container may provide required configuration for setting up shared event channels and event filters if necessary.

No. Custom stereotypes can be defined UML tool to re-present CCM components. Code generation to certain extend is possible using tool provided scripts.

Entity components offer a persistent view to a database entity. Its sole purpose is providing an interface through which a database entity can be created, queried, modified or deleted. All entity components are uniquely identified by an id within their container. An entity component exposes this unique identity in the form of a value type. All entity components survive a system crash. In addition to being created and destroyed, Entity components have the additional ability of being explicitly queried using finder operations in its home.

Session components model a conversational session with a client of the component. Session components are introduced to provide an efficient mechanism to manage conversational state. As is implied from its meaning, the conversational state is destroyed when interrupted by a system crash.

Process components are business process components having some persistence state not visible to client. The same instance of process component can be accessed by multiple clients and retains some state information across invocation of each operation. For example order processing and payment processing can be modeled as process components.

Service components model a stateless component. It is assumed that no state is stored across invocations within the component, thereby providing a stateless programming model. As is implied from the name, they are ideally used for modeling general services within a business application like a currency converter or daily/hourly stock quotes.

System Deployer

A component developer is an expert on a specific domain. His main task is to identify components that can be reusable across the specific domain. These components will reflect business processes sessions or entities. The developed physical software unit will also consist of a software package descriptor detailing the component as a whole. The final package is called CORBA Component Package.

An application assembler’s responsibility is to compose an application out of individual components selected from his repository of components. For this reason, an application assembler will have to be an expert in the solution domain. In addition to composing application out of individual components, he will also generate an application descriptor, which will describe the constituents of the application. The application assembler will be assisted by tools provided by the vendor to assemble components.

The system deployer’s responsibility is to map the environmental constrains to the assembled application. Here he will have to take care of setting the required security and persistence constrains on the individual components of the assembly. Deployment tools provided by the vendor will assist him in this task.

It has to be emphasized that components are not new to CORBA. CORBA did offer limited support for component programming with the help of interfaces. However a component model was missing within CORBA, which basically provided an Object Model for server side programmers with IDL interfaces to define a clear separation between the client of the server and the server itself. CCM leverages the CORBA 2.4 standard to provide a component model for CORBA. In addition to using CORBA 2.4 IDL specification to specify the interfaces of a component, it extends it to add precise component semantics to the specification. CCM extensively uses the POA (Portable Object Adapter) to model a container for components. As always, interoperability between component implementation from different vendors is addressed by both IDL and GIOP/IIOP (General Interoperability Protocol/Internet Interoperability protocol). Its important to understand that CCM alleviates the difficulties of programming non-functional server side code and introduces an efficient packaging model for existing CORBA systems. Basic CCM components are aimed at expediting the migration from CORBA 2 components to CCM components.

CCM and EJB share the same conceptual component model. However, CCM can be conceptually viewed as a more complete component model than EJB. EJB relies on the Java language to define the interfaces of its components. However, Java language does not support the concept of a component in explicit language constructs. This lack of language support is not present in CCM. CCM has language (in this case OMG IDL) support for explicitly declaring components. This lack of EJB component model can be alleviated with the help of a modeling tool (has to support UML) that supports the EJB component model. An additional advantage of CCM is support for extended components. With extended components, we can model individual components exposing a set of interfaces with additional support for extensibility.

Java’s distribution mechanism is addressed by RMI (Remote Method Invocation). CORBA uses an ORB with IIOP semantics for interoperability. Sun realized the importance of IIOP for its server side components to inter-operate with legacy applications and data stores. A merger of RMI and IIOP was proposed which would support simplicity of RMI interfaces and interoperability of IIOP. With this EJB Components were accessible to CORBA systems. With CCM, CORBA is provided with a component model that is modeled against EJB interfaces. However, the interfaces are syntactically incompatible and require of additional bridging software to accommodate seamless interoperability between the component models. The idea is to provide an EJB view for CCM components and a CCM view for EJB components. This is specified within the CCM specification.

In addition to this, CCM also specifies an EJB container within a CCM Server. This way, an EJB Component can be deployed within an EJB Container provided by a CCM Server. The concept of a POA is used to model an EJB container for this purpose. Most CCM application servers are expected to provide an EJB container for deploying EJB components along side CCM components within a single application server, there by providing additional cost and maintenance benefits.

An application server provides an integrated environment for server side software. By an integrated environment, we mean an integration of existing distributed technologies like component oriented, object oriented and message oriented middleware. We will also be provided with Directory service, Event service, Transaction service, Persistence service and Security Service. Additional services can be integrated into the application server through standardized interfaces. In addition to providing an integrated environment, application servers provide the required scalability and reliability for server side development. Here the emphasis is placed on industrial strength load balancing and fault tolerance implementation. A good application server will support scaling up (increasing the hardware capacity of the server) and scaling out (supporting clusters/farms of application servers providing transparent access to components living within the server process). An inherent ability to tolerate faults that occur within the server is essential for providing an uninterrupted conversation with the client. However, its to be added that the support for fault tolerance and load balancing is only as good as the specification the application server implements. CORBA has excellent support for both fault tolerance and load balancing built into its management framework.

K2 is an application server with support for the above-described features of an application server. K2 implements a subset of the CCM specification and adds a plethora of features like support for SOAP and XML Messaging. This support makes K2 complaint to the needs of the enterprise needing both the benefits of Component Software and the flexibility of Messaging Software.

Currently K2 supports C++ language mapping for CCM components. Using C++ wrappers, you can encapsulate legacy Fortran and COBOL applications.

K2 is available on both Window NT and LINUX. The implementation is fairly ORB independent that supports CORBA 2.4 features. At the moment we are able to port to TAO, ORBACUS and ORBIX. The distribution is available with TAO 1.2. It’s possible to run K2 with different flavor of ORB, platform, Operating System and compiler in a clustered configuration and deploy binaries in respective K2 container using deployment tool.

Yes and No. If third party compiled environment match with supported container environment, then container can generate additional glue code to make it final deployable zip file. At present no C++ ORB generates portable stubs and skeletons that can run in another ORB environment. For that reason it’s necessary that your third party environment must match with container environment in terms of C++ compiler, OS, processor and ORB if you want to deploy third party C++ binary.

CORBA 3.0 IDL is an extension of the CORBA 2.x IDL, and continues to support all the constructs that are supported in the CORBA 2.x IDL. To define components and its home you can use “support” key word to extend existing interfaces to components. This essentially does not affect the client side code, as you can narrow component reference to required interface. However for non-factory pattern, the client must be aware of component home to create a component instance. In CCM it’s mandatory have a home.

A component finally gets converted into an equivalent interface that inherits from CCM framework interfaces. This is part of CCM specification as defined by Object Management Group. CCM Container implements the framework interfaces either by code generation or in the form of library.

To run both components and existing IDL implementation together by leveraging over existing deployment model, you may define a wrapper component that essentially does initialization of non-component IDL implementations i.e. creating object references, advertising services etc. Then invoke wrapper component initialization using small client after deployment that can be done using simple client or Python Managed Object provided by K2 infrastructure services.

Complexity can be reduced when you divide it. Considering a large server implementation, it’s advisable to identify only few meaningful components having supported, provided or used (for connection) interfaces. Rest you can leave to code generation. In fact the Component remains very small unit so that its implementation comprises of potentially complex parts that exhibits behaviors and relationship to provide proper implementation. CCM specification focuses on customization and extension through delegation and configuration. An application can be viewed as an assembly of several interconnected reusable components.

Additionally you can partition your component deployment into multiple instances of CCM server. This will be required when some component will require single threaded server and others will require thread pool or thread per request strategy.

Coding will be easy to do without prior knowledge of POA and other service APIs. For that purpose container provides a context that can be used by programmer to access CORBA services (most of them can be set up using deployment descriptor). The basic idea of component model to generate as much as servers side code possible and let programmer focus only on business logic.

In the latest release 1.2 K2 Container does not support any event model for extended component features i.e. publishes, consumes and emits ports. These features will be supported in next release. We are planning to provide integration with Notification Service to support CCM event model.

CCM is first multi-language and multi-platform standard compared to EJB. CCM components can be developed and deployed using C++, Ada, Smalltalk including JAVA. CCM specifies interworking model with EJB that can complements existing EJB implementation. CCM defines extended component features known as ports with flexibility of having multiple interfaces within single component. These features allow greater re-use of components through assembly (engineering) rather than developing (manufacturing). CCM model can be considered as a superset of EJB 1.1 model.

Service, Session and Entity CCM components are essentially same as Stateless Session, Stateful Session and Entity Beans respectively. Process Component is something new in CCM. This component is useful for mapping business components into a specialized type that requires persistence and survives after server crashes. Process component can provide multiple interfaces, managing its state independently not visible to client. It is useful for integration with Workflow Manager or Business Process Management Tools.

CORBA component package is a zip file that contains component IDL, soft package descriptor, CORBA component descriptor, component implementation binary in form of shared library, dependent libraries and initial configuration defined in a property file.

Assembly package is an archive file that contains assembly information about one or more assembly instances. It is described in a file called Component Assembly Descriptor. This descriptor primarily describes how component instances are created, configured and inter-connected together.

An assembly tool can import the CORBA Component Package for additional configuration and provide information how Components are collocated in a single process or cluster or node and specify how and where the services are to be advertised.