river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Chance <sgcha...@gmail.com>
Subject Re: River & OSGi
Date Sat, 07 Nov 2009 05:11:20 GMT

I'm a relative simpleton software engineer compared to many of you on
this list. Nevertheless, I remain convinced the "group think"
continues to stagnate River. That situation seems unlikely to change
without intervention. I find myself rooting for those who get
chastised for offering ways to say "yes". Don't get me wrong! I love
you all - as brothers! :-) However, revolution seems in order.

As for the subject of this email, I must be missing something.
Lengthy, verbose and detailed narratives that most people probably
don't really digest pervade threads - at least the threads about River
& OSGi.

If I said something like the following, would it be concise and
accurate? Let's try.

OSGi is a service architecture for services in the same address space. [1]

Jini/River is a service architecture for distributed systems built out
of services separated by a network. [1]

How in the world can it be so hard to grasp - even embrace - that the
intersection of these two constructs is synergistic?

I have an idea! Let the "Negative Nancys" hide and watch as Paremus -
who get it - lead the industry and literally change the paradigm of
application service architecture and provisioning.

[1] Before you leap, be advised that these descriptions were provided
by Jim Waldo in the "Artima" link someone provided earlier.

In fact, I pulled the thread on the referenced articles. And if I
understood Peter Kriens' posts correctly, Jini dropped out of
prominence from the OSGi specs basically due to lack of passion - dare
I say leadership? - from the Jini community. While I like to consider
myself part of this community, there is no way I could write those
lengthy, verbose and detailed emails discussing things like

But those who can write those novels should be contributing to the
specifications and not acting like consultants: always finding ways to
say "no".



On 11/6/09, Mike McGrady <mmcgrady@topiatechnology.com> wrote:
> I guess this means you would prefer not to address the issues and move
> to personal attacks.  Weak but not atypical.  In fact many who follow
> this will know me and will find this amusing.
> Sent from my iPhone
> On Nov 6, 2009, at 6:20 PM, Peter Firmstone <jini@zeus.net.au> wrote:
>> Michael,
>> I just went back over the list to see what contribution you've made
>> to River by reading some of your posts.  Your the bloke that gave
>> cause for Dan Creswell to resign from River.
>> This is a developer list, I'm trying to contribute something and get
>> this project moving again as have others like, Jukka, Jonathan, Tom
>> and Dennis among others.
>> This software won't affect you, the Felix crowd are quite competent
>> and won't consider accepting any patches that compromise their
>> distribution.  It wont affect existing users of River that don't
>> want to utilise OSGi either.  My suggestion to you is; if you don't
>> like it, don't use it, but don't try to roadblock the hard work of
>> others with rot.
>> Now if you don't mind I'd like to get something done.  If someone
>> knows this man, please take that iPhone off him, he's a nuisance.
>> Peter Firmstone.
>> Mike McGrady wrote:
>>> I am getting ready to jump on an airplane, so will but initiate a
>>> multipart reply.
>>> Sent from my iPhone
>>> On Nov 6, 2009, at 3:32 AM, Peter Firmstone <jini@zeus.net.au> wrote:
>>>> Mike McGrady wrote:
>>>>> First, I would like to know what the "shared" "Service Pattern" is.
>>>> Sharing - Objects moved between jvm's in a distributed environment.
>>> "Shared" in your previous post meant a shared pattern.
>> Your reading too much into it, "Service Pattern" as in Pattern
>> literature, I didn't refer to "Shared Pattern".
>> 2. Jini utilises the Service Pattern for sharing distributed
>>    pluggable java software.
>>>> Distributed Service Pattern -  Dynamic Runtime Discovery - Lookup
>>>> of Objects that share a common Interface, receiving a proxy that
>>>> enables the transmission of as Parameters and Returned Methods
>>>> using Jeri / RMI / Serialization etc.
>>> The terminology just changed,  "Service Pattern" now has
>>> distributed added.  Please indicate what this "pattern" is where it
>>> occurs in Felix.  Looks like a loose and inappropriate use of
>>> "pattern" if you mean design pattern, like inapropriately calling
>>> MVC a design pattern.
>>>>> Second, I would like to note that in my opinion changing Felix,
>>>>> which is architecturally on firm ground to accommodate Jini is a
>>>>> huge mistake.
>>>> Why? Felix is designed to be embedded into systems, are you
>>>> suggesting Felix isn't suitable, would you prefer I use another
>>>> Modular infrastructure to manage package visibility?  If so which
>>>> one? The current alternative JSR-294 depends on Java 7 and hasn't
>>>> been released yet.  I fail to see why utilising mature code as
>>>> opposed to expending much time reimplementing when something
>>>> already exists would be a huge mistake?   I have considered
>>>> extending Classworlds, however this would require jvm restarts
>>>> when packages needed to be replaced.  The Java Package Version
>>>> Specification is optional and isn't widely implemented.
>>> OSGi is designed with services that are not inherently remote and
>>> are dynamic in that they appear and disappear in the course of a
>>> runtime.  This is very different from "managing package
>>> visibility".  You need to distinguish.modularity, lifecycle
>>> management and services and to more appreciate their varied levels
>>> of abstraction.
>>>>> I am not convinced that this analysis understands the depth of
>>>>> OSGi.  Certainly the module, lifecycle, service levels of
>>>>> abstraction in OSGi seem to me to not coincide with the notion of
>>>>> service in Jini.  This difference is greater when distribution is
>>>>> considered.  I would suggest that no decisions be made without a
>>>>> more developed and better expressed alternative than this.  Felix
>>>>> does not need to compromise it's architectural integrity to
>>>>> accommodate less mature concepts in Jini.
>>>> OSGi segregates bundles of software (jar files with metadata) into
>>>> separate classloaders, controls visibility of packages between
>>>> bundles based on compatibility information (metadata) in jar files
>>>> and enables the bundles to be stopped, replaced and restarted.
>>> This is a serious but not unusual over simplification of OSGi.
>>> This is the lowest level of OSGi.
>>>> To utilise OSGi, a Jini program must be distributed in a bundle
>>>> containing dependency information on package version imports.
>>> This is ambiguous in important respects.
>>>> To be made available outside its Classloader (one for each bundle)
>>>> the visibility of Packages must be controlled, it's public API
>>>> Packages must be registered ie the bundle started.  Since Java
>>>> cannot reload class files when a Bundle is upgraded, it must
>>>> reside in another Classloader, so Classloaders are Bundle and
>>>> version specific.  The service pattern enables the bundle to be
>>>> rediscovered by identity locally within the JVM after an upgrade.
>>> I don't think you understand what an OSGi service is.  An OSGi
>>> service is a contract.
>>>> A Jini service must be exported and registered to be available for
>>>> lookup, if it is being managed by an OSGi framework it must first
>>>> have it's bundle started and registered.
>>> What you mean by "managed" needs to be specified.  JIni
>>> registration and OSGi registration are not the same of course.
>>>> Jini currently loads class files into classloaders based on the
>>>> local availability of classes or http coadebase URL origin,
>>>> imposing restrictions on sharing of Objects, this is suboptimal,
>>>> OSGi can assist in resolving this issue by providing a framework
>>>> that manages package visibility.  However I don't believe that
>>>> OSGi alone is enough in a distributed environment
>>> What do you mean here?  OSGi is what it is.
>>>> Please provide me with facts so we can have a meaningful discussion,
>>> I have no idea how this relates to this discussion.  What facts
>>> about what?
>>>> from your reaction I detect your gut feel is telling you this
>>>> isn't the right approach, my gut feel is that it is. I've based my
>>>> reasoning on facts, I need some factual information to be
>>>> convinced otherwise.
>>> What facts?  You have not explained what you mean and you speak
>>> very loosely where precision is required, but yet make very
>>> sweeping and important recommendations.  My mind, not my gut, does
>>> not like this since we do important business with Felix and do not
>>> want it fiddled with without clarity, understanding and open
>>> discussion at depth.
>>> I don't think, again, you understand the nature and proper
>>> architectural positioning of OSGi services.  Rather, you seem to
>>> focus on the sorts of things or understandings we could get from
>>> sources like Wikipedia, I.e., superficial and misguided. Maybe your
>>> understanding is deep and accurate but we have no way of knowing
>>> and what you say indicates the opposite.
>>> Ideas - nor facts - are at issue.
>>> I have asked you to to tell me about your view of services on this
>>> context, which is critical, and have gotten a gloss of liwer level
>>> functionallity.
>>> Let me remake my request that you explain what you initially meant
>>> about Jini and OSGi services because it sounds all wrong to me.
>>> Thanks.
>>>> No offense intended.
>>> None taken - ditto.
>>>> Regards,
>>>> Peter.
>>>>> Mike
>>>>> Sent from my iPhone
>>>>> On Nov 5, 2009, at 7:03 PM, Peter Firmstone <jini@zeus.net.au>
>>>>> wrote:
>>>>>> Well,  I've had a good think about it, this is presently the way
>>>>>> I'd like to utilise OSGi:
>>>>>> First let me make one thing clear:
>>>>>> 1. Both OSGi and Jini utilise the Service Pattern.
>>>>>> 2. Jini utilises the Service Pattern for sharing distributed
>>>>>>   pluggable java software.
>>>>>> 3. OSGi utilises the Service Pattern for making java software
>>>>>>   modular, versioned and pluggable without JVM restarts.
>>>>>> When I refer to Jini I'm referring to the Jini Platform, when I
>>>>>> refer to River, I'm referring to the Apache River implementation
>>>>>> of Jini.
>>>>>> Java Also uses the Service Pattern with SPI for 3rd Party
>>>>>> Vendors to Provide Pluggable implementations of JVM components
>>>>>> or extensions, eg JDBC, Encryption software etc. Gregg inspired
>>>>>> me by pointing out possible PreferredClassLoader changes
>>>>>> utilising the RMIClassLoaderSPI.
>>>>>> By embedding an OSGi implementation such as Felix into River in
>>>>>> a pluggable manner (usage is optional) River can support OSGi
>>>>>> applications and provide Jini Services to those local
>>>>>> applications.
>>>>>> Doing so will require modification to the Felix Codebase, which
>>>>>> is probably best managed as a Patch for a Particular Version of
>>>>>> Felix.
>>>>>> Additionally, I figure further modifying to Felix to support
>>>>>> interactions with Remote Codebase Services utilising Static
>>>>>> Analysis to identify Package API.  The Static Analysis will be
>>>>>> used for three reasons, one to identify compatibility between
>>>>>> software in addition to the Bundle & PackageVersion metadata,
>>>>>> two to identify later versions of import packages that are
>>>>>> compatible using a Subset of their API used by a Bundle.  Lastly
>>>>>> but perhaps most significantly to allow software to evolve
>>>>>> without fear of runtime exceptions caused by binary
>>>>>> incompatibilities.  Modification to Felix would be done in a
>>>>>> manner that didn't break compatibility with OSGi.
>>>>>> Let me make one thing clear, OSGi does not compete with River,
>>>>>> nor is OSGi's remote service standard intended to compete with
>>>>>> distributed frameworks, nor are they intending to implement a
>>>>>> distributed framework, the API is there to be utilised by
>>>>>> distributed frameworks, OSGi made a statement to this effect.
>>>>>> Benefits:
>>>>>> 1. Existing OSGi Applications can be hosted by River.
>>>>>> 2. Existing OSGi Applications can utilise Jini Services without
>>>>>>   modification to OSGi applications, in a pluggable fashion.
>>>>>> 3. The River Platform (with OSGi felix embedded) is the minimum
>>>>>>   installation requirement (apart from Java), all sofware can be
>>>>>>   downloaded on demand from codebase services, guaranteed
>>>>>>   compatible, including additional security benefits from having
>>>>>>   bytecode API identified by Static Analysis from a code base
>>>>>> with a
>>>>>>   trust relationship.  The codebase would never execute uploaded
>>>>>>   bytecode, just analyse and distribute it.  Hence codebases are
>>>>>>   mediators/proxy's for disconnected or untrusted service
>>>>>> providers
>>>>>>   or clients.  All code and API apart from a minimal core platform
>>>>>>   code could evolve dynamically over time.
>>>>>> 4. OSGi enables local bundles to be restarted, this would allow
>>>>>> River
>>>>>>   to locally update older bundle's when a need no longer exists to
>>>>>>   utilise an older version bundle or if another bundle requires a
>>>>>>   later version, complementing software evolution.
>>>>>> I know that this is perhaps a somewhat bold ambition, however I
>>>>>> believe it would increase the interest in the River project,
>>>>>> especially from the OSGi community.
>>>>>> There are plenty of details to work out, such as how to
>>>>>> implement persistence services for bundles and their import
>>>>>> packages over restarts, how to coordinate starting and stopping
>>>>>> of bundles that contain Jini remote services.  How to proxy Jini
>>>>>> Lookup services from within the OSGi framework to make these
>>>>>> services available to existing OSGi applications.  OSGi would
>>>>>> not be able to work with Jini Services that didn't themselves
>>>>>> utilise OSGi, Felix wouldn't know which bundles were required
>>>>>> for compatibility reasons.  That's where codebase services would
>>>>>> come to the rescue, by checking for known OSGi bundles that are
>>>>>> in fact compatible and substituting them.  If a compatible
>>>>>> bundle couldn't be found the codebase service would have to
>>>>>> create a bundle using available code.
>>>>>> One remaining concern I have is the approach of integrating
>>>>>> Felix into River.  I'd like to make the required changes within
>>>>>> Felix Pluggable components if possible, so that the existing
>>>>>> felix implementation would only require some minor changes that
>>>>>> we might be able to get them to accept.  That would allow us to
>>>>>> have a totally independent implementation which could continue
>>>>>> to work with future versions of Felix, and possibly other OSGi
>>>>>> implementations, in case word spreads about River in the OSGi
>>>>>> community.  I can't see that I could use OSGi for replacing OSGi
>>>>>> system components, but it might be possible using SPI,
>>>>>> ironically again another Service Pattern.
>>>>>> I acknowledge that the alternative method of making River a
>>>>>> bundle within OSGi is possible without changes to OSGi, however
>>>>>> it doesn't make it possible then for OSGi to utilise the
>>>>>> codebase services I'm interested in.  If someone can show me
>>>>>> that it is possible to do so I'll consider the option seriously.
>>>>>> Cheers,
>>>>>> Peter.

Sent from my mobile device

Sam Chance
443-694-5293 (m)
410-694-0240 x108 (o)

View raw message