During a discussion on Twitter about provisioning OSGi based applications, I mentioned this was a topic of debate at the Enterprise Expert Group and was asked if I could post some details. Because of OSGi Alliance confidentiality rules, it's not possible to publish details. But I can give a general summary.
As I may have mentioned before, one of the biggest gaps we identified in the enterprise release is improved support for the enterprise application development lifecycle (developing, building, testing, deploying, updating etc.). While some of this is going to depend on specific tooling extensions, some aspects are things the EEG can help through standardization. One of those is the OSGi Bundle Repository, otherwise known as RFC 112, which is largely based on the work Richard Hall did with the Oscar Bundle Repository. (It should also be noted that the OSGi Alliance hosts a bundle repository, and that some vendors of OSGi-based infrastructure also provide bundle repositories.)
Before its revival in January, the RFC was last worked on in March, 2006. Meanwhile, the Eclipse P2 project has continued to evolve, addressing much of the same space (and more besides). The current RFC 112 draft was published as one of the early design drafts released for EclipseCon / OSGi DevCon last month.
One challenge the EEG faced was that no one on the EEG knew much, if anything, about what was going on with P2. We understood that we needed to take the P2 work into consideration - this was clearly stated during the OSGi BOF for example, in addition to other community members pointing this out. It was necessary for the EEG to get up to speed on P2, and Pascal Rapicault was kind enough to join the EEG calls and give us a presentation.
What has emerged is a kind of consensus, at least on the approach to the requirements. Here I need to also mention that the normal OSGi Alliance standardization process starts with an RFP, not an RFC. OBR was an exception to this rule, and when questions started to come up about the requirements behind its design, it was necessary for the EEG to take a step back and document the requirements in an RFP we could all agree to. This is basically where we are in the process right now.
During today's call however we got a little closer to returning to the design work. At EclipseCon we announced the schedule for the next release of the OSGi specifications - R4.2. The core is going to be published in June, the compendium in July (adding distributed OSGi and the Spring-inspired Blueprint service), and an enterprise "profile" is scheduled for Q4 (I suppose this means December, realistically) that will contain the various Java EE component mappings. The OBR standard is also targeted for the December release. To get there, as for any other part of the OSGi standard, we have to follow the OSGi Alliance process and ensure everything is approved by the membership and the Board of Directors.
Anyway, where we are in the process is trying to gain consensus around the requirements. The debate is basically over what should be considered in scope for the standard. The most fundamental requirement is to standardize on a repository for bundles and their associated resources, so that someone searching for a particular bundle or set of bundles has a place to find and retrieve them, and in so doing resolve any dependencies they may have among each other and/or to external resources such as configuration files or data resources.
The debate really centers around how much further to go. I think it's fair to say we reached consensus on two items: the layered approach and that the core foundation is the repository. Requirements for additional features and functions on top of the repository are not really considered optional by developers who need tools to assemble, provision, and deploy OSGi-based applications. But this additional level or levels may also not be necessary to standardize. If we do a good job with the core, vendors and open source projects can add on these other capabilities.
One other thing we may want to tackle - and there is another RFP being written about this - is to define an application in the context of an OSGi framework. This is a controversial topic, since we want to avoid enforcing a static style of application definition onto a dynamic framework, but nonetheless seems like it would be useful to help support additional development lifecycle stages, beyond a simple retrieve & resolve.
6 years ago
Posts
Speaking personally, I think the whole issue of provisioning is quite a bit larger than P2. Further, I think there are a variety of models that are equally valid and far different than P2. Granted, I have no problems with people pursuing provisioning from the OSGi perspective, but quite frankly, I have no idea why we're tying OBR to this issue.
ReplyDeleteAs I've mentioned on the EEG call, this is exactly like blocking the development of a file system because we don't know all the possible ways that something can use its contents. Or blocking the development of the web because we haven't spec'd the possible uses of the contents.
These two issues are clearly orthogonal and shouldn't be linked. It makes as much sense as linking the development of S3 to a distributed file system which uses it.
Hal - you are right, these issues got linked in a way that perhaps they should not be. The OBR work was revived due to gaps in requirements coverage of the EEG work, which included a discussion of provisioning. Actually the gaps identified included a good bit of the development lifecycle. What we in the EEG can do to help is standardize OBR as a foundational layer - perhaps your point is that we shouldn't or can't standardize the provisioning mechanisms layered on top. I think that's what was agreed.
ReplyDelete