Re: [ecf-dev] Re: Riena Creation Review 19th Dec 2007

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

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

Christian Campo <christian.campo@xxxxxxxxxxxx>
Sent by: ecf-dev-bounces@xxxxxxxxxxx

01/10/2008 09:53 AM

Please respond to
"Eclipse Communication Framework \(ECF\) developer mailing list."        <ecf-dev@xxxxxxxxxxx>

To	Scott Lewis <slewis@xxxxxxxxxxxxx>
cc	"Eclipse Communication Framework \(ECF\) developer mailing list." <ecf-dev@xxxxxxxxxxx>
Subject	[ecf-dev] Re: Riena Creation Review 19th Dec 2007

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