river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike McGrady <mmcgr...@topiatechnology.com>
Subject Re: OSGi and Jini
Date Tue, 30 Jun 2009 02:31:56 GMT
I think there really is no serious question that OSGi is a huge  
advancement beyond the horrid Java class loading default model.  Greg,  
so far as I can tell you are willing to go down with the ship and are  
against all change.  I doubt if many will have the desire to battle  
your tremendous and admirable energy in support of the status quo.

Sent from my iPhone

On Jun 29, 2009, at 6:51 PM, Gregg Wonderly <gregg@wonderly.org> wrote:

> Sam Chance wrote:
>> Well, if you aren't excited about OSGi as a module system, then what
>> about SCA as an assembly model?  SCA is language- and
>> technology-independent. It's being used to build composite systems
>> comprised of heterogeneous components.
>> I really hadn't thought of using OSGi bundles to represent
>> configuration or properties documents. I've only 'seen' it used to
>> deploy functional software. In fact, OSGi standardizes metadata in  
>> the
>> manifest file of a jar/zip file. The runtime then uses the metadata  
>> to
>> manage the dependencies, imports, exports, etc.
>> Developers I know who've been introduced to it resonate with it.
>> Management likes it as a way to normalize/standardize software  
>> modules
>> (i..e. pre-built, pre-tested, pre-approved components).
>> I don't know. I think its adoption is past or almost past the knee of
>> the curve.
> I do see it "around", but I guess I'm not seeing it "everywhere" in  
> a way that
> makes me feel like "it's not leaving" yet.
>> Sadly, Jini is somewhere in the white noise. I believe OSGi could
>> bring a resurgence of Jini/River. And to be frank, I feel like  
>> Richard
>> Nicholson and his team at Paremus are the only ones who 'get it'.
> They understand a lot about both systems, clearly, and have put  
> together a
> package that seems to be a great step towards integrating both.
>> To be sure, however, the languishing nature of the Jini technology  
>> and
>> the lack of a forward leaning vision with enthusiastic, committed
>> developers forging the vision has lead to the current state of
>> obscurity. We can't even figure out how to pay a sub $300 bill.
>> Accordingly, Jini/River is unlikely on anyone's radar, much less
>> critical path. I highly doubt, Paremus, for example, is critically
>> dependent on it. No one can afford to because of things just  
>> mentioned
>> and the fact that Jini veterans cling defiantly to a myopic view that
>> steadily drives it into the grave.
>> Wow, that's pretty harsh! I must have pent up frustration or anger  
>> issues! :-)
> Here's another "my perspective" "rant".
> Frankly, I believe what is killing small package, easily reused  
> software
> development is the "everything is just a web page" mindset that all  
> the new
> "software developers" are toting around on signs.  The driving  
> force, I believe,
> is the "your language doesn't do what my language does" mentality  
> that is driven
> by the ignorant who think that if you can't type it in text without  
> a library
> loaded to support it, then it's not a "language feature".   People  
> want their
> lives to be simple.  They want to carry around as little extra  
> "stuff" in their
> development "kit" as they can.  So if the "language" doesn't do it,  
> it doesn't seem to be interesting.  JavaEE is a platform that is  
> "standardized".  Jini is a platform that is "standardized", just not  
> by Sun, IBM, Oracle or any of the other big JavaEE behemoths.
> There was the whole "java is not open source" movement that drove  
> the "I'm an open source developer" development toward "web pages  
> should be used for every UI", because then they weren't making their  
> friends developing new languages for simple silly web page tasks  
> feel bad.   Sun developed the silly business
> of thinking (well there was actually just one person at the top of  
> Sun that
> created this problem and Jonathan fired him for not wanting to open  
> source Java) that web pages solved all problems, but that was too  
> little too late.
> Over the years, Sun focused their support of Java JSRs on nothing  
> but huge, ugly, completely insane software systems in JavaEE that  
> require nothing short of mammoth machines and software packaging  
> systems to get useful things out of the JavaEE applications.  I  
> shutter at the thought of how many useless man years of intelligent  
> design time got wasted...
> I was on the Sun developer advisory council for years, as were about  
> 6 other Jini people as I recall (who regularly attended until it  
> disappeared last year without even a goodbye or thank you).  We  
> hounded those folks over and over at the complexity and ugly nature  
> of JavaEE.  Mr. Green tried to make sure we knew that Sun was  
> focused on JavaEE.
> In the end, so many people find it more acceptable to use XML based  
> data
> encoding and transport, rewritting/repackaging it for every language  
> and every platform that needs a tweek.  They then start buying  
> packages that do the work for them when it seems that it really is  
> quite expensive and costly to get "right" after so many times doing  
> it.  They eventually discover JavaEE tools and IDEs that "do" a lot  
> of the work for you, and then figure out that well, they don't quite  
> do it all, quite right, and then they start patching and moving away  
> from the tools into privately maintained, ugly codebases, still  
> swearing that it works great for them.
> Jini, as a simple system, has a couple of very complex issues, which  
> people
> don't want to have worry about during development.  One is security,  
> the other is mobile code management.  Since the configuration of  
> these things are don't strictly done programmatically with language  
> features, out of the box, people get frustrated and overwhelmed with  
> details that they have to manage.  It's all over the list here and  
> on the internet too.  The abstractions that are in place to create  
> the platform are not fleshed out in concrete, usable classes, for  
> all the more typical scenarios.  Instead, we have X.500 and Kerberos  
> authentication which just doesn't sit around on everyones network,  
> ready to go and fully managed and configured to work at the moment  
> it's needed.
> When Java1.4 came out, JAAS was there, but with completely useless  
> login modules.  The provided OS login modules do nothing more than  
> go and get credentials from the OS for who the process is running  
> as, and provide those in the returned Subject.  There is no  
> authentication provided.  The OS login modules should have provided  
> for authentication so that you could say, this user is allowed  
> access to this system and here's the authorized principals that  
> apply.  But no, that wasn't possible because Sun engineers thought  
> that people writing applets might exploit it by running background  
> loops trying to authenticate by exhaustive search while web pages  
> were open with invisible applets running, and that would then allow  
> people to exploit that knowledge to get into authenticated  
> networks.  There was a security model in Java which could keep this  
> from happening.  The login modules could have used the  
> SecurityManager to control things.
> Look around at some of the things started early in our community,  
> where these issues are "buried" into deployment systems  
> (com.sun.jini.start) and containers (RIO, Seven, etc) , and you can  
> see incompatible differences in "where" and "how" these things are  
> managed.
> The end result, is that because the community won't decide on a  
> "standard"
> container, other than the built in com.sun.jini.start package, we  
> have no ability to say that there is a level playing ground or equal  
> opportunity for deployment needs.  I don't want to demean anyones  
> work at trying to solve the problems they have with these projects.   
> I'm just saying that because they've evolved in lots of different  
> directions with regard to configuration, that we have lots of ways  
> to configure things with varying capabilities and it means that no  
> one can move anything anywhere else trivially, and thus things are  
> going to remain fragmented, forever, from my perspective.  Just to  
> make it clear, I feel that the disparate state of configuration and  
> deployment in Jini is like saying I have a check balancing service  
> to your friend who has linux, and then saying, ohh I wrote it for  
> the MAC, you'll have to port it.
> My org.wonderly.jini2.browse.JiniDesktop class in the
> http://startnow.dev.java.net project provides a simple ServiceUI  
> client desktop
> that utilizes several other things that I found valuable in managing  
> the load on
> the network and the startup time of a client UI when there are 100s of
> services to discover and downloading everthing in the codebase is  
> slow.
> Mark Brouwer uses a different strategy of packaging his codebases.
> The PREFERRED.LIST is in a jar with minimal size, and that jar  
> "includes"
> references to the other jars needed, or he has multiple jars on the  
> codebase list.
> Different mechanisms and details like this mean that the way you  
> package your service has implications on how it works in other  
> peoples environments!  My solution is at the network layer so that  
> it works for all codebase.  Mark's works at the classloader layer so  
> that it works with Jars composed in particular ways.  We each have  
> found different, working ways, to solve problems, but compatibility  
> is at different layers which creates incompatibilities at other  
> layers.
> We don't have standards in Jini for packaging and deployment of  
> services and
> codebase jars.  We don't have things that allow people to move  
> between containers that have different operating base environments.
> We really, really, did I say really yet, need to make some decisions  
> about packaging and container interfaces and move on.  We need to  
> have a WAR like file that is the "service".  We need to have a more  
> simplified "base security" setup which uses "user logon"  
> credentials, not explicitly specified certificates and other hard to  
> maintain and manage bits of information.  People can put in  
> compatibility layers for their existing systems to meet with those  
> standards if they so choose.
> As a community, we are not making many decisions because Sun has  
> been the
> caretaker of Jini.  The Sun Jini folks have done an amazing job of  
> creating some
> very useful software that is, from my perspective, a great platform  
> for
> distributed systems.  But, clearly, most if not all of them have  
> other responsibilities, if not interests now.
> What we need to do now is get moving on making the system easy to  
> use.  There are packages of things in the communities efforts that  
> we can make into standard parts of the River distribution.  From my  
> viewpoint, JavaEE is starting into a spiral path out of "preference"  
> because more simple ways to do web apps are falling into view as the  
> frustrated people decide enough is enough.  If we make some of the  
> hardest parts of River configuration and deployment much more  
> manageable, we have the opportunity to finally get the attention of  
> the people who are searching for the next solution, since what they  
> last tried is not working.
> What happens next is what the community decides.  I'd like to play a  
> part, but
> to date, everything that I've found to be interesting and wanted to do
> differently in Jini has not been that interesting to the rest of the  
> community.
> I'm setting back, waiting for something to start rolling that I am  
> interested in, and I'll jump in to assist as best I can, as I am  
> able to and where needed.
> Gregg Wonderly

View raw message