Sent from my iPhone On Nov 18, 2009, at 11:13 PM, Peter Firmstone <[email protected]> wrote:
Mike you need to stop sounding like your looking down from the top of the podium and adopt a little humility in your comments. Do try to be a little more agreeable. Otherwise it rubs people the wrong way, which just isn't productive. If your on the run all the time, perhaps you might want to get a netbook instead of the iPhone, then you can open an ide too. Much better for participating.I think that what comes across as an attitude of I know better and your wrong (whether intended or not) on the dev list is what puts people off participating. Nobody wants to argue the details, we want to feel like we're contributing something. We need to encourage people to try, perhaps we can set up an experimental area for would be committers, if need be, so they gain confidence to participate, more knowledgeable people can have a look and make suggestions and assist. Once you start to get to know the codebase it isn't that hard to work with, I've been creating jUnit tests from the integration test code when I make changes to a class, it's pretty easy to do in your ide and the test results are instant. Every now and then you can run the integration and jtreg tests.I downloaded your code from svn on kharma, have had a brief look and plan to look into it further, while doing so I thought to myself, here is someone who can write code, why are we having so much trouble communicating?You know when I talk to the great coders, their attitude is never one of superiority, it's always one of generosity and assistance, they're just happy to help with whatever problem your experiencing. I think that's what distinguishes the great programmers, communication, it is reflected in their code too, and I'm not talking about comments, I mean you read the code, the names of methods and classes, the intent is just obvious. But then look on find bugs, even the best are still human.One word of advise about life, once you realise your own mortality and stare death in the face, before your time, especially when you have children, you wont worry so much about the technicalities, the little things just don't bother you anymore. Make the most of life while it lasts, it really is fleeting. It's not what you have that matters, its who. Everything we argue over today will be forgotten tomorrow.Best Regards, Peter. Mike McGrady wrote:Sent from my iPhone On Nov 18, 2009, at 8:59 PM, Sam Chance <[email protected]> wrote:Mike, The typos and comments in your "reply" suggest you may be tired or a little under "some" influence.I am using an iPhone and haven't taken a single intoxicant for millenia. iPhones make up there own spelling at times.If your "SOA experience" is typical, I can almost guarantee that it consists of proliferating (SOAP-based) web services...so what? Wrapping an interface in XML simply perpetuates the same brittle - point-to-point - architecture.This is not true for real systems.As for SLA, you *must* be joking! SLA are one of the *missing* aspectsof "mainstream" SOA. In fact, only recently has SLA been elevated inthe dialog. I'm quite confident the "weighty SOA mindset" you posit isbased on WS-*.You are clearly confident but mistaken. Try to get SDN data for the FAA SWIM program your way. Knowing about the data has virtually nothing to do with actually getting it.I find it almost humorous that you seem to refute Jini and OSGi as instances of SOA constructs. You may want to circle back and change all the literature about these two SOA frameworks to reflect your view. Good luck with that.SOA is not a framework. SOA is an architecture in which the atomic elements are business level services. This is standard talk.I live and work in the DC area. I sense you do as well; or at leastyou work on DoD or Federal government systems. That would explain yourview about "SOA". But I could be wrong.I dont live in DC. I live in the Seattle area.I'd welcome the chance to meet with you and hammer out these issues. I'm sure I could learn a lot...and *maybe* teach you a thing or two. :-)I am sure I could learn a lot from you.If you want to see SLA implemented by the runtime in a policy and model-driven way, look at the Paremus Service Fabric. (Seems like groundhog day...again).Service level agreements are not implemented in code. This is WHY SOA works.Sam On 11/18/09, Mike McGrady <[email protected]> wrote:I have been involved with some fairly mature and well known SOAsystems for years and I certainly would never consider either Jini orOSGi to be anything remotely like a SOA netwrk. SOA services are explicitly SLA based and defined by business rules outside any IT strictures. That is the key to there success.Only in a general and inconsequential sense can OSGi be considered tohave a registry. Keeping syst state is not a registry. I wish this conversation, since it diverges willy milky fromestablished computer science terminology could stuck to the particulars.Just my thing and I probably have nothing more to say. Sent from my iPhone On Nov 18, 2009, at 5:14 PM, Sam Chance <[email protected]> wrote:Peter,I agree with the notion that Jini and OSGi both implement the publish, find and bind interaction model/pattern/paradigm / whatever additional related words one prefers. I've always described this construct as the "operational model" of SOA. It is exceedingly obvious to even the mostcasual observer that Jini and OSGi adhere to this. The essentialdifference is - in general terms - OSGi implements "publish-find- bind" in a local memory space (I.e. a JVM) and Jini implements this across multiple memory spaces (I.e. distributed). In my view, it is precisely this difference that yields the complimentary nature of the two [SOA]frameworks.Ironically, although contemporary mainstream SOA "deployments", which are arguably Just a Bunch Of Web Services (JBOWS), prescribe 'publish,find and bind', they rely little on a registry (e.g. UDDI) for the 'find' function. Instead, they achieve the 'find' function via ahighly distributed and decentralized mechanism called "WoM" (Word ofMouth). :-) Sam On 11/18/09, Michael McGrady <[email protected]> wrote:Peter,Okay. I see. You are not using "pattern" in the sense of patternbroughtinto computer science by the Gang of Four. You are using that termmore in a plain English sense. I think this is misleading in this venue and would suggest that you use another word to avoid the possible misunderstandingthat you meant "design pattern" as it is used in computer science.On a more substantial note, I don't think the "pattern" you discussis thesame at all for Jini and OSGi. The services for OSGi are not likethe services for SOA. SOA services may or may not be akin to the services forJini. I am very careful about abstracting or generalizing because,although my first and last love in computer science is architecture, the devil is in the detail.For my part, I think it would be worthwhile to determine the level of Ossification you want. For example, there would be no harm at allin seeing whether you can modularize the jar files into bundles. Once that is done, then you can begin seeing how the actual processes in OSGi match those inJini. As yet, you do not even know, as I understand it, what OSGiservices you want. That would need to be determined, since you will be customizing them. I hope this is helpful and thank you for stating what you were thinking. Mike On Nov 17, 2009, at 8:33 PM, Peter Firmstone wrote:Mike McGrady wrote:Here's a Clarification of what I meant by "Service Pattern", fromI am presently the author of a framework called "Karma" (Kolona Automated Resource Management Architecture) that is open source with a managementapp under another open source framework AUM (Automated UniversalMiddleware). 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.)Richards Book, page 12, this should clear up any remaining confusion:"the service-oriented publish, find, and bind interaction pattern:service providers publish their services into a service registry, while service clients search the registry to find available services to use (see Figure 1.3)." So there you go it's the "Publish, find and bind interaction pattern"The point I was attempting to make in the beginning was that Jini,OSGi,ServiceLoader and Netbeans Modules all use the "Publish, find andbindinteraction pattern" to solve different problems, I was trying tolay out the understanding to avoid an argument and promote a discussion about howto implement utilisation of OSGi within River and its applications.I still haven't managed to achieve this discussion, hopefully thebest way forward will become more apparent during implementation. Cheers, Peter.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. Ifyou check there in a few months, you can see what I was hoping totalk 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 forpluggable replacement implementations. That's the "Service Pattern" Aswe have seen it is possible to use the Service Pattern to solvea 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 ormay not be part of a Jini service, it may be a purely local JVMpackage,eg a library dependency or local domain package. For example, Ihave 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 sharethisinformation locally with Package Y that currently has referencesto 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 performssometask that could be done optimally if the processing can be movedto 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 locallyqueriesa remote database using JDBC and performs a considerable amount ofmanipulation 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 hasthe database data, would consume significantly less network resources. EGthe data transferred over the network is reduced by a factor of100 by processing the data on the database machine after querying. A bundlethat provides a "local JVM application" an "OSGi service" couldutilisea "Jini Service" to request the data be processed at the Database machine in a particular manner before receiving the result. Thisfunction 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'tlocked to their http codebase origin), in combination with OSGi or something like it, to ensure compatible classes and packages areloadedamong separate JVM instances. Yes Newton does something similar,however it is AGPLv3 licensed. I envision a distributed environment where nodes can have the majorityof 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, aremakingassumptions and haven't been following the discussions I've postedpreviously about Versioned Classes, Classloader trees, Static Analysis and Codebase Services, this is frustrating as I was hoping for someparticipation. It seems I can only get attention when I mention a controversial subject. What I want is attention to solving theproblems that will make River better.In my note below when I'm referring to the "Service Pattern", Imean 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 isstarted. The alternative is to use delegates to update references between objects when the Classloader changes as per some of theother patches I've uploaded.Jini also utilises a "Service Pattern", but to solve a differentproblem. I knew this was going to be a difficult topic to present. What we need are separate lists, where people who want to participate inconstructive development to solve problems can do so and anotherlist 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 hasimplementation ideas, but are afraid to mention it, please feelfree 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 generateson thislist, however without the Service Pattern one cannot upgrade apackage 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 bundleversion if desired, without having to persist or shut down theentire JVM.If thats all you want you dont need OSGi. Service lifecycles aresupported with a variety of container approaches, from JEE, Spring toRio. You also do not need to shutdown the JVM to load new serviceclasses. 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)-- Sent from my mobile device Sam Chance 443-694-5293 (m) 410-694-0240 x108 (o)
