| The other side of the server-side coin [message #63611] |
Thu, 16 March 2006 22:25  |
Eclipse User |
|
|
|
Originally posted by: bhunt.online.mac.com
I've just started reading about the new OSGi server-side work, and it
looks interesting. It appears that you are looking at embedding OSGi
inside a container - do I understand this correctly? Has anyone
considered the other side of the coin - creating a container as a
plugin? it seems that there could be a framework of server-side
services that would operate at a higher level outisde a web container
or an EJB container.
For example, I could imagine a generic RSP (Rich Server Platform) with
tooling in the Eclipse IDE that could connect to the RSP and deploy
plugins. I might create a plugin with a task extension point. The
plugin would execute the task extensions at user specified times (think
cron). Other developers could crete plugins that extended that task
extension point and simply deploy their plugins for execution.
Just my $0.02
Bryan
|
|
|
| Re: The other side of the server-side coin [message #63634 is a reply to message #63611] |
Thu, 16 March 2006 23:03  |
 Harald Niesche
Messages: 23
Registered: July 2009 |
Junior Member |
|
|
Bryan Hunt wrote:
> I've just started reading about the new OSGi server-side work, and it
> looks interesting. It appears that you are looking at embedding OSGi
> inside a container - do I understand this correctly? Has anyone
> considered the other side of the coin - creating a container as a
> plugin? it seems that there could be a framework of server-side
> services that would operate at a higher level outisde a web container or
> an EJB container.
There is the OSGi HttpService that implements something like a servlet
container. Several implementations are available, one is based on Jetty,
so you might say this has been considered.
I believe the whole point of the embedding efforts to be that you no
longer have to care where your bundle will be deployed -- you can deploy
it as part of some web application, in a rich client or in some embedded
server application, the bundle won't have to know.
> For example, I could imagine a generic RSP (Rich Server Platform) with
> tooling in the Eclipse IDE that could connect to the RSP and deploy
> plugins. I might create a plugin with a task extension point. The
> plugin would execute the task extensions at user specified times (think
> cron). Other developers could crete plugins that extended that task
> extension point and simply deploy their plugins for execution.
I am not sure, but someone may already be working on IDE support for
provisioning. Manageability is one of the goals of the OSGi platform.
And for your 'cron' service, an implementation based on (declarative)
services might be nicer, as it would allow you to add tasks dynamically
without installing any bundles (I believe extension points are only
parsed on framework startup / bundle installation, please correct me if
I am wrong).
In the discussions about the OSGi server-side stuff, several people
mentioned that a higher-level application model like the RCP model would
be needed, so I think your ideas on this subject will be very welcome.
Harald
|
|
|
|
| Re: The other side of the server-side coin [message #63679 is a reply to message #63611] |
Fri, 17 March 2006 01:43 |
Patrick Mueller
Messages: 15
Registered: July 2009 |
Junior Member |
|
|
Bryan Hunt wrote:
> I've just started reading about the new OSGi server-side work, and it
> looks interesting. It appears that you are looking at embedding OSGi
> inside a container - do I understand this correctly? Has anyone
> considered the other side of the coin - creating a container as a
> plugin? it seems that there could be a framework of server-side
> services that would operate at a higher level outisde a web container or
> an EJB container.
Running a container as a bundle is a nice development time story, as you
can then do a launch via an equinox launch, instead of having to deploy
your plugins inside a container's web app and deal with that. I've got
a not-completely-kosher-servlet-wise Jetty launch for some servlet work
I do now, that's good enough for me, and the launch time is a couple of
seconds. Very nice compared to having to having to deal with a real
container, external to the IDE (even nicer that WTP, for me anyway).
Ideally, such a story could dovetail with the servlet bridge, so you
could do your final deployment that way, but all your development work
with the 'container in a bundle' story.
I suppose the best answer would be to see if the HttpService in OSGi
would serve this purpose. It might. Kill two birds with one stone: get
the HttpService implemented in equinox OSGi, and create a usable
development environment for folks planning on deploying under the
servlet bridge.
Note that I'm assuming equinox doesn't already implement the
HttpService; otherwise you could already do this, or something close.
--
Patrick Mueller - pmuellr@yahoo.com
Oblique Strategies: Accretion
|
|
|
|
| Re: The other side of the server-side coin [message #63724 is a reply to message #63657] |
Sat, 18 March 2006 01:53 |
Harald Niesche
Messages: 23
Registered: July 2009 |
Junior Member |
|
|
Erkki Lindpere wrote:
> This whole OSGi in the container thing seems very interesting to me, and
> it would be great to deploy for example BIRT in a web app as it is,
> without requiring it's own "platform" or plugin loading mechanism, but
> just standard OSGi.
>
> But there's one thing that concerns me: how (if at all) is scalability
> addressed? I have only read parts of the OSGi spec, and haven't really
> taken a look at all this that has been discussed in this newsgroup
> lately, but based on what I know, OSGi doesn't seem to handle
> scalability very well?
You are right: OSGi isn't about scalability, or replication services.
But it doesn't keep you from replicating things, I find it supports it
rather nicely. We have built an application on top of an embedded OSGi
framework that runs distributed across several machines.
OSGi actually helped doing it, because by reducing the coupling between
service use and implementations it made the services easier to distribute.
Harald
|
|
|
|
Powered by
FUDForum. Page generated in 0.02596 seconds
] 
Search
Help
Register
Login
Home
