Difference between revisions of "Profile Specification"

From Gcube Wiki
Jump to: navigation, search
(DILIGENT Resources and profiles)
(WSRFService)
Line 57: Line 57:
  
 
==== WSRFService ====
 
==== WSRFService ====
 +
 +
 +
===== Fix the service equivalence (ServiceEquivalenceFunctions section) =====
 +
This section 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 ====
 
==== Library ====

Revision as of 16:30, 12 February 2007

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

There are four types of package:

  • WSRFService
  • Library
    • Shared
    • Stubs
  • Portlet
  • GridJob


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

Common sections

Name and Class

DL Logical Dependencies

Component-specific sections

WSRFService

Fix the service equivalence (ServiceEquivalenceFunctions section)

This section 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