Technical Approach

The proposed architecture can be divided in three layers:

    • The Business Modelling layer is where a top level service model is drawn. Users of this layer will typically be Public Administration (PA) domain experts that have sufficient knowledge of the domain. This knowledge includes the legislation that a service is based on, related directives, prerequisites etc.
    • The Configuration layer allows referencing the implementation of the business logic in actual software components. This task is carried out by the IT Consultant, who is responsible for the configuration and deployment of OntoGov services. In our platform, the software implementation will always be achieved through Web Services interfaces.
    • The Runtime layer should orchestrate and control the execution of the atomic services by making the correct invocations of the Web Services configured in the Configuration layer.

In principle, the lifecycle of an e-Government service starts when PA Managers trigger the generation or the change of a service. In order to accomplish this task, PA Managers need to have a high-level view of service models, links to related laws, resources involved and inter-relations with other services.

Such a high-level view is provided by the service models developed through the Business Model layer. The service ontology (or service model) becomes the main source of information for the Configuration layer. During configuration, the IT Consultant should identify the actual software components (Web Services) that enact the service model and the policy and security level that their SOAP messages should accomplish.

The Web Services Orchestration Registry is an ontology-based repository that stores the mappings between atomic services defined in the service model and Web services that carry on with the task. According to the WSDL definition, these mappings comprise the selection of the WSDL operation (method) that should be called once the web service is invoked, and the linking of the WSDL parts (I/O attributes) to the atomic service inputs and outputs.

A Runtime Framework should be properly installed in a broker machine to allow the execution of Web services. A key component here is the Process Engine that acts as an orchestration machine extracting the service ontology from the ontologies and proceeding to deliver the request to the first atomic service described in the process model. The engine relies on the use of a component called Synchronization Manager that hides the complexity of the synchronous or asynchronous behaviour of the Web services.

In support of the logical architecture described above and based on the analysis of the existing standard for Semantic Web Services (i.e. OWL-S and WSMO), we have defined a set of ontologies. They can be clustered in the following way:

    • Meta ontologies;
    • Domain-oriented ontologies;
    • Administration ontologies.

The Meta Ontologies define the schema i.e. the language for modelling the e-Government services. The Domain-oriented Ontologies model the concrete e-Government services and all data relevant for these services. The main ontology of this cluster is the so-called Service Ontology that represents the e-Government services. Since the goal of the OntoGov project is to enable better management of e-Government services, we have introduced the Administration Ontologies.

Last updated: February 2005

Close Menu