[
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
