FAQ - K2 and CCM Overview
1 What is K2?
2 What is CCM?
3 What is Component Software?
4 What are Component Homes?
5 What are Components?
6 What is a Component Runtime?
7 What are Basic Components?
8 What are Extended Components?
9 What’s difference between publish and emit ports?
10 How CCM event model is related to Notification Service?
11 Is there any UML tool that supports code generation of CCM components?
12 What are the different Component Types supported by CCM?
13 What are Entity components?
14 What are Session components?
15 What are Process components?
16 What are Service components?
17 What are the identifiable roles in the Component Software Development Process?
18 What are the roles of a Component Developer?
19 What are the roles of a Component Assembler?
20 What are the roles of a Deployer?
21 How is CCM related to CORBA 2.4 ?
22 How is CCM related to EJB?
23 How is K2 related to an Application Server?
24 What are the language mappings available with K2?
25 What OS and ORB does K2 support?
26 Can I deploy a CCM Component C++ binary developed by third party?
27 How to migrate existing CORBA 2 IDL to CORBA 3 IDL without affecting client code?
28 How well do the components get converted to CORBA 2.4 and what are the problems of running them together?
29 Will large servers with complicated IDL (replacing existing servers) make coding difficult?
30 Does the K2 container support the event model for extended component?
31 Is CCM a technical improvement on EJB? If yes on which technical aspects?
32 What are the advantages of having four types of components (Service, Entity, Session, Process) in CCM model instead of only two in EJB model (Entity, Session)?
33 What’s CORBA component package?
34 What’s CORBA assembly package?

K2 and CCM Overview

1. What is K2?


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.

2. What is CCM?


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.

3. What is Component Software?


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.

4. What are Component Homes?


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.


5. What are Components?


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.

6. What is a Component Runtime?


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.

7. What are Basic Components?


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.

8. What are Extended Components?


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.

9. What's difference between publish and emit ports?


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.

10. How CCM event model is related to Notification Service?


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.

11. Is there any UML tool that supports code generation of CCM components?


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

12. What are the different Component Types supported by CCM?

  CCM extends the basic concept of a component to support
  Session and
  Service components.

13. What are Entity components?


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.

14. What are Session components?


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.

15. What are Process components?


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.

16. What are Service 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.

17. What are the identifiable roles in the Component Software Development Process?

  In CCM, there are three identifiable roles when developing component software.
  Component Developer
  Application Assembler

System Deployer


18. What are the roles of a Component Developer?


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.

19. What are the roles of a Component Assembler?


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.

20. What are the roles of a Deployer?


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.

21. How is CCM related to CORBA 2.4?


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.

22. How is CCM related to EJB?


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.

23. How is K2 related to an Application Server?


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.


24. What are the language mappings available with K2?


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

25. What OS and ORB does K2 support?


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.

26. Can I deploy a CCM Component C++ binary developed by third party?


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.

27. How to migrate exiting CORBA 2 IDL to CORBA 3 idl without affecting client code?


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.

28. How well do the components become converted to CORBA 2.4 and what are the problems of running them together?


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.

29. Will large servers with complicated IDL (replacing existing servers) make coding difficult?


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.

30. Does the K2 container support the event model for extended component?


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.

31. Is CCM a technical improvement on EJB? If yes on which technical aspects?


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.

32. What are the advantages to have four types of components (Service, Entity, Session, Process) in CCM model instead of only two in EJB model (Entity, Session)?


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.

33. What’s CORBA component package?


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.

34. What’s CORBA assembly package?


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.

K2 Assembly Tool
Financial Component
Knowledge Base
World Of
CCM Link
Copyright © 2008 iCMG. All rights reserved.
Site Index | Contact Us | Legal & Privacy Policy