Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[ecf-dev] Re: Riena Creation Review 19th Dec 2007

Hi Christian/all,

I didn't know about the change in EF procedure (i.e. no bugzilla vote) until reading your posting (this morning, after the Riena review call), so I would like to say the following:

First, I'm +1 for creating the Riena project.

But, as the leader of a mature project (ECF) that seemingly could/has/will have significant overlap with Riena, I would like to make the following statement. I had planned to use the project creation bug for this, but I'll instead make it here.

ECF was created as a project created to define communications APIs of a variety of kinds. The common thread for all of these APIs, however, is that they are defined in a transport-independent way...that is, the use of the API does not dictate or require the use of a particular protocol/messaging transport. Although this may seem like a small thing technically, it turns out not to be...because of issues of addressing/endpoint identity, the need for and difficulty of runtime extensibility of communications, security, and other things.

More and more, there are commercial, open source, and standards efforts focused around scenarios for interprocess communication to support remote OSGi (OSGi client/OSGi server, non-OSGi-client to OSGi-server, multipoint/cluster OSGi, etc). Examples of existing implementations are r-OSGi, various commercial products and internal efforts, Nyota, ECF providers based upon simple tcp, JMS, XMPP, JBI/SCA-based work as well as others). Plus there are the beginnings of standardization efforts within the OSGi Enterprise Expert group (rfcs/rfps 119).

My plea to the Riena project team is to work with ECF to define and use (and ultimately standardize) *open* middleware APIs for remote OSGi services, that are not bound to any particular communication protocol(s). Note this implies more than just defining open source APIs, but it also implies using and in some cases defining open protocols. My observation is that although in the interoperability interests of both developers and users, this is sometimes a very hard thing to ask of commercial organizations...to go out of their way to make it possible for (in some cases) competitor's and/or OS software to be used in preference to their own.

I think by doing this cooperatively, instead of redoing/reimplementing common mechanisms (e.g. identity, discovery, security, transparent and/or non-transparent access to remote services), both the ECF project and the Riena projects can provide a great service to the Eclipse community, including both open source and commercial members. Riena and ECF can/could aspire to help define and standardize remoting for OSGi services in general...and provide true interoperability and vendor independence.

To this end, the ECF project will encourage, support, and enable any efforts to

a) Create a Nyota-based ECF remote services provider (i.e. expose Nyota remote services via ECF remote service API)

b) Use the ECF remote services and discovery APIs for Riena efforts (e.g. persistence, other remote services)

c) Use of/and or enabling of authentication and authorization efforts undertaken in Riena

d) Any other opportunities for inter-project collaboration that are identified...for example, a ECF+Riena-based exemplary application.


Realistically speaking, as an all-volunteer project, on some occasions, taking on these additional efforts may require cooperative inter-project resource commitment and planning...i.e. ECF committers may not be able to do *all* the work associated with the above integrations. I strongly urge the Riena team to cooperatively take on some of this burden, with the help and support of the Eclipse Foundation and EMO, in the interests of providing the best, open, interoperable solutions for the community. ECF will commit to doing everything within our means to support such efforts.

As a relevant informational aside, Jan Rellermeyer (author of r-OSGi) is in the process of completing an r-OSGi based ECF remote services API provider. This work will soon be going through the EF IP review process for anticipated inclusion in ECF 2.0 (Ganymede). Note the technical work involved was not large (several weeks of Jan's part-time effort), and results in the ability for remote services based upon the ECF remote services API to use r-OSGI and/or other providers (jgroups, JMS, XMPP, ECF generic, etc) without modifying application-level code.

I look forward to working with you all. I invite you to join the ecf-dev@xxxxxxxxxxx mailing list, as well as examine/use/critique and suggest improvements and/or needed generalizations especially to:

ECF Core API (identity, basic distributed container model): http://wiki.eclipse.org/ECF_API_Docs#ECF_Core

ECF Discovery API (dynamic service discovery): http://wiki.eclipse.org/ECF_API_Docs#Discovery_API

ECF Remote Services API:
http://wiki.eclipse.org/ECF_API_Docs#Remote_Services_API

Thanks...and best of luck with Riena. Please do keep these communities in touch.

Scott


Christian Campo wrote:
Hello Heiko,

there will be no bugzilla entry where you vote and then after a week we see whether the vote was successful.

Instead anybody who has issues with the Riena proposal or wants to vote against it has to say so during the confcall.

The advantage is that we know directly after the call if the creation review was successful.

The way how projects are voted on is a decision taken by the Eclipse foundation and not by us the Riena project team. So in this case they told us that for now they didn't want to use the bugzilla mechanisme anymore.

I wasn't aware of this changed procedure until I wrote the second posting. So the quote from me "Please vote for Riena" is missleading (or wrong :-)).

christian campo


Heiko Seeberger schrieb:
Hi Christian,

Where/how can we vote?

Heiko

Christian Campo schrieb:
Hi all,

Creation Review call is on the 19th of Dec. Check out the slides at http://www.eclipse.org/proposals/.

And please vote for Riena.

thanks

christian campo



Back to the top