Skip to main content

[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:

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 (preferred) or on this mailing list, or both.


Back to the top