Good luck with your endeavours too Mike.
Perhaps you might try a less aggressive approach next time, look for the
common ground first, I don't know anybody that likes being told they
don't know what they're talking about, perhaps my ego isn't the only one
that got in the way?
I hope your friends found it amusing. Do you still have the iPhone?
Peter.
Mike McGrady wrote:
I am presently the author of a framework called "Karma" (Kolona
Automated Resource Management Architecture) that is open source with a
management app under another open source framework AUM (Automated
Universal Middleware).
UM (Universal Middleware) is a more current name for OSGi.
We could have called it DUM (Distributed Universal Middleware) instead
of AUM but thought better.
Too bad we did not get on better when I asked you what you meant by
"Service Pattern". (I still have no idea what you mean.) Anyway,
this does all you want to do and we have a plan to have it set as a
standard with IEEE, where I am a member of the standards committee.
If you check there in a few months, you can see what I was hoping to
talk to you about before your ego got in the way.
Good luck with your endeavors.
Mike
On Nov 8, 2009, at 5:06 PM, Peter Firmstone wrote:
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.
Mike McGrady
Principal Investigator AF081-028 AFRL SBIR
Senior Engineer
Topia Technology, Inc.
1.253.720.3365
[email protected]
