OSGi on the Server Side and the matter of the WOO
RogerV
http://dev2dev.bea.com/pub/a/2007/12/osgi-introduction.html
No-Fluff-Just-Stuff founder, Jay Zimmerman, likes to refer to what he
calls the WOO factor - window of opportunity - when talking about the
dynamics of our software development industry.
For me, Adobe Flex is a case in point of the WOO factor that he talks
about. It's a technology that was ready and in position at the right
time to become a dominant RIA solution. In contrast Java was caught
with nothing to show in the RIA space. It missed the WOO.
Right now, I have a server-side project that will be built on OSGi.
It's here today, has a proven track record (Eclipse), and solves the
problems of project size scalability that we need to grapple with over
product life time.
Once again, just as EJB3 missed the WOO and has been eclipsed by
Spring Framework, whatever standard that Sun will end up backing via a
JSR to address this space will miss the WOO.
Why am I writing this as though I'm lamenting a sad development? I
guess that's a good question. There's really nothing to be down about.
Great software solutions on the Java platform exist outside of JSR
land. Indeed, maybe the very best software used in Java circles has
been the non JSR stuff.
In coming to the Java community I've never had a problem sidestepping
the nonsense being peddled and instead adopted what made sense. With
JEE I completely ignored session and entity beans and just used JMS
MDBs and Hibernate. So in 2003/2004 I built a distributed system
system on principals that the SOA dudes are all crowing about now.
More recently I've completely ignored MVC web frameworks on the server-
side and instead went with RIA + SOA where MVC is completely done on
the client-side. (Doing MVC on the server-side in defiance of the
Fallacies of Distributed Computing was wrong headed from the get go.)
http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing
So here we stand today poised to fish or cut bait on this matter of
large scale SOA-based development on the server-side - and we badly
need a modularity solution for Java.
This is the moment of the WOO and here stands OSGi.
James Ward
-James
RogerV
Michael Coté, an industry analyst with RedMonk, reports that the
Eclipse foundation is targeting moving OSGi into the server
application environment:
OSGi in Java - Eclipse Equinox Screencast and Video Series
http://www.redmonk.com/cote/2008/01/17/osgi-in-java-eclipse-equinox-screencast-and-video-series/
"What's new, and very much in the cards for 2008 is Eclipse moving
into the server side, into an even more tooling and framework position
for the Java world."
"At the core of their strategy is OSGi"
Then there is the Spring Framework itself that is making an OSGi move
with a v1.0 release:
Spring Dynamic Modules for OSGi: simplified development of OSGi
applications
http://www.infoq.com/news/2008/01/spring-dm
So there we have two big movers and shakers of the Java platform world
(Eclipse and Spring) pushing OSGi for server-side enterprise
development.
Looks like once again the JSR crowd are going to be too late to the
party.
Oh, here is an interesting intro article describing OSGi as "SOA" for
the internal structure of an app:
Of Programming and Architecture: SOA in a JVM
http://blogs.nagarro.net/kayser/soa-in-a-jvm/
Neil Bartlett
* IBM WebSphere Application Server is already based on an OSGi runtime
(specifically Eclipse Equinox).
* BEA committed a while back to developing ALL of their new products
on OSGi. In their marketing literature they refer to the BEA "micro
Services Architecture" or mSA, which is essentially OSGi plus some
utilities on top. An internal source at BEA told me that eventually
their flagship product, WebLogic Application Server, would probably be
converted to OSGi.
* BEA's strategy is unlikely to change after the acquisition by
Oracle, since Oracle are also strong supporters of OSGi. They are on
the OSGi Enterprise Expert Group, and their EclipseLink product offers
persistence services for OSGi.
* JBoss uses OSGi in their ESB platform. Another open source ESB,
Mule, is aiming to convert to OSGi in a future version.
* As you noted, SpringSource/Interface21 are supporters. In his blog,
Rod Johnson stated his intention to push the JEE 6 expert group
towards the use of OSGi for delivering modularity in JEE.
* Last year, even Sun joined the OSGi Alliance. In fact they RE-
joined, since they were founding members.
However, I wouldn't say that these developments are negative for the
"JSR crowd". Remember that OSGi R4.1 has been standardised under the
JCP via JSR 291 (for Java SE) and JSR 232 (for Java ME). OSGi itself
began life as JSR 008.
Regards
Neil
On Jan 26, 1:14 am, RogerV <rog...@qwest.net> wrote:
> Intimations that the WOO for OSGi may indeed be 2008:
>
> Michael Coté, an industry analyst with RedMonk, reports that the
> Eclipse foundation is targeting moving OSGi into the server
> application environment:
>
> "What's new, and very much in the cards for 2008 is Eclipse moving
> into the server side, into an even more tooling and framework position
> for the Java world."
>
> "At the core of their strategy is OSGi"
>
> Then there is the Spring Framework itself that is making an OSGi move
> with a v1.0 release:
>
> Spring Dynamic Modules for OSGi: simplified development of OSGi
RogerV
> However, I wouldn't say that these developments are negative for the
> "JSR crowd". Remember that OSGi R4.1 has been standardised under the
> JCP via JSR 291 (for Java SE) and JSR 232 (for Java ME). OSGi itself
> began life as JSR 008.
associated JSR(s). These days, though, doesn't look like OSGi fate
necessarily rest on the glacial JSR process.
It's now coming down to a matter of what will become the defacto
modularity solution for the Java platform. OSGi is well on its way to
achieving that status.
This happens over and over.
A significant number of Java developers used log4j and yet Sun went
and invented a different logging solution for the JSE.
J2EE/EJB2.x started collapsing under its own weight. Developers
started gravitating toward Spring Framework. JEE5/EJB3 is failing to
woo back the defectors. In contrast, Spring Framework adoption
continues to accelerate. It would now be very interesting (if one were
a Java app server provider) to build an app server entirely around
Spring. It would be one by nature that would be entirely modular (as
opposed to "kitchen sink" monolithic the way JEE servers are). It
would be modular and have an Isolates capability. It would completely
supplant the Apache-web-server/multi-instance-Tomcat combos and be
pure Java. Yet Sun would never do something innovative like that with
their Grizzly underpinned Glassfish code base.
Sun chose to push Ruby as the pre-eminent scripting language for the
JVM, while the Java developer community (who were not necessarily Ruby
language aficionados - as Sun seemed to posit that they all were)
tended to better like Groovy as it was crafted especially to be a
companion scripting language to Java on the JVM. (Groovy syntax is
very friendly to Java programmers and just uses the existing class
libraries - with a wee bit of enhancement for closure-style
programming.)
I've attended a number of NFJS conferences by now and believe I've
detected a current of underlying against amongst that body of Java
attendees and presenters in regard to attitudes held toward Sun. In
reflection over the years, I see the reason why. Sun repeatedly seems
to choose the path that defies the Java community at large. If Sun
isn't holding onto the rudder, then they don't want anything to do
with it.
My money says Sun will attempt to also ignore OSGi and push an
alternative modularity solution through the JSR process - despite what
the greater Java developer community decides to embrace. They can't
help themselves - it's in their corporate DNA to behave this way.
Alexey Zinger
> I've attended a number of NFJS conferences by now and believe I've
> detected a current of underlying against amongst that body of Java
> attendees and presenters in regard to attitudes held toward Sun. In
> reflection over the years, I see the reason why. Sun repeatedly seems
> to choose the path that defies the Java community at large. If Sun
> isn't holding onto the rudder, then they don't want anything to do
> with it.
I'm not sure I see it quite that way. Look at the example of log4j. Is it not
true that the java.util.logging framework is implementation agnostic and JSE in
fact ships with a log4j implementation of it. Similarly, I could see the same
thing happening with a modularity framework -- Sun can have their perceived
rudder by having a top-level framework that ships with JEE, but underneath uses
OSGi by default. And given the nature of the beast, it probably shouldn't be
all that bad to write adapters for things to work in a variety of modularity
frameworks. I'm not seeing a big problem here.
Alexey
2001 Honda CBR600F4i (CCS)
1992 Kawasaki EX500
http://azinger.blogspot.com
http://bsheet.sourceforge.net
http://wcollage.sourceforge.net
____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
RogerV
thread, you must know I'm a secret admirer of Sun Microsystems. I just
don't always see eye to eye with how they could be innovating (and
embracing innovation) themselves on their own platform that they
invented.
It frustrates me to no end to see companies approach the world with
self-imposed blinders. Self-imposed handicaps.
On Jan 26, 1:07 pm, Alexey Zinger <inline_f...@yahoo.com> wrote:
> --- RogerV <rog...@qwest.net> wrote:
> > I've attended a number of NFJS conferences by now and believe I've
> > detected a current of underlying against amongst that body of Java
> > attendees and presenters in regard to attitudes held toward Sun. In
> > reflection over the years, I see the reason why. Sun repeatedly seems
> > to choose the path that defies the Java community at large. If Sun
> > isn't holding onto the rudder, then they don't want anything to do
> > with it.
>
> I'm not sure I see it quite that way. Look at the example of log4j. Is it not
> true that the java.util.logging framework is implementation agnostic and JSE in
> fact ships with a log4j implementation of it. Similarly, I could see the same
> thing happening with a modularity framework -- Sun can have their perceived
> rudder by having a top-level framework that ships with JEE, but underneath uses
> OSGi by default. And given the nature of the beast, it probably shouldn't be
> all that bad to write adapters for things to work in a variety of modularity
> frameworks. I'm not seeing a big problem here.
>
> Alexey
> 2001 Honda CBR600F4i (CCS)
Joshua Marinacci
anything about it) but I do know that we focused on Ruby as our next
JVM language because that's where the numbers are. Ruby on Rails is
growing quickly so we wanted JRuby to be the best Ruby implementation
out there.
- Josh, on the go
RogerV
On Jan 27, 3:54 am, Joshua Marinacci <jos...@gmail.com> wrote:
> I can't comment on the osgi stuff (since I honestly don't know
> anything about it) but I do know that we focused on Ruby as our next
> JVM language because that's where the numbers are. Ruby on Rails is
> growing quickly so we wanted JRuby to be the best Ruby implementation
> out there.
>
> - Josh, on the go
attention to the hype band-wagon of the Ruby crowd. Yet strangely I
don't think the Java community at large has been as infected with
Rubism as Sun strategic planners were. Instead, most in the Java
community didn't really feel inclined to abandon Java and move to
Ruby, but were content to learn (or pay attention to) good ideas from
Ruby and Rails.
So when RoR mania first hit the scene, the Ruby legion was in full
force at NFJS conferences (Dave Thomas, Bruce Tate, et al). RoR
dominated a lot of hallway conversation that year.
Yet next year, those folks weren't much around. Instead Groovy and
Grails was the dominate subject matter in terms of alternative
languages for the JVM. Even sessions not directly on Groovy or Grails
had a tie in to Groovy. One on using Java 6 to integrate a scripting
language into a Java application featured doing that with Groovy.
Another on rules engines used Groovy as the rules engine scripting
language. Yet another on test driven development featured using
Groovy. The panel discussions, when the subject came up of what would
be a big factor in Java for the coming year - Groovy became a major
item that was brought up by panelist.
Groovy uptake was so apparent in the Java community that the NFJS
folks themselves felt compelled to get involved in supporting its
development (this after Sun strangely opted for Ruby instead).
So perhaps folks are thinking the NFJS attendees are perhaps just a
bunch of odd balls and aren't really representative of the "Java
community".
Just how out of the mainstream are the NFJS crowd? Well, the NFJS
faction is certainly well known for its uptake of Spring Framework,
and the NFJS organization is heavily involved in doing Spring
Framework conferences as well.
Which has greater momentum in the Java community today? Spring or
Sun's JEE5/EJB3?
Spring momentum continues to accelerate while JEE5/EJB3 is rather
languishing:
Spring Passes EJB in Job Listings - The JEE Monolith Is Breaking Up
http://www.dzone.com/links/spring_passes_ejb_in_job_listings_the_jee_monolit.html
RogerV
January, it will be fair to look back on 2008 and dub it the year of
OSGi.
All the app servers or frameworks are somehow incorporating OSGi -
that's including the JEE app servers. Eclipse is looking to parley
their success with OSGi for their IDE as something to be used for
server-side development now.
Really all that's left to be done is have a JSR that ratifies OSGi as
THE module solution for the Java programming platform.
Any attempt at this point in time in pursing alternative module
solutions than OSGi will be just another vain effort in an exercise of
futility and irrelevance.
Indeed, it would be fair to say that continuing a non-OSGi JSR effort
at this point would amount to a deliberate attempt to sow
fragmentation of the Java community into different variant forks.
Instead, graciously admit defeat and move on. No one entity any longer
has the ability to impose what will be pervasive for Java computing
and community acceptance.
Alan Kent
pointed out very interesting in understanding OSGi and JSR 277 and 294.
They are tackling different problems to me (but I am basing this purely
on my understanding of what the interview said - not on real experience).
Here is my current understanding:
OSGi is a very dynamic thing, with lots of plugin support. You have to
design the interfaces of how all the different "bundles" fit together.
You have to work out all the contracts about what interactions can occur
across boundaries. Existing third party libraries cannot just become a
bundle - do get all the benefit from OSGi you really want their APIs
designed to fit in with the OSGi model. You have to add manifests to
control the visibility across bundle boundaries. This is ideal for
things like Eclipse where Eclipse wants to define a framework that other
people plug in to. Everything is dynamic, you can turn bits on and off
while everything is running, Eclipse define all the contracts that
everyone else conform to, etc.
Then there are the other two JSRs.
JSR 294 deals with introducing better scope of visibility than just the
package level scope. It allows me to break a complex set of classes
into multiple packages, but still control what to make 'public' to
consumers of the code I develop. Its a language level thing, improving
on the current public/protected/package scope stuff. It is not
dynamic. It does not require interfaces to be defined and contracts to
be agreed to on how all the different bits are going to play together.
It does not require any change to deal with existing third party
libraries. It is useful to me even if I use OSGi.
JSR 277 is a static module system. It is not infrastructure for
dynamically pluggable components. It does not require all parties to
agree to contracts on how everything is going to plug together with
interfaces defined for all the APIs. It is more of a static
organizational thing.
I really like OSGi and am planning to use it Real Soon Now on a project
I am doing. This is because I really need a dynamic pluggable framework
and I can define all the contracts between the plugins. JSR 294 feels
nice to me - better ability to control visibility is nice for internal
code management. JSR 277 I don't think I have a personal need for. My
understanding is it imposes less constraints and has less I have to do
to use it, but for my particular current need I don't think it will give
me any benefit. (This does not mean its not useful to others.)
But it is clearer in my mind that they are not tackling the same
problem. Overlapping problem space yes, but they are not the same thing.
Alan
Disclaimer: I have not used any of these technologies. Just my
understanding based on the SE podcast I listened to.
David Linsin
Joshua Marinacci
I don't think the idea was that lots of developers were leaving in
droves to Ruby (though a few high profile people were, as I recall).
The idea is to expand the scope of the Java platform and bring in more
new developers. JRuby was low hanging fruit. It already existed,
Ruby had a growing community, and the JRuby project itself needed some
support. So we hired the JRuby guys so they could work on it full
time. Sounds good to me!
Next is PHP which will have NetBeans support in NB 6.1.
I believe a Groovy plugin for NB is underway as well, but I don't know
it's status.
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google
> Groups "The Java Posse" group.
> To post to this group, send email to java...@googlegroups.com
> To unsubscribe from this group, send email to javaposse-...@googlegroups.com
> For more options, visit t
Casper Bang
prototyping support for this.
/Casper
RogerV
Rhino project moving on to ECMAScript 4 compliance?
Plain JavaScript I find less than interesting. But ECMAScript 4
running on the JVM would be quite interesting.
BTW, somewhere along the way I recall recently hearing of a case where
Forth was being used in a new system. I can't recall the context of
use, though. Surely it was some manner of embedded system.
I was previously under the impression that Forth had gone completely
out of vogue so it was interesting to hear of a new system using it.
Joshua Marinacci
basic highlighting already.
- j
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google
> Groups "The Java Posse" group.
> To post to this group, send email to java...@googlegroups.com
> To unsubscribe from this group, send email to javaposse-...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/javapo
Joshua Marinacci
ignorant of the last 5 years of Javascript development. :)
- j
James Ward
http://www.bluishcoder.co.nz/2008/02/quick-introduction-to-tamarin-tracing.html
-James
RogerV
really have never liked JavaScript.
ActionScript3, which is based on ECMAScript 4 spec, I pretty much
like.
If I still lived the world of day to day development (these days am
just a dev-mgr/architect - yeah, another reason for a stoning), I
could see myself getting along just fine with AS3.
Classes, interfaces, namespace scoping, are all first class in the
language. AC3 compiles with static type checking as the default
behavior. That I like about AS3, as I fall on the side of the fence of
being a fan of static type checking. AS3 still has some JavaScript
goodness, such as closures, and that works very naturally with such as
async programming.
If tomorrow all the javac compilers all just got devoured by a runaway
anti-Java virus, yet left the JVM unscathed, and all there were was an
ECMAScript 4 Rhino to run on the JVM, well - I could imagine a worse
apocalypse.
Joshua Marinacci
(maker of ActionScript3) provides you with a strict compiler. Are the
languages themselves different?
- Josh
James Ward
Today AS3 is not fully ES4 compliant because it was built before the spec was finalized. However Tamarin and AS3 will be updated to be ES4 compliant.
Michael Neale
http://labs.jboss.com/community/interviews/ales_osgi.html
On Jan 25, 6:29 pm, "James Ward" <jaw...@adobe.com> wrote:
> Isn't JBoss 5 supposed to have some modularity features? Are they using OSGi, the official JSR, both, or neither?
>
> -James
>
> ----- Original Message -----
> From: java...@googlegroups.com <java...@googlegroups.com>
> To: The Java Posse <java...@googlegroups.com>
> Sent: Fri Jan 25 00:22:39 2008
> Subject: [The Java Posse] OSGi on the Server Side and the matter of the WOO
>