A MODEL-BASED REPOSITORY FOR OPEN SOURCE SERVICE AND COMPONENT INTEGRATION

Transcription

1 A MODEL-BASED REPOSITORY FOR OPEN SOURCE SERVICE AND COMPONENT INTEGRATION Rodrgo García-Carmona, Félx Cuadrado, Juan C. Dueñas Departamento de Ingenería de Sstemas Telemátcos, ETSI Telecomuncacón, Unversdad Poltécnca de Madrd Madrd, Span {rodrgo, /cuadrado, Alvaro Navas Cloud & Securty Laboratory, HP Labs, Long Down Av., Stoke Gfford, Brstol, U.K. Keywords: Abstract: OSG, Open source, Software ntegraton, Component dstrbuton. Open source s a software development paradgm that has seen a huge rse n recent years. It reduces IT costs and tme to market, whle ncreasng securty and relablty. However, the dffculty n ntegratng developments from dfferent communtes and stakeholders prevenís ths model from reachng ts full potental. Ths s manly due to the challenge of determnng and locatng the correct dependences for a gven software artfact. To solve ths problem we propose the development of an extensble software component repostory based upon models. Ths repostory should be capable of solvng the dependences between several components and work wth already exstng repostores to access the needed artfacts transparently. Ths repostory wll also be easly expandable, enablng the creaton of modules that support new knds of dependences or other exstng repostory technologes. The proposed soluton wll work wth OSG components and use OSG tself. 1 INTRODUCTION In recent years software development has been undergong a huge change, evolvng from a closed software paradgm to new processes that ncorpórate open source software n producís and servces. The number and relevance of software developments based n the open source paradgm have experenced an exponental growth (Deshpande and Rehle, 2008). The reason for ths les n the partcular strengths that open source can brng nto the table, lke ts ablty to reduce IT costs, delver producís faster and mprove the securty and relablty of systems. Ths stuaton has been also fostered by the numerous success cases n ndustry that have followed ths model. In fact, sources lke Forrester have descrbed 2009 as "the year IT professonals realzed that open source runs ther busness", and predct that ths trend s gong to contnué n the followng years (Evelson and Hammond, 2010). Most of the strengths that open source provdes are the product of the open communtes and the development models that arse from them. At ths pont t has become clear that the communty efforts are leveraged by the partcpatng elements, wth everyone benefttng from the created ecosystem. Example succesful communtes are the Apache Software Foundaton, the Eclpse Foundaton, the ObjectWeb communty and SourceForge. Those communtes have matured wth dfferent collaboraton and archtecture models. As a consequence, these communtes are lke solated slands whch no communcaton between them. Unfortunately, whle they acheve a very hgh nfernal consstency, there s a severe lack of compatblty and ntegraton among them. Ths hampers one of the most mportant factors for the success of open source; the reusablty of code, snce the lack of ntegraton complcates ths process. These ntegraton challenges are also aggravated by the multplcty of tools used by dfferent projects. To further complcate ths ssue, most of these tools are not concerned n workng wth other solutons. The heart of ths problem les n evaluatng the nterdependences of software components. These

2 dependences tend to form a complex mesh that can span several projects and code bases and t s dífcult and costly to navgate. One of the most severe problems of open source development s fgurng whch already exstng components one has to use. In addton to the technology mpedance msmatch, there are addtonal factors whch must be consdered. An often overlooked factor wth open source usage s the exstence of several software lcenses. Whle on frst thought these elements should not nterfere, they do actually restrct the potental uses, snce some of these lcenses are ncompatble between them or wth commercal ones. It can be seen that the problem les not only n code nteroperablty but also n addtonal aspects, such as legal lcense compatblty, or desgn accordng to smlar hardware capabltes. In practce, all these problems tend to produce fragmentaton, complcatng the use of what software t s already avalable. The meetng pont for ths ntegraton s, n almost every communty, a software repostory. Snce the repostory act as a central hub for all development efforts, the dffcultes exposed here are partcularly evdent n t. In ths artcle we present a comprehensve, model-based component repostory that provdes two features that ease the ntegraton of software elements: 1) An automatc dependency resoluton that can work wth several types of concerns (software, hardware, etc..) and 2) A federaton system that can aggregate the contents of other repostores and n turn expose ther own components to the outsde world. Ths repostory has been developed n the context of the ITEA-OSAMI European project and ts objectve s to act as a man hub n an Internet federaton of repostores, whle beng publcly avalable. It ntegrates artfacts publshed by the members of both the ITEA-OSAMI project tself and external partners. Ths artcle s structured as follows: The next secton gves a bref explanaton of the most recent developments n the topcs that concern our work. Secton 3 explans our proposal n detal, and secton 4 performs a valdaton of our work usng an mplementaton of the repostory. Fnally, the last secton outlnes the conclusons we have reached and shows how our work could be further developed nthefuture. 2 STATE OF THE ART In ths secton we provde a bref state of the art of the technologes that are especally relevant for our proposal: the OSG component model and the already exstng software repostory solutons. 2.1 The OSG Component and Servce Model OSG s an open specfcaton that defnes a component and servce model for the Java platform. The latest versón of the specfcaton s 4.2 (OSG Allance, 2009), and s mantaned by the OSG Allance, a consortum formed by embedded and enterprse companes, such as IBM, Oracle, Red Hat or Semens. It was orgnally desgned for home gateways and embedded systems, but ts adopton has greatly ncreased lately n desktop tools and enterprse applcaton servers. The relevance of the OSGI specfcaton has ncreased manly because t provdes a modularty layer that was mssng n the Java platform. Ths s enabled by the defnton of OSG bundles. Bundles extend java lbrarles (JAR fles), allowng them to expose ther functonalty to the rest of the platform n a controlled way. Bundles use the Java manfest fle to declare explctly what does the component provde to the rest of elements (n the form of java packages) and what does t requre n order to work property (ether java packages or complete bundles), provdng n both cases versón compatblty nformaton Ths drectly addresses the 'JAR hell' problem of complex Java-based systems, greatly easng the deployment and confguraton of new software. Addtonally, OSG bundles collaborate through a lghtweght servce mechansm, wth servces beng rantme Java objects that mplement nterfaces. Ths enables effectve decouplng between collaboratng components and smplfes the development of extensble systems. The OSG framework provdes an executon platform for OSG bundles, enablng dynamc deployment and confguraton of the components. These factors make OSG bundles an deal specfcaton for open, composable servce-based ecosystems, as t provdes smple mechansms for effectve nteroperablty and modularzaton All n all, OSG s the best soluton n the Java world for the desgn and mplementaton of modular applcatons. It enables an even lower couplng and brngs the SOA prncpes to the vrtual machne. Our proposal wll use OSG for both the components

3 t wll manage and the actual repostory tself. 2.2 Software Repostory Standards At ths moment there are several repostory technologes that are popular n open source communtes. Every one of them has ts own component model and capabltes. We detal each n ths secton, wth a specal focus n ther support of OSG bundles and federaton capabltes. Maven (Massol et al., 2004) s one of these solutons, a software project management and comprehenson tool. Maven has become the de facto standard for managng Java projects, thanks manly to the support and ts extended use nsde the Apache communty. Maven uses a generc project descrpton model for descrbng software projects named Project Object Model (POM). The POM fle of a project defnes the project's lfecycle as well as ts dependences and confguraton parameters. However, ths model has been defned as generc as possble, n order to cover a wde range of software projects. Henee, t does not accurately reflect the specal relatonshps of specfc types of software components, such as OSG bundles. For example, dependences onto a partcular software package can be defned, but not onto a complete bundle. POM cannot descrbe these knds of dependences, losng nformaton n gong from manfest to POM. Despte ths dsadvantage, Maven repostores provde other nterestng capabltes, such as beng able to store all the nformaton concernng a project (source code, documentaton, etc) or the herarchcal federaton wth other Maven repostores, augmentng the Maven basc dependeney resoluton mechansm. However, ths mechansm does not work wth repostores mplemented usng other technologes. Another model used to descrbe bundles s the OBR (OSG Bundle Repostory) project. Ths model was presented as the draft OSG RFC 112 (Hall, 2006). The RFC defnes both an XML schema for bundle descrpton and the Java API for browsng OBR repostores. An OBR repostory s very smple n ts structure, provdng just an XML fle descrbng the server contents. Ths eases the creaton of OBR repostores as only the bundles and how to download them need to be descrbed, leavng plenty of freedom to desgn the archtecture supportng those operatons. Ths smplcty has the drawback that the clents are forced to carry out most of the operatons, a problem aggravated by the fact that there s no standard defnton of an OBR clent. The draft status of the OBR presents addtonal dsadvantages, such as the lack of mechansms for managng repostory contents (e.g. upload new bundle, update, or delete). and that the federaton mechansm between OBR repostores s not well-defned. In the 3.0 versón of Eclpse, the Eclpse archtecture was changed to use OSG as the project core. Ths change pushed the Eclpse communty to develop ther own bundle repostory, named P2 (Le Berre and Rapcault, 2009). The P2 repostory s wdely used, snce versón 3.4 of the Eclpse Platform uses t as the management mechansm for ts components (OSG bundles). The P2 specfcaton defnes two repostory types: metadata and artfact. The metadata repostory stores Installable Unts, whch are the P2 representaton of an artfact. Ths means that almost anythng can be descrbed as an Installable Unt (confguraton fles, bundles, executables, etc). The metadata repostory also provdes the P2 federaton mechansm. Complementng t s the artfact repostory, whch stores the bnary and descrpton fles assocated to the Installable Unts. There s also a thrd component, the Drector, whch s part of the repostory clent. The Drector s n charge of resolvng dependences and nstallng and unnstallng the artfaets. However, ths soluton has an mportant drawback: Its component model s concerned only wth software drect dependences, beng oblvous to other constrants that could affect artfaets. Also, the ncreasng success of the OSG platform has stmulated the creaton of propretary bundle repostores especally dedcated to store ths type of software components. The Sprng Bundle Repostory (Rubo, 2009) s the most notorous example of ths trend. Ths repostory stores a collecton of bundles and lbrary descrpton fles ready for producton use. A lbrary descrpton fle s a document descrbng a set of bundles that are frequently used together. The access to the repostory s made through Maven, Ivy or a web nterface. The web nterface shows nformaton related to the dependences and exported resources of a bundle, offerng lnks to download them. However, the propretary nature of ths soluton greatly lmts ts applcablty and usefulness. It can be seen that there are a lot of exstng solutons for a bundle repostory. But wth the excepton of the Sprng repostory (whch supports Maven), there are no federaton mechansms between repostores of dfferent types. On top of that, dfferent development communtes have chosen dfferent repostory solutons. Ths fact

4 makes mplementng a dependency resoluton mechansm a dffcult task. Despte a prevous attempt at creatng standardcomplyng repostores (Iyengar, 1998), ths work has not been followed up snce ts publcaton. However, n the dgtal contents world there are many studes (Kraan and Masón, 2005) and proposals (Smth et al., 2003) (Van de Sompel et al., 2006) on ths topc. But none of them have been appled to a software artfact repostory. There are huge dfferences n nature and needs between software components and multmeda contents, and the soluton that works wth one cannot be used wth the other wthout severe modfcatons. 3 PROPOSED SOLUTION In ths secton we detal our proposed soluton. For ths am we have dvded ths chapter n several subsectons. As we have already sad n the ntroducton, our am was to provde an artfact repostory that helps to mprove software ntegraton. To acheve ths, our soluton provdes two man features: A faceted dependency resoluton, and a repostory federaton engne. One subsecton s devoted to each of them. Also, to fully grasp how we propose to fulfll both, frst we ntroduce two basc topcs needed for the proper understandng of our proposed repostory: 1) the characterstcs of the model representaton of software artfacts, and 2) the archtecture of the repostory tself. 3.1 Software Component Metamodel To enable the correct processng of the components the repostory needs to manage, and the ntegraton of nformaton to and from other solutons, t s mperatve to have a model representaton of the software elements. Therefore, we have defned a metamodel wth enough expressvty to capture all the nformaton that we need, but at the same tme hdng non needed data. From ths metamodel, a model nstance descrbng each software artfact, ts capabltes and ts needs can be created. We have named these model nstances Deployment Descrptors. Although the metamodel wll be prmarly used to represent OSG-related artfacts, t has been desgned to support wthout modfcatons other elements, such as non-bundle JARs or addtonal component/servce models (such as EJBs, Sprng beans or Web Servces). The metamodel ams to capture all the relevant nformaton of all types of software elements. Ths s enabled by the concept of Resource, whch we have adopted from the OMG Deployment & Confguraton (Object Management Group, 2006) standard. :<enumeratlon>> ' LocaltyConstrant RE MOTE LOCAL <enumeratlon>> * ConstralntKInd DEFAULT EXCLUSIVE NOT PropertyC onstrant 1 ñame : Strng 1 valué : AnyURI 1 knd : PropertyConstrantKmd propertyconstralnts Constralnt 1 ñame : Strng 1 versionrange : Strng 1 type : Strng 1 klnd : ConstralntKInd DeploymentUnt 1 ñame : Strng 1 versón : Strng 1 type : Strng 1 descrlptlon : Strng dependency <<enumeratlon>> ' PropertyConstrantKnd Dependency MÍNIMUM MÁXIMUM ATTRIBUTE SELECTION CONSUMPTION 1 Id : Strng 1 locallty : LocaltyConstrant 1 ñame : Strng 1 versionrange : Strng 1 type : Strng... exportedresource É] Property S (from resource) 1 ñame : Strng 1 valué : AnyURI propertles É] Resource S (from resource) Fgure 1: Software component metamodel. 1 ñame : Strng 1 versón : Strng 1 type : Strng Fgure 1 depcts a subset of the metamodel. As can be seen n t, Resources are the man buldng blocks. A Resource represents any logcal or physcal manageable system element, and t s defned by three fxed parameters {ñame, versón and type) common to all Resources and an undefned lst of specfc Propertes for each Resource type. The core element s the Deployment Unt. Deployment Unts represent the artfacts whch can be deployed over the envronment contaners. In an OSG context, Deployment Unts represent OSG bundles. Conceptually, a Deployment Unt would be the lowest abstracton level of our software model, beng the unt of software dstrbuton. The Deployment Unt s composed by a set of chldren Resources, Dependences and Constrants that provde computable nformaton about the developer, software lcense, packagng type, exported packages, logcal dependences and hardware compatblty restrctons. Dependences represent the requred physcal and logcal dependences needed n order to assure a smooth runnng of the Deployment Unt. Two types of elements can satsfy a Dependency: specfc Resources or whole Deployment Unts. Ths

5 represents the two man mechansms defned n OSG: Requre-Bundle and Import-Package. In addton to ths, the metamodel allows us to further descrbe the type of Dependency, enablng to dfferentate requrements on remote resources such as Web or REST Servces from requrements that must be satsfed by a unt n the same host (e.g. as t provdes a Java package). Ths aspect s dentfed by a localty parameter that could be remote or local. Fnally, Constrants enable the expresson of requrements over the runtme executon envronment, each one requrng a specfc Resource to be present at (or absent from) the envronment. Followng ths defnton, we have defned three knds of Constrants, dependng on the requred behavor: default (to be present), exclusve (to be present and not used more than once) and not (to not be present). To further extend the Dependency and Constrant models, Propertes can be defned. Each needed Property can be defned by a ñame, an evaluaton functon and a threshold valué. As an example, a typcal Constrant would dentfy a Resource of type "hardware.processor" wth an addtonal Property "speed" of a knd "mnmum" and an expresson valué of "2000". Ths means that the Deployment Unt requres a mcroprocessor wth a mnmum speed of 2 GHz. Both Dependences and Constrants are shown n Fgure 2. the orgnal format (the manfest fle) or the nformaton models of other repostory solutons. Ths means that a conversón from one of those solutons nto our proposal would not result n the loss of nformaton, although the opposte would. 3.2 Repostory Archtecture The need to fedérate wth múltple types of repostores, as well as evaluatng component dependency takng nto account múltple factors have motvated us to desgn the archtecture of the repostory wth a modular and extensble approach. We have selected the OSG platform as the base technology to acheve those requrements, On a sde note, ths allowed us to test the system from the start, n order to check whether the repostory was able to host tself successfully. Fgure 3 shows a layered vew of the repostory components. In the lower levés le the Java Vrtual Machne, the OSG framework, and a datábase soluton for storng the relevant nformaton. On top of t are the basc OSG components from thrd partes that are needed for the repostory to work. The repostory uses Sprng Dynamc Modules for structurng the nter-bundle Communcatons. The EMF (Eclpse modelng Framework) components enable the defnton of the metamodel and provde the tools needed to work wth them programmatcally. Hbernate Provdes an ORM (Object-Relatonal Mappng) nterface wth the Envronment Fgure 2: Dependences and Constrants. The metamodel allows us to represent all the OSGspecfc mechansms, as well as expressng mportant nformaton that s not contemplated on r J É * 1 Sprng-DM OSGÍR4 5 JVM Sprng 3 Fgure 3: Repostory Archtecture.

6 datábase system. Fnally, the Apache Tomcat bundles embed a lghtweght applcaton server that wll host the remote access nterfaces developed for the repostory. The next layer contans the basc components of the repostory: Software Model: Provdes the metamodel defned at the prevous secton, as well as Java bndngs and marshallng mechansms. Repostory Core: The basc component of the repostory. Provdes the man servce nterfaces of the components and defnes the extensón semantcs. Repostory Manager: Ths component manages the physcal artfacts and the component nformaton It provdes CRUD (Create-Read-Update-Delete) operatons over the managed Deployment Unts, Web Interface: Web-based graphcal user nterface that allows human users to browse the repostory contents. Remote Interface: Exposes a REST nterface that enables the communcaton between the repostory and other software. Resolver: The component that processes and resolves Deployment Unt dependences, obtanng unt closures that work correctly together. Fnally, the topmost level of the dagram shows some extensons to the repostory that expand the base functonalty to fedérate wth an addtonal type of repostores (OBR), and apply addtonal crtera for the dependency resoluton. Over the next sectons we wll present addtonal detals on the federaton and resoluton capabltes of the repostory. 3.3 Faceted Dependency Resoluton Ths modular archtecture makes possble the easy expansón of the repostory capabltes. Ths feature s used to defne dfferent types of dependences, each one resolved by a dfferent component. Moreover, ths stracture enables the defnton of a faceted dependency resoluton engne. In t, there are not only several dependency types, but also addtonal condtons that the canddates to satsfy one need to comply. These condtons are called Facets. An example of a Facet s the lcense compatblty. It s perfectly possble that a Deployment Unt satsfes every dependency that another has, but at the same tme do not be vald because ther lcenses are ncompatble. Other Facets could be securty settngs, packagng procedures or executon requrements. Each Facet can be added to Resolver Core Resource Resolver Lcense Resolver Repostory Manager resolve(du) / Gets Servce Reference for all Facets, here only one: Lcense Check All neec led DUs loop ) ^ j 1 getdependences(du) l ^ 1 gettype(dep) l resolvedependency(dep) getfacets(du) satsfyngdus Gets Servce R efenoefo^ a Resource De Dendency Type Resolver ^"I! L- H checkfacet(du, satsfyngdu) <- [ OK/NO Resolve(satsfyngDU1) l Only one DU s OK^ Fgure 4: Dependency Resoluton. getunts(resource) satsfyngdus % ^ 2 DUs found \ 1 between the DU and each satsfyng DU

7 the resoluton engne as an OSG bundle, and t offers ts features as servces that are called by the resoluton core component. An example of ths process that uses a Lcense Compatblty Facet we developed s shown n Fgure 4. In t a user cals the resolver wth the ntenton of knowng the dependences needed for a Deployment Unt (DU). The resolver processes every Dependency, lookng for other Deployment Unts that can satsfy t. After some of them have been found, the resolver searches for Facets that need to be checked and, after fndng one (Lcense Compatblty), makes use of t. In ths partcular example only one unt s vald after ths check. algnment to OSG concepts and the explct acknowledgement of federaton requrements make t an deal canddate for testng our federaton approach. Here we present how we acheve two-way ntegraton between our repostory nstances and federated OBR repostores. 3.4 Repostory Federaton To enable the ntegraton between open source components t s not enough to just resolve ther dependences. It s also necessary to be able to provde the artfacts that fulfll those requrements. Snce open source communtes are fragmented and each one uses dfferent tools and technques, the repostory needs to access and understand the nformaton that les n other repostores. To acheve ths end, the federaton capabltes allow our repostory to communcate wth external types of repostores currently avalable. Federaton support s desgned wth extensblty n mnd, and each technology extensón can be federated just by provdng three servces: Model transformaton servce between our nformaton model nstances and the format the target soluton uses to represent software artfacts. Remote manager servce that accesses the nformaton contaned n the external federated repostores. Remote nterface servce that can be accessed by the target soluton repostores. Ths s only possble f the target soluton has some knd of federaton support for repostores of ts own type. For a more detaled explanaton of how these features can be mplemented we wll use OBR as an example of a target soluton. An example of an nfrastructure that uses ths two-way federaton s depcted n Fgure Sample Integraton: OBR The OSG Bundle Repostory RFC s a draft standard for provdng a common nterface to dstrbuted OSG repostores. Its offcal nature, Gateway Fgure 5: Repostory Federaton. SmartPhone We talk about two-way federaton, as we both act as OBR provders and consumers. For external OBR repostores, we offer an OBR vew that can be used by them n ther standard federated dependency resoluton processes. Addtonally, our repostory can handle a lst of external OBR repostores, and can delégate dependency resoluton requests to the dstrbuted OBR nstances. Both approaches of federaton are acheved though the same method: Model transformaton from our generc model to the specfc component model defned by OBR. For maxmzng extensblty, the OBR model does not explctly rely on OSG concepts. The repostory works wth resources, dentfed by a symbolc ñame and a versón. Addtonally, a download URL s provded for each element. Each resource contans two types of declaratons. Frst, resources offer a lst of capabltes to the

8 avalable : Propertv Constrant knd: CONSUMPTION argument: 256M : Constrant type: hw.memory.ram knd: none repostorv.web.controller: Resource versón: type: osg.java.package vsb: local repostorv.web.war: Deployment Unt versón: type: jar.osg.bundle repostorv.servces.core: Dependencv d:0 versonrange: [1.0.0, 2.0.0) type: osg.java.package model.deplovment.unt: Dependencv d:1 versonrange: [1.0.0,) type: osg.java.package <resource d=" repostory.web.war/1.0.1" presentatonname=" repostory.web.war" symbolcname-' repostory.web.war" versón 1 ="1.0.1"> <capablty name="bundle"> <p n="manfestverson" v="2"/> <p n="presentatonname" v=" repostory.web.war"/> <p n="symbolcname" v=" repostory.web.war"/> <p n="verson" t="verson" v="1.0.1"/> </capablty> <capablty name="package"> <p n="package" v="repostory.web.controller"/> <p n="verson" t="verson" v="1.0.1"/> </capablty> <requre extend="false" flter="(&(package=repostory.servces.core) (verson>=1.0.0)(verson<2.0.0)" multple= name="package" optonal="false"/> <requre extend="false" flter="(&(package=model.deployment.unt) (verson>=1.0.0))" multple-'false" name= optonal="false"/> </resource> 'false" 'package" Fgure 6: Model mappng between OBR and the presented model. envronment. They represent ether the whole element (named bundlé), or a software element such as a java package (named package). Each capablty s further refned through propertes, whch have a ñame, valué and valué type (e.g. Strng or number). The second knd of elements are requrement statements, that demand the presence of resources n the resolved confguraton. They model logcal requrements that must be satsfed. Ths specfcaton's concepts can be mapped to a subset of the Deployment Unt model. Fgure 6 presents an example mappng between both models. Every OBR concept has an equvalent defnton n our abstractons. The OBR resource plus the bundle capablty elements are mapped to the base Deployment Unt concept (The defnton of unts as resource subclasses allows ths). Addtonal capabltes are mapped to unt exported Resources, such as the presented java package. Resource vsblty nformaton s lost, whch s not problematc for OSG-specfc elements (all of them are local), but presents the lmtatons of OBR for reasonng over dstrbuted physcal envronments. Addtonally, each OBR requrement s mapped nto a logcal Dependency. All the nformaton derved from the Constrants from our model has no equvalent. Ths bears no mpact from the OBR perspectve, as our repostory provdes all the requred nformaton. On the other hand, the use of federated OBR repostores by our specfc nstance can result n lesser-qualty results, n cases when physcal concerns need to be evaluated. 4 VALIDATION ITEA-OSAMI s an European project whch s beng executed by 34 partners from both the academa and enterprse. The objectve of ths project s to develop open source common foundatons for a dstrbuted, dynamc servce-orented platform. Consortum partners come from múltple domans (healthcare, personal, and moble offce), follow dfferent software development processes, and depend on exstng open source resources from dfferent communtes. Ths created a need for a centralzed platform that eased partner ntegraton The repostory presented n ths artcle has been developed and deployed n order to address the project requrements. It has wdely succeeded at ths task, becomng the central pont of the ITEA- OSAMI ecosystem. ITEA-OSAMFs runnng nstance of the repostory can be publcly accessed at: (Fgure 7 shows the vsual aspect of the web nterface, whs s lstng several unts already resolved). After assessng partner concerns, we provded two extensons to the repostory. Regardng federaton, OBR support was developed, as t was mandatory to support OBR-based deployment clents as well as accessng open source bundles

9 íétfdíí f(4tfk 0$t<tfy Man page Fnd Resources Lpload Lat Search results: Ñame Versón Descrpttou 2.L-pm.t.Dam.r5pDE.tDry.cU2nt 2.L-pm.t.OE-am.modal. =.w ore. E-prnETT am arrork. cor= ccm. E-prn Ec-Líc=. OTE. apach=.ccmmone-.lc-e Ín.s. or E. E-prn E rr am awcrk. c-xm ore, ^une&amewofkjeam ; : =. = :!:]_- = =." : =.:": :::: :: : DTE. EH:lÍpE-2.DE-EÍ?t=r. = : LLjz E-2. E-:^Lí7-L.: cumen cr=r. = : Lp E-2. c cr^.j ct= % E-y E- t smb L-nc.1= 24 Deplo>Tnent unts feuncl dsplayng 1 to 10. Showngpage 1 of 3 'T' ÁctlODS H«>- HXP H*vP HwP Fgure 7: Screenshot. developed at two thrd-party repostores. Addtonally, snce the begnnng of the project open source lcense management was a potentally conflctng aspect among partners. However, these ssues were addressed wth the defnton of a lcense-aware dependency Facet, based on the dependency compatblty analyss module from another project partner. In ths context, we have valdated the proposed metamodel, as well as the defned archtecture and extensblty capabltes. It has successfully been used by all the project partners, provdng a common ntegraton pont for the developed open source software and servces, both nternally created and from the man open source communtes. 5 CONCLUSIONS AND FUTURE WORK In ths artcle we have proposed an archtecture of a model-based repostory for the ntegraton of software components, wth a specal focus on OSG bundles. Ths repostory has been desgned around an nformaton model for software components, whch manages to show all relevant data whle hdng the undesred complextes. We have also shown how ths archtecture has been desgned to be extensble. Usng ths modularty we have demonstrated how t can be easly expanded to support two mportant features: Faceted dependency resoluton: Offers support for an unlmted number of condtons that dependences are forced to respect. Two-way federaton: Enables our soluton to access contents avalable n other repostores and at the same tme expose tself to them. We also have developed a lcense compatblty Facet and the components needed to acheve federaton wth OBR repostores. Fnally, our work has been valdated n the context of the ITEA-OSAMI European project, where t has been subjected to an ntensve use by more than 30 partners from dfferent countres and sources (unverstes, research centers, software and telecom companes, etc). Concernng future developments, the most straghtforward way to mprove the already exstng work s through the support of more repostory technologes for federaton and new dependency

10 Facets. In the frst feld, federaton wth Eclpse P2 would be the most nterestng repostory to support, snce t sees wde use n several communtes. About dependency Facets, more of them could be developed, takng as an example the lcense check already created. These components are relatvely easy to mplement thanks to the nfrastructure of our proposal. Not drectly related wth ths, but also nterestng, are the possbltes for the repostory to work n a cloud envronment. Ths lne of work s concerned not only wth the deployment of the repostory tself, but also wth how t can manage the software artfacts of several types of cloud solutons (IaaS, PaaS or SaaS). To support features lke these the nformaton model would probably need to be extended and the archtecture of the repostory revsed. ACKNOWLEDGEMENTS CORDRAtm Workshop. In: D-LbMagazne, Vol. 11, Num. 3. Smth, M., Barton, M., Bass, M., Branschofsky, M., McClellan, G., Stuve, D., Tansley, R., Walker, J.H., DSpace, An open Source Dynamc Dgtal Repostory. In D-Lb Magazne, Vol. 9 Num. 1. Van de Sompel, H., Lagoze, C, Bekaert, J., Lu, X., Payette, S., Warner, S., An Interoperable Fabrc for Scholarly Valué Chans. In D-Lb Magazne, Vol. 12, Num. 10. Tansley, R., Buldng a Dstrbuted, Standardsbased Repostory Federaton, The Chna Dgtal Museum Project. In D-Lb Magazne, Vol. 12, Num. 7/8.Moore, R., Lopes, J., Paper templates. In: TÉMPLATE'06, lst Internatonal Conference on Témplate Producton. ScTePress. Van de Sompel, H., Chute, R., Hoschstenbach, P.. The adore federaton archtecture: dgtal repostores at scale. In: Internatonal Journal on Dgtal Lbrarles, Vol. 9, Num 2. Object Management Group. Deployment and Confguraton of Dstrbuted Component-based Applcatons Specfcaton. Versón 4.0. Aprl The work presented n ths artcle has been performed n the context of the European project ITEA-OSAMI, under grant by Spansh Mnstero de Industra, Tursmo y Comerco n the PROFIT program. REFERENCES Deshpande, A., Rehle, D., The Total Growth of Open Source. In: Proceedngs of the Fourth Conference on Open Source Systems. Sprnger Verlag. Evelson, B., Hammond, I, The Forrester Wave: Open Source Busness Intellgence (BI), Q3 2010, Forrester Research. OSG Allance, OSG Servce Platform Reléase 4 Versón 4.2 Specfcatons. June Massol, V., Van Zyl, I, Porter, B., Casey, J., Sánchez, C, Better bulds wth Maven. Mergere Inc. Hall, R. S., OSG RFC-0112 Bundle Repostory. February Le Berre, D., Rapcault, P., Dependency management for the Eclpse ecosystem: Eclpse P2, metadata and resoluton. In: Proceedngs of the l st Internatonal Workshop on Open Components Ecosystem. ACM. Rubo, D., Pro Sprng Dynamc Modules for OSG Servce Platforms. Apress Iyengar, S., A unversal repostory archtecture usng the OMG UML and MOF. In Enterprse Dstrbuted Object Computng Workshop. EDOC '98. Proceedngs. Second Internatonal. Kraan, W., Masón,!, Issues n Federatng Repostores, A Report on the Frst Internatonal