Business Natural Languages Development in Ruby
Jay Fields presents his concept of Business Natural Languages - a type of Domain Specific Languages geared towards being readable by domain experts.
Tracking change and innovation in the enterprise software development community
Posted by Scott Delap on Aug 10, 2006 02:56 PM
OSGi is a specification of a Java based service platform targeted for use by systems that require long running times, dynamic updates, and minimal disruptions to the running environment.. The Eclipse Equinox project provides one of many available implementations of this specification (EclipseZone recently featured a podcast with Equinox project lead Jeff MacAffer) and serves as the reference implementation of the latest OSGi R4 specification. Initially, OSGi was targeted at home automation and residential gateway devices. More recently, it has found use in everything from mobile phones to cars.The OSGi specification breaks software up into units of functionality called bundles. As a result this makes OSGi an idea base for applications such as IDE and application servers that often have numerous "modules" that may or may not need to be started at runtime or after the application has been started. The Eclipse IDE has made use of OSGi as its base since version 3.0. More recently other applications have started leveraging OSGi.
One recent use of the Eclipse Equinox technology is to bundle servlets and JSP's in Eclipse style plugins for dynamic WAR deployment. The Apache Tuscany SOA project has recently started exploring OSGi. Websphere 6.1 and JOnAS 5 are also being reworked as OSGi applications. A case study published by Adobe details how they made use of OSGi in their Adobe Creative Suite 2 application:
... [team members] found that reusing Adobe Creative Suite 2 components in an Equinox environment was as simple as writing a thin compatibility layer.Developing plug-ins to deliver new functionality in the past had presented significant challenges. Since it was difficult to validate dependencies, Version Cue had not been able to make the most efficient use of system resources by loading exactly what was needed. Using Equinox and the Eclipse plug-in model, resolving plug-in dependency is simple, and they have been able to achieve true dynamic loading and unloading of plug-ins on demand. The result is a smarter, leaner and faster application that provides a better user experience.
Developers in the trenches are also starting to notice OSGi. Xerto's Imagery application is built on Swing but uses OSGi for its plugins layer. Blogger Werner Schuster recently commented:
if you want to write any kind of nontrivial program where you want a clean seperation of the individual modules. If you do that, you can spend ages writing a runtime system that tediously reimplements all the OSGi features,.. or you can just use OSGi. And it will pay off… OSGi isn‘t a new kid on the block… it‘s now up to version 4, not to mention that Eclipse has used it now for about 3 years and provided lots of feedback. I became really convinced of OSGi usefulness when I had some class loading issues while writing EclipseShell… I already feared having to mess with the classloaders (not much fun if you‘re using JVM based dynamic languages which might or might not pack their own class loading tricks). But no! The solution to my problems was … adding a line to the Manifest.MF ... et voila! (If you‘re curious, google for “Buddy-Classloading”)...So… screw Sun‘s NotInventedHere syndrome, screw Dolphin, screw waiting for JSR-277 to be shoved into existence. The future is here right now and it‘s tried, tested and easy to use in the form of OSGi, Eclipse for development, and Equinox for the runtime.
It will be interesting to see how the Java community makes use of OSGi which is available today versus Sun's "super-packages" (JSR 294) and Java Modules (JSR 277) initiatives scheduled for Java 7. A blog post by Sun's Alexis Moussine-Pouchkine described the two JSR's:
JSR 294 is development-time and language driven while JSR 277 is all about deploy-time ... one of JSR 294's goal is to enable "separate compilation", i.e. compile against an interface without needing the actual implementation. Most of JSR 277 has to do with annotating JSR 294 modules. Pretty much like moving archive manifest information to Java annotations.
RESTful todo list sample tutorial with Groovy & Project Zero
Introducing Project Zero: Building RESTful services for your Web application
Hibernate without Database Bottlenecks
IBM Web 2.0 Developer eKit: Free Tutorials, Webcasts, Whitepapers
How about an interview with expert group members for those JSRs? I feel they are a bit too silent, and that is really worrysome for specs with potential to have such a big impact on the future of java development.
Great idea, we're on it. What questions would you have for them that you'd like us to ask?
I have a question for the JSR 277 guys. Like all JSRs, 277 must answer the standard formation questions, one of which is "Why isn't this need met by existing specifications?". If a JSR cannot answer that question satisfactorily then it should not exist. The answer given for JSR 277 discusses a few alternatives in order to reject them; specifically JNLP, WARs, EARs, "Class-Path:" etc, and finally OSGi Release 3. However OSGi R3 is the old version, we are now on OSGi Release 4, and it is R4 that is being brought into the JCP as JSR 291. There are no arguments offered as to why OSGi R4 does not meet the need, and in fact all of the reasons given for rejecting OSGi R3 (and they are valid reasons) no longer apply to OSGi R4. Therefore, given that an existing specification does already meet the need that JSR 277 intends to meet, why is JSR 277 still needed?
Apache is currently incubating an OSGi implementation called Felix. Some of the Java-based Apache projects have looked into adopting OSGi for their own internal container.
Some things I would like to know:
(Sorry for my English)
I forgot that I had one more question: * Is fixing bug 4670071 within JSR-277's scope?
Jay Fields presents his concept of Business Natural Languages - a type of Domain Specific Languages geared towards being readable by domain experts.
Adoption and interest for Distributed Version Control Systems is constantly rising. We will introduce the concept of DVCS and have a look at 3 actors in the area: git, Mercurial and Bazaar.
Deborah Hartmann interviewed Segundo Velasquez about his experience as customer with an Agile team during the initial phase of software design of a product.
David Cooksey shows how to fine grained versioning to a ClickOnce deployment using an HttpHandler written with ASP.NET, making partial rollouts to a test audience much easier.
Windows workflow (WF) is an excellent framework for implementing business processes, but lacks support for human activities. This article describes a completely generic approach for changing this.
In this interview taken during OOPSLA 2007, Markus Voelter talks about the importance of documenting the software architecture, and gives some good and also bad examples on how it could be done.
William Soo and Meeraj Kunnumpurath discuss the Voca transaction processing system, architectural challenges and requirements, Voca's Spring/J2EE architecture, and the future SEPA architecture.
Security is about trade-offs. Only a few have the expertise to design good security. This talk focuses on Security Patterns, such as Role-based Access Control, Single Access Point, and Front Door.
7 comments
Reply