11.01.2012 WP11 Conference Call

From IMarine Wiki

Jump to: navigation, search

Contents

Agenda

Time: Wednesday January 11, 2012, 11:00 - 13:15 Europe/Rome

Conference call agenda:

  • To express points of view on the focus of tasks of the WP, so that their objectives are met.
  • To present and discuss on a possible methodology for work in the WP.
  • To set a time plan for next steps.

Preparation document

Participants

Andrea Manzi (CERN)

Ciro Formisano (ENG)

Fabio Simeoni (FAO)

Francesco Barchetta (Terradue)

George Kakaletris (NKUA)

Gianpaolo Coro (CNR)

Pasquale Pagano (CNR)

Rena Tsantouli (NKUA)

Yannis Marketakis (FORTH)

Main Discussions and Actions

Introduction

  • Initial concern was to focus on HTTP APIs
  • There are questions whether we should not only redefine the HTTP APIs but also redefine our clients
  • Initial thought is to create a framework for the APis and then build APIs based on the framework. Three things we should define:
    • Principles
    • Architecture (in the same level of abstraction with the previous framework for HTTP)
    • Procedures
  • Expectancies to hear the opinions of the others on the framework design


Points of View on the focus of the WP tasks

(Lino) - When we talk about a framework we should aim to deliver a well organised set of APIs that allow to consume the resources that we offer in the infrastructure

- His desire is not a set of clients - one for each service but APIs more oriented towards main areas (i.e. data access), gathering functionalities from various services

- Change the way we consume our resources in a more organized way

(George) - We can have extensions per functionality (for instance jdbc API offered for data access, or jboss framework based specs for security etc.)

(Andrea) Aggrees that we could define some areas and group the access of web services that belong to the same area - and then provide an API for each area

(Fabio) - We should consider issues of consistency and whether it is worth to replicate our functionality with other interfaces when we already build on standards. Web Services are standards, as HTTP is.

- The working model could be unclear, since the per area control coordination is difficult. Who will take charge in every area?

- Clarify whether we talk about http or java based api

- Define the ambiguous term of framework and what do we expect from it

(George) - There is a small doubt that our interfaces are standard but nevertheless, there are higher level standards, more specific to the area of our services.

- Not talking about just going to http - but also http based standards like OpenSearch, accessing the content over http, etc. The concern is to adopt higher level standards and not just to move our levels to REST

- About Java APIs: interoperable APIs are the most important in this workpackage

(Lino) - Pay attention not to plan huge work that requires more effort than already allocated to WP11 and a lot of coordination

- The definition of a framework per functional area, including a lot of services needs a lot of coordination

- The way we have worked in the past 4 years proves that our functionality cannot be offered to other teams because they are too complex. We have to recognise this point and accept that we cannot continue to work in this way for the next two years. We should decide to focus in something that we agree that will be the key to attract more users of our functionality and put our effort there.

- We do not need to offer everything but to identify the key factor to attract more consumers to our infrastructure and simplify the life of the external factors

- D4S must follow the market (practices other cloud providers follow)

(Fabio)

  • Need to define the type of products we want to target - two options:
    • work on JAVA APIs that abstract complexities and remove all boundaries and dependencies to specific technology
    • assume that the reason people are not using us is because they don't want to have binding to a certain technology but prefer to use stronger standards - this is about implementing standard front end to our services
    • We should remember that in practice developing standards could hide a lot o our functionality offered: functional, performance cost, lose a lot if we provide all our product through a standard interface

(Lino)

  • The two options are not an alternative:
    • The first option should be performed in a different Workpackage (WP8) while this WP focuses on the second option. We should not see them as alternatives, we should try to invest on both. They become alternatives only because we have limited effort
    • About reducing the internal functionalities exposed through the standards, this is a price we can pay if more clients are to be using us.

(George) - Simple actions we need to take. Put down cases that can be identified - like we did in NA4 - analyze them in a cost/benefit manner and implement the more valuable

- Within the workpackage there is an explicit reference to the ASL - we need to fix things that are wrong with this layer

(Ciro) From a developer point of view to have a standard api would be useful

(Francesco) Going gowards other communities who can be interested in using iMarine is important

(Lino) It's strange that we don't offer the same abstractions as the ones that are popoular (f.e. cdmi even if it has many limitations - covers only blobs and not more complex structures)

(Fabio) - First need coordination of what it means to turn these APIs into a framework that hides complexity and then at latter stage to turn them into an integration problem and create bindings to http based standards.

- What is the best technology path? Evolution of the ASL?

- This could be a roadmap that avoids paralysis


Possible methodology for work in the WP

(George) - Initial idea was to go forth the way we did in the previous project and strike the expertise of the older members to define the areas and analyse the opportunities. He will have to think a bit more about this.

- About the framework: what do we expect the framework to be? Some principles? An architecture on which our APIs will be delivered?

(Lino) - As Fabio stated, we should first define the principle governing the JAVA APIs. Therefore, in WP11 we could define the activity that all JAVA APIs that will be provided have to be compliant with this principle.

- The principle will define a certain direction (handling of scope, hiding complexity of the distributed infrastructure) and then on top of this we can construct another layer (Fabio calls it bindings to HTTP standards) that will move towards the standards.

- If we define principles that are shared by all clients then it will be easy to build on top of it a binding API to support a protocol.

(George) This is the layering that was designed in the past within ASL. What we describe now is more or less the structure that we already have. We need redefinition of the structure of this but also of the structure of the client libraries etc. This layer is more than just clients, as there are "core" area, like session management etc.

(Lino) We don't follow common principles. By defining the principles we will start putting an order. All java libraries will adhere to these principles that will lead to a proper JAVA framework.

(George) - Another thing is to define the principles and another thing to define the functional areas and these two can proceed in parallel.

Proposal:

  • Start a thread where we first discuss and include principles
  • Collect functional areas like in NA4
  • HTTP or JAVA API decisions will follow

(Fabio) - Agrees that things can progress in parallel.

- Common functionality we have to deal with: obligation, discovery, scope handling, security

  • Athens should:
    • Design a roadmap to define the main areas: Content, Storage, Search, Execution
    • Analyse technological solutions towards creating bindings
  • Need for an integration layer in between applications and the underlying services


Time plan for next steps

(George)

  • We shall immediately start an area in the wiki where we will write down everything discussed
  • Arrange another meeting in two weeks (January 24th). The date is an estimation and it will be further discussed.
Personal tools