river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: River & OSGi
Date Wed, 11 Nov 2009 01:51:28 GMT
Mike,

Something I've mentioned previously on this list, you might have missed 
it, is using Static Analysis (at the codebase service) to analyse 
uploaded bytecode and produce Mirror objects that record signatures of a 
class's api.

These class objects are contained within a PackageMirror (collection of 
class mirrors) that represents a package, these can then be used to 
disclose Packages Public, Protected and serialVersionUID API.

The versioning metadata from a bundle can be recorded in the PackageMirror.

With this information, it is possible to identify package compatibility 
prior to classloading at runtime.

Further, it is important to note that another type of Mirror, a 
PackageDependencyMirror represents a subset of an import packages API.

This is useful to identify if a Package can satisfy an import dependency.

Byte code is capable of evolving with less contraints than source code, 
for instance an interface can add new methods, this won't break classes 
that only utilise a subset of an Interface.

Best Regards,

Peter.

Peter Firmstone wrote:
> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
>



Mime
View raw message