[
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,
Christian Campo wrote:
> 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).
I disagree strongly with your assertion of lack of overlap. Just
because ECF has other areas of API focus does *not* mean that we are not
fully committed to working on/improving/extending what we already have
WRT remote services...which is a transport independent, remote OSGi
services API...supporting both network transparent and non-transparent
OSGi service remoting.
As I read the Riena charter and Nyota docs, this is very much
overlapping with what Riena/Nyota are planning on doing. Having these
efforts be independent (the path of least resistance for EF projects)
would be, I think, a very bad thing for the community...because it will
create confusion.
> 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)
I understand this. But I still don't see ECF remote services and Riena
as fundamentally different...both are about inter-process communication
at the OSGi services level and above.
>
> 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)
I respectfully disagree. As we've already discussed in the riena
newsgroup, ECF remote services supports *both* transparent and
non-transparent remote services. The reason I have emphasized b in some
discussions is because so few/none of the other OSGi remoting approaches
even support non-transparent access to remote services (e.g. one-ways,
futures, etc), which I believe is a weakness for those approaches
(because of the issues with assuming network transparency aka the Note
on Distributed Computing argument).
>
> 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).
You may believe that, but I doubt the dev community that you would like
to support uniformly agrees with you. There are many applications that
imply/desire/would benefit from non-transparent remote access, and there
are many architects and designers that are well aware of the issues
involved with network transparent approaches.
>
> 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.
The capability was there. It just hasn't/wasn't being promoted.
>
> ECF has changed in the meantime and r-osgi is obviously becoming a
part of ECF.
Yes. Jan Rellermeyer has already nearly completed an ECF provider based
upon r-OSGi and has joined the ECF team as a committer. We will be
including this work in the ECF distribution as soon as the IP process
allows it (estimate: ECF 2.0.0 M5). Same goes for SLP provider of the
discovery API...worked on by Markus Kuppe and Jan.
>
> 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
Our concept of IContainer does include the notion of JAAS
authentication BTW. This is done at connect time (IContainer.connect)
through the IConnectContext interface:
http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/org/eclipse/ecf/core/security/IConnectContext.html
This interface exposes CallbackHandlers, which are used at connect time
to authenticate. Note that the Callback (and other interfaces) are not
from JAAS *yet*, but the intention is that they will eventually will be.
> - call the OSGi Service on the server with the Subject.doAsPrivileged
Yes. We do not do this now, but given that IDs are principals, and that
a server implementation can create a Subject upon authentication/login
(via JAAS), then such calls are indeed possible now with ECF providers
for server impls.
> - transferring session ids
We do this now with the ECF ID.
> - 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
Yes. Defining a Permissions store, changing the JVM default security
Policy and defining Permissions interfaces are all things that we have
simply not worked on, because ECF has been trying to maintain
compatibility with as small an OSGi runtime as possible (CDC
1.0/Foundation 1.0) in the case of the ECF core/identity plugins and others.
But, now that the JAAS security framework is headed into Equinox (at CDC
1.1/Foundation 1.1 I believe) work with you in this area will be much
easier.
>
> 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.
That's great to hear Christian. We are going to try to work with the
EE on doing reference impl work for the RFC (199 I think) for
distributed services. Our efforts there will be focused on the ECF
remote services API...not implementation/provider-specific work.
>
> Defining a technical dependency in Riena components in general to ECF
components is nothing I really
> want.
I would urge you to reconsider...at least for the following:
ECF core plugins: org.eclipse.ecf (68k), org.eclipse.ecf.identity (43k)
ECF remote services API: org.eclipse.ecf.remoteservices (12k)
ECF discovery: org.eclipse.ecf.discovery (22k)
These four plugins are *pure* API. No implementation at all. But they
do define a basic, extensible APIs. They are also quite small in code size.
Note that the p2 work currently depends upon/requires the ECF core
plugins, so the these will be in Ganymede/Equinox as of the Ganymede
release. There is also some potential that the discovery API might be
interesting to Equinox/runtime efforts as well (for discovering...e.g.
update sites, p2 meta-data repositories, remote services, etc).
> 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.
You are indeed correct...there is nothing (yet) approaching a 'standard'
for remote services in OSGi. In my view, this is a good thing, as
premature standardization is *not* a good thing. We are, however,
interested in contributing to the standardization by promoting the ECF
remote services API as a transport-independent, small, general,
not-bound-only-to-network-transparent-solutions approach.
We have no commercial interest in promoting our own implementation (or
anyone else's) as a standard...rather our only interest is in making
remote services APIs available to developers that are
1) open
2) extensible
3) as small/simple/compact as possible
4) sufficient for a variety of distributed systems use cases (i.e.
support both network-transparent and network-non-transparent remote access)
> 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.
Although I have confidence that the OSGi EE will allow for multiple
implementations, I suspect this will be a long process of
standardization (years)...and there will of course also be multiple
versions of the standard. We expect and hope to contribute to this
standardization, by using the ECF remote services API to
1) point out and help define areas of importance that the RFP authors
are not currently considering (e.g. non-transparent access to remote
services, and programmatic remote service APIs...in addition to
declarative approaches)
2) provide reference implementations of the contents of the RFP proposals
3) provide a 'grounding' of the standardization efforts by connecting
the EE standardization with an existing and large community (Eclipse
developers).
So I don't think we disagree with you at all about the standardization
process...but I expect/hope that ECF will contribute to that process,
rather than being a passive receiver of standardization (since there is
nothing close to standardization of an open approach at the
specification level, not to mention the implementation level).
> 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.
I'm not sure I understand what you are saying here, but a comment: IMHO
standardization of communications protocols has traditionally had a hard
time separating API/spec from implementation. There are several reasons
for this I think...one of which being that enterprise software standards
are frequently very politically charged...because of the implications
for businesses (and the perceived 'owner') of the 'standard'. All you
need to do is look at xml, security, web services, other standardization
efforts to see these things happening. The reason is that it is in the
business interests of the implementer to have *their* implementation
drive the standardization...for obvious business reasons.
My hope is that this process (in the OSGI EE with involvement of Eclipse
Foundation/Eclipse projects/ECF/Riena) can be different from that...i.e.
that it will be possible to keep API (e.g. ECF remote services API and
subsequent follow ons) and implementation (r-OSGi, ECF generic, Nyota,
etc) truly *separate* (in Equinox terms...actually separate
bundles/class namespaces).
>
> 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)
I think this would be a very good exercise. I expect you would find it
necessary to define an abstract remote services API...like the ECF
remote services API in order to do this...so would humbly suggest that
implementing an ECF remote services provider based upon Nyota (as we
have done with r-OSGI) would be a good way to go. It would also help us
refine/generalize the ECF remote services API, by pointing out
weaknesses/areas that are insufficiently general...and then we would (of
course) happily respond by enhancing/generalizing the remote services
API (and/or core APIs) as needed.
>
> 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.
Yes, I would very much like to do that together. Again I hope you will
consider the ECF remote services API as a candidate for 'publishing and
accesssing Remote Services without any knowledge about the
implementation of the communication framework'. That was the intention
for the org.eclipse.ecf.remoteservices bundle from the beginning. We
haven't reached completion on that goal yet (I'm sure that there are
both design weaknesses and areas where more capability are needed), but
your input and modifications to the API would be most welcome.
>
> 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.
I expect it would not be necessary to drop components of your own in
order to use the ECF remote services API.
> 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.
Yes.
>
> 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)
I agree that there is lots of potential and value to come from
cross-project interaction...particularly when focusing on
enterprise/server applications on OSGi/Equinox.
>
>
> 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.
OK. I'll look forward to any pointers...particularly WRT security that
you can provide (pointers to the src base are perfectly fine).
>
> 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.
That would be ideal. Perhaps at some point we could discuss some joint
demo-level work...or at least have a public discussion about possible
demo applications for remote services, as we (Jan, Markus, and myself)
are working through ideas for EclipseCon 2008 demos right now (of
r-OSGi/remote services, and discovery). It may be to our mutual
advantage (i.e. more/cooler demos) to share the work involved.
I'm cross posting this response to the Riena newsgroup...which didn't
seem to be on the original cc list. My apologies if this creates a
problem for you.
Thanks,
Scott
