...the words every proud parent longs to hear, to know they've succeeded in keeping their offspring alive long enough for them to become a teenager. I heard this as I walked through the door yesterday and was doubly pleased when I found out why. The video I made a little while ago to kick off the new Enterprise OSGi YouTube channel has successfully attracted enough attention for my daughter to be teased at school, once again proving the value and reach of social media. Result.
Showing posts with label OSGi. Show all posts
Showing posts with label OSGi. Show all posts
Saturday, 18 June 2011
Monday, 8 March 2010
Apache Aries - An open source project for Enterprise OSGi Applications
I spoke at the recent OSGi DevCon London conference (part of JAX-London 2010) as it extended late into the evening - Oracle's Mike Keith and I were competing with the bar in the 9-10pm slot as we talked about the Apache Aries and Eclipse Gemini open source projects. For those of you who chose the bar, or who couldn't make it to the gathering in West London, here are my slides on Apache Aries. They describe the primary goals and capabilities of Apache Aries, including how to get involved.
The 1-line summary is: Take a look at Aries if you want ready-to-use components that provide enterprise OSGi capability or if you want to join the development community to drive the technology forward.
The 1-line summary is: Take a look at Aries if you want ready-to-use components that provide enterprise OSGi capability or if you want to join the development community to drive the technology forward.
Friday, 25 September 2009
OSGi 4.2 Published
My previous post mentioned early drafts of the OSGi 4.2 specifications which define part of the enterprise OSGi programming model that the new Apache Aries project is implementing. Since then the OSGi Service Platform V4.2 have been finalized and published by the OSGi Alliance. The platform is defined in two specifications - the "core" and "compendium" specifications. The latter includes the new Blueprint container specification mentioned in the previous post, an important part of the enterprise OSGi programming model we're implementing in Aries.
Tuesday, 8 September 2009
OSGi in the Enterprise – the Apache Aries incubator
There have been an increasing numbers of discussions recently - these two on TheServerSide are pretty representative - over the role of OSGi technology in enterprise Java applications. On the one hand it can be an asset in enabling a more modular approach to building enterprise applications: not only is a significant amount of enterprise Java middleware built on OSGi for this reason but so are some significant applications such as LinkedIn and the Jazz Team Server. On the other hand is the question of just how OSGi features in the programming model for enterprise applications. What is the web component model? The persistence model? How does the vast landscape of existing Java EE components begin to take some advantage from OSGi?
These are the questions the OSGi Alliance Enterprise Expert Group (EEG) are addressing through a set of specifications related to how existing, familiar Java EE technologies are exploited in an OSGi environment. For example, the EEG's Web Application specification (RFC 66) describes how an OSGi web container manages the lifecycle of application components written to the Servlet and JSP specifications and how existing WAR files are transformed to a web application bundle whose web components are then managed by that container. Other EEG specifications follow a similar pattern, describing how JPA, JTA, JNDI and other technologies in common use in Java EE applications should be catered for in an OSGi environment. And the Spring framework is relevant here too as the inspiration for the OSGi Blueprint container specification. This defines a standard dependency injection container including the application configuration XML (the application "blueprint") used by the container to manage, wire and configure simple Java components and optionally publish/consume these as services in the OSGi service registry. A public draft roll-up of these specifications was published earlier this year by the OSGi Alliance, ahead of finalization.
The broad adoption of OSGi as part of the enterprise Java application programming model depends not only on the EEG specifications - to encourage consistency of behaviour across enterprise OSGi platforms, to ensure application portability and avoid vendor lock-in - but also on their widespread implementation. This is the primary motivation of the Aries incubator, which aims to deliver implementation of the EEG specifications that are part of the enterprise OSGi programming model. Aries sets out to provide enterprise OSGi componentry that can be integrated into application or integration server runtimes - such as Geronimo and ServiceMix - without being tied to any one of these. Some of the work - for example the Blueprint container implementation - actually started inside Geronimo but, as it evolved, it seemed better to move it into a new incubator to help develop a community with a focus on enterprise OSGi that was independent of any specific target runtime.
Want to help develop Aries? Have a look at the proposal and discussion and get involved.
These are the questions the OSGi Alliance Enterprise Expert Group (EEG) are addressing through a set of specifications related to how existing, familiar Java EE technologies are exploited in an OSGi environment. For example, the EEG's Web Application specification (RFC 66) describes how an OSGi web container manages the lifecycle of application components written to the Servlet and JSP specifications and how existing WAR files are transformed to a web application bundle whose web components are then managed by that container. Other EEG specifications follow a similar pattern, describing how JPA, JTA, JNDI and other technologies in common use in Java EE applications should be catered for in an OSGi environment. And the Spring framework is relevant here too as the inspiration for the OSGi Blueprint container specification. This defines a standard dependency injection container including the application configuration XML (the application "blueprint") used by the container to manage, wire and configure simple Java components and optionally publish/consume these as services in the OSGi service registry. A public draft roll-up of these specifications was published earlier this year by the OSGi Alliance, ahead of finalization.
The broad adoption of OSGi as part of the enterprise Java application programming model depends not only on the EEG specifications - to encourage consistency of behaviour across enterprise OSGi platforms, to ensure application portability and avoid vendor lock-in - but also on their widespread implementation. This is the primary motivation of the Aries incubator, which aims to deliver implementation of the EEG specifications that are part of the enterprise OSGi programming model. Aries sets out to provide enterprise OSGi componentry that can be integrated into application or integration server runtimes - such as Geronimo and ServiceMix - without being tied to any one of these. Some of the work - for example the Blueprint container implementation - actually started inside Geronimo but, as it evolved, it seemed better to move it into a new incubator to help develop a community with a focus on enterprise OSGi that was independent of any specific target runtime.
Want to help develop Aries? Have a look at the proposal and discussion and get involved.
Tuesday, 6 May 2008
Spring and WebSphere – fish and chips, or fish on a bike?
The announcement by SpringSource last week of a Spring-OSGi based application server – the SpringSource Application Platform – has generated quite a storm of discussion in the blogosphere from fans and detractors alike. Is all the excitement merited? And what impact, if any, does it have on WebSphere's support for Spring applications?
I think its merited - that's why I'm writing about it. The Spring framework has done a lot to shake up the Java Enterprise world by popularising the dependency injection (DI) pattern both as a way to wire application components together and as a way to provide the enterprise services those applications need. This was a “good thing”, as was the adoption by EJB3/JPA and JAX-WS Web Services of DI-based POJO programming models, enabling POJO-based business logic to be developed and more easily tested outside a JEE environment thus accelerating and simplifying the development experience. Enterprise qualities of service, such as security and transactions, get applied by the JEE container without requiring changes to the application when the application is deployed into the JEE container. The Spring framework goes further with this than Java EE because the Spring framework is itself a “lightweight container” that is bundled with the application regardless of whether the application runs in a Java SE or Java EE environment. The lightweight container that is a part of the Spring framework
A common misunderstanding I see from people coming into contact with the Spring framework for the first time is that the Spring framework itself provides many of the enterprise qualities of service available in a Java EE container. Again, Spring support for transactions is a good illustrative example. The Spring framework reference documentation, for example, says “One of the most compelling reasons to use the Spring Framework is the comprehensive transaction support.” In my opinion, comprehensive transaction support is one of the most compelling reasons to use a JEE AppServer which actually provides a recoverable 2PC transaction manager. The Spring framework does not – it simply delegates to whatever is already there. In a Java SE environment, this means the resource (JDBC, JMS etc) provider; in a Java EE environment this means the JEE AppServer’s JTA transaction manager.
The core Spring framework has done a good job of integrating with various underlying Java EE providers. Its complimentary nature and popular adoption by Java developers have led WebSphere and all of the major JEE vendors to demonstrate integration with and exploitation by the Spring framework. People like the Spring framework because it provides a nice, simple composition and deployment model and gives them portability between Java SE and EE runtimes.
This portability is different from portability of JEE applications between JEE vendors. Portability across Java EE vendors is at the level of Java EE APIs (EJB, JMS, JTA etc) standardized through the Java Community Process. The Spring framework libraries define their own Java programming interfaces; these interfaces are not part of any standard but applications that use them are portable between Java SE and EE runtimes because the Spring framework libraries are packaged as part of the application rather than as part of the underlying runtime platform. This Spring "lightweight container" isolates the application from the differences between SE and EE runtimes. In an EE runtime, the lightweight container delegates to the EE container to engage the EE qualities of service.
While there clearly is synergy between JEE providers and the core Spring framework, it remains to be seen how the new SpringSource Application Platform will change the dynamics of the relationship between SpringSource and the other JEE vendors. I say “other” because SpringSource now, for the first time, is going to be positioned as a JEE vendor. This may not be SpringSource’s primary intention but it is inevitable given comments like “It is highly likely that the SpringSource Application server will become Java EE 6 Compliant in some form” from SpringSource’s Rod Johnson on InfoQ. But JEE is not the SpringSource end game here – OSGi is. There has been a great deal of interest expressed over the last year in combining OSGi’s modularity with Spring’s application configuration model, which is what the Spring Dynamic Modules project offers – under an Apache open source license. The next logical step is the dynamically provisioned application server platform that hosts Spring-OSGi applications as the deployable unit, a step SpringSource have taken with their new SpringSource Application Platform offering. But there remains a “roll-your-own” approach towards familiar JEE enterprise services such as messaging, persistence and transaction support – these are services that need to be plugged in, they are not provided by "S2AP" itself. Perhaps that will change over time and S2AP will evolve its own positioning into a complete enterprise Java application server.
Does any of this affect WebSphere? Well, nothing has changed in the core Spring framework. Regardless of what the future holds for the SpringSource Application Platform, the core Spring framework project remains complimentary to WebSphere. Like fish and chips.
I think its merited - that's why I'm writing about it. The Spring framework has done a lot to shake up the Java Enterprise world by popularising the dependency injection (DI) pattern both as a way to wire application components together and as a way to provide the enterprise services those applications need. This was a “good thing”, as was the adoption by EJB3/JPA and JAX-WS Web Services of DI-based POJO programming models, enabling POJO-based business logic to be developed and more easily tested outside a JEE environment thus accelerating and simplifying the development experience. Enterprise qualities of service, such as security and transactions, get applied by the JEE container without requiring changes to the application when the application is deployed into the JEE container. The Spring framework goes further with this than Java EE because the Spring framework is itself a “lightweight container” that is bundled with the application regardless of whether the application runs in a Java SE or Java EE environment. The lightweight container that is a part of the Spring framework
spring.jar abstracts away some of the differences between an underlying Java EE runtime vs an underlying Java SE runtime. For example, the Spring framework transaction support provides a common local transaction demarcation model regardless of whether the underlying runtime is SE or EE. Actual transactional work within the demarcation scope is delegated to the underlying resource managers wired into the application – for example JDBC or JMS providers.A common misunderstanding I see from people coming into contact with the Spring framework for the first time is that the Spring framework itself provides many of the enterprise qualities of service available in a Java EE container. Again, Spring support for transactions is a good illustrative example. The Spring framework reference documentation, for example, says “One of the most compelling reasons to use the Spring Framework is the comprehensive transaction support.” In my opinion, comprehensive transaction support is one of the most compelling reasons to use a JEE AppServer which actually provides a recoverable 2PC transaction manager. The Spring framework does not – it simply delegates to whatever is already there. In a Java SE environment, this means the resource (JDBC, JMS etc) provider; in a Java EE environment this means the JEE AppServer’s JTA transaction manager.
The core Spring framework has done a good job of integrating with various underlying Java EE providers. Its complimentary nature and popular adoption by Java developers have led WebSphere and all of the major JEE vendors to demonstrate integration with and exploitation by the Spring framework. People like the Spring framework because it provides a nice, simple composition and deployment model and gives them portability between Java SE and EE runtimes.
This portability is different from portability of JEE applications between JEE vendors. Portability across Java EE vendors is at the level of Java EE APIs (EJB, JMS, JTA etc) standardized through the Java Community Process. The Spring framework libraries define their own Java programming interfaces; these interfaces are not part of any standard but applications that use them are portable between Java SE and EE runtimes because the Spring framework libraries are packaged as part of the application rather than as part of the underlying runtime platform. This Spring "lightweight container" isolates the application from the differences between SE and EE runtimes. In an EE runtime, the lightweight container delegates to the EE container to engage the EE qualities of service.
While there clearly is synergy between JEE providers and the core Spring framework, it remains to be seen how the new SpringSource Application Platform will change the dynamics of the relationship between SpringSource and the other JEE vendors. I say “other” because SpringSource now, for the first time, is going to be positioned as a JEE vendor. This may not be SpringSource’s primary intention but it is inevitable given comments like “It is highly likely that the SpringSource Application server will become Java EE 6 Compliant in some form” from SpringSource’s Rod Johnson on InfoQ. But JEE is not the SpringSource end game here – OSGi is. There has been a great deal of interest expressed over the last year in combining OSGi’s modularity with Spring’s application configuration model, which is what the Spring Dynamic Modules project offers – under an Apache open source license. The next logical step is the dynamically provisioned application server platform that hosts Spring-OSGi applications as the deployable unit, a step SpringSource have taken with their new SpringSource Application Platform offering. But there remains a “roll-your-own” approach towards familiar JEE enterprise services such as messaging, persistence and transaction support – these are services that need to be plugged in, they are not provided by "S2AP" itself. Perhaps that will change over time and S2AP will evolve its own positioning into a complete enterprise Java application server.
Does any of this affect WebSphere? Well, nothing has changed in the core Spring framework. Regardless of what the future holds for the SpringSource Application Platform, the core Spring framework project remains complimentary to WebSphere. Like fish and chips.
Subscribe to:
Posts (Atom)