[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[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
