river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike McGrady <mmcgr...@topiatechnology.com>
Subject Re: River & OSGi
Date Thu, 19 Nov 2009 09:16:38 GMT
I'm probably not made for these lists.  Maybe I should just keep my  
opinion to myself.  I consider myself an expert in the field on some  
topics and don't have months to go through what I consider to be the  
standard misconceptions.

Sent from my iPhone

On Nov 18, 2009, at 11:13 PM, Peter Firmstone <jini@zeus.net.au> 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 <sgchance@gmail.com> 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*  
>>> aspects
>>> of "mainstream" SOA. In fact, only recently has SLA been elevated in
>>> the dialog. I'm quite confident the "weighty SOA mindset" you  
>>> posit is
>>> based 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 least
>>> you work on DoD or Federal government systems. That would explain  
>>> your
>>> view 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 <mmcgrady@topiatechnology.com> wrote:
>>>> I have been involved with some fairly mature and well known SOA
>>>> systems for years and I certainly would never consider either  
>>>> Jini or
>>>> OSGi 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 to
>>>> have a registry.  Keeping syst state is not a registry.
>>>> I wish this conversation, since it diverges willy milky from
>>>> established 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 <sgchance@gmail.com> 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 most
>>>>> casual observer that Jini and OSGi adhere to this. The essential
>>>>> difference 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 a
>>>>> highly distributed and decentralized mechanism called  
>>>>> "WoM" (Word of
>>>>> Mouth). :-)
>>>>> Sam
>>>>> On 11/18/09, Michael McGrady <mmcgrady@topiatechnology.com> wrote:
>>>>>> Peter,
>>>>>> Okay.  I see.  You are not using "pattern" in the sense of  
>>>>>> pattern
>>>>>> brought
>>>>>> into computer science by the Gang of Four.  You are using that  
>>>>>> term
>>>>>> more 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
>>>>>> misunderstanding
>>>>>> that you meant "design pattern" as it is used in computer  
>>>>>> science.
>>>>>> On a more substantial note, I don't think the "pattern" you  
>>>>>> discuss
>>>>>> is the
>>>>>> same at all for Jini and OSGi.  The services for OSGi are not  
>>>>>> like
>>>>>> the
>>>>>> services for SOA.  SOA services may or may not be akin to the
>>>>>> services for
>>>>>> Jini.  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  
>>>>>> all
>>>>>> in 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 in
>>>>>> Jini.  As yet, you do not even know, as I understand it, what  
>>>>>> OSGi
>>>>>> services
>>>>>> 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:
>>>>>>>> I am presently the author of a framework called "Karma" (Kolona
>>>>>>>> Automated
>>>>>>>> Resource Management Architecture) that is open source with
>>>>>>>> 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.)
>>>>>>> Here's a Clarification of what I meant by "Service Pattern",
>>>>>>> from
>>>>>>> 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
>>>>>>> and
>>>>>>> bind
>>>>>>> interaction pattern" to solve different problems, I was trying
>>>>>>> to
>>>>>>> lay out
>>>>>>> the understanding to avoid an argument and promote a discussion
>>>>>>> about how
>>>>>>> to implement utilisation of OSGi within River and its  
>>>>>>> applications.
>>>>>>> I still haven't managed to achieve this discussion, hopefully
>>>>>>> the
>>>>>>> best way
>>>>>>> forward will become more apparent during implementation.
>>>>>>> Cheers,
>>>>>>> Peter.
>>>>>>>> Anyway, this does all you want to do and we have a plan to
>>>>>>>> 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
>>>>>>>>> solve
>>>>>>>>> a number
>>>>>>>>> of different problems.  Eg Netbean Plugins, SPI, OSGi,
>>>>>>>>> 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
>>>>>>>>> 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
>>>>>>>>> package X
>>>>>>>>> version 2 loaded as version 1 isn't compatible with the
>>>>>>>>> Objects
>>>>>>>>> (domain data) I'm recieving in serialized form.  I need
>>>>>>>>> share
>>>>>>>>> this
>>>>>>>>> information locally with Package Y that currently has
>>>>>>>>> references
>>>>>>>>> to
>>>>>>>>> objects in Package X version 1.  The Objects in Package
>>>>>>>>> version 1 that
>>>>>>>>> Package Y references need to have their class files upgraded.
>>>>>>>>> Without
>>>>>>>>> OSGi I can do this by persisting state, stopping the
>>>>>>>>> restarting and
>>>>>>>>> loading package X version 2.
>>>>>>>>> I'm not looking at distributed OSGi, but I can see a
>>>>>>>>> case for
>>>>>>>>> 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.
>>>>>>>>> query and
>>>>>>>>> its result are sent over the network using a database
>>>>>>>>> connection.
>>>>>>>>> The processing for that data, if shifted to the machine
>>>>>>>>> has
>>>>>>>>> the
>>>>>>>>> database data, would consume significantly less network
>>>>>>>>> resources.  EG
>>>>>>>>> the data transferred over the network is reduced by a
>>>>>>>>> of
>>>>>>>>> 100 by
>>>>>>>>> processing the data on the database machine after querying.
>>>>>>>>> bundle
>>>>>>>>> that provides a "local JVM application" an "OSGi service"
>>>>>>>>> could
>>>>>>>>> utilise
>>>>>>>>> a "Jini Service" to request the data be processed at
>>>>>>>>> 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
>>>>>>>>> Jini, it
>>>>>>>>> is an implementation detail that is abstracted.
>>>>>>>>> My objectives are all based around codebase services
>>>>>>>>> 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 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
>>>>>>>>> are
>>>>>>>>> making
>>>>>>>>> assumptions and haven't been following the discussions
>>>>>>>>> posted
>>>>>>>>> previously about Versioned Classes, Classloader trees,
>>>>>>>>> Analysis
>>>>>>>>> and Codebase Services, this is frustrating as I was hoping
>>>>>>>>> some
>>>>>>>>> participation.  It seems I can only get attention when
>>>>>>>>> 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,
>>>>>>>>> service is a
>>>>>>>>> common interface, the new upgraded service is discovered
>>>>>>>>> it is
>>>>>>>>> started.  The alternative is to use delegates to update
>>>>>>>>> references
>>>>>>>>> between objects when the Classloader changes as per some
>>>>>>>>> the
>>>>>>>>> other
>>>>>>>>> patches I've uploaded.
>>>>>>>>> Jini also utilises a "Service Pattern", but to solve
>>>>>>>>> different
>>>>>>>>> problem.
>>>>>>>>> I knew this was going to be a difficult topic to present.
>>>>>>>>> What we need are separate lists, where people who want
>>>>>>>>> participate in
>>>>>>>>> constructive development to solve problems can do so
>>>>>>>>> another
>>>>>>>>> list
>>>>>>>>> where people can pontificate about software ideals and
>>>>>>>>> disrespectful arguments with each other without holding
>>>>>>>>> development.
>>>>>>>>> While we're developing we can keep an eye on the argument
>>>>>>>>> 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
>>>>>>>>> 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
>>>>>>>>>>> generates
>>>>>>>>>>> on this
>>>>>>>>>>> list, however without the Service Pattern one
>>>>>>>>>>> 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
>>>>>>>> Mike McGrady
>>>>>>>> Principal Investigator AF081-028 AFRL SBIR
>>>>>>>> Senior Engineer
>>>>>>>> Topia Technology, Inc.
>>>>>>>> 1.253.720.3365
>>>>>>>> mmcgrady@topiatechnology.com
>>>>> -- 
>>>>> 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)

View raw message