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 22:30:15 GMT
Thanks Sam,

Sam Chance wrote:
> I'd like to echo Mike's recommendation to check out Manning's Early
> Access Program for the OSGi In Action book. There's another one
> accessible there called OSGi Application Frameworks. I just happen to
> be reading the "green papers" and "free" chapters.
> Glad to see more reconciling posts! Sorry if I contributed to any angst.
> But...I believe River developers literally hold the secret to enabling
> and realizing inter-sector convergence on a scale net yet seen. We
> will see seamless interoperation of residential, auto, mobile,
> enterprise and other logical domains. New opportunities - and
> vulnerabilities - will drive new industries and capabilities. I'm
> looking forward to it!

It's certainly a possibility and good opportunity.

> On 11/9/09, Peter Firmstone <jini@zeus.net.au> 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
>>>>>> "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
>>>>>> standard with IEEE, where I am a member of the standards
>>>>>> committee.  If you check there in a few months, you can see what
>>>>>> 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
>>>>>>> local JVM, I need to have package X version 2 loaded as version
>>>>>>> isn't compatible with the new Objects (domain data) I'm recieving
>>>>>>> in serialized form.  I need to share this information locally
>>>>>>> Package Y that currently has references to objects in Package
>>>>>>> version 1.  The Objects in Package X version 1 that Package Y
>>>>>>> references need to have their class files upgraded.  Without
>>>>>>> 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
>>>>>>> utilising a Jini Service, when a local OSGi bundle that performs
>>>>>>> some task that could be done optimally if the processing can
>>>>>>> moved to where the data resides, this is just an example there
>>>>>>> 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
>>>>>>> the database data, would consume significantly less network
>>>>>>> resources.  EG the data transferred over the network is reduced
>>>>>>> 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,
>>>>>>> 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
>>>>>>> OSGi or something like it, to ensure compatible classes and
>>>>>>> packages are loaded among separate JVM instances.  Yes Newton
>>>>>>> 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
>>>>>>> posted previously about Versioned Classes, Classloader trees,
>>>>>>> Static Analysis and Codebase Services, this is frustrating as
>>>>>>> was hoping for some participation.  It seems I can only get
>>>>>>> attention when I mention a controversial subject.  What I want
>>>>>>> attention to solving the problems that will make River better.
>>>>>>> In my note below when I'm referring to the "Service Pattern",
>>>>>>> mean the service pattern that OSGi implements, enables bundles
>>>>>>> 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
>>>>>>> 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
>>>>>>> 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
>>>>>>> on the argument list without getting embroiled.
>>>>>>> Anyway I've said enough, I'm going back to doing the things I
>>>>>>> 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
>>>>>>> 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
>>>>>>>>> this list, however without the Service Pattern one cannot
>>>>>>>>> upgrade a package without first persisting everything
>>>>>>>>> shutting down the entire JVM, then restarting.  At least
>>>>>>>>> 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
>>>>>>>> supported with a variety of container approaches, from JEE,
>>>>>>>> Spring to Rio. You also do not need to shutdown the JVM to
>>>>>>>> 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
>>>>>>>> former, not the latter.
>>>>>> Mike McGrady
>>>>>> Principal Investigator AF081-028 AFRL SBIR
>>>>>> Senior Engineer
>>>>>> Topia Technology, Inc.
>>>>>> 1.253.720.3365
>>>>>> mmcgrady@topiatechnology.com

View raw message