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.Monday, 20 August 2007
Is WS-Transaction useable in the real world today?
The WS-Transaction specifications can be used by a Web service to include the processing of the service in a distributed transaction. But Web services themselves are often simply a means to integrate existing applications into new composites and/or a means to expose those applications to new types of clients/channels. So, in a bottom-up design where new Web services that can exploit WS-Transaction capabilities are wrappering existing back-end applications, do the back-end applications have to have been designed to be used with transactions?
The answer is: it depends...
The back-end applications might provide a core business service that has been doing its job well for many years and runs in an environment that ensures the transactional integrity of any data updates performed by the application, such as a CICS program. Or the back-end application might be a database stored procedure, or a purchase order workflow or anything else.
Most of them will have been around for longer than the WS-Transaction specifications but equally most of them can be exposed through Web services that exploit WS-Transaction capability.
There's plenty of information in the WAS 6.0 and 6.1 InfoCenters on how to use this feature of WAS and samples that can be downloaded from developerWorks. As a general guide through all that information, I posted an article on Web Service Transaction support in WAS on the WebSphere Community Blog. There's also a good article on Building transactional Web services with WebSphere Application Server and Microsoft .NET using WS-AtomicTransaction that describes how to configures both systems for WS-AT interoperability.
Going back to the title of this article, I believe the answer is a resounding Yes and there are numerous commercial runtimes - including IBM's WebSphere Application Server and CICS - that have tried and tested production-ready support available today.
Feel free to comment on any gaps in the information that could be usefully filled.
The answer is: it depends...
The back-end applications might provide a core business service that has been doing its job well for many years and runs in an environment that ensures the transactional integrity of any data updates performed by the application, such as a CICS program. Or the back-end application might be a database stored procedure, or a purchase order workflow or anything else.
Most of them will have been around for longer than the WS-Transaction specifications but equally most of them can be exposed through Web services that exploit WS-Transaction capability.
- WS-AT is typically useful only when the back-end application runs in an environment that supports some form of distributed 2PC, although the precise manner of the 2PC really doesn't matter since the WS-AT provider can adapt the AT protocol messages to the desired domain-specific transaction protocols. So, for example, WebSphere Application Server represents a received WS-AT context as a JTA transaction within the AppServer process and hence subordinates any XA resource managers (including XATransaction JCA resource adapters) and downstream OTS resources (and on zOS, any RRS unit of recovery) to the received WS-AT context.
- WS-BA is typically useful when any work performed by the back-end application can be undone/reversed through a compensation handler that drives another back-end application (or by the same back-end application with a different set of data). The compensation handler logic itself is application logic but the determination of when/if such a compensation handler should be driven and the recoverable recording of data to be used by the compensation handler is what the WS-BA infrastructure must provide.
There's plenty of information in the WAS 6.0 and 6.1 InfoCenters on how to use this feature of WAS and samples that can be downloaded from developerWorks. As a general guide through all that information, I posted an article on Web Service Transaction support in WAS on the WebSphere Community Blog. There's also a good article on Building transactional Web services with WebSphere Application Server and Microsoft .NET using WS-AtomicTransaction that describes how to configures both systems for WS-AT interoperability.
Going back to the title of this article, I believe the answer is a resounding Yes and there are numerous commercial runtimes - including IBM's WebSphere Application Server and CICS - that have tried and tested production-ready support available today.
Feel free to comment on any gaps in the information that could be usefully filled.
Wednesday, 9 May 2007
Web Services Transaction 1.1 OASIS Standard published
OASIS, the international standards consortium, announced on 8 May 2007 that its members have approved Web Services Transaction (WS-Transaction) version 1.1 as an OASIS Standard, a status that signifies the highest level of ratification.
The final open standard versions of the WS-Transaction 1.1 are now available at the locations referenced in my earlier post.
The final open standard versions of the WS-Transaction 1.1 are now available at the locations referenced in my earlier post.
Friday, 20 April 2007
Tuesday, 17 April 2007
WS-Transaction 1.1 has been committed
The WS-Tx TC - which IONA's Eric Newcomer and I chair - has now delivered the WS-Transaction 1.1 OASIS Standard which comprises the following specifications:
- WS-Coordination 1.1 - which describes a common framework for Web services transaction models,
- WS-AtomicTransaction 1.1 - which uses WS-Coordination and describes a Web services protocol for atomic, 2PC transactions,
- WS-BusinessActivity 1.1 - which uses WS-Coordination and describes a Web services protocol for compensating transactions.
The TC held its first meeting in November 2005 and took, as input, drafts of these three specs that were contributed by members of the TC including IBM, Microsoft, IONA, Hitachi and BEA. During the course of the TC a number of the companies involved in the TC (IBM, Microsoft and JBoss/RedHat) developed implementations of the specifications to test the completeness of the specification by driving a number of pre-agreed AT and BA interop scenarios. We did this remotely using internet endpoints and it successfully validated all the parts of the specs covered by the scenarios. You can view the results for AT and BA scenarios.
Follow-on work
The TC will continue in maintenance mode to work on any maintenance issues brought to our attention and to produce a new version of the specifications with an updated references to WS-Policy 1.5 once the W3C has published a W3C Recommendation for WS-Policy 1.5 anticipated in August 2007.
Tags: ws-tx, WS-Transaction, WS-AtomicTransaction, WS-Coordination, WS-BusinessActivity, WS-AT, WS-BA
Subscribe to:
Posts (Atom)
