VMware Infrastructure 3 Book Excerpt and Author Interview
VMware Infrastructure 3: Advanced Technical Design Guide and Advanced Operations Guide provides a wealth of practical insights into setting up virtualization in todays corporate environments.
Tracking change and innovation in the enterprise software development community
Posted by Mark Little on Jul 13, 2007 06:43 AM
In an recent interview, Eric Newcomer, IONA's CTO and co-chair of the Enterprise working group in OSGi, talks about his company's interest in OSGi, where he thinks OSGi will be going over the next few years, and why he thinks it has grown in popularity. Eric also has a few words to say on the relevance of OSGi to ESB and SOA, as well as whether or not Sun should become more interested in OSGi.The End of Middleware: Freedom from IT Stacks as we know it
The Key to SOA Governance: Understanding the Essence of Business
JProbe Freeware – Eclipse Plugin for efficient memory analysis and diagnosis
Real World REST & Document-Oriented Distributed Databases Tracks @ QCon SF Nov 19-21
Introducing application infrastructure virtualization and WebSphere Virtual Enterprise
Sun and the members of the JCP are making a huge effort to ensure that it is compatible with OSGi, OSGi will support 277 (after all, 277 has 2 OSGi people on it). But it would be quite wrong for Sun to favour one vednor solution (OSGi) over all the others (Maven, Ivy, etc). JSR-277 is a good thing for OSGi. It makes life easier from a JDK perspective for it and the other competing solutions. Bundles/modules become first class citizens on the JVM level. Beyond that, it’s up to the framework (OSGi or whatever else) to provide any value-add stuff they want to. 277 does not limit that. OSGi will offer proprietary extensions on top of the basic spec just like everything else in vendor land. So why do the OSGi people jump up and down all the time. It would be rather like if the JBOSS folks were constantly attacking JPA because it didn't solely support hibernate.
They attack JSR 277 not because it's coming from a JCP, but rather because the spec group blatantly ignored an 8-year experience OSGi brought us, and naively approached the problem with a "don't tell us how to do it, we know better" approach. Isn't it the core idea of JCP to embrace industry experience and not reinvent a squared wheel?
I still don't get what the issue is. Members of the JSR-277 expert group include two .NET experts, two OSGi experts who co-authored the R4 modularity spec, Maven's creator and Ivy's creator. Sonds like "embracing industry experience" to me, and exactly what the JCP is supposed to do.
William, Take a look at the expert group mailing list for JSR 277, which is now open to the public (albeit read-only). Having done so, it's really hard to see that the two OSGi experts (Glyn Normington and Richard Hall) are being listened to. It's certainly not from a lack of effort on their behalf. There are numerous areas in the JSR 277 draft spec and the current strawman which are irreconcilable with OSGi: Sun is willfully refusing to learn any lessons from the experiences of OSGi/JSR 291. OSGi people are not simply complaining because our favourite module system has not been chosen. That would be childish. The principle reason that we are making so much noise is that JSR 277 is heading towards failure as a module system! It will be hugely damaging to the entire Java community to have a broken module system baked into the JVM. I would really like JSR 277 to be a success, but I believe that it should build on OSGi rather than compete with it. Competing APIs are great in some areas (e.g. GUI libraries or XML parsers) but the module system of the platform is not one of those areas. Can you think any other language or platform that has multiple competing module systems? Neil.
By this logic OSGi should be encouraged to recruit JEE experts and define a better alternative to EJB.
Plus it's wrong to say that "... t would be quite wrong for Sun to favour one vednor solution ..." Have you looked at who's involved with OSGi? Last time I looked it was more than a single vendor! With the exception of Sun, I think all of the usual major JEE suspects are there.
That's right! Without wanting to oversimplify the issue here. It seems like yet another round of Sun playing the "not invented here" game. Ever since I got acquainted with OSGi it seemed to me like it had solved so many questions of component models, component dependency checking, deployment and upgradeability that most appserver vendors have not yet solved properly and that the official jee standards are not even touching at all.
VMware Infrastructure 3: Advanced Technical Design Guide and Advanced Operations Guide provides a wealth of practical insights into setting up virtualization in todays corporate environments.
Ruby 1.9's Fibers and non-blocking I/O are getting more attention - we talked to Mohammad A. Ali of the NeverBlock project and Tony Arcieri of the Revactor project.
Tim Mackinnon talks about the aspirations behind the Agile principles and practices, the desire to become efficient, to write quality code which does not end up being thrown away.
Brian Goetz discusses the difficulties of creating multithreaded programs correctly, incorrect synchronization, race conditions, deadlock, STM, concurrency, alternatives to threads, Erlang, Scala.
Often the hardest part of changing technologies is language syntax differences. This new article provides Java developers with a transition guide to Actionscript which forms the foundation of Flex.
Neal Ford talks about having multiple languages running on one of the two major platforms: Java and .NET. He also presents the advantages offered by Ruby compared to static languages like Java or C#.
David Anderson talks about the history of Agile, the current status of it and his vision for the future. The role of Agile consists in finding ways to implement its principles.
Nick Sieger talks about the future of JRuby, Java Integration, and his work on JEE deployment tools for Ruby on Rails like Warbler.
7 comments
Reply