Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Using ECF to create a osgi cloud...

Hi Chris,

On 1/28/2013 9:58 AM, Chris Hawk wrote:

We have an equinox based system that we are investigating a way to port it for a cloud environment. The initial idea is to have a central node (perhaps one for each customer) and reusable satellite nodes that will provide multi tenancy remote services for each other. For each node we will define "roles" that will help us to identify the kind of services provided and in the central node we configure which satellite nodes it could use.

I believe that ECF's RS and RSA implementation would the main component in this puzzle. But I couldn't find any resource yet that could help us to choose which providers we would use to achieve our goal.

This is a very interesting question. I regret to say we don't have a lot written down (yet) comparing the relative non-functional characteristics of the various providers. Perhaps we can use your need to get some of these comparisons and experiences written down...with input from as many people in the community as well as from the ECF committers. To this end, I will create a wiki page specifically to record experiences with the various providers...for remote services specifically. As soon I do so, I'll send a notice to this mailing list. Hopefully...with enough input from community members and can turn into a useful resource to address these kinds of questions.

A little bit of seed+context information

In the context of ECF's implementation of OSGi remote services, we are basically talking about discovery providers (to support remote service discovery), and distribution providers (to support the actual remote method calls). So, I would like to break things down broadly with discovery and distribution.


Zeroconf (jmdns)
SLP (service locator protocol)
'File-based' discovery [1]


ECF generic
REST-based providers
    Jaxr (under construction)
SOAP-based provider
Generic-based providers

The main thing to say as a starting point for this discussion is that these providers have different non-functional characteristics...i.e. they differ in how/what kinds of security, performance, reliability the provide under various runtime/deployment situations. For example, WRT may be that for given application...because of app specific security requirements...that it's not possible or desirable to use multicast-based mechanisms (e.g. SLP or Zeroconf). OTOH, there are deployment scenarios (e.g. Internet with capital 'I') where using some discovery approaches will be practically difficult.

One other broad point to make about both discovery and remote services providers. ECF's architecture [2], supports the creation/use of arbitrary other providers (i.e. making/using your own custom provider). Combined with the fact that all the existing providers (for both discovery and remote services) are available in open source...and can be used as examples and/or extended to create actual implementations. This makes it quite easy to create custom providers (for both discovery and/or distribution), that are potentially proprietary (up to you), and can perhaps meet the specific requirements better than any of the existing providers. The question of 'what's right'? in those situations has to be based upon an examination of the specific requirements and runtime behaviors for the app.

As well, the providers can/will differ in how performant they are under different sorts of use situations. Further, because of our own resource limitations, some providers can/have gotten more technical and community attention than others. If work is functionally enhance a provider, to do performance work, or to fix bugs...we will do what we can to provide the necessary support. In some cases, however, we may need some help from the community...or won't be able to do the desired work.

So...with that...let the discussion commence. I'll create a wiki page today/Monday, and notify about it's existence in response to this thread.

BTW...thanks in advance to those that are able/willing to 'chime in' about their experiences with various providers and their use cases. That a real, valuable contribution to the ECF project and the community. So again: thanks.




ecf-dev mailing list

Back to the top