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
- 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
||Load balancing and fault tolerance
||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
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'
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