Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4AF80ECA.6020404@zeus.net.au>
Date: Mon, 09 Nov 2009 22:44:58 +1000
From: Peter Firmstone <jini@zeus.net.au>
Organization: Zeus Project Services
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: river-dev@incubator.apache.org
Subject: Re: River & OSGi
References: <4AF391EE.70006@zeus.net.au>
	 <0D2AF945-B7BF-4DA9-9D27-557F3D296460@topiatechnology.com>
	 <4AF40932.5070502@zeus.net.au>
	 <004F9331-EED2-4895-AA9A-E413FBEDB716@topiatechnology.com>
	 <4AF4D950.1000102@zeus.net.au>
	 <17F527F6-22B6-4C54-B7E3-E8FC9F645C28@topiatechnology.com>
 <e736790911062111o2bc4e991mfc3afed4f1fca92b@mail.gmail.com>
 <4AF65C5D.3070506@zeus.net.au>
 <BB1EB5CC-A54F-4A03-8215-1CE027A09F69@gmail.com>
 <4AF76B20.7010007@zeus.net.au>
 <EEC576FD-8AD9-45A3-B125-18C2736115D2@topiatechnology.com>
 <4AF79D63.7020900@zeus.net.au> <4AF7CFA0.7070800@zeus.net.au>
 <23377FB1-BAFC-4165-92CB-F03920F84CC3@topiatechnology.com>
In-Reply-To: <23377FB1-BAFC-4165-92CB-F03920F84CC3@topiatechnology.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.

Ok, thanks for the tip, I'll look it up, I'm very open to good reference 
material and learning ; )

Cheers,

Peter.


>
> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>