| Re: [ecf-dev] ECF for OSGi RS/RSA 1.1 Reference Implementation |
Hi Folks,
Background
For those not already aware: ECF 3.9.0 implements two OSGi specifications: Remote Services (chap 100 in enterprise draft specification [1]), and Remote Service Admin 1.1 (chap 122 in enterprise draft specification [1]). As well, our implementation fully passes the RS/RSA 1.1 Compatibility Test (CT) suite. We run the CT test suite as part of our automated build, automatically running the OSGI CT as a result of any change to the relevant ECF code in order to guarantee continuous specification compliance and to guard against regression.
Reference Implementation
Prior to formal release of the R6 enterprise specifications (later this year), the OSGi Enterprise Experts Group (which I am on) chooses a Reference Implementation. ECF submitted it's RS/RSA implementation as a candidate for the RS/RSA 1.1 Reference Implementation. This year, there are two candidates for the RS/RSA RI: ECF's and Amdatu (a relatively new open source Foundation).
OSGi Selection Criteria
Because there are two candidates, the EEG had a meeting last Thurs (9/11) where the candidates presented arguments in their favor, given a previously defined set of Selection Criteria. Though I would like to, I'm not able to point you at the Selection Criteria or ECF's (and Amdatu's) responses to the criteria because these OSGi Alliance documents have not been made public.
I can tell you that ECF's responses to the Selection Criteria, as well as my further arguments in favor of ECF as RI were *very strong*. What do I mean by 'very strong'? The Selection Criteria included several aspects that ECF has been and is exceptional on...for example, we've been part of the EF simultaneous release for the past 9 years, and had an average of 4 releases per year over all those years. This makes us exceptionally reliable as a project. All of these releases have conformed to both the EF Development Process and the Simultaneous Release Requirements...both of which are very rigorous and quality focused in the open source world. Additionally, we have performed all the project requirements of the Eclipse Foundation IP/Legal requirements, which are generally agreed to be exceptionally rigorous in terms of open source Legal/IP/provenance.
Community Building and Support
As a mature, independent-led EF project, ECF has a large and vibrant community, with both commercial and non-commercial consumers. We have provided technical support, as well as learning/tutorial docs for RS/RSA, and this also makes us valuable as a RI, since part of the function of a RI is to allow consumers to use the RS/RSA specifications without having to understand all of specification, and without having to build/provide their own implementation....i.e. to make it easy to create, use, debug, test OSGi remote services. IMHO there is much more do to here to OSGi RS/RSA interoperability and make the specification as well as our implementation easier to understand and use, but ECF is out in front in this effort, and this will continue as ECF focuses on RS/RSA-specific tooling as a major theme for Mars simultaneous release (June 2015).
Useful Technical Qualities
ECF's technical approach of having a modular provider architecture, which allows new discovery and distribution providers to be used/substituted...or created as necesssary. My own experience shows that in remoting/communications it's often the case that application-level requirements affect messaging transport decisions (e.g. security, performance/bandwidth constraints, server/service integration, deployment constraints). ECF both provides a number of existing modules for discovery and distribution (represented by 5+ discovery providers and 6+ distribution providers produced by use), and provides documented and stable APIs for configuring and/or creating custom discovery and distribution providers, along with tutorials and examples of how to do this. This modularity creates flexibility for consumers, allowing them to 'mix and match' spec-compliant discovery and distribution providers and/or configure, extend, or substitute their own implementation of these subsystems (in open source or not), without having to re-implement the specification.
In preparation for the EEG presentation last week, I presented written arguments similar to the above, with more details as well as many supporting links/references to ECF code, documentation, and community (this list, forums, wiki, etc).
RI Voting Process
Since the EEG did not reach consensus about a RI choice during last week's meeting, the OSGi process specifies that to select the RI an EEG vote is to be taken. The call for this vote on the EEG mailing list occurred yesterday/Monday Sept 15. According to OSGi Alliance rules, the EEG members allowed to vote on such question are limited to Strategic and Principal members [3]. Unfortunately this set of voting members does not include me (I am an invited researcher on the EEG), nor does it include the Eclipse Foundation (a contributing associate member).
Which brings me to why I'm writing this note:
a) to inform the ECF community that this vote is going on
b) to ask: if you use and/or support ECF's work on RS/RSA, would like to see ECF be considered as the RS/RSA reference impl based upon its merits, please consider communicating that support to the Strategic and Principal members who are eligible to vote on the EEG [3].
The vote is going to last until COB Wednesday, September 24.
Thanksinadvance for your continued support of ECF.
Scott
[1] http://www.osgi.org/Specifications/Drafts
[2] https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements
[3] http://www.osgi.org/About/Members
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev