Hi Jeff,
I agree (that this can/should be a good interaction between ECF and
Riena). As I think we're all aware, ECF's work to date in remote
services (i.e. the discovery API and the remote services API...and
providers zeroconf, SLP for discovery, and ECF generic, xmpp, JMS,
r-OSGi for remote services) is just the beginning of a 'complete'
enterprise solution for distributed OSGi. Riena, of course, is just
getting going as an open source project.
I think ECF's strength as an open, transport-independent API(s) does
allow Riena to address requirements for transport plugability and
benefit immediately from working with these two ECF APIs (building
above and providers below)...with the only cost being a little
collaboration. And of course, we are completely willing to address
new requirements on these APIs as they might be uncovered.
So +1 for close collaboration and Eclipse runtime efforts playing
together in a first class way. As you say, it seems essential for
joint success.
Scott
Jeff McAffer wrote:
This feels like the start of a very
good interaction. Clearly these are two significant code bases that
have evolved independently and there is some overlap. The key to
success, especially given our focus on runtime technology, is ensuring
that the various Eclipse pieces can play together in a first class way.
That is a long term challenge that will be met by the community taking
a series of baby steps. Personally I'm very excited about the
possibilities
in this space and look forward to a close collaboration.
Jeff
Hi Scott,
thanks for your +1 on Riena.
I wasn't sure what to say to your post (thats why the answer took so
long).
I think we
all want the same thing, but have a sometimes slightly different view
on
things.
Do Riena and ECF have a significant overlap ? I tend to say no, because
ECF covers so many
aspect of communication like datashare, filetransfer, chat, voip,
skype,
jabber, discovery
(and many others that I am not aware of) which Riena has no equivalent
and has no plans
to create one (our "discovery" does not really count I believe).
Riena on the other hand is not only communication but also security,
objecttransaction,
persistence, reporting, a whole new way to create client UIs. (and many
other things)
So the discussion is about Remote Services. There we have the two parts
a) transparent remote
service and b) non-transparent remote services. Now we believe very
much
in a) while you believe
much more in b). (So I could even argue we have no overlap at all but I
dont do that seriously)
But nevertheless Riena's communication component only does the
transparent
remote services part.
There is no non-transparent approach and no plan to create one. The
reason
is that we believe
that a component A should be able to call component B no matter whether
its remote or local (maybe
its both or its sometimes remote and sometimes local).
Now Riena created its own implementation previously called "Nyota"
beginning of last year when
no other implementation existed that did implemented remote service the
way we thought its right.
Some people had created remote services on the server in a transparent
way like r-osgi at that time,
but had their own more or less proprietory way to then call that
service
on the client (i.e. r-osgi).
They didn't have a OSGi Service as proxy on the client, ECF also didn't
have that so thats
why we created a solution for ourselves.
ECF has changed in the meantime and r-osgi is obviously becoming a part
of ECF.
So the next steps are to include security (authentication,
authorization)
in that picture:
- only allow service to be called when a valid user is logged in on the
client
- call the OSGi Service on the server with the Subject.doAsPrivileged
- transferring session ids
- accessing and maintaining permissions on client and on server and
making
them accessible in a
(again) transparent way, in other words so that you can find out
if the current user has a permission
with the same API no matter whether you are on the client or on
a server
As your one plea for an open middleware API I am all for it to define a
standard way how
remote services are published (on the server) and accessed on the
client.
OSGi is a good
starting point for services in general and if we can define a way how
he
can make them remote
I am happy to work together with ECF.
Defining a technical dependency in Riena components in general to ECF
components
is nothing I really
want.
ECF in my view (and thats were we have slightly different point of
views)
is a major player in
the communication area in the Eclipse ecosystem but for remote services
its one of many
possible implementation of a yet to be defined Remote Service Standard.
I am sure also the OSGi EE group once they can come up with a standard
will allow multiple
implementations for a Remote Service implementation. In my view that is
totally unrelated to
the fact that such an implementation might offer multiple protocols
underneath.
Thats technical
details.
Having said this I realize that having its own communication will give
Riena communication a
sort of competive advantage over any other communication framework
which
is kind of unfair.
So I take that as an action item that I must find a way to also remove
any technical dependency
to Riena communication components from all the other Riena components.
(So Riena Security, Persistance
etc have no direct knowledge of Riena Communication)
We are not there yet but thats a good goal. On the way to that goal we
hopefully together (Riena and ECF)
can define a mechanism on how an arbitrary component can publish and
access
Remote Services without
any knowledge about the implementation of the commmunication framework.
I hope we can do that together.
So bottom line, working together with ECF is something I definitly like
to do. Dropping components
of our own is currently nothing we would like to do.
Also you might be happy to hear that we are interested to become part
of
the new runtime top level project
once it comes into existence.
So that will definitly through us into the same pond. And hopefully
quite
natural we would talk together
to define such a standard together with others how remote osgi services
should work.
Enabling things like security that we are currently doing also for ECF
is definitly an option. That
also applies to other extensions to communication that we might be
doing
in the future.
On the wider level I see ECF as one of the many cases where Riena needs
to use other components.
Say we need to support EclipseLink, sure an obvious choice. Still we
would
want to create our
persistence wrapper in a way that you could also use Hibernate (if
thats
the Riena application builders
choice). Also SWT is an obvious choice for the UI. However that does
not
mean that we will stop
anyone from writing a Swing client or build uncessary hurdles. Same
applies
to
other functional parts that we are building i.e. SoftwareUpdate (P2,
Maynstall
or else)
christian
p.s. we are currently in the process to bring our code into CVS. Once
that
is done, we have some samples,
a webpage and stuff we can discuss how we can bring the two projects
closer
together.
p.p.s. having a joint Riena, ECF sample application is definitly a good
idea, forgot to mention that.
We are currently in process of defining multiple
examples for Riena (some with UI, some as JUnit test).
Doing the exact same samples also using ECF
is something we could do, once that is finished (and see where
differences/problems/challenges are.
Scott Lewis schrieb:
> 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
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
|
