After a couple of days spent on the new website, JBossWS 3.2.1.GA release has just been announced. It features performance improvements, component upgrades, the JAXBIntro support with CXF, bug fixes, etc.
Download it now and give it a try :-)
Thursday, November 5, 2009
Thursday, October 15, 2009
Simplifying use of JAXB Introductions
The JAXBIntros project provides a mean of using JAXB with non annotated classes, getting the required binding information from a xml config file. The information is converted into a binding customization that is basically a custom annotation reader JAXB allows as a hook for driving his context creation [1].
One of the targets of JBossWS 3.2.1 is to enable use of JAXB Introductions with the Apache CXF based stack. In order to do that I've gone through the currently available integration code between the JAXBIntro project and the JBossWS-Native stack and rationalized it to simplify the use of JAXB Introductions with every WS stack.
JAXBIntros project has been "mavenized" and the new 1.0.1.GA version is currently available in the JBoss Maven repository. It now has a convenient class (BindingCustomizationFactory) for getting binding customizations ready for being installed in a JAXB context while hiding the internals of jaxb-impl.
With that users can simply populate their own binding customization (which is really nothing more than a Map) and provide it when constructing the JAXBContext. That's all, the new context will consider the customizations and acts accordingly when used for marshalling/unmarshalling objects to/from xml.
Since the first release of JAXBIntros, JBossWS-Native used to have a CustomizableJAXBContextFactory getting the binding customization from the current endpoint deployment and providing it to the JAXBRIContextFactory.
Now, as previosly mentioned, enabling JAXB Introductions is just a matter of giving the customization map a way to JAXBContext creation, it doesn't matter which webservice stack is used.
As a prove of that, I've recently provided seamless integration with JBossWS-CXF. Basically CXF allows users to specify a Configurer (org.apache.cxf.configuration.Configurer) that is called whenever a configurable CXF bean is setup. JBossWS-CXF has a JBossWSCXFConfigurer (org.jboss.wsf.stack.cxf.client.configuration.JBossWSCXFConfigurer) users can leverage to configure the bus for use with JBossWS, in this case to simply plug-in binding customizations:
On server side the same configurer is automatically installed and it uses the binding customizations coming from the optional jaxb.intro.xml file in the deployment.
Please not that while this all comes out of the box with JBossWS-CXF 3.2.1, with "plain" Apache CXF 2.2.4 you can manually use a Configurer like the one mentioned above and/or directly provide the customization properties in the JAXBDatabinding element of the CXF Spring bus configuration file ;-)
[1] http://weblogs.java.net/blog/kohsuke/archive/2007/07/binding_3rd_par.html
One of the targets of JBossWS 3.2.1 is to enable use of JAXB Introductions with the Apache CXF based stack. In order to do that I've gone through the currently available integration code between the JAXBIntro project and the JBossWS-Native stack and rationalized it to simplify the use of JAXB Introductions with every WS stack.
JAXBIntros project has been "mavenized" and the new 1.0.1.GA version is currently available in the JBoss Maven repository. It now has a convenient class (BindingCustomizationFactory) for getting binding customizations ready for being installed in a JAXB context while hiding the internals of jaxb-impl.
public class BindingCustomizationFactory {
public static Map<String, Object> getBindingCustomization(InputStream introsConfigStream, String namespace) {
Map<String, Object> jaxbCustomizations = new HashMap<String, Object>();
populateBindingCustomization(introsConfigStream, namespace, jaxbCustomizations);
return jaxbCustomizations;
}
public static void populateBindingCustomization(InputStream introsConfigStream, Map<String, Object> customization) {
populateBindingCustomization(introsConfigStream, null, customization);
}
public static void populateBindingCustomization(InputStream introsConfigStream, String namespace, Map<String, Object> customization) {
JaxbIntros jaxbIntros = IntroductionsConfigParser.parseConfig(introsConfigStream);
IntroductionsAnnotationReader annotationReader = new IntroductionsAnnotationReader(jaxbIntros);
String defaultNamespace = namespace != null ? namespace : jaxbIntros.getDefaultNamespace();
customization.put(JAXBRIContext.ANNOTATION_READER, annotationReader);
if (defaultNamespace != null) {
customization.put(JAXBRIContext.DEFAULT_NAMESPACE_REMAP, defaultNamespace);
}
}
}
With that users can simply populate their own binding customization (which is really nothing more than a Map
Since the first release of JAXBIntros, JBossWS-Native used to have a CustomizableJAXBContextFactory getting the binding customization from the current endpoint deployment and providing it to the JAXBRIContextFactory.
Now, as previosly mentioned, enabling JAXB Introductions is just a matter of giving the customization map a way to JAXBContext creation, it doesn't matter which webservice stack is used.
As a prove of that, I've recently provided seamless integration with JBossWS-CXF. Basically CXF allows users to specify a Configurer (org.apache.cxf.configuration.Configurer) that is called whenever a configurable CXF bean is setup. JBossWS-CXF has a JBossWSCXFConfigurer (org.jboss.wsf.stack.cxf.client.configuration.JBossWSCXFConfigurer) users can leverage to configure the bus for use with JBossWS, in this case to simply plug-in binding customizations:
package org.jboss.wsf.spi.binding;
...
public class JAXBBindingCustomization extends HashMap
{
}
BindingCustomization jaxbCustomizations = new JAXBBindingCustomization();
BindingCustomizationFactory.populateBindingCustomization(getResourceURL("jaxws/cxf/jaxbintros/META-INF/jaxb-intros.xml").openStream(), jaxbCustomizations);
bus = BusFactory.getThreadDefaultBus();
originalConfigurer = bus.getExtension(Configurer.class);
JBossWSCXFConfigurer configurer = new JBossWSCXFConfigurer(originalConfigurer);
configurer.setBindingCustomization(jaxbCustomizations);
bus.setExtension(configurer, Configurer.class);
//use the bus to create the service and then invoke the endpoint
On server side the same configurer is automatically installed and it uses the binding customizations coming from the optional jaxb.intro.xml file in the deployment.
Please not that while this all comes out of the box with JBossWS-CXF 3.2.1, with "plain" Apache CXF 2.2.4 you can manually use a Configurer like the one mentioned above and/or directly provide the customization properties in the JAXBDatabinding element of the CXF Spring bus configuration file ;-)
[1] http://weblogs.java.net/blog/kohsuke/archive/2007/07/binding_3rd_par.html
Thursday, October 1, 2009
JBossWS performances: improvements coming in 3.2.1 and stacks comparison
I've recently added a few classes for running some performance tests to jbossws-framework.
Performance testing and tuning are really complex topics; generally speaking I agree with those saying that you need to establish your goals/reasons before starting dealing with optimizations, profiling, etc. My ultimate goal this time was to look for potential bottlenecks badly affecting performances, both in the JBossWS-Native stack and in the whole JBossWS framework (considering we plug CXF and Metro stacks too into JBoss AS). Needless to say, I also wanted to get a better idea of how the supported ws stack integrations compare in terms of performances... ;-)
For these reasons I basically chose a black box approach and tested the whole ws stack performing concurrent invocations to a given endpoint. Tests have been performed in two different scenarios, with the client and server hosts either living on the same LAN or on the Internet, to cope with the different latency (which you really need to consider when looking for bottlenecks / bugs in this field).
I've actually been able to work on improvements and a couple of bug fixes, which basically boosted all stacks performances, especially the Native one. Fixes are currently on trunk and already ported to the JBoss EAP branches, the next JBossWS community version including them will be the 3.2.1.GA. The 3.2.1 release is currently scheduled for the end of October.
I guess you're now looking for the numbers... Unfortunately I'm not going to write any of them here, as the results are of course influenced by the testing conditions and my goals were not to stress test all the stack in multiple conditions and come to a thorough picture of the JBossWS performances.
Anyway I do have some general considerations coming out of my tests and you can read them below. After all the tests available to the public and you are free to run them in your environment (and perhaps add more of them ;-) )
As of today (fixes will be available in 3.2.1.GA):
Performance testing and tuning are really complex topics; generally speaking I agree with those saying that you need to establish your goals/reasons before starting dealing with optimizations, profiling, etc. My ultimate goal this time was to look for potential bottlenecks badly affecting performances, both in the JBossWS-Native stack and in the whole JBossWS framework (considering we plug CXF and Metro stacks too into JBoss AS). Needless to say, I also wanted to get a better idea of how the supported ws stack integrations compare in terms of performances... ;-)
For these reasons I basically chose a black box approach and tested the whole ws stack performing concurrent invocations to a given endpoint. Tests have been performed in two different scenarios, with the client and server hosts either living on the same LAN or on the Internet, to cope with the different latency (which you really need to consider when looking for bottlenecks / bugs in this field).
I've actually been able to work on improvements and a couple of bug fixes, which basically boosted all stacks performances, especially the Native one. Fixes are currently on trunk and already ported to the JBoss EAP branches, the next JBossWS community version including them will be the 3.2.1.GA. The 3.2.1 release is currently scheduled for the end of October.
I guess you're now looking for the numbers... Unfortunately I'm not going to write any of them here, as the results are of course influenced by the testing conditions and my goals were not to stress test all the stack in multiple conditions and come to a thorough picture of the JBossWS performances.
Anyway I do have some general considerations coming out of my tests and you can read them below. After all the tests available to the public and you are free to run them in your environment (and perhaps add more of them ;-) )
As of today (fixes will be available in 3.2.1.GA):
- the supported stacks comes with different default logging configurations. More in details, Native is much more verbose than CXF and Metro, both client and server side. You should really want to set org.jboss.ws Log4j category (and org.jboss.wsf too) at INFO level;
- in the medium / high latency scenario, the three stacks show comparable performances, with CXF actually giving the best results, Metro being in the middle and Native performing slightly worse than the others;
- in the low latency scenario (LAN tests), CXF and Metro stacks run almost the same and are faster than Native stack (the gap here is bigger than in the medium/high latency scenario though).
Friday, August 28, 2009
JBossWS 3.2.0.GA is available
As you can see at the renewed JBossWS home page, JBossWS 3.2.0.GA has just been released. This release includes the Native stack as well as the Apache CXF based stack and the Glassfish Metro based one. The supported target containers are JBoss AS 5.0.0.GA, JBoss AS 5.0.1.GA and JBoss AS 5.1.0.GA.
It's been a hot summer here and I'm not referring to the weather only... the work for JBoss EAP 5 (which of course includes webservice features provided by JBossWS) is proceeding full steam ahead, but at the same time Richard and me are taking care of the community webservice project as always.
While featuring some major refactoring on the integration layer with the application server -which should make our future development easier-, JBossWS 3.2.0.GA provides many interesting new features.
On the Native stack side, the HTTP transport layer -which has historically been based on JBoss Remoting- has been rewritten to leverage Netty. This has given us chances for performing some client side improvements, like an easier configuration for the chunk size (in chunked-encoding mode) and finally making one-way invocations non-blocking (whenever that's allowed by the specs). Further improvements should probably come soon thanks to this move.
The Metro stack does not come with a lot of news, but the release was probably awaited as there's been no 3.1.2 release for JBossWS-Metro.
Much more to say on the CXF stack side instead ;-) First of all, I'd like to thank the Apache CXF developers for allowing me to get aboard the project, I'm going to do my best for the sake of both Apache CXF and the integration in JBossWS.
For now, my committership has allowed for fast integration of fixes to the CXF codebase, resulting in a really good synchronization of CXF and JBossWS-CXF releases.
As a matter of fact, some of the interesting features coming in 3.2.0.GA are about the soap:address rewrite. After my contribution of a couple of missing features to the Apache CXF codebase [*], JBossWS has now the same behaviour when using the Native stack and the CXF stack.
The endpoint address in the wsdl as well as the URL shown in the JBossWS deployed services console can be modified according to:
We have plans for further contribution to Apache CXF in the future, stay tuned.
One of the aims of the JBoss Web Service Framework is to add features on top of what the supported stacks already provides. Thanks to a contribution from Andrew Dinn, a colleague involved in the JBoss Transactions project, JBossWS 3.2.0.GA includes a common API for using the JAX-WSA (JSR-261) WS-Addressing functionalities in a stack independent way. The (different) implementations currently supported under the hood are those of Native and CXF stacks.
Further information available in the release notes. That's enough for now, download JBossWS-3.2.0.GA and give it a try! :-)
[*] CXF-1996, CXF-2364
It's been a hot summer here and I'm not referring to the weather only... the work for JBoss EAP 5 (which of course includes webservice features provided by JBossWS) is proceeding full steam ahead, but at the same time Richard and me are taking care of the community webservice project as always.
While featuring some major refactoring on the integration layer with the application server -which should make our future development easier-, JBossWS 3.2.0.GA provides many interesting new features.
On the Native stack side, the HTTP transport layer -which has historically been based on JBoss Remoting- has been rewritten to leverage Netty. This has given us chances for performing some client side improvements, like an easier configuration for the chunk size (in chunked-encoding mode) and finally making one-way invocations non-blocking (whenever that's allowed by the specs). Further improvements should probably come soon thanks to this move.
The Metro stack does not come with a lot of news, but the release was probably awaited as there's been no 3.1.2 release for JBossWS-Metro.
Much more to say on the CXF stack side instead ;-) First of all, I'd like to thank the Apache CXF developers for allowing me to get aboard the project, I'm going to do my best for the sake of both Apache CXF and the integration in JBossWS.
For now, my committership has allowed for fast integration of fixes to the CXF codebase, resulting in a really good synchronization of CXF and JBossWS-CXF releases.
As a matter of fact, some of the interesting features coming in 3.2.0.GA are about the soap:address rewrite. After my contribution of a couple of missing features to the Apache CXF codebase [*], JBossWS has now the same behaviour when using the Native stack and the CXF stack.
The endpoint address in the wsdl as well as the URL shown in the JBossWS deployed services console can be modified according to:
- a server configuration allowing for rewrite of host and port of both valid and invalid user provided URLs;
- the host/port used by the client when actually hitting an endpoint deployed on an application service bound to multiple network interfaces (or simply in the multiple virtual host case)
We have plans for further contribution to Apache CXF in the future, stay tuned.
One of the aims of the JBoss Web Service Framework is to add features on top of what the supported stacks already provides. Thanks to a contribution from Andrew Dinn, a colleague involved in the JBoss Transactions project, JBossWS 3.2.0.GA includes a common API for using the JAX-WSA (JSR-261) WS-Addressing functionalities in a stack independent way. The (different) implementations currently supported under the hood are those of Native and CXF stacks.
Further information available in the release notes. That's enough for now, download JBossWS-3.2.0.GA and give it a try! :-)
[*] CXF-1996, CXF-2364
Monday, June 1, 2009
JavaEE 5 CTS: JBossWS-CXF finally gives great results!
As you already know, the JBossWS stack integration layer work started back in 2007. We've worked on enabling features and functionalities both using the JBossWS native stack and the integrated stacks (Apache CXF and Sun Metro).
We've been using and continuously enriching a common testsuite for proving/showing the working functionalities with all stacks.
JBoss AS 5 is JavaEE5 certified with JBossWS-Native stack; on the contrary we've been quite far from passing the official certification testsuite with the third-party integrated stacks (we actually did not care about that for quite some time). At least till the beginning of 2009...
When the collaboration with Apache CXF became more intense, we've been able to successfully identify existing issues and push their fixes to releases. Apache CXF is of course already JAX-WS certified, but our (JBoss) aim is to pass the JavaEE certification testsuite with JBossWS-CXF on top of the application server and that's a different (and bigger) testsuite than the JAX-WS standalone one.
Anyway, finally, last week we've passed 100% of the tests in the jaxws, jws, saaj and jaxr module of the JavaEE 5 CTS TCK.
This might sound a bit too technical, so let's read it as follows: JBoss AS 5.1.0.GA now supports all [*] the WS functionalities included in the Java EE 5 also using JBossWS-CXF integrated stack, based on Apache CXF.
This is a great achievement for us; I'd like to thank the current JBossWS team (especially Richard) and the former one (Thomas and Heiko) for their contribution, as well as Daniel and the other Apache CXF guys for the collaboration.
Willing to try out Apache CXF stack integration then? The JBossWS-CXF 3.1.2.GA has just been released!
Get it and enjoy :-)
[*] except for JAX-RPC functionalities, which are not part of Apache CXF.
We've been using and continuously enriching a common testsuite for proving/showing the working functionalities with all stacks.
JBoss AS 5 is JavaEE5 certified with JBossWS-Native stack; on the contrary we've been quite far from passing the official certification testsuite with the third-party integrated stacks (we actually did not care about that for quite some time). At least till the beginning of 2009...
When the collaboration with Apache CXF became more intense, we've been able to successfully identify existing issues and push their fixes to releases. Apache CXF is of course already JAX-WS certified, but our (JBoss) aim is to pass the JavaEE certification testsuite with JBossWS-CXF on top of the application server and that's a different (and bigger) testsuite than the JAX-WS standalone one.
Anyway, finally, last week we've passed 100% of the tests in the jaxws, jws, saaj and jaxr module of the JavaEE 5 CTS TCK.
This might sound a bit too technical, so let's read it as follows: JBoss AS 5.1.0.GA now supports all [*] the WS functionalities included in the Java EE 5 also using JBossWS-CXF integrated stack, based on Apache CXF.
This is a great achievement for us; I'd like to thank the current JBossWS team (especially Richard) and the former one (Thomas and Heiko) for their contribution, as well as Daniel and the other Apache CXF guys for the collaboration.
Willing to try out Apache CXF stack integration then? The JBossWS-CXF 3.1.2.GA has just been released!
Get it and enjoy :-)
[*] except for JAX-RPC functionalities, which are not part of Apache CXF.
Friday, May 8, 2009
JBossWS-Native 3.1.2.GA released
I've just released JBossWS-Native 3.1.2GA. This is a minor bug fix release for the Native stack only, required to fix a bunch of issues for the upcoming JBoss AS 5.1.0.GA. The most relevant one to end-users is probably the @EJB annotation support in WS components too.
Changes related to the Apache CXF and Sun Metro stacks will go the next 3.2.0 version.
Changes related to the Apache CXF and Sun Metro stacks will go the next 3.2.0 version.
Thursday, April 23, 2009
Java Application Server Day 2009
JBoss / Red Hat is joining the Java Application Server Day 2009 in Genoa (Italy) on May, 21st. That's an interesting event organized by the Genoa JUG; the topic is the state of the art and the future of Java application servers.
I'll be there on behalf of JBoss, presenting recent changes in JBoss AS 5. Stay tuned for further updates.
I'll be there on behalf of JBoss, presenting recent changes in JBoss AS 5. Stay tuned for further updates.
Wednesday, April 15, 2009
JBossWS 3.1.1.GA released
This time we had a fast development cycle... we've just released JBossWS 3.1.1.GA. The main reason for this is that we wanted to have this release included in the upcoming JBoss AS 5.1.0.CR1, so we fixed the release date a bit earlier.
JBossWS 3.1.1.GA is basically a bug fix release, especially for the CXF and Native stacks. The most important changes are:
The supported target containers for this release are JBoss 4.2.3.GA, JBoss 5.0.0.GA and JBoss 5.0.1.GA.
The binaries and sources, including the samples can be obtained here.
Installation instructions, quick start and user guides are available on the JBossWS mediawiki:
And now... let's start working on JBossWS 3.2.0!
JBossWS 3.1.1.GA is basically a bug fix release, especially for the CXF and Native stacks. The most important changes are:
- Resource injection in jaxws endpoints and handlers
- Improved CXF integration and upgrade to Apache CXF 2.2
- wsrunclient script for JBossWS-CXF and JBossWS-Metro
- Some FastInfoset and MTOM interoperabily fixes and testing
- Bug fixes
The supported target containers for this release are JBoss 4.2.3.GA, JBoss 5.0.0.GA and JBoss 5.0.1.GA.
The binaries and sources, including the samples can be obtained here.
Installation instructions, quick start and user guides are available on the JBossWS mediawiki:
And now... let's start working on JBossWS 3.2.0!
Thursday, March 26, 2009
JBoss to provide support for Apache CXF
It's been one year since the JBossWS 3.0 release. That marked the JBoss Web Service Framework (WSF) birth and allowed Apache CXF (XFire at that time) and Glassfish Metro webservice stacks to run on the JBoss Application Server.
Since each stack (including the JBossWS Native one) comes with its own specific functional feature set and performance characteristics, the WSF aim is to allow users to deploy the stack that best suits their needs.
While this was indeed possible starting from JBossWS 3.0.0.GA, in the latest months we've been working hard on the integration layer to enlarge the set of features available and tested cross-stack, with the target being making the three WS stacks offer enterprise ready.
This implies hard testing, running the J2EE certification testsuite with all stacks and getting in touch with the Apache and Glassfish community and developers to get and provide fixes for things not working as expected with every stack.
Recently, the collaboration with Apache CXF has become more intense: we've been able to work together on many issues and frequent integration of new CXF releases (which means new features available).
For this reason, yesterday Red Hat officially announced we’ll add full production and developer support for Apache CXF (through JBossWS-CXF) as a core component of our JBoss Enterprise Platforms.
The involvement with Apache CXF will definitely both foster the CXF project and make the JBoss enterprise offer stronger in the WS field.
Since each stack (including the JBossWS Native one) comes with its own specific functional feature set and performance characteristics, the WSF aim is to allow users to deploy the stack that best suits their needs.
While this was indeed possible starting from JBossWS 3.0.0.GA, in the latest months we've been working hard on the integration layer to enlarge the set of features available and tested cross-stack, with the target being making the three WS stacks offer enterprise ready.
This implies hard testing, running the J2EE certification testsuite with all stacks and getting in touch with the Apache and Glassfish community and developers to get and provide fixes for things not working as expected with every stack.
Recently, the collaboration with Apache CXF has become more intense: we've been able to work together on many issues and frequent integration of new CXF releases (which means new features available).
For this reason, yesterday Red Hat officially announced we’ll add full production and developer support for Apache CXF (through JBossWS-CXF) as a core component of our JBoss Enterprise Platforms.
The involvement with Apache CXF will definitely both foster the CXF project and make the JBoss enterprise offer stronger in the WS field.
Friday, March 13, 2009
JBossWS-CXF and WCF interoperability
Bryan Kearney is performing interesting interoperability tests with Microsoft WCF using our JBossWS-CXF integration stack... and the results look good :-)
Read the details here. Thanks Bryan!
Read the details here. Thanks Bryan!
Tuesday, March 3, 2009
JBossWS 3.1.0.GA released
The first post on this blog is to announce the release of JBossWS 3.1.0.GA.
For those who are not familiar to the project, starting from major release 3, JBossWS provides an integration layer allowing users to leverage different webservice stacks (JBossWS-Native, Apache CXF and Metro) on JBossAS.
Probably the most important achievement in JBossWS 3.1.0.GA is the improvement in terms of JAX-WS 2.1 support, as that's now available cross-stack:
Besides the JAX-WS 2.1 support, JBossWS 3.1.0.GA has further new features, improvements and bug fixes in each stack, please refer to the release notes:
The supported target containers for this release are JBoss 4.2.3.GA, JBoss 5.0.0.GA and JBoss 5.0.1.GA.
The binaries and sources, including the samples can be obtained here.
Installation instructions, quick start and user guides are available on the JBossWS mediawiki:
For those who are not familiar to the project, starting from major release 3, JBossWS provides an integration layer allowing users to leverage different webservice stacks (JBossWS-Native, Apache CXF and Metro) on JBossAS.
Probably the most important achievement in JBossWS 3.1.0.GA is the improvement in terms of JAX-WS 2.1 support, as that's now available cross-stack:
- the 2.1 implementation has been completed in JBossWS-Native (CXF and Metro already support JAX-WS 2.1);
- the wsconsume tool now supports target 2.1;
- WebServiceContext now supports JAX-WS 2.1 specific methods with all stacks.
Besides the JAX-WS 2.1 support, JBossWS 3.1.0.GA has further new features, improvements and bug fixes in each stack, please refer to the release notes:
The supported target containers for this release are JBoss 4.2.3.GA, JBoss 5.0.0.GA and JBoss 5.0.1.GA.
The binaries and sources, including the samples can be obtained here.
Installation instructions, quick start and user guides are available on the JBossWS mediawiki:
Subscribe to:
Posts (Atom)