http://kharma.sourceforge.net/
On Nov 9, 2009, at 4:59 AM, Dennis Reedy wrote:
Mike,
I've seen little reference to Kolona Automated Resource Management
Architecture, other then at http://www.topiaventures.com/. You
mention its open source, where is the project located and what
license is it?
Also, can you provide some detail on how you are using KARMA and AUM
to OSGify GigaSpaces?
On Nov 9, 2009, at 727AM, Mike McGrady wrote:
Thank you.
My desire was not to force you to talk any particular way. My
desire was to find out what you neantt. I suspected from my own
experience that once you gave your statements a fleshing out that
they would not hang together.
The more important thong in my thinking is my work with very large
and complicated systems and my resultant need to separate things
into cohesive units matching a sensible architecture.
My present work involves connecting the global information grid
(GIG) with the FAA NAS through FAA SWIM with a pluggable
architecture that will work with other ATC agencies like SESAR. I
am using KARMA and AUM to OSGify GigaSpaces.
So you can see I am very much atti ed to what you want to do but
just think you might be misapprehending OSGi by not fully grasping
it's notion of services. I would suggest a close read of Richard
Hall's MEAP book on ISGi.
Mike
Sent from my iPhone
On Nov 9, 2009, at 12:15 AM, Peter Firmstone <[email protected]>
wrote:
Mike,
You come from a background of Standard setting? Well that
explains your wish to have a discussion using "correct
terminology". For a layman like myself (at least in Computing), I
use loose terms to describe what I'm talking about. I guess this
means there's a gulf between us when making attempts to
communicate using computing terms. To the layman, me, a Service
appears to be a software design pattern. Yes I'm also guilty of
calling MVC a design pattern.
On the other hand, something that you can take away from our
conversation, that might serve you well in future endeavors, is
that you need tolerance, patience and understanding when dealing
with people who are of different cultural or work backgrounds, the
average programmer is not at your level of detail and would most
likely take offense.
I'm a Mechanical Engineer, so I understand the importance of
accurate terms in Engineering, the only difference between my
field and yours, is that Mechanical Engineers are legally liable
and suffer heavy penalties, or gaol terms for mistakes, hence
strict adherence to terminology, so it is surprising to see it in
computing.
If I were to discuss with you, a Power Station, or Structural
Stress, you would be the layman.
I decided to respond in an aggressive manner, as your post had the
tell tale signs of a protracted heated argument brewing and this
Subject has been touchy in the past. I was cutting you off at the
pass and battening down the hatches.
You have my apologies, I didn't show you the courtesy of
tolerance, patience and understanding either. I take back what I
said.
If you'd like to try again, you can tell me that my terminology
isn't right and I'll try to find another way of explaining it,
without getting frustrated or offended. But you must also
understand, that just because people like myself don't use proper
terminology doesn't mean we don't have an understanding, you might
have a better understanding, but do try not to get frustrated,
that is detectable and comes across poorly.
Regards,
Peter Firmstone.
Peter Firmstone wrote:
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]
Mike McGrady
Principal Investigator AF081-028 AFRL SBIR
Senior Engineer
Topia Technology, Inc.
1.253.720.3365
[email protected]
