Tapestry for Nonbelievers
A new article by I. Drobiazko and R. Zubairov introduces v. 5 of the Apache Tapestry component-oriented web framework. The tutorial shows how to create a component and covers IoC in Tapestry and Ajax.
Tracking change and innovation in the enterprise software development community
Posted by Ryan Slobojan on Jan 25, 2008 07:00 AM
The Spring Dynamic Modules for OSGi project, formerly known as Spring OSGi, released version 1.0 today. InfoQ spoke with SpringSource CTO Adrian Colyer and Spring Dynamic Modules project lead Costin Leau to learn more about this release and what it provides for the Spring community.
Adrian Colyer described the philosophy behind the Spring Dynamic Modules project:
The fundamental goal is to enable application developers to take advantage of the benefits of the OSGi platform (modularity, versioning support, module lifecycle / operations) when writing an enterprise application. Contrast this with the approach taken by some vendors that use OSGi in the construction of their product offerings, but don't pass any of the benefits of OSGi onto the applications that are deployed on those offerings. We want to make it as easy as possible to exploit OSGi without needing to write code that is coupled to the OSGi Service Platform (retaining for example the ability to easily unit test) and without needing to deal explicitly. Spring Dynamic Modules brings together the simplicity and power of Spring with the sophistication of the OSGi Service Platform.
Costin Leau said the main goal of the 1.0 release was the creation of a stable and robust foundation for working with Spring applications inside of an OSGi environment. Leau identified the major features of this release as:
OsgiServiceFactoryBean, and the current application context is exported as an OSGi serviceorg.springframework.osgi.test package, which contains many OSGi-enabled JUnit test classesLeau also indicated that a detailed explanation of all of the features in version 1.0 was available in the reference documentation.
Since the origin of the OSGi specification is in the mobile space, InfoQ asked Colyer whether there were plans to create a mobile version of Spring Dynamic Modules. Colyer responded that, due to dependencies upon Spring 2.5, which in turn depends upon JDK 1.4, it is not currently possible and that there were no current plans to create a mobile version of the Spring Framework. However, Colyer did indicate that there is a large amount of interest from current OSGi developers who are seeking to simplify application development, and that although most of those developers are in the enterprise realm, if demand increased for a mobile version then that would justify the investment needed to create it.
When asked about plans for the future of Spring Dynamic Modules, Colyer said:
The 1.0 release provides a solid foundation for creating Spring-powered OSGi based applications. The critical next step and the focus of the 1.1 release will be on making it easy to use common enterprise libraries in the OSGi Service Platform - with an emphasis on making web applications under OSGi much easier to build than they are today. SpringSource is also an active participant in the OSGi Enterprise Expert Group and we hope to help many of the ideas found in the Spring Dynamic Modules project to make their way into the OSGi R5 specification. Spring Dynamic Modules would obviously seek to support any such standards at that point in time.
Colyer also added that there were no plans to support other dynamic module frameworks such as JSR 277, and said "The industry momentum seems to be clearly behind OSGi".
A Technical Introduction to Terracotta
Evaluation Guide: Is Your SCM Tool Ready for Agile?
Hibernate without Database Bottlenecks
Info 2.0: IBM's vision for the world of Web 2.0 and enterprise mashups (Webcast)
Fighter Jets and Agile Development at Lockheed Martin (Case study)
Are there options available to use OSGi in applications deployed as EAR files?
A nice comparison between spring osgi, eclipse extensions and osgi service component http://neilbartlett.name/downloads/extensions_vs_services.pdf
Steven, Yes, take a look at the Eclipse Equinox server-side support: http://www.eclipse.org/equinox/server/ Ideally in the future, OSGi will permeate the entire JEE container rather than just being a small subsystem accessed through a "bridge" servlet (this has already happened to some of them). Using OSGi would then be a simple matter of deploying your bundle to the server just like any other. However, the bridge mechanism is a useful stopgap while JEE servers still exist on the market that are not OSGi-based. Regards, Neil
There's also Pax-Web (http://wiki.ops4j.org/confluence/x/AYAz) which provides a Jetty 6 based HttpService and adds support for filters, etc. Alin has also written an extender bundle (http://wiki.ops4j.org/confluence/x/OQJN) that lets you deploy WAR files onto an OSGi framework using Pax-Web, it's pretty cool stuff.
A new article by I. Drobiazko and R. Zubairov introduces v. 5 of the Apache Tapestry component-oriented web framework. The tutorial shows how to create a component and covers IoC in Tapestry and Ajax.
In this interview, Burton Group consultant Pete Lacey talks to Stefan Tilkov about his disillusionment with SOAP, his opinion on REST, and addresses some of the perceived shortcomings REST vs. WS-*.
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.
4 comments
Reply