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! On 11/9/09, Peter Firmstone <[email protected]> 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 <[email protected]> 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 >>>>> [email protected] >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >> > > -- Sent from my mobile device Sam Chance 443-694-5293 (m) 410-694-0240 x108 (o)
