POLD – overview

What does POLD actually mean?
POLD stands for POLicy Description and it is one of the most important components of NetQoS system from the user preference/requirements management point of view. POLD is the tool that takes responsibility for processing the NetQoS policies from abstract (non-technological) into concrete (network-related) parameters. A policy can be treated as a some kind of a rule defined by any system user (e.g. service provider or home-user). There are two kinds of policies maintained by POLD: high-level (HL) policies and intermediate-level (IL) policies. HL policies are policies created by system users and they appear in the system in a human-readable form. An example of HL policy may looks like:

HL policy can be divided into two parts: condition and action. Condition section determines circumstances (like location or time period) when policy should be used, and action section defines an action, that should be taken (e. g. reservation of network resources) in reply the context being.
This kind of policy is understandable but the network elements like routers require network configuration parameters instead of abstract non-technical specification of user preferences. Thus POLD also provides more network-oriented IL policies. IL policies are created (are output of) so called refinement process and they contain information about network, application type, location and QoS parameters' values, that are required by the service. An example of IL policy may look like:

Policy refinement – the role of semantic support
Refinement is one of the most important POLD capabilities, because it makes high-level policies understandable for low-level components that operate on network infrastructure. This process uses sophisticated techniques including ontology mapping and ontology reasoning to translate policies from HL into IL form. During refinement the SLA (Service Level Agreement) is used. Based on the SLA information POLD is able to point out the network, which should be used to fulfill demands specified in a particular policy (that applies in a given context).
To properly operate on policies POLD uses semantic support. Ontologies are used to a) provide standard based container for policy packaging b) provide domain knowledge (QoS expertise). Underneath it is shown how policies are processed (high level view) from user preference to operational parameters for routers (Figure below).

The P1, P2, P3 points on the diagram indicate the key processing stages (and controlling knobs) that influence the depth and sequencing of the refinement process:

• P1 – point is related to the level/depth of expertise that is applied to actor’s policy during mapping process (can be imagined as width of the pipe)
• P2 – point indicates capabilities of controlling model-based and template-based rules in the refinement process (external expert may create additional knowledge by applying rules)
• P3 – denotes the point of policy optimisation with respect to operational context of the system (with special focus for NETQoS on provisioning of Transport services).

Technical approach
POLD is built of a set of elements, that are responsible for different areas of its overall functionality. Its main functional blocks has been shown below (Figure below).

The main functionalities of selected elements have been briefly described below:

• Access interface: an interface that should be used by other NetQoS components to interact with POLD. This interface makes accessible methods, that allow to perform some operations on policies or ontologies.
• Ontology Manager (OM): responsible for maintaining and performing all operations on ontologies. It uses several advanced techniques (including SWRL and SPARQL) to query and manipulate ontologies. It allows to extract information from ontologies, also makes possible to dynamically change its internal structure (like relations between classes and instances). An example SWRL query in human-readable form may look like:
  
  hasParent(?x1,?x2) and  hasBrother(?x2,?x3) -> hasUncle(?x1,?x3)
• Policy Manager (PM): maintain all policy operations. It is used to install, update, delete, match or validate policies stored in POLD repository.
• Ontology Assembly Layer (OAL): a bridge between OM and ontology repository. Used to load or update ontology files stored in repository.
• IBM Minerva: ontology repository; a place, where ontologies (current and older versions) are stored. As a repository manager an IBM Minerva is used. This tool stores RDF data in its own, local database (based on Apache Derby engine).
• Hibernate ORM: Object – Relational Mapping mechanism; advanced and powerful Java framework that allow to exchange data between an application and a database in convenient form.
• Database: Relational database (MySQL has been used) to store all data maintained and required by POLD like high-level or intermediate-level policies.

The two most important POLD elements are Policy Manager and Ontology Manager. All business logic of the application is kept in them. Other elements work more like data sources, adapters or interfaces between POLD and third-party components.
POLD business logic was written in Java 5.0, but other technologies were used, the most important are:

• ORM (Object – Relational Mapping): technique provided by Hibernate framework. Hibernate covers the whole communication between the repository (RDBMS) and the POLD application core (Java). Hibernate allows to map database tables into Java classes that are accordant with Java POJO pattern (Plain Old Java Object). Hibernate separates and makes independent database and business parts of an application. Any changes made in one of this elements don’t require any changes in the second – only some minor changes in configuration files should be made. The last advanced Hibernate feature used by POLD is persistence – this technique ensures, that any changes made in java objects will be automatically reflected in database object representation without any additional programming efforts.
• SWRL (Semantic Web Rule Language): a powerful language for querying and manipulating ontologies.
• SPARQL (RDF Query Language): in some ways it is similar to the traditional SQL. It allows querying ontologies to find relevant information. SPARQL uses RDF triples as its elementary data units. A triple consists of a subject, a predicate, and an object. The subject identifies what object the triple is describing. The predicate defines the piece of data in the object we are giving a value to. The object is the actual value.
• Java Socket API used by POLD to work in client-server mode. Server component contains all application logic, it also manages OM and PM components. On the other hand client works like a stub – it has no built-in logic but provides an interface, that allow to communicate with the server. Client was written in pure Java, and it doesn't require any special libraries or plugins to work properly.