27.01.2012 T8.1-T8.4 Conference Call

From IMarine Wiki

Jump to: navigation, search

Contents

Agenda

Time: Friday January 27, 2012, 16:30 - 19:00 CET

  • Possible integration paths of the new Resource Model in the Enabling Software
  • Discovery API
  • Client Publisher API

Participants

T8.1: Manuele Simi (CNR)

T8.4: Fabio Simeoni (FAO)

Main Discussions and Actions

Preliminar considerations:

  • T8.4 has drafted the new Resource Model based on aggregation of Facets
  • T8.1 is both the main producer and consumer of Resources


The discussion longed on the feasibility and opportunity of integrating the new Resource Model in the existing Enabling Software. We discussed pros and cons with the following relevant points:

  • it is not feasible nor convenient adapting all the existing gCube Services to the new Resource Model. This means that T8.1 must guarantee that all the resources under its realm (GHN, RI, Service) must still be published following the previous model;
  • in the future, high-level management functionalities of the Enabling Layer (located in the Resource Manager, Resource Broker and VRE Modeler services )will interface enabling services developed on top of different foundation technologies. Having as less parameters as possible in the interfaces of the enabling services will simplify their interactions now and the integration of future services developed on foundations different from than gCore;
  • in the new Resource Model, information about different aspects of a resource's lifetime are carried inside the resource itself. This allows to ideally pass only the resource identified to both producers and consumers of such a resource;
  • high-level management functionalities will have a great simplification by consuming resources based only on one single Resource Model;
  • the lower-level management functionalities of the Enabling Layer (located in the Deployer and gHNManager services) may also be simplified, for sure at interface level, the lesser number of parameters we pass, the simpler will be to communicate with enabling services developed on other foundations;
  • having resource-related interfaces simplified will also foster the replacement of the Software Repository with a Maven Repository
  • new resources consumed by new services (and only by them) should be published under the new model. For instance, a configuration resource consumed by a service newly developed in iMarine (whatever foundation technologies it relies on) should be published only as a "facet-container"

We ended up with the conclusion that Services, RIs and GHNs must be exposed by the Information System in both models. How this will be practically implemented?

Drafted Integration Path

Translator:

  • we need a translator from old resources to new resources. Having a translator in each consumer is not feasible. Nor it is to translate resources at query time.
  • in the long chain of producing and consuming resources, the earlier the translator comes, the better.
  • the publication phase is the best candidate. And the IC service seems to be the best place (a single point of translation).
  • when the IC service will receive a resource belonging the RI, Service or GHN class, it will automatically generate a resource compliant with the new model starting from the information reported in the profile and this will be indexed in a separate collection or database instance (to investigate);
  • this will introduce a duplication of information handled by the IS, but it is acceptable compared to the advantages in the rest of the enabling layer;
  • backward compatibility:
  • non-Enabling services keep to see the resources they are used to consume published according to the old model
  • new Enabling services will see the merging of the two models obtained with the translator (by consuming only the new model)
  • old services that want to see the new model and resources must migrate to the new Discovery API

Impact on discovery phase:

  • Queries sent by the existing ISClient will be executed against the old model (nothing to change in the implementation);
  • Services using the ISClient will see only resources published in the old model (that could be a partial view of the resources available)
  • Queries executed by the forthcoming Discovery API will be executed against the new model;
  • Services that want to see all the resources must use the new the Discovery API
  • sketching the interface:
  • query-centrinc: query objects with fire() methods
  • simple queries such as "give me all the resources with a Facet named X"
  • advanced queries over Facet's content to evaluate
  • use JAXB to automatically bind the returned XML Facets to Java objects when their associated classes are available on the local Classpath

Impact on the publication phase:

  • the existing ISPublisher will keep publishing only resources compliant with the new model (that will be translated by the IC), nothing to change
  • the new Client Publisher library will publish only resources compliant with the new model;
  • sketching the interface:
  • R create( R ), R must be without the ID
  • R update ( R ), RI must be with ID
  • R remove ( R ), remove the resource from the current scope (the Registry will physically remove it if no scope remains)
Personal tools