Viadeo Twitter Google Bookmarks ! Facebook Digg del.icio.us MySpace Yahoo MyWeb Blinklist Netvouz Reddit Simpy StumbleUpon Bookmarks Windows Live Favorites 
Logo Documentation Qt ·  Page d'accueil  ·  Toutes les classes  ·  Toutes les fonctions  ·  Vues d'ensemble  · 

Qt Service Framework

The Qt Service Framework allows clients to discover and instantiate arbitrary services.

Introduction

The Qt Service Framework defines a unified way of finding, implementing and accessing services across multiple platforms.

Due to the service frameworks knowledge of service interfaces, their versions and QObject-based introspection it may even be used to unify and access multiple platform specific service implementations via the same Qt-based client application.

Overview

A service is an independent component that allows a client to perform a well-defined operation. Clients can find services based on their name and version as well as the interface that is implemented by the service object. Once the service has been identified the framework starts the service and returns a pointer to it. QServiceManager is the main interface through which clients can access the mentioned framework functionality. In addition services themselves may also act as clients to the service framework by requesting other services installed on the system.

Service provider are implemented via plug-ins. QServicePluginInterface defines the main interface for each plug-in. In order to avoid that clients have to link against service specific libraries each service object must be derived from QObject. Therefore the QMetaObject system can be used to dynamically discover and invoke the service's capabilities. To achieve the best level of access via the Qt meta object system services should be implemented in such a way that their entire functionality is accessable via the signals, slots, properties or invokable functions (see Q_INVOKABLE macro for more details).

Each service plug-in implements one service only but can provide multiple implementations for multiple interfaces. Therefore a service (plug-in) can retain a certain level of backwards compatibility even if the main service interface breaks in such a way that a new interface name has to be used. Existing clients can still use the previous version of service interface whereas new clients can utilize the new interface.

Future versions of this framework may also enable access to out-of-process service provider.

Using the Framework

This section assumes that the user wants to access the FileManager service which offers an implementation for the com.nokia.qt.examples.FileStorage interface The service framework enables multiple ways of accessing those implementations.

QServiceManager is the main class to lookup and instantiate services. Services can be found by constraining the search via service meta data or by using the default lookup mechanism.

Verbose Lookup

The client code has precise knowledge of the service and its interfaces.

    QServiceManager manager;
    QServiceFilter filter("com.nokia.qt.examples.FileStorage");
    filter.setServiceName("FileManager");

    // find services complying with filter
    QList<QServiceInterfaceDescriptor> foundServices;
    foundServices = manager.findInterfaces(filter);
    Q_ASSERT(foundServices.count());

    // instantiate the FileStorage object
    QObject *fileStorage;
    fileStorage = manager.loadInterface(foundServices.at(0));

Default Lookup

The client code has knowledge of the interface and doesn't really care about the service that implements the interface. In such cases the default service lookup can be utilized to create a service object instance. If the same service provides multiple versions of the same interface the latest version is returned. Therefore subsequent versions of the same interface must always be binary compatible to previous versions.

    QServiceManager manager;
    QObject *storage;
    storage = manager.loadInterface("com.nokia.qt.examples.FileStorage");
Header Lookup

So far all lookup mechanism returned a QObject pointer. This pointer can be utilised by introspecting the object using Qt's meta object system. Therefore the client does not have to have any knowledge of the object header or symbols. However in some use cases it may be more convenient to directly interact with the service object by including the service header and/or linking against the service provider.

The subsequent code snippet demonstrates how this may look like:

    #include <filestorage.h>
    ...
    QServiceManager manager;
    FileStorage *storage = 0;
    ...
    manager.setInterfaceDefault("FileManager", "com.nokia.qt.examples.FileStorage");
    storage = manager.getInterface<FileStorage>("com.nokia.qt.examples.FileStorage");

Service Scope

The QServiceManager operates in either User scope or System scope. By default, it operates in user scope. The choice of scope affects whether registered services are available system-wide or only to the current user, and whether service and interface lookups are limited to system-wide service or whether the current user's together with system service configurations are considered.

User Scope

In user scope, services are registered in a storage location specific to the current user. When a default service is set for an interface using setInterfaceDefault(), the referenced service can be either a user-specific or system-wide service.

For service and interface lookups, a manager will first search the user-specific services; if the requested component is not found, the manager then searches the system-wide services, if the user has sufficient permissions to do so.

The QServiceManager::serviceAdded() and QServiceManager::serviceRemoved() notifications are emitted when services are added or removed from either the user-specific or system-wide services. These signals have a scope parameter to indicate the scope in which the service was added or removed. (Note the system-wide service notifications are only available if the user has sufficient permissions to access the system-wide service storage.)

System Scope

In system scope, services are registered in a system-wide storage location. The manager does not access user-specific services for any operations. Service and interface lookups fail if the requested services are not found in the system-wide service storage. Service registration is performed in the system-wide storage.

If setInterfaceDefault() is called for a user-specific service, the operation fails.

Also, the QServiceManager::serviceAdded() and QServiceManager::serviceRemoved() notifications are only emitted for system-wide services.

Adding and Removing of Services

New services can be installed and removed at runtime. An XML file is used to describe the service meta data and links the service code to its meta description.

XML Format

Services are installed via an XML file which describes the meta data and location of the service. The xml file can be described via the following DTD:

        <!ELEMENT service ( name, filepath, description?, interface+ ) >
        <!ELEMENT description ( #CDATA ) >
        <!ELEMENT filepath ( #PCDATA ) >
        <!ELEMENT interface ( name, version, description?, capabilities?, customproperty* ) >
        <!ELEMENT capabilities ( #PCDATA ) >
        <!ELEMENT name ( #PCDATA ) >
        <!ELEMENT version ( #PCDATA ) >
        <!ELEMENT customproperty ( #CDATA ) >
        <!ATTLIST customproperty key NMTOKEN #REQUIRED >

The elements and attributes have the following meanings:

ElementSubElementDescription
serviceThe service tag can contain an arbitrary number of interface tags and one description tag.
"descriptionA user readable description of the purpose of the service.
"filepathThe absolute path and name of the plug-in to be loaded when this service is requested. Alternatively if the plug-in name only is provided the standard library paths (see QCoreApplication::libraryPaths()) are used to find the plug-in. Note that if the plugin name is given only, platform specific parts such as the suffix ".dll" and ".so" or plugin prefix "lib" should be removed to enable cross platform resolution. QLibrary is used to determine the platform specific parts of the plugin.
"nameThe name of the service.
interfaceThe interface describes the properties of the interface.
"capabilitiesThis property is a list of arbitrary strings which are interpreted as permissions/capabilities. This list can be empty.
"nameThe name of the interface using the Java class name notation. (e.g. com.nokia.qt.TestService)
"versionThis property contains the interface and implementation version. The version tag follows the major.minor notation. The major version indicates the interface version the minor version the implementation version.

The version number must be greater than 1.0. The version cannot be less than 1.0 because the Service Framework is dependent on the fact that services must be binary compatible between major versions, and services with versions less than 1.0 are unlikely to be binary compatible with later versions.

"descriptionA user readable description of the purpose of the interface.
"custompropertyAn implementation specific key value pair which can be used for filtering or as description.

An example for a valid XML service description could be the following TestService:

        <?xml version="1.0" encoding="utf-8" ?>
        <service>
            <name>TestService</name>
            <filepath>testserviceplugin</filepath>
            <description>Test service description</description>
            <interface>
                <name>com.nokia.qt.ILocation</name>
                <version>1.4</version>
                <capabilities></capabilities>
                <description>Interface that provides location support</description>
            </interface>
            <interface>
                <name>com.nokia.qt.ILocation</name>
                <version>1.5</version>
                <capabilities></capabilities>
                <description>Interface that provides location support</description>
            </interface>
            <interface>
                <name>com.nokia.qt.ISysInfo</name>
                <capabilities>ReadUserData</capabilities>
                <version>2.3</version>
                <description>Interface that provides system information support</description>
                <customproperty key="key1">value1</customproperty>
                <customproperty key="key2">value2</customproperty>
            </interface>
        </service>

Tools for XML Generation

The framework includes a GUI tool under tools/servicexmlgen for generating and inspecting service XML files. This makes it easy to enter service metadata and interface details and generate the appropriate XML to describe the service. It can also be used to load and inspect existing service XML files.

Here is a screenshot of the application, loaded with the TestService XML description provided above.

Installing the Service at Runtime

New services can be added and removed at any time via QServiceManager::addService() and QServiceManager::removeService().

On Symbian devices a service can be installed using the Symbian package installer. More details about this process can be found in the Qt Service Framework on Symbian documentation.

Identifying Services

Each implementation is identified by a service name, an interface name and its version. This information is encapsulated by QServiceInterfaceDescriptor which can be used to request references to service objects.

QServiceFilter simplifies the lookup of already installed services. Developers specifies the criteria used during the meta data lookup. The subsequent example demonstrates the interaction between QServiceInterfaceDescriptor and QServiceFilter by creating references to all services that implement the interface com.nokia.qt.ILocation:

        QServiceManager mgr;
        QServiceFilter filter;
        filter.setInterfaceName("com.nokia.qt.ILocation");
        QList<QServiceInterfaceDescriptor> list = mgr.findInterfaces(filter);
        for(int i = 0; i < list.size(); i++) {
            QObject *serviceObject;
            serviceObject = mgr.loadInterface(list[i]);

            // returned object owned by client
            if (serviceObject)
                serviceObject->setParent(this);
        }

Upgrading Services

There are two ways in which to upgrade a service. The first is an incremental approach whereby QServiceManager::addService() is used to register an XML descriptor whose service name already exists but defines new interface implementations. For example an already existing service, "ovi" may define version 1.0 of interface,"IDownload". QServiceManager::addService() is then called with an XML descriptor that declares itself as belonging the "ovi" service, but implements version 1.1 of the interface "IDownload". Both implementation versions will be available for use.

The second method is a replacement approach whereby an existing service is completely removed and replaced by a new service.

As an example the already existing "ovi" service may implement interface "IDownload" version 1.0, the new "ovi" service may implement "IDownload" version 1.0 and version 1.1. In this case the old service implementation must be first be removed using QServiceManager::removeService() to make way for the new service implementation.

Examples

Main Classes

QAbstractSecuritySessionGeneric mechanism to enable permission checks for services
QServiceContextContext information to services
QServiceFilterDefines criteria for defining a sub-set of all available services
QServiceInterfaceDescriptorIdentifies a service implementation
QServiceManagerEnables the loading of service plugins and the (de)registration of services
QServicePluginInterfaceDefines the interface that every plug-in based service must implement

Publicité

Best Of

Actualités les plus lues

Semaine
Mois
Année
  1. « Quelque chose ne va vraiment pas avec les développeurs "modernes" », un développeur à "l'ancienne" critique la multiplication des bibliothèques 64
  2. Apercevoir la troisième dimension ou l'utilisation multithreadée d'OpenGL dans Qt, un article des Qt Quarterly traduit par Guillaume Belz 0
  3. Les développeurs ignorent-ils trop les failles découvertes dans leur code ? Prenez-vous en compte les remarques des autres ? 17
  4. BlackBerry 10 : premières images du prochain OS de RIM qui devrait intégrer des widgets et des tuiles inspirées de Windows Phone 0
  5. Quelles nouveautés de C++11 Visual C++ doit-il rapidement intégrer ? Donnez-nous votre avis 10
  6. Adieu qmake, bienvenue qbs : Qt Building Suite, un outil déclaratif et extensible pour la compilation de projets Qt 17
  7. La rubrique Qt a besoin de vous ! 1
Page suivante

Le Qt Developer Network au hasard

Logo

Combiner licence, à propos et fermer

Le Qt Developer Network est un réseau de développeurs Qt anglophone, où ils peuvent partager leur expérience sur le framework. Lire l'article.

Communauté

Ressources

Liens utiles

Contact

  • Vous souhaitez rejoindre la rédaction ou proposer un tutoriel, une traduction, une question... ? Postez dans le forum Contribuez ou contactez-nous par MP ou par email (voir en bas de page).

Qt dans le magazine

Cette page est une traduction d'une page de la documentation de Qt, écrite par Nokia Corporation and/or its subsidiary(-ies). Les éventuels problèmes résultant d'une mauvaise traduction ne sont pas imputables à Nokia. Qt qtmobility-1.0-tp
Copyright © 2012 Developpez LLC. Tous droits réservés Developpez LLC. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents et images sans l'autorisation expresse de Developpez LLC. Sinon, vous encourez selon la loi jusqu'à 3 ans de prison et jusqu'à 300 000 E de dommages et intérêts. Cette page est déposée à la SACD.
Vous avez déniché une erreur ? Un bug ? Une redirection cassée ? Ou tout autre problème, quel qu'il soit ? Ou bien vous désirez participer à ce projet de traduction ? N'hésitez pas à nous contacter ou par MP !
 
 
 
 
Partenaires

Hébergement Web