From EGI Knowledge Base

Jump to: navigation, search


[edit] What is UMD?

UMD stands for Unified Middleware Distribution, the proposed approach of handling middleware maintenance, integration, testing, and deployment within the EGI and NGI infrastructure. It defines components, processes, involved parties etc. in order to guarantee the infrastructure to get reliable middleware in terms of both functionality and quality.

Quoting EGI_DS deliverable D5.4, EGI Blueprint:

  "The middleware consortia ARC, gLite and UNICORE propose to foster the
   convergence of their current solutions into a Unified Middleware Distribution
   (UMD), similar to what the Virtual Data Toolkit (VDT) in the US is for the Open
   Science Grid (OSG). UMD is a pragmatic way to coordinate at the European level
   the current independent and parallel developments avoiding duplication of
   effort. UMD will contain the necessary high-quality middleware components
   satisfying the strict policies, interoperability standards and quality criteria
   defined by the Middleware Unit and endorsed by the Middleware
   Coordination Board (MCB). The set of services included in UMD will expand and
   evolve according to the requirements of European research communities and the
   operational needs of the resource providers. Components from sources other than
   ARC, gLite and UNICORE can also be part of UMD if requested by users or NGIs,
   following the same rules agreed by the MCB. UMD will also deliver stable
   documented interfaces that will enable the development and the contribution of
   additional higher-level services by third parties."

[edit] Goals and benefits

  • the maintenance of the currently deployed middleware in production use across Europe that supports a diverse and active application community
  • the convergence of widely deployed components from different providers to a single, ideally standardized interface, that will enable communities to utilize services from any European middleware provider
  • the rationalization of European middleware components to eliminate duplication where there are components with converged interfaces that are deployed to meet identical use cases
  • the continued development of new functionality to meet the evolving needs of its application community and to ensure that Europe continues to be recognized as a leading provider of e-infrastructure software

By the three middleware consortia coming together through UMD to meet the middleware needs of EGI, we expect to:

  • have an increasingly stronger view within standards bodies such as the OGF (see the recent activity within the GLUE and PGI working groups)
  • provide standard interfaces to common services and provide defined environments through synchronised development activities to provide a coherent architecture
  • simplify the life for application developers and users by enabling transparent access to resources regardless of the deployed middleware implementation
  • by converging and rationalising the European middleware reduce the long-term software maintenance costs for the European e-infrastructure

[edit] Released software

Components released to production will be made available in a single repository, certified by the software provider and verified by the MU to adhere with defined criteria:

  • Generic criteria: interoperability, completeness, extensibility, deployability, simplicity, product documentation, platform portability, lightweight (i.e. only install the additional components that need to be installed), co-existence (i.e. require minimal, ideally none, changes to any other commonly installed software components), ...
  • Component specific criteria: performance, stability, scalability, standards compliance, command line syntax, public API, graphical interface...

[edit] UMD Roadmap

A living document that specifies, for each component in UMD:

  • when it is exepected to become available and verified
  • support mechanisms (including the expected response time) and currently planned duration of any funded support
  • testing and certification work that the component has undergone, including results, to meet the generic or component specific criteria
  • projected changes in functionality and expected minor/major release dates
  • dependencies on and from other software components (and their versions),

[edit] Public documents

[edit] Current work

Currently the following working groups are active in preparation of UMD definition:

[edit] Technical working group

Provide a survey of existing middleware components, the scope of the information gathering initially is based on the three middleware stacks ARC, gLite and UNICORE due to limited manpower however later as available resources allow it'll be extended to cover other technologies used today.


  • ARC: Balazs Konya (chair), Aleksandr Konstantinov
  • gLiTe: Moreno Marzolla, Laurence Field
  • UNICORE: Bernd Schuller, Morris Riedel

"Survey of potential Universal Middleware Distribution (UMD) components", Image:ComponentSurvey.pdf

[edit] Process working group

Define the UMD process and organization within the EGI model. Technical workflow for the release of components, their integration, testing and final certification before deployment. Roles and responsibilities of the different players: Interfaces between the Middleware Consortia, MU, MCB or Specialized Support Centers (Application), Central Technical Officer .


  • gLite: Steven Newhouse (chair), Ales Krenek
  • ARC: Oxana Smirnova, Farid Ould-Saada
  • UNICORE: Achim Streit, Bernd Schuller

The "Process document", Image:EGISoftDev10.pdf

[edit] Operation and user requirements Working group

Collect preliminary wishes from developers, operations and users on missing functionalities and define a preliminary roadmap for the future UMD evolution and comes up with concrete ideas for future UMD developments. The outcome (wish list for 2 years and vision for 5 years) will serve as a basis of discussion with the EGI Council and its technical units once these will be set up


  • DEISA: Denis Girou, Stefan Heinzel
  • EGEE: Steve Traylen, Johan Montagnat
  • NDGF: Michael Gronager, Josva Kleist
  • EGI-DS: Roberto Barbera

[edit] Coordination Group

The job of the coordination group is to

  • prepare the UMD meetings / workshops
  • study the EU calls
  • prepare the way the middleware funding will be organised
  • track progress


  • ARC: Farid Ould-Saada
  • gLiTe: Mirco Mazzucato
  • UNICORE: Achim Streit

[edit] Meetings

[edit] Former work

Work on UMD was started by creating Middleware taskforce in EGI DS, once the need for UMD had been identified.

Following this group work UMD preparation self-organized there in a series of meetings with the outcome of spawing the above working groups

[edit] Internal area

These pages are working documents of the UMD team, access is restricted.


Personal tools
hidden pages