| RE: [smila-dev] FW: [eclipse.org-committers] Are you interested inOSGi (Equinox) as a server |
|
i agree, we just had a little bit of a discussion/meeting here and one
scenario we could think feasible is to adopt RIENA for all needs in regard to
remoting for interal components and to use tsuscany for places where we need to
cross language bounderies. do u think that is possible? Kind regards Thomas Menzel @ brox IT-Solutions GmbH From: smila-dev-bounces@xxxxxxxxxxx
[mailto:smila-dev-bounces@xxxxxxxxxxx] On Behalf Of Juergen.Schumacher@xxxxxxxxxxx And another bit of information: The reference implementation of
RFC 119 seems to happen in the Apache CXF project, see this mail [1] (very
fresh). The code is a available sandbox branch of their subversion [2]. It seems to me that we should currently not put too much own
effort in developing an own OSGi service remoting technology … Cheers, Jürgen. [1]
http://www.nabble.com/Distributed-OSGi-update-td20065391.html [2] http://svn.apache.org/repos/asf/cxf/sandbox/dosgi From: smila-dev-bounces@xxxxxxxxxxx
[mailto:smila-dev-bounces@xxxxxxxxxxx] On Behalf Of Juergen.Schumacher@xxxxxxxxxxx Hi, FYI: The next OSGi spec (4.2) will contain something currently
called RFC 119 – Distributed OSGi. An early draft is available at [1], RFC 119
starts at page 169. The requirements sound very much like what we want to have.
Especially it talks about exposing OSGi services to non-OSGi-non-Java clients
and integration of non-OSGi-non-Java service. And interestingly, though it’s
not intended to force the use of any specific technology or framework (apart
from OSGi, of course ;-) to implement the spec, there is a section called
“Reference Implementation based on SCA” (though it’s empty in the draft) and
lots of other reference to SCA throughout the document. So it seems that we
have not been completely off the track with our plans. But adhering to this RFC
would make it possible to exchange the underlying technology, if necessary
(hopefully). Of course, projects like ECF are thinking about RFC 119, too
[2]. Yours, Jürgen [1] http://www.osgi.org/download/osgi-4.2-early-draft.pdf [2] http://dev.eclipse.org/mhonarc/lists/ecf-dev/msg01834.html From: smila-dev-bounces@xxxxxxxxxxx
[mailto:smila-dev-bounces@xxxxxxxxxxx] On Behalf Of Juergen.Schumacher@xxxxxxxxxxx I’ve been watching the discussion from the beginning. And I’ll
continue. The Riena OSGi-service remoting indeed looks interesting
and seems to work quite simply. ECF was a bit hard to understand last time I
had a look at the documentation (which is not very detailed). I hope that they
both join their efforts in this area. However, it would be only a replacement for remote access to
services, and probably only by clients using the same technology. It
would probably not help with integrating components implemented in other
languages than Java (which was the second use case for Tuscany). Regards, Jürgen. From:
smila-dev-bounces@xxxxxxxxxxx [mailto:smila-dev-bounces@xxxxxxxxxxx] On
Behalf Of Thomas Menzel have u had a look at this? maybe that can be a replacement for Tuscany !? I know too little of the whole stuff to make a judgement. Kind
regards Thomas Menzel @ brox IT-Solutions GmbH From: eclipse.org-committers-bounces@xxxxxxxxxxx
[mailto:eclipse.org-committers-bounces@xxxxxxxxxxx] On Behalf Of Joel
Rosi-Schwartz Hi, This week I started a thread on the eclipse.rt.riena,
eclipse.technology.ormf, eclipse.technology.ecf and eclipse.technology.osee
newsgroups titled "Why are we all creating our own OSGi server
with remoting capability?" If you are involved in a project that presently requires a
server, will need one in the future or are simply interested in server side
eclipse, please join in the conversation on the newsgroups. Please note that I am using the terms server and
"server side" generally and do not mean web server in
particular. All the best, Joel P Please
consider the environment before printing this e-mail. Thank you.
|
