Open In App

CORBA Component Model (CCM)

Improve
Improve
Like Article
Like
Save
Share
Report

The CCM extends CORBA object model via defining elements and offerings that allow utility developers to implement, manage, configure, and deploy components that combine generally used CORBA services, such as transaction, security, persistent state, and event notification services, in general environment. The CCM specification is backward well suited with older CORBA specifications. The CCM is server-side component model for constructing and deploying CORBA applications.

It offers constant component structure framework for growing distributed n-tier middleware. It would be honest to name element written to CCM spec CORBA component. Key factors of CCM are as follows :

  1. It is extension of Enterprise JavaBeans.
  2. It guarantees entirely compatible embedding of current EJB solutions.
  3. It is both language and platform-independent.


Features of CCM :

  1. Portable Object Adapter –
    The major function of CORBA object adapter is to act as mediator or you can say to mediate between ORB and object receiving incoming calls and returning results. Portable object adapter having its instance which accepts requests on behalf of group of objects.


  2. CCM Components –
    A CCM utility is assembly of CCM components, each of which may additionally be custom-built. Made to particular customer’s order or Commercial off-the-shelf or commercially available off-the-shelf (COTS).

    A CCM component is further divided into 4 types :

    • (i) Session Component :
      Instances of session components hold state for period of transnational session and enable for couple of calls within such session.
    • (ii) Service Component :
      Service components are instantiated per incoming call and as result, can’t hold state throughout calls.
    • (iii) Process Component :
      Instances of process components have continual state – their lifetime corresponds to lifetime of some process they are servicing.
    • (iv) Entity Component :
      Entity components eventually have persistent instances that correspond to entities in some database – they can be accessed by using providing database entity’s primary key.

    There are some ports in CCM, categorized into different types such as facets, receptacles, match sources etc. A facet is supplied interface and receptacle is required interface. A component instance’s receptacles are linked to other instances’ facets. Event sources and sinks are similar, however alternatively of being linked to each other, they are both linked to event channels.

    Receptacles supply join and disconnect operations and internally correspond to object references to other objects of suitable type. To support initial configuration of any new component in CCM, Configuration interfaces is used.


  3. CCM Container –
    To start the further process every CCM component which is component of instance of CCM is positioned inside CCM container. Components engage with POA as well as transactions, security, persistence, and notification offerings by means of interfaces on their container. A container additionally has receptacles that receive callbacks into component instance. Transaction manage can be container-managed or self-managed.

    In the container-managed case, a component configuration states if transactions are supported, required, required new, or no longer supported. To manage all these requests, container will stop and start transactions process accordingly. In the same way, we can declare persistence as self-managed. or it can be declared as container-managed.


Last Updated : 13 Jul, 2020
Like Article
Save Article
Previous
Next
Share your thoughts in the comments
Similar Reads