river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike McGrady <mmcgr...@topiatechnology.com>
Subject Re: River & OSGi
Date Mon, 09 Nov 2009 04:13:48 GMT
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
mmcgrady@topiatechnology.com










Mime
View raw message