From EGI Knowledge Base
 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 EGI.org 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."
 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
 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...
 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),
 Public documents
- Slides on UMD from the EGI PB meeting, Amsterdam, May 29 2009
 Current work
Currently the following working groups are active in preparation of UMD definition:
 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
 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, EGI.org 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
 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
 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
- NorduGrid conference, Budapest, Oct 28, 2008
- Rome Dec 12, 2008
- EGEE All-activity, Jan 27-28, 2009
- Munich, Feb 4, 2009
- Oslo, Mar 11-12, 2009
- CERN, Apr 23-24, 2009
- Orsay, June 29-30, 2009
 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
 Internal area
These pages are working documents of the UMD team, access is restricted.