Yes that's the beauty of Services, they provide opportunity for
pluggable replacement implementations. That's the "Service
Pattern" As
we have seen it is possible to use the Service Pattern to solve
a number
of different problems. Eg Netbean Plugins, SPI, OSGi, Jini.
I'm looking at OSGi to wire up services inside the JVM as you
say. When
I say package, I mean a java package residing in the local JVM
it may or
may not be part of a Jini service, it may be a purely local JVM
package,
eg a library dependency or local domain package. For example, I
have
package X, version 1 loaded in my local JVM, I need to have
package X
version 2 loaded as version 1 isn't compatible with the new
Objects
(domain data) I'm recieving in serialized form. I need to share
this
information locally with Package Y that currently has references
to
objects in Package X version 1. The Objects in Package X
version 1 that
Package Y references need to have their class files upgraded.
Without
OSGi I can do this by persisting state, stopping the JVM,
restarting and
loading package X version 2.
I'm not looking at distributed OSGi, but I can see a use case for
utilising a Jini Service, when a local OSGi bundle that performs
some
task that could be done optimally if the processing can be moved
to
where the data resides, this is just an example there are
probably 10
other ways of doing this:
A local application bundle that provides an OSGi service locally
queries
a remote database using JDBC and performs a considerable amount of
manipulation to that data prior to returning a subset. The
query and
its result are sent over the network using a database JDBC
connection.
The processing for that data, if shifted to the machine that has
the
database data, would consume significantly less network
resources. EG
the data transferred over the network is reduced by a factor of
100 by
processing the data on the database machine after querying. A
bundle
that provides a "local JVM application" an "OSGi service" could
utilise
a "Jini Service" to request the data be processed at the Database
machine in a particular manner before receiving the result. This
function could be locally available as an OSGi service to some
other
local application, that application doesn't need to know about
Jini, it
is an implementation detail that is abstracted.
My objectives are all based around codebase services (objects
aren't
locked to their http codebase origin), in combination with OSGi or
something like it, to ensure compatible classes and packages are
loaded
among separate JVM instances. Yes Newton does something similar,
however it is AGPLv3 licensed.
I envision a distributed environment where nodes can have the
majority
of their packages downloaded and upgraded via codebase servcies.
Providing an evolving cluster, that upgrades it's bundles
incrementally,
while maintaining the maximum level of class and package
compatibility.
Think Agile Cluster Running System component upgrades.
People, who are jumping in now because I've mentioned OSGi, are
making
assumptions and haven't been following the discussions I've posted
previously about Versioned Classes, Classloader trees, Static
Analysis
and Codebase Services, this is frustrating as I was hoping for
some
participation. It seems I can only get attention when I mention a
controversial subject. What I want is attention to solving the
problems
that will make River better.
In my note below when I'm referring to the "Service Pattern", I
mean the
service pattern that OSGi implements, enables bundles to be
upgraded by
loading the replacement bundle in a new classloader, The
service is a
common interface, the new upgraded service is discovered after
it is
started. The alternative is to use delegates to update references
between objects when the Classloader changes as per some of the
other
patches I've uploaded.
Jini also utilises a "Service Pattern", but to solve a different
problem.
I knew this was going to be a difficult topic to present.
What we need are separate lists, where people who want to
participate in
constructive development to solve problems can do so and another
list
where people can pontificate about software ideals and have
disrespectful arguments with each other without holding up
development.
While we're developing we can keep an eye on the argument list
without
getting embroiled.
Anyway I've said enough, I'm going back to doing the things I
need to
do, if someone who has been following my posts to date has
implementation ideas, but are afraid to mention it, please feel
free to
contact me directly to discuss, I do need some input to gain
confidence
that I'm approaching these problems in the right manner.
Peter.
Dennis Reedy wrote:
On Nov 8, 2009, at 1251AM, Peter Firmstone wrote:
I had avoided OSGi purely due to the controversy it generates
on this
list, however without the Service Pattern one cannot upgrade a
package
without first persisting everything and shutting down the
entire JVM,
then restarting. At least OSGi allows you to stop a bundle
and any
dependents, persist what you need to then start with a later
bundle
version if desired, without having to persist or shut down the
entire
JVM.
If thats all you want you dont need OSGi. Service lifecycles are
supported with a variety of container approaches, from JEE,
Spring to
Rio. You also do not need to shutdown the JVM to load new service
classes.
Adopting OSGi as a micro-kernel architecture for wiring up
services
inside the JVM is a different thing. Looking at distributed
OSGi is a
totally different thing on top of that. IMO, if you want to
consider
OSGi for River, you focus on the former, not the latter.
