Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » ORMF » Why are we all creating our own OSGi server with remoting capability?
Why are we all creating our own OSGi server with remoting capability? [message #13054] Tue, 14 October 2008 12:18 Go to next message
Joel Rosi-Schwartz is currently offline Joel Rosi-SchwartzFriend
Messages: 624
Registered: July 2009
Location: London. England
Senior Member
Hi,

It seems to me that we may be reinventing the same wheel and I would
like to propose that we pool our resources and create a base OSGi
runtime (server) that is capable of remoting over various transport
mechanisms that are of common and general interest. I am not talking
about creating an application server, but I think one could be built on
top of what I considering by others.

Not only do we all have a need for this, but I suspect there are a few
other Eclipse projects that are or will be requiring similar.
Eventually I would foresee this effort spinning off into a RT project.

Anyone interested in discussing this?

Thanks,
Joel
--
Joel Rosi-Schwartz
Etish Limited [http://www.etish.org]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^...^
/ o,o \ The proud parents of Useme & ORMF
|) ::: (| Open Requirements Management Framework
====w=w==== [http://www.eclipse.org/ormf/]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: Why are we all creating our own OSGi server with remoting capability? [message #13086 is a reply to message #13054] Tue, 14 October 2008 16:39 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: slewis.composent.com

Hi Joel,

Joel Rosi-Schwartz wrote:
> Hi,
>
> It seems to me that we may be reinventing the same wheel and I would
> like to propose that we pool our resources and create a base OSGi
> runtime (server) that is capable of remoting over various transport
> mechanisms that are of common and general interest. I am not talking
> about creating an application server, but I think one could be built on
> top of what I considering by others.
>
> Not only do we all have a need for this, but I suspect there are a few
> other Eclipse projects that are or will be requiring similar. Eventually
> I would foresee this effort spinning off into a RT project.
>
> Anyone interested in discussing this?


Yes, absolutely.

Since this is going cross multiple newsgroups I'll give an overview of
what's currently happening with ECF...as well as with my own work
relevant to this area.

ECF has a remote services API [1], which is a transport independent API
for interacting with remote OSGi services. We currently have impls
(called providers) based upon: r-OSGi, JMS, XMPP, and ECF 'generic'.
We are hopeful that we will soon have a provider that is based upon the
Riena project codebase, and hopefully others will be created in future.
The creation/addition of other providers is (always) very welcome
(these impls can be proprietary or not)...as is reporting of API
problems and/or needed extensions and enhancements.

We also have a discovery API [2], that can/is used to support network
service discovery. We currently have two providers for this: one based
upon zeroconf, the other based upon service locator protocol (SLP - RFC
2608).

We (ECF committers) are involved in the OSGi enterprise experts group
(Jan Rellermeyer, an ECF committer participates directly in the expert
group). We expect to use the ECF discovery and remote services APIs to
produce an open source reference implementation for RFC 119 (distributed
OSGi) during this year.

ECF has just moved from being a technology project to being a runtime
project, and is currently working on it's 3.0 release cycle.

We are very keen on supporting the development of OSGi/Equinox-based
servers, with remote services, discovery, and/or other APIs of possible
interest for server-side development (e.g. async file transfer,
presence/IM, model synchronization, etc). ECF's filetransfer API is
currently being used to support Equinox p2.

I (Scott) am also currently working on several things having to do with
server-side equinox that are of potential interest:

1) I've been working on creating minimal OSGi/Equinox servers that are
deployable as web archives (wars) to any servlet environment. These
platforms contain the OSGi core, and various sets of bundles (based upon
specific configurations).

2) Further, I've been adding Equinox p2 (runtime install/management)
bundles into these configurations, so that the runtime can perform
bundle install and management using p2 (with dependency resolution,
etc...all the stuff p2 can do).

3) I'm currently working to create some management APIs...for doing
(e.g.) bundle install/uninstall/update in both server, RCP, and Eclipse
client scenarios.

4) I expect to use the ECF discovery API and remote services API to
expose the services defined via 3 so that external processes can
remotely manage an Equinox runtime. Given the transport-independence of
the approach (ECF discovery and remote services API), this will allow
the management to be done with an open-ended set of transports.

I agree with you that some of the mechanisms involved are of common and
general interest. I believe that the ECF discovery and remote services
are in that category, and I believe that some of the work (just
beginning) on runtime management may also be in that category. I
personally would welcome any collaboration that is possible, and agree
that pooling resources across existing projects may be a very good way
to go about this (given the common needs among several projects and
community members).

Thanks Joel,

Scott

[1] http://wiki.eclipse.org/ECF_API_Docs#Remote_Services_API
[2] http://wiki.eclipse.org/ECF_API_Docs#Discovery_API
Re: Why are we all creating our own OSGi server with remoting capability? [message #13115 is a reply to message #13054] Thu, 16 October 2008 09:03 Go to previous messageGo to next message
Christian Campo is currently offline Christian CampoFriend
Messages: 590
Registered: July 2009
Senior Member
Hi Joel,

I think what you are more interested in is not to worry about my resources of RCF, ORMF oder OSEE for that matter but
rather have a common unified way to define and use remote services in OSGi. So that you and others dont have to make
tough choices between different APIs for different remoting implementations.

For this to work, I believe there needs to be a set of APIs how such a remote service mechanism looks like and then
everybody can program against it. As Scott already mentioned it, this API spec exists and ist called "RFC 119", a part
of OSGi 4.2 spec that defines how OSGi services become remote services.

I underline that this is the spec is what you are probably looking for for remoting. I still think there is a lot more
that you need for building an application server, but that wasnt your topic. (my assumption).

As Scott said there will be a RFC119 compliant implementation in ECF rather sooner than later. I foresee that others
have their own implementation (within Eclipse and outside in other OSGi container implementations). But that is no
longer your worry because you use a standard API and can use any implementation that you like that complies to that
standard.

christian campo


Joel Rosi-Schwartz schrieb:
> Hi,
>
> It seems to me that we may be reinventing the same wheel and I would
> like to propose that we pool our resources and create a base OSGi
> runtime (server) that is capable of remoting over various transport
> mechanisms that are of common and general interest. I am not talking
> about creating an application server, but I think one could be built on
> top of what I considering by others.
>
> Not only do we all have a need for this, but I suspect there are a few
> other Eclipse projects that are or will be requiring similar. Eventually
> I would foresee this effort spinning off into a RT project.
>
> Anyone interested in discussing this?
>
> Thanks,
> Joel
Re: Why are we all creating our own OSGi server with remoting capability? [message #13144 is a reply to message #13115] Thu, 16 October 2008 09:30 Go to previous messageGo to next message
Joel Rosi-Schwartz is currently offline Joel Rosi-SchwartzFriend
Messages: 624
Registered: July 2009
Location: London. England
Senior Member
Hi Christian,

You pretty much have it. Just to rephrase in practical rather than
technical terms: the goal of most projects is to provide some stated
functionality, not to recreate infrastructure and plumbing. The state
of affairs at the moment in regards to remote services in OSGi is that,
in my opinion, too much time building (and then maintaining) the bottom
layer of runtime the architecture. What I would like for us to make
available to all comers is a single download that included Equinox,
remote services with plugable transports (with the common ones
pre-packaged) and a bundle(s) for the client side with the
implementation required to complement it.

In fact shipping it along with Equinox is not absolutely essential, so
made with and without would be a better idea.

What I do think should be avoided is all of the extra application
baggage that connected to distribution when it is part of a larger
project. Once other projects have to weed out what is relevant to there
needs and they have several providers to choose from, the decision
making process becomes more difficult.

Joel

On 2008-10-16 10:03:20 +0100, Christian Campo
<christian.campo@compeople.de> said:

> Hi Joel,
>
> I think what you are more interested in is not to worry about my
> resources of RCF, ORMF oder OSEE for that matter but rather have a
> common unified way to define and use remote services in OSGi. So that
> you and others dont have to make tough choices between different APIs
> for different remoting implementations.
>
> For this to work, I believe there needs to be a set of APIs how such a
> remote service mechanism looks like and then everybody can program
> against it. As Scott already mentioned it, this API spec exists and ist
> called "RFC 119", a part of OSGi 4.2 spec that defines how OSGi
> services become remote services.
>
> I underline that this is the spec is what you are probably looking for
> for remoting. I still think there is a lot more that you need for
> building an application server, but that wasnt your topic. (my
> assumption).
>
> As Scott said there will be a RFC119 compliant implementation in ECF
> rather sooner than later. I foresee that others have their own
> implementation (within Eclipse and outside in other OSGi container
> implementations). But that is no longer your worry because you use a
> standard API and can use any implementation that you like that complies
> to that standard.
>
> christian campo
>
>
> Joel Rosi-Schwartz schrieb:
>> Hi,
>>
>> It seems to me that we may be reinventing the same wheel and I would
>> like to propose that we pool our resources and create a base OSGi
>> runtime (server) that is capable of remoting over various transport
>> mechanisms that are of common and general interest. I am not talking
>> about creating an application server, but I think one could be built on
>> top of what I considering by others.
>>
>> Not only do we all have a need for this, but I suspect there are a few
>> other Eclipse projects that are or will be requiring similar.
>> Eventually I would foresee this effort spinning off into a RT project.
>>
>> Anyone interested in discussing this?
>>
>> Thanks,
>> Joel


--
Joel Rosi-Schwartz
Etish Limited [http://www.etish.org]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^...^
/ o,o \ The proud parents of Useme & ORMF
|) ::: (| Open Requirements Management Framework
====w=w==== [http://www.eclipse.org/ormf/]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: Why are we all creating our own OSGi server with remoting capability? [message #13174 is a reply to message #13086] Thu, 16 October 2008 10:09 Go to previous messageGo to next message
Joel Rosi-Schwartz is currently offline Joel Rosi-SchwartzFriend
Messages: 624
Registered: July 2009
Location: London. England
Senior Member
Hi Scott,

On 2008-10-14 17:39:00 +0100, Scott Lewis <slewis@composent.com> said:

> Hi Joel,
>
> Joel Rosi-Schwartz wrote:
>> Hi,
>>
>> It seems to me that we may be reinventing the same wheel and I would
>> like to propose that we pool our resources and create a base OSGi
>> runtime (server) that is capable of remoting over various transport
>> mechanisms that are of common and general interest. I am not talking
>> about creating an application server, but I think one could be built on
>> top of what I considering by others.
>>
>> Not only do we all have a need for this, but I suspect there are a few
>> other Eclipse projects that are or will be requiring similar.
>> Eventually I would foresee this effort spinning off into a RT project.
>>
>> Anyone interested in discussing this?
>
>
> Yes, absolutely.
>
> Since this is going cross multiple newsgroups I'll give an overview of
> what's currently happening with ECF...as well as with my own work
> relevant to this area.
>
> ECF has a remote services API [1], which is a transport independent API
> for interacting with remote OSGi services. We currently have impls
> (called providers) based upon: r-OSGi, JMS, XMPP, and ECF 'generic'.
> We are hopeful that we will soon have a provider that is based upon the
> Riena project codebase, and hopefully others will be created in future.
> The creation/addition of other providers is (always) very welcome
> (these impls can be proprietary or not)...as is reporting of API
> problems and/or needed extensions and enhancements.
>
> We also have a discovery API [2], that can/is used to support network
> service discovery. We currently have two providers for this: one
> based upon zeroconf, the other based upon service locator protocol (SLP
> - RFC 2608).
>
> We (ECF committers) are involved in the OSGi enterprise experts group
> (Jan Rellermeyer, an ECF committer participates directly in the expert
> group). We expect to use the ECF discovery and remote services APIs to
> produce an open source reference implementation for RFC 119
> (distributed OSGi) during this year.
>
> ECF has just moved from being a technology project to being a runtime
> project, and is currently working on it's 3.0 release cycle.
>
> We are very keen on supporting the development of OSGi/Equinox-based
> servers, with remote services, discovery, and/or other APIs of possible
> interest for server-side development (e.g. async file transfer,
> presence/IM, model synchronization, etc). ECF's filetransfer API is
> currently being used to support Equinox p2.
>
> I (Scott) am also currently working on several things having to do with
> server-side equinox that are of potential interest:
>
> 1) I've been working on creating minimal OSGi/Equinox servers that are
> deployable as web archives (wars) to any servlet environment. These
> platforms contain the OSGi core, and various sets of bundles (based
> upon specific configurations).
>
> 2) Further, I've been adding Equinox p2 (runtime install/management)
> bundles into these configurations, so that the runtime can perform
> bundle install and management using p2 (with dependency resolution,
> etc...all the stuff p2 can do).
>
> 3) I'm currently working to create some management APIs...for doing
> (e.g.) bundle install/uninstall/update in both server, RCP, and Eclipse
> client scenarios.
>
> 4) I expect to use the ECF discovery API and remote services API to
> expose the services defined via 3 so that external processes can
> remotely manage an Equinox runtime. Given the transport-independence
> of the approach (ECF discovery and remote services API), this will
> allow the management to be done with an open-ended set of transports.
>
> I agree with you that some of the mechanisms involved are of common and
> general interest. I believe that the ECF discovery and remote services
> are in that category, and I believe that some of the work (just
> beginning) on runtime management may also be in that category. I
> personally would welcome any collaboration that is possible, and agree
> that pooling resources across existing projects may be a very good way
> to go about this (given the common needs among several projects and
> community members).
>
> Thanks Joel,
>
> Scott
>
> [1] http://wiki.eclipse.org/ECF_API_Docs#Remote_Services_API
> [2] http://wiki.eclipse.org/ECF_API_Docs#Discovery_API

The work that you are doing on server side equinox is certainly of
interest (as a side note please see [1]). I am especially pleased that
you are working on management and P2 based provisioning. These are two
areas that very much need attention.

I know that Christian has some really good ideas and plans around a
Universal Exception Handler, that would be very pertinent.

I my reply to Christian I emphasised a need to focus the distribution
to the common "every app can benefit from" features, I think that is
core requirements for adoption.

For me as an adopter I found the lack of documentation to be a real
problem in working out what to use and how to use it. This has to be
addressed if others are going to use our work.

Cheers,
Joel

[1] I find it confusing that within Equinox the context of OSGi "server
side" automatically indicates "web server". This really threw me when I
started to Google around "OSGi" "Equinox" and "server" or "server
side". For me web servers are a very small coner of the server world.
Okay they are ubiquitous and even every grandmother knows what it is,
but give me a break :-) we were creating and using server technology
decades before Tim thought up the web browser. sigh... when all I have
is a hammer :-)

--
Joel Rosi-Schwartz
Etish Limited [http://www.etish.org]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^...^
/ o,o \ The proud parents of Useme & ORMF
|) ::: (| Open Requirements Management Framework
====w=w==== [http://www.eclipse.org/ormf/]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: Why are we all creating our own OSGi server with remoting capability? [message #13201 is a reply to message #13054] Thu, 16 October 2008 14:34 Go to previous messageGo to next message
Dennis O'Flynn is currently offline Dennis O'FlynnFriend
Messages: 73
Registered: July 2009
Member
I think consolidating efforts on a server-side Eclipse platform is a great
idea. There is work is several projects that could be coordinate to provide
a server-side platform similar to what RCP provides for the client-side.

Most of the server-side hype so far has been around running Equinox within a
web app server. I'm more interested in establishing an Eclipse based server
used to host "applications". Other Eclipse projects can deploy there
server-side "applications" to this server-side platform. To accomplish
this, there is additional functionality needed for a server-side platform
that is normally not needed in a client-side environment.

I assume this proposal is to establish such a server-side platform (Equinox
+ Eclipse core runtime + manageability + etc.). Is this correct?

-Dennis



"Joel Rosi-Schwartz" <Joel.Rosi-Schwartz@Etish.org> wrote in message
news:gd22mn$nb7$1@build.eclipse.org...
> Hi,
>
> It seems to me that we may be reinventing the same wheel and I would like
> to propose that we pool our resources and create a base OSGi runtime
> (server) that is capable of remoting over various transport mechanisms
> that are of common and general interest. I am not talking about creating
> an application server, but I think one could be built on top of what I
> considering by others.
>
> Not only do we all have a need for this, but I suspect there are a few
> other Eclipse projects that are or will be requiring similar. Eventually I
> would foresee this effort spinning off into a RT project.
>
> Anyone interested in discussing this?
>
> Thanks,
> Joel
> --
> Joel Rosi-Schwartz
> Etish Limited
> [http://www.etish.org]
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ^...^
> / o,o \ The proud parents of Useme & ORMF
> |) ::: (| Open Requirements Management Framework
> ====w=w==== [http://www.eclipse.org/ormf/]
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
Re: Why are we all creating our own OSGi server with remoting capability? [message #13228 is a reply to message #13201] Thu, 16 October 2008 15:05 Go to previous messageGo to next message
Joel Rosi-Schwartz is currently offline Joel Rosi-SchwartzFriend
Messages: 624
Registered: July 2009
Location: London. England
Senior Member
Hi Dennis,

Great to have you in the conversation.

On 2008-10-16 15:34:23 +0100, "Dennis O'Flynn"
<dennis.oflynn@compuware.com> said:

> I think consolidating efforts on a server-side Eclipse platform is a great
> idea. There is work is several projects that could be coordinate to provide
> a server-side platform similar to what RCP provides for the client-side.

Yes.

> Most of the server-side hype so far has been around running Equinox within a
> web app server. I'm more interested in establishing an Eclipse based server
> used to host "applications". Other Eclipse projects can deploy there
> server-side "applications" to this server-side platform. To accomplish
> this, there is additional functionality needed for a server-side platform
> that is normally not needed in a client-side environment.

Exactly my interests.

> I assume this proposal is to establish such a server-side platform (Equinox
> + Eclipse core runtime + manageability + etc.). Is this correct?

This is how I see it. There will always be an urge (or outside
pressure) to extend this to building a full blow application server
similar to j2ee. My opinion is that our vision should stop far short
of that. There is no reason, though, that what I envision could not be
the basis of such an effort by others in the future.

Are we on the same page?

Joel

>
> -Dennis
Re: Why are we all creating our own OSGi server with remoting capability? [message #13256 is a reply to message #13201] Thu, 16 October 2008 16:00 Go to previous messageGo to next message
Gunnar Wagenknecht is currently offline Gunnar WagenknechtFriend
Messages: 453
Registered: July 2009
Location: Germany ✈ Vancouver
Senior Member

Dennis O'Flynn schrieb:
> Most of the server-side hype so far has been around running Equinox within a
> web app server. I'm more interested in establishing an Eclipse based server
> used to host "applications". Other Eclipse projects can deploy there
> server-side "applications" to this server-side platform. To accomplish
> this, there is additional functionality needed for a server-side platform
> that is normally not needed in a client-side environment.

Hmm, this is already available today in OSGi/Equinox. It's called OSGi
application service. Equinox also has an extension on top of it
(IApplication). It comes with an interface for managing the applications
(via API or console commands). Just type "help" on the Equinox console.
Deployment is also possible using p2. Everything is there.

Or are you guys talking about a web-frontend for managing those?

-Gunnar

--
Gunnar Wagenknecht
gunnar@wagenknecht.org
http://wagenknecht.org/
Re: Why are we all creating our own OSGi server with remoting capability? [message #13282 is a reply to message #13115] Thu, 16 October 2008 18:24 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: slewis.composent.com

Hi Folks,

Some comments below.

Christian Campo wrote:
> Hi Joel,
>
> I think what you are more interested in is not to worry about my
> resources of RCF, ORMF oder OSEE for that matter but rather have a
> common unified way to define and use remote services in OSGi. So that
> you and others dont have to make tough choices between different APIs
> for different remoting implementations.
>
> For this to work, I believe there needs to be a set of APIs how such a
> remote service mechanism looks like and then everybody can program
> against it. As Scott already mentioned it, this API spec exists and ist
> called "RFC 119", a part of OSGi 4.2 spec that defines how OSGi services
> become remote services.


At least the versions that I've seen of RFC 119 is that it does not
actually define runtime APIs, but rather it defines a declarative
structure for registration and look up of remote services. This may
have changed more recently but the last version I saw didn't define
programmatic APIs (e.g. java interfaces).

The spec is also 'just a spec'...in the sense that many implementations
can/should/will exist. AFAIK, there is not a reference implementation
for RFC 119 yet, although I've heard from Jan that there are
proprietary/closed implementations from a/some member companies...and
these might be considered reference implementations...although I'm not
clear on the OSGi orgs model for reference implementations (i.e. whether
they can be/must be open source).

Further, I don't believe RFC 119 is actually finished/approved in any
formal way, so I would expect it to change before it is approved
(nothing wrong with that, it's just that it's still early days in terms
of standardization).

If I've misstated any of these elements Jan R or Markus K will (please)
correct me.

>
> I underline that this is the spec is what you are probably looking for
> for remoting. I still think there is a lot more that you need for
> building an application server, but that wasnt your topic. (my assumption).


Even with the spec, everyone will need an implementation to build
anything upon.

>
> As Scott said there will be a RFC119 compliant implementation in ECF
> rather sooner than later.


Yes. We have as one of our 3.0 plan items to use the ECF remote
services API and ECF discovery API to implement RFC119. Since ECF's
APIs *are* runtime APIs, we believe we can (with minimal/hopefully no
changes to the runtime API) implement the RFC 119 declarative structures.

Of course, ECF's remote services and discovery APIs are open/open source
and will remain so. Our hope is that some will use the existing
provider/transport implementations (i.e. r-OSGi, XMPP, JMS, ECF
generic), and that others will create providers...both in open source
and proprietary.

One very positive side effect of this approach is that if we are able to
use the ECF remote services API/discovery API to create a reference impl
of RFC 119, then that work would not have to be done separately for each
provider...i.e. they all would then be RFC 119 compliant...i.e.

RFC 119 -> ECF rs/disc APIs -> ECF providers (r-OSGI, XMPP, etc)


I foresee that others have their own
> implementation (within Eclipse and outside in other OSGi container
> implementations). But that is no longer your worry because you use a
> standard API and can use any implementation that you like that complies
> to that standard.

Well, that's the good thing about standards...there are so many to
choose from :). Just kidding...I am glad that RFC 119 is making
progress and am happy to support it...but I do think that

1) Having working implementations is important to actually drive the
standard (because I haven't seen a standard yet that got it right the
first time)

2) I feel that RFC 119 has overemphasized declarative approaches and has
not focused enough (at least to my knowledge) on runtime API...which for
some clients/use cases is a more natural approach (i.e. declarative is
not my personal favorite for (e.g.) server-side remote services).

Thanks,

Scott



>
> christian campo
>
>
> Joel Rosi-Schwartz schrieb:
>> Hi,
>>
>> It seems to me that we may be reinventing the same wheel and I would
>> like to propose that we pool our resources and create a base OSGi
>> runtime (server) that is capable of remoting over various transport
>> mechanisms that are of common and general interest. I am not talking
>> about creating an application server, but I think one could be built
>> on top of what I considering by others.
>>
>> Not only do we all have a need for this, but I suspect there are a few
>> other Eclipse projects that are or will be requiring similar.
>> Eventually I would foresee this effort spinning off into a RT project.
>>
>> Anyone interested in discussing this?
>>
>> Thanks,
>> Joel
Re: Why are we all creating our own OSGi server with remoting capability? [message #13309 is a reply to message #13174] Thu, 16 October 2008 18:51 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: slewis.composent.com

Hi Joel,

Joel Rosi-Schwartz wrote:
<stuff deleted>

>
> The work that you are doing on server side equinox is certainly of
> interest (as a side note please see [1]). I am especially pleased that
> you are working on management and P2 based provisioning. These are two
> areas that very much need attention.
>
> I know that Christian has some really good ideas and plans around a
> Universal Exception Handler, that would be very pertinent.
>
> I my reply to Christian I emphasised a need to focus the distribution to
> the common "every app can benefit from" features, I think that is core
> requirements for adoption.
>
> For me as an adopter I found the lack of documentation to be a real
> problem in working out what to use and how to use it. This has to be
> addressed if others are going to use our work.


Yes, I agree. We (ECF) team would very much appreciate:

1) Creation of specific enhancement requests for documentation areas
that people consider problematic...so we can prioritize efforts there.
We know that more documentation is needed (of course), but want to
target the specific problematic areas rather than guess.

2) Any contributions of documentation, example code, etc. Like other EF
projects, ECF is a community project and has to depend upon its
community for contributions.

>
> Cheers,
> Joel
>
> [1] I find it confusing that within Equinox the context of OSGi "server
> side" automatically indicates "web server". This really threw me when I
> started to Google around "OSGi" "Equinox" and "server" or "server side".
> For me web servers are a very small coner of the server world. Okay they
> are ubiquitous and even every grandmother knows what it is, but give me
> a break :-) we were creating and using server technology decades before
> Tim thought up the web browser. sigh... when all I have is a hammer :-)
>

I agree completely with you. Equinox servers can/could/will be the
basis for all manner of servers: web servers (of course), but also
(e.g.) XMPP servers [1], event/messaging servers [2], game servers,
etc., etc

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=235844
[2]
http://www.bea.com/framework.jsp?CNT=index.htm&FP=/conte nt/products/weblogic/event_server/
Re: Why are we all creating our own OSGi server with remoting capability? [message #13336 is a reply to message #13256] Thu, 16 October 2008 19:50 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: slewis.composent.com

Just a quick comment below,

Gunnar Wagenknecht wrote:
> Dennis O'Flynn schrieb:
>> Most of the server-side hype so far has been around running Equinox within a
>> web app server. I'm more interested in establishing an Eclipse based server
>> used to host "applications". Other Eclipse projects can deploy there
>> server-side "applications" to this server-side platform. To accomplish
>> this, there is additional functionality needed for a server-side platform
>> that is normally not needed in a client-side environment.
>
> Hmm, this is already available today in OSGi/Equinox. It's called OSGi
> application service. Equinox also has an extension on top of it
> (IApplication). It comes with an interface for managing the applications
> (via API or console commands). Just type "help" on the Equinox console.
> Deployment is also possible using p2. Everything is there.


Although Gunnar is right about there being p2 console commands they are
not extensive (i.e. it lets you do some adding/viewing of p2
repositories, creating proiles, and installing components from those
repositories). It doesn't (yet) support uninstall, reverting to
previous profiles/versions, etc or other things that p2 can do.

Scott
Re: Why are we all creating our own OSGi server with remoting capability? [message #14013 is a reply to message #13256] Fri, 17 October 2008 10:39 Go to previous messageGo to next message
Joel Rosi-Schwartz is currently offline Joel Rosi-SchwartzFriend
Messages: 624
Registered: July 2009
Location: London. England
Senior Member
On 2008-10-16 17:00:53 +0100, Gunnar Wagenknecht <gunnar@wagenknecht.org> said:

> Dennis O'Flynn schrieb:
>> Most of the server-side hype so far has been around running Equinox within a
>> web app server. I'm more interested in establishing an Eclipse based server
>> used to host "applications". Other Eclipse projects can deploy there
>> server-side "applications" to this server-side platform. To accomplish
>> this, there is additional functionality needed for a server-side platform
>> that is normally not needed in a client-side environment.
>
> Hmm, this is already available today in OSGi/Equinox. It's called OSGi
> application service. Equinox also has an extension on top of it
> (IApplication). It comes with an interface for managing the applications
> (via API or console commands). Just type "help" on the Equinox console.
> Deployment is also possible using p2. Everything is there.
>
> Or are you guys talking about a web-frontend for managing those?
>
> -Gunnar

I do not think that we are speaking specifically about a web-frontend,
at least that is not my thinking. Rather, I thing that we need an
expanded set of management services exposed as an API that enables
extended console commands, but more importantly (IMHO) also exposes
these to any GUI based client that wants to support them. These could
be Web, Java Swing, SWT, RCP, etc.. The point is to enable the
possibilities.

As far as "Everything is there", well I am a new to OSGi so maybe I am
just not getting it. But as a person whose goal is to create a
Requirements Framework, I certainly do not experience it as simply
being there. If I am missing the point, I would truly appreciate it if
someone could point my in the right direction.

Joel
--
Joel Rosi-Schwartz
Etish Limited [http://www.etish.org]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^...^
/ o,o \ The proud parents of Useme & ORMF
|) ::: (| Open Requirements Management Framework
====w=w==== [http://www.eclipse.org/ormf/]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: Why are we all creating our own OSGi server with remoting capability? [message #14035 is a reply to message #14013] Fri, 17 October 2008 16:15 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: slewis.composent.com

Hi Joel,

Joel Rosi-Schwartz wrote:
<stuff deleted>

>> Hmm, this is already available today in OSGi/Equinox. It's called OSGi
>> application service. Equinox also has an extension on top of it
>> (IApplication). It comes with an interface for managing the applications
>> (via API or console commands). Just type "help" on the Equinox console.
>> Deployment is also possible using p2. Everything is there.
>>
>> Or are you guys talking about a web-frontend for managing those?
>>
>> -Gunnar
>
> I do not think that we are speaking specifically about a web-frontend,
> at least that is not my thinking. Rather, I thing that we need an
> expanded set of management services exposed as an API that enables
> extended console commands, but more importantly (IMHO) also exposes
> these to any GUI based client that wants to support them. These could be
> Web, Java Swing, SWT, RCP, etc.. The point is to enable the possibilities.


Yes, this is a very good point...and is essentially what I have just
started to do: create APIs (interfaces) which expose management
capabilities for different parts of Equinox.

There are, of course, several large 'parts' of Equinox that can be
managed: The OSGI concepts (i.e. starting/stopping bundles),
capabilities exposed by the Equinox IApplication API (starting/stopping
applications), capabilities exposed by p2
(installing/updating/uninstalling IUs...which can represent
components/modules, individual bundles, IApplications, or other things
(e.g. features).

I agree with Joel that such APIs need to be separated from any
particular user interface, so that different interfaces can/could be
used (console, web, RCP/SWT/, etc as Joel lists).

Further, I think it's a good idea to design these interfaces such that
they can be easily used remotely...with whatever remoting technology.
For example, not passing around complicated objects by reference as
parameters in the API...since marshaling can/would be made difficult or
impossible.

So this is what I am starting (defining these interfaces) as applied to
the management capabilities exposed by OSGi, IApplication API, and P2
(to begin anyway). I would/will be happy to collaborate with any/all of
you on this.


>
> As far as "Everything is there", well I am a new to OSGi so maybe I am
> just not getting it.


I think that Gunnar was referring specifically to the IApplication
structures for launching/stopping applications within an Equinox
runtime...and using them from the console.

If the (equinox, IApplication, p2) capabilities are to be exposed for
other UIs (other than the console), then creating APIs one level down
from the console will indeed be necessary...and so that's why I've begun
going in those directions.

Scott
Re: Why are we all creating our own OSGi server with remoting capability? [message #14052 is a reply to message #13256] Sat, 18 October 2008 03:43 Go to previous messageGo to next message
Simon Kaegi is currently offline Simon KaegiFriend
Messages: 381
Registered: July 2009
Senior Member
I get the feeling when Joel started this thread he was more interested in
the more general remoting problems as opposed to remote management but I'll
admit I'm very interested in this second problem. ...comments inlined...

"Gunnar Wagenknecht" <gunnar@wagenknecht.org> wrote in message
news:gd7ofo$pdq$1@build.eclipse.org...
> Dennis O'Flynn schrieb:
>> Most of the server-side hype so far has been around running Equinox
>> within a
>> web app server. I'm more interested in establishing an Eclipse based
>> server
>> used to host "applications". Other Eclipse projects can deploy there
>> server-side "applications" to this server-side platform. To accomplish
>> this, there is additional functionality needed for a server-side platform
>> that is normally not needed in a client-side environment.
>
> Hmm, this is already available today in OSGi/Equinox. It's called OSGi
> application service. Equinox also has an extension on top of it
> (IApplication). It comes with an interface for managing the applications
> (via API or console commands). Just type "help" on the Equinox console.
> Deployment is also possible using p2. Everything is there.
>
I use the console a great deal in my day-to-day ops and think it's very
useful as a way to take a look at the state of the system but am less
confident in its abilities to modify the system. Perhaps if it somehow it
allowed one to run scripts...

> Or are you guys talking about a web-frontend for managing those?
If anyone was looking for a show of hands, I would be interested in working
on a web-frontend as a green thread for server management work. By this I
don't necessarily mean something specific to web UIs (although that might be
a good first target) but more looking at a HTTP/resource based way at
getting state and manipulating the framework in interesting ways.

Last year I looked at a few remote management possibilites for p2 and
equinox and although we didn't end up doing work in the area felt that a DMT
Admin based approach might be worth a second look. (For those not
familiar... DMT stands for Device Management Tree and the DMT Admin Service
is one of the specifications put out by the OSGi Alliance and is in the R4.1
service compendium -- see http://www.osgi.org/Specifications/HomePage )

I mention DMT only since it's often overlooked in favour of JMX/WSDM.
Speaking of which... there is some JMX work in the Equinox Incubator that
although now a little dated might be worth a look.

-Simon
Re: Why are we all creating our own OSGi server with remoting capability? [message #14069 is a reply to message #14052] Sat, 18 October 2008 09:33 Go to previous messageGo to next message
Joel Rosi-Schwartz is currently offline Joel Rosi-SchwartzFriend
Messages: 624
Registered: July 2009
Location: London. England
Senior Member
On 2008-10-18 04:43:43 +0100, "Simon Kaegi" <simon_kaegi@ca.ibm.com> said:

> I get the feeling when Joel started this thread he was more interested in
> the more general remoting problems as opposed to remote management but I'll
> admit I'm very interested in this second problem. ...comments inlined...

Simon is almost right, that was my starting point as a hard requirement
I personally have. In fact, however, my broader desire is for the work
to support all of the "basics" that most server projects require. With
the caveat (that I keep bringing up;) that I do not propose that we
build an application server; that is for another person another day.
Remoting, management, provisioning, IoC/DI (SAT?), logging, ...
available as single distribution and ready to go.

Joel
Re: Why are we all creating our own OSGi server with remoting capability? [message #14120 is a reply to message #13228] Mon, 20 October 2008 12:59 Go to previous messageGo to next message
Dennis O'Flynn is currently offline Dennis O'FlynnFriend
Messages: 73
Registered: July 2009
Member
Joel,

Short answer: yes - I think we are on the same page.

Long answer:

The Eclipse Foundation is ideally positioned to provide a server-side
platform parallel to what it already provides with RCP. This includes both
the tooling (development) and runtime (deployment) environments. In
addition, Eclipse can provide a consistent programming model for both client
and server components (aka plug-ins).

I believe an Eclipse server-side platform would be / could be comprised of:
* Equinox
** service component model
** service application model
* Eclipse core runtime
** extension component model
* Managability
** JMX (exemplary implementation)
* Logging
** This can be messy if not addressed up front
* Interoperabiity
** web services
** messaging
* Spring-OSGi
* Native-OS service
** Enhance Equinox launcher to support Apache Commons Daemon, etc...

Such a server-side platform could support the deployment of multiple
"applications" (OSGI service applications) from different providers. The
server-side platform would provide the runtime environment needed to host
the applications. Imagine being able to deploy a database service
application (ex: Derby Network Server), communications service application
(ex: ECF generic server), as well as other projects' service applications
all to the same server-side platform.

I think the focus of this propsoal to "pool our resources and create a base
OSGi runtime (server)" should be to focus on providing the Eclipse
server-side platform to support the deployment and management of OSGi
service applications.
Re: Why are we all creating our own OSGi server with remoting capability? [message #14137 is a reply to message #14120] Mon, 20 October 2008 15:44 Go to previous messageGo to next message
Joel Rosi-Schwartz is currently offline Joel Rosi-SchwartzFriend
Messages: 624
Registered: July 2009
Location: London. England
Senior Member
Dennis,

That's a somewhat broader vision than I started with, but one that I
would be very happy to participate in. Are you going to write the
project proposal :-) I'd be very pleased to sign on.

Cheers,
Joel


On 2008-10-20 14:59:27 +0200, "Dennis O'Flynn"
<dennis.oflynn@compuware.com> said:

> Joel,
>
> Short answer: yes - I think we are on the same page.
>
> Long answer:
>
> The Eclipse Foundation is ideally positioned to provide a server-side
> platform parallel to what it already provides with RCP. This includes both
> the tooling (development) and runtime (deployment) environments. In
> addition, Eclipse can provide a consistent programming model for both client
> and server components (aka plug-ins).
>
> I believe an Eclipse server-side platform would be / could be comprised of:
> * Equinox
> ** service component model
> ** service application model
> * Eclipse core runtime
> ** extension component model
> * Managability
> ** JMX (exemplary implementation)
> * Logging
> ** This can be messy if not addressed up front
> * Interoperabiity
> ** web services
> ** messaging
> * Spring-OSGi
> * Native-OS service
> ** Enhance Equinox launcher to support Apache Commons Daemon, etc...
>
> Such a server-side platform could support the deployment of multiple
> "applications" (OSGI service applications) from different providers. The
> server-side platform would provide the runtime environment needed to host
> the applications. Imagine being able to deploy a database service
> application (ex: Derby Network Server), communications service application
> (ex: ECF generic server), as well as other projects' service applications
> all to the same server-side platform.
>
> I think the focus of this propsoal to "pool our resources and create a base
> OSGi runtime (server)" should be to focus on providing the Eclipse
> server-side platform to support the deployment and management of OSGi
> service applications.
Re: Why are we all creating our own OSGi server with remoting capability? [message #14154 is a reply to message #14137] Mon, 20 October 2008 16:44 Go to previous messageGo to next message
Dennis O'Flynn is currently offline Dennis O'FlynnFriend
Messages: 73
Registered: July 2009
Member
Maybe we should have a confernece call where we can set the scope of this
initiative. This would give everyone interested a chance to share their
ideas and agree upon the direction.

What do you think?

"Joel Rosi-Schwartz" <Joel.Rosi-Schwartz@Etish.org> wrote in message
news:gdi91d$f9h$1@build.eclipse.org...
> Dennis,
>
> That's a somewhat broader vision than I started with, but one that I would
> be very happy to participate in. Are you going to write the project
> proposal :-) I'd be very pleased to sign on.
>
> Cheers,
> Joel
>
>
> On 2008-10-20 14:59:27 +0200, "Dennis O'Flynn"
> <dennis.oflynn@compuware.com> said:
>
>> Joel,
>>
>> Short answer: yes - I think we are on the same page.
>>
>> Long answer:
>>
>> The Eclipse Foundation is ideally positioned to provide a server-side
>> platform parallel to what it already provides with RCP. This includes
>> both
>> the tooling (development) and runtime (deployment) environments. In
>> addition, Eclipse can provide a consistent programming model for both
>> client
>> and server components (aka plug-ins).
>>
>> I believe an Eclipse server-side platform would be / could be comprised
>> of:
>> * Equinox
>> ** service component model
>> ** service application model
>> * Eclipse core runtime
>> ** extension component model
>> * Managability
>> ** JMX (exemplary implementation)
>> * Logging
>> ** This can be messy if not addressed up front
>> * Interoperabiity
>> ** web services
>> ** messaging
>> * Spring-OSGi
>> * Native-OS service
>> ** Enhance Equinox launcher to support Apache Commons Daemon, etc...
>>
>> Such a server-side platform could support the deployment of multiple
>> "applications" (OSGI service applications) from different providers. The
>> server-side platform would provide the runtime environment needed to host
>> the applications. Imagine being able to deploy a database service
>> application (ex: Derby Network Server), communications service
>> application
>> (ex: ECF generic server), as well as other projects' service applications
>> all to the same server-side platform.
>>
>> I think the focus of this propsoal to "pool our resources and create a
>> base
>> OSGi runtime (server)" should be to focus on providing the Eclipse
>> server-side platform to support the deployment and management of OSGi
>> service applications.
>
>
Re: Why are we all creating our own OSGi server with remoting capability? [message #14171 is a reply to message #14120] Mon, 20 October 2008 20:01 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: slewis.composent.com

All,

Perhaps we should create a new 'management' incubation component within
the Equinox project so that those of us working on/thinking about
management for Equinox runtimes can have a place and means to share them.

A new component would give us all a

1) place to share contributions in CVS
2) record/share work with standards orgs (e.g. DMT, WSDM, OADM, etc),
3) share information among all of us with wiki and web pages

What do people think? Should we speak with the Runtime PMC about such a
component?

Scott

Dennis O'Flynn wrote:
> Joel,
>
> Short answer: yes - I think we are on the same page.
>
> Long answer:
>
> The Eclipse Foundation is ideally positioned to provide a server-side
> platform parallel to what it already provides with RCP. This includes both
> the tooling (development) and runtime (deployment) environments. In
> addition, Eclipse can provide a consistent programming model for both client
> and server components (aka plug-ins).
>
> I believe an Eclipse server-side platform would be / could be comprised of:
> * Equinox
> ** service component model
> ** service application model
> * Eclipse core runtime
> ** extension component model
> * Managability
> ** JMX (exemplary implementation)
> * Logging
> ** This can be messy if not addressed up front
> * Interoperabiity
> ** web services
> ** messaging
> * Spring-OSGi
> * Native-OS service
> ** Enhance Equinox launcher to support Apache Commons Daemon, etc...
>
> Such a server-side platform could support the deployment of multiple
> "applications" (OSGI service applications) from different providers. The
> server-side platform would provide the runtime environment needed to host
> the applications. Imagine being able to deploy a database service
> application (ex: Derby Network Server), communications service application
> (ex: ECF generic server), as well as other projects' service applications
> all to the same server-side platform.
>
> I think the focus of this propsoal to "pool our resources and create a base
> OSGi runtime (server)" should be to focus on providing the Eclipse
> server-side platform to support the deployment and management of OSGi
> service applications.
>
>
Re: Why are we all creating our own OSGi server with remoting capability? [message #14238 is a reply to message #14137] Wed, 29 October 2008 10:29 Go to previous message
Dennis O'Flynn is currently offline Dennis O'FlynnFriend
Messages: 73
Registered: July 2009
Member
Joel,

I posted a brief write-up of a proposed Eclipse Server Platform to Riena's
Idea wiki page:
*
http://wiki.eclipse.org/Riena_Interesting_Ideas#Eclipse_Serv er-side_Platform


"Joel Rosi-Schwartz" <Joel.Rosi-Schwartz@Etish.org> wrote in message
news:gdi91d$f9h$1@build.eclipse.org...
> Dennis,
>
> That's a somewhat broader vision than I started with, but one that I would
> be very happy to participate in. Are you going to write the project
> proposal :-) I'd be very pleased to sign on.
>
> Cheers,
> Joel
>
Re: Why are we all creating our own OSGi server with remoting capability? [message #564446 is a reply to message #13054] Tue, 14 October 2008 16:39 Go to previous message
Scott Lewis is currently offline Scott LewisFriend
Messages: 975
Registered: July 2009
Senior Member
Hi Joel,

Joel Rosi-Schwartz wrote:
> Hi,
>
> It seems to me that we may be reinventing the same wheel and I would
> like to propose that we pool our resources and create a base OSGi
> runtime (server) that is capable of remoting over various transport
> mechanisms that are of common and general interest. I am not talking
> about creating an application server, but I think one could be built on
> top of what I considering by others.
>
> Not only do we all have a need for this, but I suspect there are a few
> other Eclipse projects that are or will be requiring similar. Eventually
> I would foresee this effort spinning off into a RT project.
>
> Anyone interested in discussing this?


Yes, absolutely.

Since this is going cross multiple newsgroups I'll give an overview of
what's currently happening with ECF...as well as with my own work
relevant to this area.

ECF has a remote services API [1], which is a transport independent API
for interacting with remote OSGi services. We currently have impls
(called providers) based upon: r-OSGi, JMS, XMPP, and ECF 'generic'.
We are hopeful that we will soon have a provider that is based upon the
Riena project codebase, and hopefully others will be created in future.
The creation/addition of other providers is (always) very welcome
(these impls can be proprietary or not)...as is reporting of API
problems and/or needed extensions and enhancements.

We also have a discovery API [2], that can/is used to support network
service discovery. We currently have two providers for this: one based
upon zeroconf, the other based upon service locator protocol (SLP - RFC
2608).

We (ECF committers) are involved in the OSGi enterprise experts group
(Jan Rellermeyer, an ECF committer participates directly in the expert
group). We expect to use the ECF discovery and remote services APIs to
produce an open source reference implementation for RFC 119 (distributed
OSGi) during this year.

ECF has just moved from being a technology project to being a runtime
project, and is currently working on it's 3.0 release cycle.

We are very keen on supporting the development of OSGi/Equinox-based
servers, with remote services, discovery, and/or other APIs of possible
interest for server-side development (e.g. async file transfer,
presence/IM, model synchronization, etc). ECF's filetransfer API is
currently being used to support Equinox p2.

I (Scott) am also currently working on several things having to do with
server-side equinox that are of potential interest:

1) I've been working on creating minimal OSGi/Equinox servers that are
deployable as web archives (wars) to any servlet environment. These
platforms contain the OSGi core, and various sets of bundles (based upon
specific configurations).

2) Further, I've been adding Equinox p2 (runtime install/management)
bundles into these configurations, so that the runtime can perform
bundle install and management using p2 (with dependency resolution,
etc...all the stuff p2 can do).

3) I'm currently working to create some management APIs...for doing
(e.g.) bundle install/uninstall/update in both server, RCP, and Eclipse
client scenarios.

4) I expect to use the ECF discovery API and remote services API to
expose the services defined via 3 so that external processes can
remotely manage an Equinox runtime. Given the transport-independence of
the approach (ECF discovery and remote services API), this will allow
the management to be done with an open-ended set of transports.

I agree with you that some of the mechanisms involved are of common and
general interest. I believe that the ECF discovery and remote services
are in that category, and I believe that some of the work (just
beginning) on runtime management may also be in that category. I
personally would welcome any collaboration that is possible, and agree
that pooling resources across existing projects may be a very good way
to go about this (given the common needs among several projects and
community members).

Thanks Joel,

Scott

[1] http://wiki.eclipse.org/ECF_API_Docs#Remote_Services_API
[2] http://wiki.eclipse.org/ECF_API_Docs#Discovery_API
Re: Why are we all creating our own OSGi server with remoting capability? [message #564470 is a reply to message #13054] Thu, 16 October 2008 09:03 Go to previous message
Christian Campo is currently offline Christian CampoFriend
Messages: 590
Registered: July 2009
Senior Member
Hi Joel,

I think what you are more interested in is not to worry about my resources of RCF, ORMF oder OSEE for that matter but
rather have a common unified way to define and use remote services in OSGi. So that you and others dont have to make
tough choices between different APIs for different remoting implementations.

For this to work, I believe there needs to be a set of APIs how such a remote service mechanism looks like and then
everybody can program against it. As Scott already mentioned it, this API spec exists and ist called "RFC 119", a part
of OSGi 4.2 spec that defines how OSGi services become remote services.

I underline that this is the spec is what you are probably looking for for remoting. I still think there is a lot more
that you need for building an application server, but that wasnt your topic. (my assumption).

As Scott said there will be a RFC119 compliant implementation in ECF rather sooner than later. I foresee that others
have their own implementation (within Eclipse and outside in other OSGi container implementations). But that is no
longer your worry because you use a standard API and can use any implementation that you like that complies to that
standard.

christian campo


Joel Rosi-Schwartz schrieb:
> Hi,
>
> It seems to me that we may be reinventing the same wheel and I would
> like to propose that we pool our resources and create a base OSGi
> runtime (server) that is capable of remoting over various transport
> mechanisms that are of common and general interest. I am not talking
> about creating an application server, but I think one could be built on
> top of what I considering by others.
>
> Not only do we all have a need for this, but I suspect there are a few
> other Eclipse projects that are or will be requiring similar. Eventually
> I would foresee this effort spinning off into a RT project.
>
> Anyone interested in discussing this?
>
> Thanks,
> Joel
Re: Why are we all creating our own OSGi server with remoting capability? [message #564492 is a reply to message #13115] Thu, 16 October 2008 09:30 Go to previous message
Joel Rosi-Schwartz is currently offline Joel Rosi-SchwartzFriend
Messages: 624
Registered: July 2009
Location: London. England
Senior Member
Hi Christian,

You pretty much have it. Just to rephrase in practical rather than
technical terms: the goal of most projects is to provide some stated
functionality, not to recreate infrastructure and plumbing. The state
of affairs at the moment in regards to remote services in OSGi is that,
in my opinion, too much time building (and then maintaining) the bottom
layer of runtime the architecture. What I would like for us to make
available to all comers is a single download that included Equinox,
remote services with plugable transports (with the common ones
pre-packaged) and a bundle(s) for the client side with the
implementation required to complement it.

In fact shipping it along with Equinox is not absolutely essential, so
made with and without would be a better idea.

What I do think should be avoided is all of the extra application
baggage that connected to distribution when it is part of a larger
project. Once other projects have to weed out what is relevant to there
needs and they have several providers to choose from, the decision
making process becomes more difficult.

Joel

On 2008-10-16 10:03:20 +0100, Christian Campo
<christian.campo@compeople.de> said:

> Hi Joel,
>
> I think what you are more interested in is not to worry about my
> resources of RCF, ORMF oder OSEE for that matter but rather have a
> common unified way to define and use remote services in OSGi. So that
> you and others dont have to make tough choices between different APIs
> for different remoting implementations.
>
> For this to work, I believe there needs to be a set of APIs how such a
> remote service mechanism looks like and then everybody can program
> against it. As Scott already mentioned it, this API spec exists and ist
> called "RFC 119", a part of OSGi 4.2 spec that defines how OSGi
> services become remote services.
>
> I underline that this is the spec is what you are probably looking for
> for remoting. I still think there is a lot more that you need for
> building an application server, but that wasnt your topic. (my
> assumption).
>
> As Scott said there will be a RFC119 compliant implementation in ECF
> rather sooner than later. I foresee that others have their own
> implementation (within Eclipse and outside in other OSGi container
> implementations). But that is no longer your worry because you use a
> standard API and can use any implementation that you like that complies
> to that standard.
>
> christian campo
>
>
> Joel Rosi-Schwartz schrieb:
>> Hi,
>>
>> It seems to me that we may be reinventing the same wheel and I would
>> like to propose that we pool our resources and create a base OSGi
>> runtime (server) that is capable of remoting over various transport
>> mechanisms that are of common and general interest. I am not talking
>> about creating an application server, but I think one could be built on
>> top of what I considering by others.
>>
>> Not only do we all have a need for this, but I suspect there are a few
>> other Eclipse projects that are or will be requiring similar.
>> Eventually I would foresee this effort spinning off into a RT project.
>>
>> Anyone interested in discussing this?
>>
>> Thanks,
>> Joel


--
Joel Rosi-Schwartz
Etish Limited [http://www.etish.org]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^...^
/ o,o \ The proud parents of Useme & ORMF
|) ::: (| Open Requirements Management Framework
====w=w==== [http://www.eclipse.org/ormf/]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: Why are we all creating our own OSGi server with remoting capability? [message #564502 is a reply to message #13086] Thu, 16 October 2008 10:09 Go to previous message
Joel Rosi-Schwartz is currently offline Joel Rosi-SchwartzFriend
Messages: 624
Registered: July 2009
Location: London. England
Senior Member
Hi Scott,

On 2008-10-14 17:39:00 +0100, Scott Lewis <slewis@composent.com> said:

> Hi Joel,
>
> Joel Rosi-Schwartz wrote:
>> Hi,
>>
>> It seems to me that we may be reinventing the same wheel and I would
>> like to propose that we pool our resources and create a base OSGi
>> runtime (server) that is capable of remoting over various transport
>> mechanisms that are of common and general interest. I am not talking
>> about creating an application server, but I think one could be built on
>> top of what I considering by others.
>>
>> Not only do we all have a need for this, but I suspect there are a few
>> other Eclipse projects that are or will be requiring similar.
>> Eventually I would foresee this effort spinning off into a RT project.
>>
>> Anyone interested in discussing this?
>
>
> Yes, absolutely.
>
> Since this is going cross multiple newsgroups I'll give an overview of
> what's currently happening with ECF...as well as with my own work
> relevant to this area.
>
> ECF has a remote services API [1], which is a transport independent API
> for interacting with remote OSGi services. We currently have impls
> (called providers) based upon: r-OSGi, JMS, XMPP, and ECF 'generic'.
> We are hopeful that we will soon have a provider that is based upon the
> Riena project codebase, and hopefully others will be created in future.
> The creation/addition of other providers is (always) very welcome
> (these impls can be proprietary or not)...as is reporting of API
> problems and/or needed extensions and enhancements.
>
> We also have a discovery API [2], that can/is used to support network
> service discovery. We currently have two providers for this: one
> based upon zeroconf, the other based upon service locator protocol (SLP
> - RFC 2608).
>
> We (ECF committers) are involved in the OSGi enterprise experts group
> (Jan Rellermeyer, an ECF committer participates directly in the expert
> group). We expect to use the ECF discovery and remote services APIs to
> produce an open source reference implementation for RFC 119
> (distributed OSGi) during this year.
>
> ECF has just moved from being a technology project to being a runtime
> project, and is currently working on it's 3.0 release cycle.
>
> We are very keen on supporting the development of OSGi/Equinox-based
> servers, with remote services, discovery, and/or other APIs of possible
> interest for server-side development (e.g. async file transfer,
> presence/IM, model synchronization, etc). ECF's filetransfer API is
> currently being used to support Equinox p2.
>
> I (Scott) am also currently working on several things having to do with
> server-side equinox that are of potential interest:
>
> 1) I've been working on creating minimal OSGi/Equinox servers that are
> deployable as web archives (wars) to any servlet environment. These
> platforms contain the OSGi core, and various sets of bundles (based
> upon specific configurations).
>
> 2) Further, I've been adding Equinox p2 (runtime install/management)
> bundles into these configurations, so that the runtime can perform
> bundle install and management using p2 (with dependency resolution,
> etc...all the stuff p2 can do).
>
> 3) I'm currently working to create some management APIs...for doing
> (e.g.) bundle install/uninstall/update in both server, RCP, and Eclipse
> client scenarios.
>
> 4) I expect to use the ECF discovery API and remote services API to
> expose the services defined via 3 so that external processes can
> remotely manage an Equinox runtime. Given the transport-independence
> of the approach (ECF discovery and remote services API), this will
> allow the management to be done with an open-ended set of transports.
>
> I agree with you that some of the mechanisms involved are of common and
> general interest. I believe that the ECF discovery and remote services
> are in that category, and I believe that some of the work (just
> beginning) on runtime management may also be in that category. I
> personally would welcome any collaboration that is possible, and agree
> that pooling resources across existing projects may be a very good way
> to go about this (given the common needs among several projects and
> community members).
>
> Thanks Joel,
>
> Scott
>
> [1] http://wiki.eclipse.org/ECF_API_Docs#Remote_Services_API
> [2] http://wiki.eclipse.org/ECF_API_Docs#Discovery_API

The work that you are doing on server side equinox is certainly of
interest (as a side note please see [1]). I am especially pleased that
you are working on management and P2 based provisioning. These are two
areas that very much need attention.

I know that Christian has some really good ideas and plans around a
Universal Exception Handler, that would be very pertinent.

I my reply to Christian I emphasised a need to focus the distribution
to the common "every app can benefit from" features, I think that is
core requirements for adoption.

For me as an adopter I found the lack of documentation to be a real
problem in working out what to use and how to use it. This has to be
addressed if others are going to use our work.

Cheers,
Joel

[1] I find it confusing that within Equinox the context of OSGi "server
side" automatically indicates "web server". This really threw me when I
started to Google around "OSGi" "Equinox" and "server" or "server
side". For me web servers are a very small coner of the server world.
Okay they are ubiquitous and even every grandmother knows what it is,
but give me a break :-) we were creating and using server technology
decades before Tim thought up the web browser. sigh... when all I have
is a hammer :-)

--
Joel Rosi-Schwartz
Etish Limited [http://www.etish.org]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^...^
/ o,o \ The proud parents of Useme & ORMF
|) ::: (| Open Requirements Management Framework
====w=w==== [http://www.eclipse.org/ormf/]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: Why are we all creating our own OSGi server with remoting capability? [message #564530 is a reply to message #13054] Thu, 16 October 2008 14:34 Go to previous message
Dennis O'Flynn is currently offline Dennis O'FlynnFriend
Messages: 73
Registered: July 2009
Member
I think consolidating efforts on a server-side Eclipse platform is a great
idea. There is work is several projects that could be coordinate to provide
a server-side platform similar to what RCP provides for the client-side.

Most of the server-side hype so far has been around running Equinox within a
web app server. I'm more interested in establishing an Eclipse based server
used to host "applications". Other Eclipse projects can deploy there
server-side "applications" to this server-side platform. To accomplish
this, there is additional functionality needed for a server-side platform
that is normally not needed in a client-side environment.

I assume this proposal is to establish such a server-side platform (Equinox
+ Eclipse core runtime + manageability + etc.). Is this correct?

-Dennis



"Joel Rosi-Schwartz" <Joel.Rosi-Schwartz@Etish.org> wrote in message
news:gd22mn$nb7$1@build.eclipse.org...
> Hi,
>
> It seems to me that we may be reinventing the same wheel and I would like
> to propose that we pool our resources and create a base OSGi runtime
> (server) that is capable of remoting over various transport mechanisms
> that are of common and general interest. I am not talking about creating
> an application server, but I think one could be built on top of what I
> considering by others.
>
> Not only do we all have a need for this, but I suspect there are a few
> other Eclipse projects that are or will be requiring similar. Eventually I
> would foresee this effort spinning off into a RT project.
>
> Anyone interested in discussing this?
>
> Thanks,
> Joel
> --
> Joel Rosi-Schwartz
> Etish Limited
> [http://www.etish.org]
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ^...^
> / o,o \ The proud parents of Useme & ORMF
> |) ::: (| Open Requirements Management Framework
> ====w=w==== [http://www.eclipse.org/ormf/]
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
Re: Why are we all creating our own OSGi server with remoting capability? [message #564552 is a reply to message #13201] Thu, 16 October 2008 15:05 Go to previous message
Joel Rosi-Schwartz is currently offline Joel Rosi-SchwartzFriend
Messages: 624
Registered: July 2009
Location: London. England
Senior Member
Hi Dennis,

Great to have you in the conversation.

On 2008-10-16 15:34:23 +0100, "Dennis O'Flynn"
<dennis.oflynn@compuware.com> said:

> I think consolidating efforts on a server-side Eclipse platform is a great
> idea. There is work is several projects that could be coordinate to provide
> a server-side platform similar to what RCP provides for the client-side.

Yes.

> Most of the server-side hype so far has been around running Equinox within a
> web app server. I'm more interested in establishing an Eclipse based server
> used to host "applications". Other Eclipse projects can deploy there
> server-side "applications" to this server-side platform. To accomplish
> this, there is additional functionality needed for a server-side platform
> that is normally not needed in a client-side environment.

Exactly my interests.

> I assume this proposal is to establish such a server-side platform (Equinox
> + Eclipse core runtime + manageability + etc.). Is this correct?

This is how I see it. There will always be an urge (or outside
pressure) to extend this to building a full blow application server
similar to j2ee. My opinion is that our vision should stop far short
of that. There is no reason, though, that what I envision could not be
the basis of such an effort by others in the future.

Are we on the same page?

Joel

>
> -Dennis
Re: Why are we all creating our own OSGi server with remoting capability? [message #564566 is a reply to message #13201] Thu, 16 October 2008 16:00 Go to previous message
Gunnar Wagenknecht is currently offline Gunnar WagenknechtFriend
Messages: 453
Registered: July 2009
Location: Germany ✈ Vancouver
Senior Member

Dennis O'Flynn schrieb:
> Most of the server-side hype so far has been around running Equinox within a
> web app server. I'm more interested in establishing an Eclipse based server
> used to host "applications". Other Eclipse projects can deploy there
> server-side "applications" to this server-side platform. To accomplish
> this, there is additional functionality needed for a server-side platform
> that is normally not needed in a client-side environment.

Hmm, this is already available today in OSGi/Equinox. It's called OSGi
application service. Equinox also has an extension on top of it
(IApplication). It comes with an interface for managing the applications
(via API or console commands). Just type "help" on the Equinox console.
Deployment is also possible using p2. Everything is there.

Or are you guys talking about a web-frontend for managing those?

-Gunnar

--
Gunnar Wagenknecht
gunnar@wagenknecht.org
http://wagenknecht.org/
Re: Why are we all creating our own OSGi server with remoting capability? [message #564580 is a reply to message #13115] Thu, 16 October 2008 18:24 Go to previous message
Scott Lewis is currently offline Scott LewisFriend
Messages: 975
Registered: July 2009
Senior Member
Hi Folks,

Some comments below.

Christian Campo wrote:
> Hi Joel,
>
> I think what you are more interested in is not to worry about my
> resources of RCF, ORMF oder OSEE for that matter but rather have a
> common unified way to define and use remote services in OSGi. So that
> you and others dont have to make tough choices between different APIs
> for different remoting implementations.
>
> For this to work, I believe there needs to be a set of APIs how such a
> remote service mechanism looks like and then everybody can program
> against it. As Scott already mentioned it, this API spec exists and ist
> called "RFC 119", a part of OSGi 4.2 spec that defines how OSGi services
> become remote services.


At least the versions that I've seen of RFC 119 is that it does not
actually define runtime APIs, but rather it defines a declarative
structure for registration and look up of remote services. This may
have changed more recently but the last version I saw didn't define
programmatic APIs (e.g. java interfaces).

The spec is also 'just a spec'...in the sense that many implementations
can/should/will exist. AFAIK, there is not a reference implementation
for RFC 119 yet, although I've heard from Jan that there are
proprietary/closed implementations from a/some member companies...and
these might be considered reference implementations...although I'm not
clear on the OSGi orgs model for reference implementations (i.e. whether
they can be/must be open source).

Further, I don't believe RFC 119 is actually finished/approved in any
formal way, so I would expect it to change before it is approved
(nothing wrong with that, it's just that it's still early days in terms
of standardization).

If I've misstated any of these elements Jan R or Markus K will (please)
correct me.

>
> I underline that this is the spec is what you are probably looking for
> for remoting. I still think there is a lot more that you need for
> building an application server, but that wasnt your topic. (my assumption).


Even with the spec, everyone will need an implementation to build
anything upon.

>
> As Scott said there will be a RFC119 compliant implementation in ECF
> rather sooner than later.


Yes. We have as one of our 3.0 plan items to use the ECF remote
services API and ECF discovery API to implement RFC119. Since ECF's
APIs *are* runtime APIs, we believe we can (with minimal/hopefully no
changes to the runtime API) implement the RFC 119 declarative structures.

Of course, ECF's remote services and discovery APIs are open/open source
and will remain so. Our hope is that some will use the existing
provider/transport implementations (i.e. r-OSGi, XMPP, JMS, ECF
generic), and that others will create providers...both in open source
and proprietary.

One very positive side effect of this approach is that if we are able to
use the ECF remote services API/discovery API to create a reference impl
of RFC 119, then that work would not have to be done separately for each
provider...i.e. they all would then be RFC 119 compliant...i.e.

RFC 119 -> ECF rs/disc APIs -> ECF providers (r-OSGI, XMPP, etc)


I foresee that others have their own
> implementation (within Eclipse and outside in other OSGi container
> implementations). But that is no longer your worry because you use a
> standard API and can use any implementation that you like that complies
> to that standard.

Well, that's the good thing about standards...there are so many to
choose from :). Just kidding...I am glad that RFC 119 is making
progress and am happy to support it...but I do think that

1) Having working implementations is important to actually drive the
standard (because I haven't seen a standard yet that got it right the
first time)

2) I feel that RFC 119 has overemphasized declarative approaches and has
not focused enough (at least to my knowledge) on runtime API...which for
some clients/use cases is a more natural approach (i.e. declarative is
not my personal favorite for (e.g.) server-side remote services).

Thanks,

Scott



>
> christian campo
>
>
> Joel Rosi-Schwartz schrieb:
>> Hi,
>>
>> It seems to me that we may be reinventing the same wheel and I would
>> like to propose that we pool our resources and create a base OSGi
>> runtime (server) that is capable of remoting over various transport
>> mechanisms that are of common and general interest. I am not talking
>> about creating an application server, but I think one could be built
>> on top of what I considering by others.
>>
>> Not only do we all have a need for this, but I suspect there are a few
>> other Eclipse projects that are or will be requiring similar.
>> Eventually I would foresee this effort spinning off into a RT project.
>>
>> Anyone interested in discussing this?
>>
>> Thanks,
>> Joel
Re: Why are we all creating our own OSGi server with remoting capability? [message #564604 is a reply to message #13174] Thu, 16 October 2008 18:51 Go to previous message
Scott Lewis is currently offline Scott LewisFriend
Messages: 975
Registered: July 2009
Senior Member
Hi Joel,

Joel Rosi-Schwartz wrote:
<stuff deleted>

>
> The work that you are doing on server side equinox is certainly of
> interest (as a side note please see [1]). I am especially pleased that
> you are working on management and P2 based provisioning. These are two
> areas that very much need attention.
>
> I know that Christian has some really good ideas and plans around a
> Universal Exception Handler, that would be very pertinent.
>
> I my reply to Christian I emphasised a need to focus the distribution to
> the common "every app can benefit from" features, I think that is core
> requirements for adoption.
>
> For me as an adopter I found the lack of documentation to be a real
> problem in working out what to use and how to use it. This has to be
> addressed if others are going to use our work.


Yes, I agree. We (ECF) team would very much appreciate:

1) Creation of specific enhancement requests for documentation areas
that people consider problematic...so we can prioritize efforts there.
We know that more documentation is needed (of course), but want to
target the specific problematic areas rather than guess.

2) Any contributions of documentation, example code, etc. Like other EF
projects, ECF is a community project and has to depend upon its
community for contributions.

>
> Cheers,
> Joel
>
> [1] I find it confusing that within Equinox the context of OSGi "server
> side" automatically indicates "web server". This really threw me when I
> started to Google around "OSGi" "Equinox" and "server" or "server side".
> For me web servers are a very small coner of the server world. Okay they
> are ubiquitous and even every grandmother knows what it is, but give me
> a break :-) we were creating and using server technology decades before
> Tim thought up the web browser. sigh... when all I have is a hammer :-)
>

I agree completely with you. Equinox servers can/could/will be the
basis for all manner of servers: web servers (of course), but also
(e.g.) XMPP servers [1], event/messaging servers [2], game servers,
etc., etc

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=235844
[2]
http://www.bea.com/framework.jsp?CNT=index.htm&FP=/conte nt/products/weblogic/event_server/
Re: Why are we all creating our own OSGi server with remoting capability? [message #564612 is a reply to message #13256] Thu, 16 October 2008 19:50 Go to previous message
Scott Lewis is currently offline Scott LewisFriend
Messages: 975
Registered: July 2009
Senior Member
Just a quick comment below,

Gunnar Wagenknecht wrote:
> Dennis O'Flynn schrieb:
>> Most of the server-side hype so far has been around running Equinox within a
>> web app server. I'm more interested in establishing an Eclipse based server
>> used to host "applications". Other Eclipse projects can deploy there
>> server-side "applications" to this server-side platform. To accomplish
>> this, there is additional functionality needed for a server-side platform
>> that is normally not needed in a client-side environment.
>
> Hmm, this is already available today in OSGi/Equinox. It's called OSGi
> application service. Equinox also has an extension on top of it
> (IApplication). It comes with an interface for managing the applications
> (via API or console commands). Just type "help" on the Equinox console.
> Deployment is also possible using p2. Everything is there.


Although Gunnar is right about there being p2 console commands they are
not extensive (i.e. it lets you do some adding/viewing of p2
repositories, creating proiles, and installing components from those
repositories). It doesn't (yet) support uninstall, reverting to
previous profiles/versions, etc or other things that p2 can do.

Scott
Re: Why are we all creating our own OSGi server with remoting capability? [message #564636 is a reply to message #13256] Fri, 17 October 2008 10:39 Go to previous message
Joel Rosi-Schwartz is currently offline Joel Rosi-SchwartzFriend
Messages: 624
Registered: July 2009
Location: London. England
Senior Member
On 2008-10-16 17:00:53 +0100, Gunnar Wagenknecht <gunnar@wagenknecht.org> said:

> Dennis O'Flynn schrieb:
>> Most of the server-side hype so far has been around running Equinox within a
>> web app server. I'm more interested in establishing an Eclipse based server
>> used to host "applications". Other Eclipse projects can deploy there
>> server-side "applications" to this server-side platform. To accomplish
>> this, there is additional functionality needed for a server-side platform
>> that is normally not needed in a client-side environment.
>
> Hmm, this is already available today in OSGi/Equinox. It's called OSGi
> application service. Equinox also has an extension on top of it
> (IApplication). It comes with an interface for managing the applications
> (via API or console commands). Just type "help" on the Equinox console.
> Deployment is also possible using p2. Everything is there.
>
> Or are you guys talking about a web-frontend for managing those?
>
> -Gunnar

I do not think that we are speaking specifically about a web-frontend,
at least that is not my thinking. Rather, I thing that we need an
expanded set of management services exposed as an API that enables
extended console commands, but more importantly (IMHO) also exposes
these to any GUI based client that wants to support them. These could
be Web, Java Swing, SWT, RCP, etc.. The point is to enable the
possibilities.

As far as "Everything is there", well I am a new to OSGi so maybe I am
just not getting it. But as a person whose goal is to create a
Requirements Framework, I certainly do not experience it as simply
being there. If I am missing the point, I would truly appreciate it if
someone could point my in the right direction.

Joel
--
Joel Rosi-Schwartz
Etish Limited [http://www.etish.org]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^...^
/ o,o \ The proud parents of Useme & ORMF
|) ::: (| Open Requirements Management Framework
====w=w==== [http://www.eclipse.org/ormf/]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: Why are we all creating our own OSGi server with remoting capability? [message #564657 is a reply to message #14013] Fri, 17 October 2008 16:15 Go to previous message
Scott Lewis is currently offline Scott LewisFriend
Messages: 975
Registered: July 2009
Senior Member
Hi Joel,

Joel Rosi-Schwartz wrote:
<stuff deleted>

>> Hmm, this is already available today in OSGi/Equinox. It's called OSGi
>> application service. Equinox also has an extension on top of it
>> (IApplication). It comes with an interface for managing the applications
>> (via API or console commands). Just type "help" on the Equinox console.
>> Deployment is also possible using p2. Everything is there.
>>
>> Or are you guys talking about a web-frontend for managing those?
>>
>> -Gunnar
>
> I do not think that we are speaking specifically about a web-frontend,
> at least that is not my thinking. Rather, I thing that we need an
> expanded set of management services exposed as an API that enables
> extended console commands, but more importantly (IMHO) also exposes
> these to any GUI based client that wants to support them. These could be
> Web, Java Swing, SWT, RCP, etc.. The point is to enable the possibilities.


Yes, this is a very good point...and is essentially what I have just
started to do: create APIs (interfaces) which expose management
capabilities for different parts of Equinox.

There are, of course, several large 'parts' of Equinox that can be
managed: The OSGI concepts (i.e. starting/stopping bundles),
capabilities exposed by the Equinox IApplication API (starting/stopping
applications), capabilities exposed by p2
(installing/updating/uninstalling IUs...which can represent
components/modules, individual bundles, IApplications, or other things
(e.g. features).

I agree with Joel that such APIs need to be separated from any
particular user interface, so that different interfaces can/could be
used (console, web, RCP/SWT/, etc as Joel lists).

Further, I think it's a good idea to design these interfaces such that
they can be easily used remotely...with whatever remoting technology.
For example, not passing around complicated objects by reference as
parameters in the API...since marshaling can/would be made difficult or
impossible.

So this is what I am starting (defining these interfaces) as applied to
the management capabilities exposed by OSGi, IApplication API, and P2
(to begin anyway). I would/will be happy to collaborate with any/all of
you on this.


>
> As far as "Everything is there", well I am a new to OSGi so maybe I am
> just not getting it.


I think that Gunnar was referring specifically to the IApplication
structures for launching/stopping applications within an Equinox
runtime...and using them from the console.

If the (equinox, IApplication, p2) capabilities are to be exposed for
other UIs (other than the console), then creating APIs one level down
from the console will indeed be necessary...and so that's why I've begun
going in those directions.

Scott
Re: Why are we all creating our own OSGi server with remoting capability? [message #564675 is a reply to message #13256] Sat, 18 October 2008 03:43 Go to previous message
Simon Kaegi is currently offline Simon KaegiFriend
Messages: 381
Registered: July 2009
Senior Member
I get the feeling when Joel started this thread he was more interested in
the more general remoting problems as opposed to remote management but I'll
admit I'm very interested in this second problem. ...comments inlined...

"Gunnar Wagenknecht" <gunnar@wagenknecht.org> wrote in message
news:gd7ofo$pdq$1@build.eclipse.org...
> Dennis O'Flynn schrieb:
>> Most of the server-side hype so far has been around running Equinox
>> within a
>> web app server. I'm more interested in establishing an Eclipse based
>> server
>> used to host "applications". Other Eclipse projects can deploy there
>> server-side "applications" to this server-side platform. To accomplish
>> this, there is additional functionality needed for a server-side platform
>> that is normally not needed in a client-side environment.
>
> Hmm, this is already available today in OSGi/Equinox. It's called OSGi
> application service. Equinox also has an extension on top of it
> (IApplication). It comes with an interface for managing the applications
> (via API or console commands). Just type "help" on the Equinox console.
> Deployment is also possible using p2. Everything is there.
>
I use the console a great deal in my day-to-day ops and think it's very
useful as a way to take a look at the state of the system but am less
confident in its abilities to modify the system. Perhaps if it somehow it
allowed one to run scripts...

> Or are you guys talking about a web-frontend for managing those?
If anyone was looking for a show of hands, I would be interested in working
on a web-frontend as a green thread for server management work. By this I
don't necessarily mean something specific to web UIs (although that might be
a good first target) but more looking at a HTTP/resource based way at
getting state and manipulating the framework in interesting ways.

Last year I looked at a few remote management possibilites for p2 and
equinox and although we didn't end up doing work in the area felt that a DMT
Admin based approach might be worth a second look. (For those not
familiar... DMT stands for Device Management Tree and the DMT Admin Service
is one of the specifications put out by the OSGi Alliance and is in the R4.1
service compendium -- see http://www.osgi.org/Specifications/HomePage )

I mention DMT only since it's often overlooked in favour of JMX/WSDM.
Speaking of which... there is some JMX work in the Equinox Incubator that
although now a little dated might be worth a look.

-Simon
Re: Why are we all creating our own OSGi server with remoting capability? [message #564700 is a reply to message #14052] Sat, 18 October 2008 09:33 Go to previous message
Joel Rosi-Schwartz is currently offline Joel Rosi-SchwartzFriend
Messages: 624
Registered: July 2009
Location: London. England
Senior Member
On 2008-10-18 04:43:43 +0100, "Simon Kaegi" <simon_kaegi@ca.ibm.com> said:

> I get the feeling when Joel started this thread he was more interested in
> the more general remoting problems as opposed to remote management but I'll
> admit I'm very interested in this second problem. ...comments inlined...

Simon is almost right, that was my starting point as a hard requirement
I personally have. In fact, however, my broader desire is for the work
to support all of the "basics" that most server projects require. With
the caveat (that I keep bringing up;) that I do not propose that we
build an application server; that is for another person another day.
Remoting, management, provisioning, IoC/DI (SAT?), logging, ...
available as single distribution and ready to go.

Joel
Re: Why are we all creating our own OSGi server with remoting capability? [message #564759 is a reply to message #13228] Mon, 20 October 2008 12:59 Go to previous message
Dennis O'Flynn is currently offline Dennis O'FlynnFriend
Messages: 73
Registered: July 2009
Member
Joel,

Short answer: yes - I think we are on the same page.

Long answer:

The Eclipse Foundation is ideally positioned to provide a server-side
platform parallel to what it already provides with RCP. This includes both
the tooling (development) and runtime (deployment) environments. In
addition, Eclipse can provide a consistent programming model for both client
and server components (aka plug-ins).

I believe an Eclipse server-side platform would be / could be comprised of:
* Equinox
** service component model
** service application model
* Eclipse core runtime
** extension component model
* Managability
** JMX (exemplary implementation)
* Logging
** This can be messy if not addressed up front
* Interoperabiity
** web services
** messaging
* Spring-OSGi
* Native-OS service
** Enhance Equinox launcher to support Apache Commons Daemon, etc...

Such a server-side platform could support the deployment of multiple
"applications" (OSGI service applications) from different providers. The
server-side platform would provide the runtime environment needed to host
the applications. Imagine being able to deploy a database service
application (ex: Derby Network Server), communications service application
(ex: ECF generic server), as well as other projects' service applications
all to the same server-side platform.

I think the focus of this propsoal to "pool our resources and create a base
OSGi runtime (server)" should be to focus on providing the Eclipse
server-side platform to support the deployment and management of OSGi
service applications.
Re: Why are we all creating our own OSGi server with remoting capability? [message #564777 is a reply to message #14120] Mon, 20 October 2008 15:44 Go to previous message
Joel Rosi-Schwartz is currently offline Joel Rosi-SchwartzFriend
Messages: 624
Registered: July 2009
Location: London. England
Senior Member
Dennis,

That's a somewhat broader vision than I started with, but one that I
would be very happy to participate in. Are you going to write the
project proposal :-) I'd be very pleased to sign on.

Cheers,
Joel


On 2008-10-20 14:59:27 +0200, "Dennis O'Flynn"
<dennis.oflynn@compuware.com> said:

> Joel,
>
> Short answer: yes - I think we are on the same page.
>
> Long answer:
>
> The Eclipse Foundation is ideally positioned to provide a server-side
> platform parallel to what it already provides with RCP. This includes both
> the tooling (development) and runtime (deployment) environments. In
> addition, Eclipse can provide a consistent programming model for both client
> and server components (aka plug-ins).
>
> I believe an Eclipse server-side platform would be / could be comprised of:
> * Equinox
> ** service component model
> ** service application model
> * Eclipse core runtime
> ** extension component model
> * Managability
> ** JMX (exemplary implementation)
> * Logging
> ** This can be messy if not addressed up front
> * Interoperabiity
> ** web services
> ** messaging
> * Spring-OSGi
> * Native-OS service
> ** Enhance Equinox launcher to support Apache Commons Daemon, etc...
>
> Such a server-side platform could support the deployment of multiple
> "applications" (OSGI service applications) from different providers. The
> server-side platform would provide the runtime environment needed to host
> the applications. Imagine being able to deploy a database service
> application (ex: Derby Network Server), communications service application
> (ex: ECF generic server), as well as other projects' service applications
> all to the same server-side platform.
>
> I think the focus of this propsoal to "pool our resources and create a base
> OSGi runtime (server)" should be to focus on providing the Eclipse
> server-side platform to support the deployment and management of OSGi
> service applications.
Re: Why are we all creating our own OSGi server with remoting capability? [message #564792 is a reply to message #14137] Mon, 20 October 2008 16:44 Go to previous message
Dennis O'Flynn is currently offline Dennis O'FlynnFriend
Messages: 73
Registered: July 2009
Member
Maybe we should have a confernece call where we can set the scope of this
initiative. This would give everyone interested a chance to share their
ideas and agree upon the direction.

What do you think?

"Joel Rosi-Schwartz" <Joel.Rosi-Schwartz@Etish.org> wrote in message
news:gdi91d$f9h$1@build.eclipse.org...
> Dennis,
>
> That's a somewhat broader vision than I started with, but one that I would
> be very happy to participate in. Are you going to write the project
> proposal :-) I'd be very pleased to sign on.
>
> Cheers,
> Joel
>
>
> On 2008-10-20 14:59:27 +0200, "Dennis O'Flynn"
> <dennis.oflynn@compuware.com> said:
>
>> Joel,
>>
>> Short answer: yes - I think we are on the same page.
>>
>> Long answer:
>>
>> The Eclipse Foundation is ideally positioned to provide a server-side
>> platform parallel to what it already provides with RCP. This includes
>> both
>> the tooling (development) and runtime (deployment) environments. In
>> addition, Eclipse can provide a consistent programming model for both
>> client
>> and server components (aka plug-ins).
>>
>> I believe an Eclipse server-side platform would be / could be comprised
>> of:
>> * Equinox
>> ** service component model
>> ** service application model
>> * Eclipse core runtime
>> ** extension component model
>> * Managability
>> ** JMX (exemplary implementation)
>> * Logging
>> ** This can be messy if not addressed up front
>> * Interoperabiity
>> ** web services
>> ** messaging
>> * Spring-OSGi
>> * Native-OS service
>> ** Enhance Equinox launcher to support Apache Commons Daemon, etc...
>>
>> Such a server-side platform could support the deployment of multiple
>> "applications" (OSGI service applications) from different providers. The
>> server-side platform would provide the runtime environment needed to host
>> the applications. Imagine being able to deploy a database service
>> application (ex: Derby Network Server), communications service
>> application
>> (ex: ECF generic server), as well as other projects' service applications
>> all to the same server-side platform.
>>
>> I think the focus of this propsoal to "pool our resources and create a
>> base
>> OSGi runtime (server)" should be to focus on providing the Eclipse
>> server-side platform to support the deployment and management of OSGi
>> service applications.
>
>
Re: Why are we all creating our own OSGi server with remoting capability? [message #564809 is a reply to message #14120] Mon, 20 October 2008 20:01 Go to previous message
Scott Lewis is currently offline Scott LewisFriend
Messages: 975
Registered: July 2009
Senior Member
All,

Perhaps we should create a new 'management' incubation component within
the Equinox project so that those of us working on/thinking about
management for Equinox runtimes can have a place and means to share them.

A new component would give us all a

1) place to share contributions in CVS
2) record/share work with standards orgs (e.g. DMT, WSDM, OADM, etc),
3) share information among all of us with wiki and web pages

What do people think? Should we speak with the Runtime PMC about such a
component?

Scott

Dennis O'Flynn wrote:
> Joel,
>
> Short answer: yes - I think we are on the same page.
>
> Long answer:
>
> The Eclipse Foundation is ideally positioned to provide a server-side
> platform parallel to what it already provides with RCP. This includes both
> the tooling (development) and runtime (deployment) environments. In
> addition, Eclipse can provide a consistent programming model for both client
> and server components (aka plug-ins).
>
> I believe an Eclipse server-side platform would be / could be comprised of:
> * Equinox
> ** service component model
> ** service application model
> * Eclipse core runtime
> ** extension component model
> * Managability
> ** JMX (exemplary implementation)
> * Logging
> ** This can be messy if not addressed up front
> * Interoperabiity
> ** web services
> ** messaging
> * Spring-OSGi
> * Native-OS service
> ** Enhance Equinox launcher to support Apache Commons Daemon, etc...
>
> Such a server-side platform could support the deployment of multiple
> "applications" (OSGI service applications) from different providers. The
> server-side platform would provide the runtime environment needed to host
> the applications. Imagine being able to deploy a database service
> application (ex: Derby Network Server), communications service application
> (ex: ECF generic server), as well as other projects' service applications
> all to the same server-side platform.
>
> I think the focus of this propsoal to "pool our resources and create a base
> OSGi runtime (server)" should be to focus on providing the Eclipse
> server-side platform to support the deployment and management of OSGi
> service applications.
>
>
Re: Why are we all creating our own OSGi server with remoting capability? [message #564876 is a reply to message #14137] Wed, 29 October 2008 10:29 Go to previous message
Dennis O'Flynn is currently offline Dennis O'FlynnFriend
Messages: 73
Registered: July 2009
Member
Joel,

I posted a brief write-up of a proposed Eclipse Server Platform to Riena's
Idea wiki page:
*
http://wiki.eclipse.org/Riena_Interesting_Ideas#Eclipse_Serv er-side_Platform


"Joel Rosi-Schwartz" <Joel.Rosi-Schwartz@Etish.org> wrote in message
news:gdi91d$f9h$1@build.eclipse.org...
> Dennis,
>
> That's a somewhat broader vision than I started with, but one that I would
> be very happy to participate in. Are you going to write the project
> proposal :-) I'd be very pleased to sign on.
>
> Cheers,
> Joel
>
Previous Topic:New ORMF contributors
Next Topic:Does Corona still support OS X
Goto Forum:
  


Current Time: Thu Dec 18 21:57:10 GMT 2014

Powered by FUDForum. Page generated in 0.04596 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software