Deployment is the process of installing or updating Software components into the Component Server infrastructure.

With component specification becoming popular, K2 provides deployment module that handles automatic deployment of a CORBA® component independent of the platform. K2 allows remote deployment in any of the servers in the cluster. Remote deployment means a package that is residing locally on the machine running the Deployment tool, is checked and installed in one of the servers.

The packaging of software components is necessary to allow easy deployment of a new component in an already existing component system using a tool or automated installation. We focus on the use of OSD as it is used by the CORBA component specification as well.

Open Software Description is an XML vocabulary used to describe software components and their relationships to other components. The OSD vocabulary is a standard (open) way to describe software components, their versions, their underlying structures and their dependence on other components. It is standard for books to have a table of contents. Similarly OSD is the equivalent content list for packaged software components.

Open Software Description provides a large and flexible vocabulary for describing software distribution packages. When structure and dependencies can be clearly described, only those parts of the package that need to be changed will be uploaded to the server and installed.


Figure 10 shows the structure of a K2 deployment descriptor. A collection of deployment descriptors that are packaged together in one physical archive file are called a Deployment Unit.

Every descriptor mainly consists of three parts:

Soft Package Descriptor
Component Property Descriptor
Attribute Descriptor


1. Soft Package Descriptor:

This descriptor describes how the component is implemented and on what other parts it is dependent on. It is the main mechanism for supplying platform independent Component implementations that can be safely installed. The following emphasises some of the Soft Package Descriptors capabilities:

  • Complex Dependencies:
  • Software components often require other components to run. OSD provides a way to specify many levels of dependency for Web-bound software components. The DEPENDENCY element of the OSD vocabulary specifies which files a software package needs to run. Dependencies are installed before their parent SOFTPKG component. If a component has multiple layers of dependencies, the components should be arranged in a hierarchical fashion to assure that the deepest nodes will be installed first.

  • Java Classes and Applets:
  • OSD files support the inclusion of Java classes and applets in a distribution unit. Specifically, this is done with the JAVA and PACKAGE tags. When described by an OSD file and packaged in a distribution unit, Java class files and applets can be installed. You can save users time and bandwidth by not overwriting or duplicating Java downloads. Downloading Java applets makes your content accessible offline and saves server cycles.

  • Operating System and Hardware Platforms:
  • Another way the OSD vocabulary reduces complexity for the user is by delivering only the software implementation the user needs. The OS and PROCESSOR elements are used to specify the operating system and hardware platforms a software component's IMPLEMENTATION requires.


2. Component Property Descriptor:

This Component Property Descriptor contains configuration parameters of the component that are evaluated during deployment time and allow changing the behaviour of a component after development. Points that are expressed in the Component Property Descriptor include:

Component types, that implement common programming idioms
Load balancing and fault tolerance settings
Security predefinitions
Transaction settings
Persistent settings and database mappings

3. Attribute Descriptor:

The Attribute Descriptor is a customisation mechanism that allows a ready developed component to be reused in different scenarios by initialising the component attributes to particular values. An example for this kind of customisation is for instance a scripting component, whose behaviour is entirely defined by the script the component will be initialised with.

Integration with Legacy

The K2 Deployment Architecture allows also deploying of legacy applications using the same package and descriptor approach described previously. This is achieved by defining a special implementation tag in the Soft-Package descriptor that is a link to the legacy application rather then the executable application itself. This mechanism ensures that even legacy applications can be described and used by the same tools and using the same principles as 'real' CORBA Components.

The only condition that will make that work is a necessary CORBA wrapper around the legacy application. This wrapper ensures that the application is accessible using IIOP.

The wrapper itself can become a managed entity within the Distributed Management Architecture, hence the legacy application is manageable through the standard K2 Management Tool, though the wrapper as well as application are not part of the K2 Fault Tolerance Management.

Figure 11 shows an example scenario of a Shopping Cart Application, that will also be used in section 4.4 about Benchmarking. The Legacy Host runs the legacy application, in this example case a currency converter written in FORTRAN. The code is wrapped into a C++ written CORBA object and published into a naming service running in the same legacy host. The deployment descriptor for this application contains the name under which the wrapper is published. During the deployment process this name will be resolved and the appropriate stub is published in the global Trading service where it can be requested and found by the shopping cart application itself.

  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