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.

 

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

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 also allows 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.