[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[ecf-dev] continue to support RFC119 service properties?
|
Hi Folks,
I've begun the process of moving the ECF implementation of RFC119 over
to using the new OSGi R4.2 draft remote services specification. For
reference and full discussion, this work will be tracked by this bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=290446
I need to start off this email by clarifying a few things:
In ~June 2009 (right around the time of the Eclipse/ECF Galileo release)
the OSGi Enterprise Experts group chose to deeply restructure RFC 119
(the distributed OSGi spec). This caused a fair amount of frustration
for me and others interested in providing spec-compliant implementations
of remote services, as RFC 119 had been being worked on for fair amount
of time (> 1 yr), and it seemed to me very late in the game to have an
RFC be changed so deeply. But the choice to change things was made by
the the OSGi folks.
Now, rather than RFC119, there is a new section in the OSGi r4.2
compendium draft called "Remote Services" (chapter 13). Happily, this
new specification is *very simple* as compared with RFC119, and includes
*no java classes* in the spec at all. So what does it specify? Well,
the remote services spec simply defines a small set of service
properties that define what service hosts and service consumers use to
signal to a distribution provider that it should expose a service for
remote access. The mechanism/java interfaces for doing this (i.e. the
'discovery' and 'distribution' parts of RFC 119) are not specified in
the remote services spec *at all*.
For us and other implementers this simplicity is a good thing, as it
simply specifies what the users of remote services need to do to have
distribution providers to expose a remote service (host), and access a
remote service (i.e. proxy). I'm sure that getting to this simplicity
of specification (i.e. just service properties) was/is the goal behind
restructuring RFC119 so deeply...and I applaud the desire to make
simplicity of the specification paramount. I think the timing of such
changes was terrible, however, coming so late in the development,
review, and voting process for RFC119.
But in any event, ECF can/will easily support the new remote services
specification (i.e. the service-properties-only spec), and I've begun
this process with bug 290446 above. Specifically, I've added the new
service property names as specified in remote services/chap 13 to
IDistributionConstants, ECF's distribution constants interface. This is
just the first step, but since ECF is already structured to separate API
(remote services and discovery) from implementation/protocol (i.e.
providers) it will not be technically difficult to accomplish.
There are some design considerations, however, that I would like to pose
to people on this list...particularly those that are currently using the
ECF RFC119 implementation from Galileo (and the recent 3.1.0 ECF release).
One choice we have is to
1) Continue to support RFC119 (i.e. by responding to the
RFC119-specified service properties) and *add* the support for the
remote services properties.
2) End/deprecate the support for RFC119 and *only* support the new
remote services properties
Happily, with very little difficulty, ECF's distribution implementation
(based upon ECF's abstract remote services API rather than any
particular protocol) can continue to support RFC119 (i.e. 1). OR we can
end support for RFC119, and support only the new remote services
properties.
But, as always, there are some tradeoffs here. Here are some downsides
to these two strategies
If we do
1) Supporting both RFC119 and the new remote service properties will
result in some additional complexity in our API. For example, we
currently have an interface called IHostContainerFinder that is
responsible for finding/getting relevant ECF containers...i.e. those
that meet the meta-data specified set of intents. If we continue to
support RFC119, we will have to *add* methods to this interface (to
support the remote services spec meta-data service properties). This
will make this and a few other interfaces slightly more complex. This
interface doesn't *have* to be used by clients, however, and so this may
not be a huge problem for people.
If we do
2) All existing clients that use the existing ECF implementation of
RFC119 will have to change the service properties that they use. That
is, if we *only* support the new remote services spec (and deprecate the
RFC119-specified service properties), then clients will have to be
changed to use the new service properties rather than the old
ones...both for remote service registration (i.e. registerService), and
for clients that have service property filters in their lookup (e.g.
using ServiceTracker).
I'm interested in how people feel about this design choice. Is it
important to people to continue to use RFC119-specified service
properties for service registration and lookup? Having/supporting *one*
set of remote service properties will ultimately be simpler for users
(and for us), and even if we do support RFC119 we will likely deprecate
all the old service properties and eventually remove them.
Ok, thanks for reading...and feel free to post thoughts/desires on bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=290446 (preferred) or on
this mailing list, or both.
Scott
