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 13:36:23 GMT
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 <jini@zeus.net.au>  
>> 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
>>>>> mmcgrady@topiatechnology.com
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>

Mike McGrady
Principal Investigator AF081-028 AFRL SBIR
Senior Engineer
Topia Technology, Inc.
1.253.720.3365
mmcgrady@topiatechnology.com










Mime
View raw message