Managing enterprise client deployment with p2

751 views

Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Managing enterprise client deployment with p2

  1. 1. Managing enterprise client deployment with p2 Thomas Kratz 12.11.2010 thomas.kratz@eiswind.de
  2. 2. About me Born 1970, Started on a ZX81 in the early 80‘s Doing a daytime job with JSF Frontend (leave that uncommented) Developing a commercial book publisher‘s software with my own company Eiswind Software on OSGi, Spring, Hibernate, Eclipse RCP since 2007 Casual Eclipse and Apache project contributor (could you provide a patch ?) Sometimes dreaming in code.
  3. 3. The scenario • RCP Client talks to backend over HttpInvoker • Server talks to client through XMPP Synchronous Remote procedure calls Asynchronous messaging (XMPP)
  4. 4. Client-Server compatibility • Client and Server share domain classes and service interfaces Client bundles Server bundles Shared bundles must be „wire compatible“
  5. 5. Definition of „wire compatible“ • OSGi versioning gives us – major, minor, micro – qualifier • We defined that „wire compatible“ means major,minor and micro must match. • Qualifier my change, shared bundles must be API compatible Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-Name: Domain Plugin Bundle-SymbolicName: de.eiswind.mango.domain Bundle-Version: 1.7.0.20101020
  6. 6. Uhh, we have customers • We are not multi-tenant, so each customer has his own server instance. • Updating the server at customer site happens at different times • Client and server should update from single central repository
  7. 7. Managing the client • At login time the client first queries the server for his OSGi version of the shared bundles • Then he looks in the repo for updates that match the servers version in terms of „wire compatible“
  8. 8. Managing the client (2) • If, at login time, server and client version do not match, Workbench starts up for getting the update with user interface disabled. • If an update is available, but would need server upgrade first, it is ignored.
  9. 9. The solution: p2 queries • We know the servers shared Bundle version, so we do a query for compatible updates of the product Installable Unit: IQueryable<IInstallableUnit> queryable = provisioningContext.getMetadata(new NullProgressMonitor()); IQueryResult<IInstallableUnit> matches = queryable.query( QueryUtil.createIUQuery("de.eiswind.mango.client.core.mango", new VersionRange(Version.createOSGi(major, minor, micro), true, Version.createOSGi(major, minor, micro + 1), false)), new NullProgressMonitor());
  10. 10. Building the Update • The QueryResult gives us all compatible IU‘s from the repository. We pick the latest and construct an update: IQueryResult<IInstallableUnit> allIUFromRepo = getAllInstallableUnitFromRepository(provisioningContext); List<IInstallableUnit> units = new ArrayList<IInstallableUnit>(); for (Iterator<IInstallableUnit> it = allIUFromRepo.iterator(); it.hasNext();) { newIUFromRepo = it.next(); units.add(newIUFromRepo); } // check if something is available at all omitted here Collections.sort(units); // get the latest matching update newIUFromRepo = units.get(units.size() - 1);
  11. 11. The UpdateOperation // now we must ensure that we don‘t get updates we // do not want Update update = new Update(oldIUFromProfile, newIUFromRepo); ProvisioningSession session = new ProvisioningSession(agent); final UpdateOperation operation = new UpdateOperation(session); status = operation.resolveModal(sub.newChild(100)); // check status omitted here operation.setSelectedUpdates(new Update[0]); for (Update available : operation.getPossibleUpdates()) { if (available.equals(update)) { log(IStatus.INFO, "Update matches available: " + update, null); selected[0] = available; operation.setSelectedUpdates(selected); } // now run the ProvisioningJob
  12. 12. Coming up: The server • Currently server is beeing ported to the virgo runtime • Virgo doesn‘t work with p2 yet, but knows the concept of a „remote repository“
  13. 13. Server updates P2 and virgo repo on eiswind.de Server at Customer BServer at Customer A Pick up virgo repository updates
  14. 14. The update cycle Server at Customer A P2 and virgo repo on eiswind.de 1) 2) Client recognizes server update 3) Client pulls update from p2 repo
  15. 15. Thanks for listening • If you‘d like to see the full update code example, just ask. • You can reach me on • thomas.kratz@eiswind.de • http://www.eiswind.de

×