Skip to main content

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


I really want to avoid pitting one project against another and ranking technologies or implementations.  We should sort this out in the broader context of Equinox/Eclipse RT (the new top level project) and look at the problems from the consumer point of view.  Taking that approach things like the EEG work in this area become very relevant.  As such we should be focussing on ensuring that that spec is reasonable and meets our needs.  If it does not, now is the time to speak up and drive the spec.  From there we can have many different implementations and approaches.  As long as they play well together then our consumers are happy.

Jeff




Scott Lewis <slewis@xxxxxxxxxxxxx>

01/23/2008 01:43 PM

To
Jeff McAffer/Ottawa/IBM@IBMCA
cc
"Eclipse Communication Framework (ECF) developer mailing list." <ecf-dev@xxxxxxxxxxx>, Christian Campo <christian.campo@xxxxxxxxxxxx>, riena-dev@xxxxxxxxxxx
Subject
Re: [ecf-dev] Re: Riena Creation Review 19th Dec 2007





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



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



Back to the top