Profile Specification

How to write the profile specification for this component depending on its type.

Preliminary definitions

DILIGENT Resources and profiles

A DILIGENT Resource is anything whose related information can be gathered, stored, monitored, and disseminated in order to provide the valuable amount of knowledge needed during the creation and management of a VDL as well as to operate the entire DILIGENT infrastructure. In the project, the following resources have been identified:

• VDL
• Collection
• Metadata Collection
• Transformation Rule
• Service
• Running Instance
• External Running Instance
• DHN
• CS
• CSInstance
• gLite resource

Such resources can be combined or created at VDL creation time in order to set up a new Virtual Digital Library. In order to be appropriately managed and discovered, a DILIGENT Resource has to be described by creating a profile document compliant with its XML schema. A Schema per each resource type has been defined and all of them are available in the CNR's SVN Repository In the following, we will focus about how to compile service profile

the Service resource

Usually, a Service is defined as a software system that delivers functionalities. In DILIGENT, a Service is a not-empty set of related Packages (connected through dependencies) forming an unique logical entity. A Package is the smallest installable unit of software that can be deployed on a DHN (e.g. a JAR o a GAR archive). Packages are the way in which the software needed to set up a DL has to prepared in order to be used and stored in the system. Once the service components have been developed, they must be described by compiling the service profile.

Package types

Concretely, a Package is a “piece of software” that can be deployed on a DHN. A Package can be:

• a WSRFService, representing a package that once deployed produces a WSRF Service (a service able to manage stateful resources following the WS-Resource patterns);
• a Portlet, representing a package that once deployed produces a portlet (Web components, managed by a portlet container, that process requests and generate dynamic GUI content) that can be hosted by the DILIGENT Portal;
• a GridJob, representing a package containing the code and the related information needed to run a certain job on the grid infrastructure (see Section 4.1.3);
• a Library, representing a software library that can be hosted on a DHN and is needed by other packages to support their tasks. There are two types of libraries:
  • Shared Library, software library offering functionality of common utility, e.g. an XML parser library or a mathematical support library;
  • Stub Library, software library offering functionality for interacting with WSRF Services.

Composition

The set of Packages forming a Service is composed by:

1. one and only one Package of WSRFService or Portlet type (the main package or the entry point)
2. an arbitrary number of other Packages of different type logically related (even if not used) by it.

How to write the profile specification

Example

<DILIGENTResource xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<UniqueID/>
	<ResourceType>Service</ResourceType>
	<AuthorizationPolicies>
		[...]
	</AuthorizationPolicies>
	<Profile>
		<Class>MetadataManagement</Class>
		<Name>MetadataCatalog</Name>
		<DescriptiveParameters>
			<DescParameter/>
		</DescriptiveParameters>
		<QoS/>
		<DeploymentInfo>
			<Deployable value="true"/>
		</DeploymentInfo>
		<DLDependencies>
			<DLComponent>
				<Class>MetadataManagement</Class>
				<Name>XMLIndexer</Name>
				<DescriptiveParametersValue/>
			</DLComponent>
			<DLComponent>
				<Class>ContentManagement</Class>
				<Name>StorageManagementService</Name>
				<DescriptiveParametersValue/>
			</DLComponent>
			<DLComponent>
				<Class>ContentManagement</Class>
				<Name>CollectionManagementService</Name>
				<DescriptiveParametersValue/>
			</DLComponent>
		</DLDependencies>
		<SpecificData/>
		<PackagesList>
                 [...]
		</PackagesList>
	</Profile>
</DILIGENTResource>

Common sections

PackageList section

Common elements

Example

<Package>
	<PackageName>MetadataCatalogService</PackageName>
	<PackageType>WSRFService</PackageType>
	<Version>1.0</Version>
	<DLMandatory value="true"/>
	<DHNMandatory value="false"/>
	<VOMandatory value="false"/>
	<DLSharable value="true"/>
	<DisposeInterfaceSupport value="false"/>
	<MultiVersionSupport value="false"/>
	<VOSharingSupport value="false"/>
	<ManifestFile/>
	<InstallScripts/>
	<UninstallScripts/>
	<RebootScripts/>
	<Dependencies>
		<Dependency>
			<Service>
				<Class>ContentManagement</Class>
				<Name>ContentManagementService</Name>
			</Service>
			<PackageName>ContentManagementLayer_lib</PackageName>
			<Version>0.1</Version>
			<SameDHN value="true"/>
			<Priority>3</Priority>
		</Dependency>
		<Dependency>
			<Service>
				<Class>MetadataManagement</Class>
				<Name>XMLIndexer</Name>
			</Service>
			<PackageName>XMLIndexerService_stubs</PackageName>
			<Version>1.0</Version>
			<SameDHN value="true"/>
			<Priority>3</Priority>
		</Dependency>
	</Dependencies>
	<DHNRequirements>
		<Req category="RunTimeEnv" operator="eq" requirement="Variable" value="java1.5"/>
		<Req category="OperatingSystem" operator="eq" requirement="Name" value="Linux"/>
	</DHNRequirements>
	<ConfigurationFiles>
		<File>....</File>

	</ConfigurationFiles>
	[...]
</Package>

Component-specific sections

Example

ServiceEquivalenceFunctions element: Fix the service equivalence

This element allows to define functions to use at runtime to understand when two Running Instances of the service are equivalents from a specific function point of view. They can be considered are a sort of criteria to find service's replicas. So far, the following fuction are used in the infrastructure:

• match, used by the Active Planner service

Library

-- Manuele Simi