JBossWS

Christmas releases!

2011-12-22T06:53:00.000-08:00

It's Xmas time and here we are with many great releases!

Few hours ago, JBoss Application Server 7.1.0 CR1 has been released: it comes with over 370 jira resolved, numerous management and clustering improvements and the EE6 Full Profile support is feature complete.

Speaking of web services, one of the AS 7.1.0.CR1 updated components is JBossWS 4.0.0.GA, which has been released yesterday and is available for download starting from today.

The first final version of the JBossWS 4 series solves few minor issues over the previously announced and described CR1 version. Have a look at the release notes and documentation for further details!

Finally, I've also released the 1.1.0.GA version of the JBoss JAX-WS Maven Plugin, which basically introduces support for the new JBossWS 4 stacks and fixes an important bug for those leveraging the Maven War Plugin too in their maven project. The artifacts are available as usual on the maven repository.

Definitely a lot of stuff to play with during the Christmas vacations ;-) Enjoy!

Web Services Resource Access specifications are recommendations

2011-12-14T00:48:00.000-08:00

After years of work, the Web Services Resource Access specifications have finally been promoted to W3C recommendations! The new WS-RA standards are:

I'd like to congratulate again the working group on this major achievement and thank Red Hat (as one of the members participating the group) for having allowed me to take part in the group and join the discussions that led to the standards definition.

Time to try JBossWS 4.0.0.CR1 !

2011-11-22T03:00:00.000-08:00

JBossWS 4.0.0.CR1 has been released at the end of last week and is currently available for download in binary and source distributions. The release covers both Native and Apache CXF integration stacks and comes with a huge number of improvements, new features and fixes compared to the previous 3.4.1 final release. Have a look at the news page and the release notes [1][2] for further details.

The release is mainly meant for JBoss Application Server 7 and has been tested against AS 7.0.0, 7.0.1, 7.0.2 and the current 7.1.0 snapshot. JBoss AS 6 support is still included, but might be removed by the time JBossWS 4.0.0 goes final (hopefully soon).

This is really the right time for giving JBossWS 4 a try before it goes final! Any feedback is welcome and might turn into last minute fixes for major issues, if any ;-)

Meanwhile we're working on passing webservices-related tests of the full JavaEE certification testsuite using JBoss AS 7; JBossWS 4.0.0 final is going to be shipped in the final AS 7.1.0 release.

Upcoming JBoss AS 7 event in Lugano (JUG)

2011-11-12T03:36:00.000-08:00

Java User Group Lugano is organizing its 20th meeting at USI on November, 30th 2011. The event will be completely dedicated to JBoss Application Server 7.
I've been proposed to present there and I'm going to have two sessions, introducing JBoss AS 7 and providing some insights on its webservices subsystem.

More details available at http://www.juglugano.ch/events/meeting_20.html .

JBossWS towards JBoss AS 7.1.0

2011-10-11T01:13:00.000-07:00

It's not hard to guess, the JBossWS team is currently working on the webservices features for the future JBoss Application Server 7.1.0.

With one of the major focuses being on the webservices part of the full JavaEE 6 certification requirements, we're currently restoring the still missing pieces in the JBossWS - JBoss AS7 integration.
Yesterday's betas of both Native and Apache CXF integration stacks mark another milestone in the afore mentioned process and bring back @WebServiceRef support and some JAXRPC functionalities on AS7.

Have a look at the release notes [1][2] for the more details and feel free to give the betas a try, feedback is welcome as usual!

[1] JBossWS-CXF 4.0.0.Beta5 release notes
[2] JBossWS-Native 4.0.0.Beta2 release notes

Latest Web Services presentations

2011-09-20T07:36:00.000-07:00

It's been a week of JBoss / Red Hat web services presentations in the North Italy area.

As mentioned in the previous blog entry, Red Hat has been sponsoring ECOWS 2011, this year's edition of the European Conference on Web Services. I've taken a session in the industry track; the audience seems to have appreciated the Red Hat involvement in the web services area, especially the contribution with the standardization bodies. The slides for my presentation are available online.

Today I've joined the first meeting of the Milan JBoss User Group and presented on the webservices subsystem of JBoss Application Server 7. Take a look at slides and get involved with the JBUG, interesting meetings are being planned for the future.

JBoss at ECOWS 2011

2011-09-07T02:30:00.000-07:00

The European Conference on Web Services (ECOWS) is the premier conference series for both researchers and practitioners to discuss the latest advances in the state of the art and practices of Web services and to foster cross-European collaboration and exchange. The 9th edition of the ECOWS series will be held on September 14-16 at the University of Lugano, Switzerland.

JBoss / Red Hat is supporting ECOWS 2011 as silver sponsor.
I'll be attending the conference and presenting on the JBoss involvement in the webservice area.
The agenda for the event covers multiple tracks, including both research and industry interesting talks.

Apache CXF PMC

2011-08-31T09:11:00.000-07:00

Just a quick note to say that I've recently been offered to join the Apache CXF PMC and I accepted.
A project management committee (PMC) is a committee of the Apache Software Foundation charged with responsibility for a top level project. The PMC is the vehicle through which decision making power and responsibility for oversight is devolved to developers.
I'm of course proud of taking part to Apache CXF decisions and will do my best. Thanks to Dan and the other members for the trust.

Publishing WS endpoints through AS7 services

2011-07-28T07:17:00.000-07:00

JBoss AS 7.0.0 Final has been released and is available to the community, so we're currently working on the 7.1.0 version of the application server, which is coming with many webservices functionalities additions. While most of them will be aim at covering JCP specification requirements (mainly JSR-109 and JSR-101), some management and general use new features are also coming soon.

Recently it's been the turn of JBoss XTS for being integrated in JBoss AS 7.
XTS provides transaction support for web services, implementing WS-AtomicTransaction and WS-BusinessActivity specifications. In order for providing such functionalities, XTS needs to start a given number of WS endpoints to take part into the transactions management. According to the JBoss AS 7 design, this is to be achieved using JBoss AS 7 services.

Publishing a WS endpoints on JBoss AS7 was previously directly bound to the processing of a given deployment unit having webservices endpoint implementation classes in it. So the required steps for achieving our goal were:

abstracting the endpoint publish process away from the deployment processing; that was possible thanks to the already existing convenient split of JBossWS endpoint publish logic into deployment aspect blocks, completely hidden behind the JBossWS SPI (iow the JBossWS internals do not directly rely on JBoss AS classes)

defining a simple API for publishing POJO endpoints given the endpoint class names, classloader and publish address

providing a JBoss AS7 implementation for such an API

serving that through an AS7 service

We ended up with a solution that might appear pretty much equivalent to the JAX-WS Endpoint.publish(..) API at first sight, except it

allows for publishing an endpoint to the HTTP server of the currently running JBoss AS 7 instance

is embedded into a JBoss AS 7 service, allowing efficient, concurrent and perhaps even lazy/on-demand start/stop of endpoints as part of AS7 operations (for instance, the boot)

The XTS integration easily leveraged the new JBossWS feature, installing and setting up dependencies on multiple WS endpoint publisher services.

You can have a look at this by checking out the latest JBoss AS 7 master from github and starting the standalone-xts.xml profile. During the boot, XTS subsystem and its 14 required WS endpoints are concurrently started in something like 2.5s on a my mid-level laptop ;-)
If you're writing your own AS7 component and need publishing a WS POJO endpoints as part of that, consider giving this new feature a try.

JBoss AS 7 webservices features

2011-07-07T06:06:00.000-07:00

JBoss Application Server 7 is highly configurable and allows for running different profiles, including one or more subsystems. The optional webservices subsystem is based on JBossWS-CXF 4.x.

JBoss AS7 users can turn on full webservices capabilities by enabling the org.jboss.as.webservices module extension and the webservices subsystem in their standalone.xml / domain.xml descriptors:


<server name="foo" xmlns="urn:jboss:domain:1.0">
    <extensions>
        [...]
        <extension module="org.jboss.as.webservices"/>
        [...]
    </extensions>
    [...]
    <profile>
        [...]
        <subsystem xmlns="urn:jboss:domain:webservices:1.0" xmlns:javaee="http://java.sun.com/xml/ns/javaee" xmlns:jaxwsconfig="urn:jboss:jbossws-jaxws-config:4.0">
            <wsdl-host>localhost</wsdl-host>
            <modify-wsdl-address>true</modify-wsdl-address>
        </subsystem>
        [...]
    </profile>
    [...]
</server>

On JBoss AS 7 Final, the webservices extension / subsystem is already enabled and available in a separate domain configuration, domain-preview.xml / standalone-preview.xml. Users can run a given server configuration as follows:


./bin/standalone.sh -server-config standalone-preview.xml

Once the webservices capabilities are enabled, basic JAXWS features as well as advanced WS-* functionalities are available.
The JBossWS 4.x documentation covers all the details, including full JAXWS user guide , JAXWS tooling and quick start sections.

Moreover, examples are also provided on advanced topics:

WS-Addressing usage

WS-Security / WS-Security Policy usage

WS-Reliable Messaging / WS-Reliable Messagin policy usage

SOAP-over-JMS usage

JBossWS @ JBUG München

2011-05-11T06:06:00.000-07:00

The JBossWS project is being presented through a talk at JBUG Munich next week (Monday, May 16th).
The presentation is going to be focussed on the recent JBossWS - Apache CXF integration efforts as well as on the future of the project.
More details on the JBUG Munich website.

JBossWS 4.0.0.Beta1 is out!

2011-05-11T03:11:00.000-07:00

After months of active development, the first Beta release of JBossWS 4 is finally out!
The main target of JBossWS 4 is in supporting the upcoming JBoss Application Server 7 and contributing to the innovation that's coming with it.
For instance, AS7 comes with a new modular classloading and requires proper isolation between user classes and JBoss implementation details. As a consequence we've gone through a complete review of ws integration classloading details, re-defined the JBossWS public API and really cleaned up a bunch of things all over the WS components. Full documentation is coming with the next beta releases, however a FAQ for WS AS7 usage is already available.

The JBossWS-CXF stack was also moved to including the recent Apache CXF 2.4 release. The integration has been completely reviewed as CXF 2.4 is less bound to Spring, hence allowing JBossWS to avoid most of the tricks that were in place before to support some "non-Spring" scenarios.

Apache CXF 2.4 also includes many new features and improvements in the WS-Security area. Adding this to some additional integration work on @EndpointConfig annotation, we're finally able to support a completely "Spring-free" WS-SecurityPolicy scenario, with signature / encryption / username token based authentication (sources, resources).

Finally, mainly because of the AS 7 improvements, in terms of performance handling ws invocations, the current JBoss AS 7 + JBossWS 4 integration is up to 35% faster then JBoss AS 6 Final + JBossWS 3.4.1.GA

The Beta1 artifacts are available on the JBoss Maven repository, sources can be retrieved from SVN repository as usual.

While JBoss AS 7 is meant to be the primary (and probably only, once we reach final stage) target of JBossWS 4.x, at the moment JBoss AS 6 Final is also supported as target container.
Please note that given the AS7 is currently in very active development phase, JBossWS 4.0.0.Beta1 is fully tested against its current (today, May 11) version only. As soon as JBoss AS 7 will reach CR level, we'll add that release to the released supported target containers list of JBossWS 4.

Please have a look at the first Beta of JBossWS 4, feedback is always welcome!

Stressing WS features of JBoss AS 6 Final

2011-01-07T06:05:00.000-08:00

JBoss AS 6.0.0.Final has been released few days ago. It passes the JavaEE 6 Web Profile certification testsuite and that's probably one the most notable achievements of this release. You should really read Dimitris blog on this topic, which gives a wide view of what's new with AS 6, especially if compared to the previous final version, JBoss AS 5.1.

An interesting discussion is currently on on JBoss forum regarding JavaEE 6 Web Profile vs Full Profile... while it's important for users/customer to provide feedback, please note that in terms of web services features, JBossWS-CXF 3.4.1.GA included in JBoss AS 6 Final is already passing the relevant tck modules of the full profile certification.
Moreover, you most probably already know that Apache CXF 2.3.1, which is consumed by JBossWS-CXF 3.4.1, is JAX-WS 2.2 compliant.

So, despite having the EE6 Web Profile stamp only on it, JBoss AS 6 really has all you need for safely leveraging the latest revisions of webservices technologies (JSR-224, JSR-109, etc.).
Moreover, in addition to the standard compliance above, the switch from the Native stack to the Apache CXF based one brings improved WS-* support (try out the WS-Policy support with security, addressing, reliable messaging, etc.) and better performances.

... just the WS contribution to JBoss AS 6 Final actually being more than a certified Java EE6 Web Profile implementation ...

Ready for JBoss AS 6... and then?

2010-12-17T01:31:00.000-08:00

Community members watching recent JBossWS subversion repository activity might have noticed that we've been having two open 3.4.x branches for quite some time. What's the meaning of that?

From one of the branches, JBossWS 3.4.0 was released just last week and had many new features, available for already released AS containers (including AS 6 CR1 and AS 5.1.0.GA). That came with JAXWS 2.2, JSR 109 v1.3, etc. - you can read all the details on my previous blog post.

On the other side, the efforts above on webservices technologies are of course meant for eventually satisfying the general JBoss Application Server EE6 certification needs. Because of that, a lot of work is being done on JBoss AS 6 trunk. In particular we had to review part of the internal webservice integration layer with the AS, to accommodate other components requirements and changes. This all happened on the branches for JBossWS 3.4.1, which has finally been released on yesterday and is ready for being the final ws stack of JBoss Application Server 6.
So 3.4.1 basically introduces just few minor additions over 3.4.0 for the end users (see the release notes [1][2]), but includes some internal changes that are really relevant for AS 6. Besides that, we verified the testsuite with IPv6 addresses ;-)
The only supported target container for 3.4.1 is the current JBoss AS 6.0.0-SNAPSHOT, which (hopefully) will soon turn into AS 6 final.

The future: JBossWS 4 and JBoss AS 7

So, what are we going to work on once we're back from X-mas time? ;-)
You might have heard on the November 17th JBoss Community Asylum that AS 7 development is really on... well, it's time for the WS team to focus on it.
Major new features and changes are coming with JBossWS 4... take a look at JIRA, the dev forum and feel free to comment/participate :-)

JBossWS 3.4.0 has landed!

2010-12-09T12:49:00.000-08:00

It's been almost two months after 3.4.0.CR1 has been released... but finally JBossWS 3.4.0 is out! I'm happy to announce that both JBossWS-CXF and JBossWS-Native final versions have been released and are available for download. The supported target containers are JBoss AS 5.0.1, 5.1.0 and 6.0.0.CR1.

This release is the result of the hard work since the beginning of 2010 on supporting the JAXWS 2.2 and JSR 109 v.1.3 changes required for JavaEE 6. Part of the work actually came through collaboration with the Apache CXF community; as a matter of fact the Apache CXF 2.3 series (included in JBossWS-CXF 3.4.0) features JAXWS 2.2 compliant functionalities.

JBossWS-CXF 3.4.0 is meant for being the stack providing webservices functionalities to JBoss AS 6, which in turns aims at JavaEE 6 compliance. We're going to cut another minor release for dealing with last minute integration issues just before AS goes final, but from a feature point of view 3.4.0 already has all you need for JavaEE 6 webservices development.

Besides that, JBossWS-CXF 3.4.0 comes with all the new features and many bug fixes of Apache CXF 2.3.0 and 2.3.1, part of which were directly contributed by our team members.
Take a look at the release notes for the full list of improvements.
Of course, the Maven artifacts for all the released components are also available on the JBoss public repository; please give 3.4.0 a try!

JBossWS 3.4.0.CR1 is out!

2010-10-13T05:21:00.000-07:00

I'm happy to announce that the first candidate release of JBossWS 3.4.0 has just been released, including JBossWS-CXF (release notes) and JBossWS-Native (release notes) stacks.

This is a major step forward in the direction of JavaEE 6 compliance. While the current release supports JAXWS 2.2 (JSR 224) and most of the additions in JSR 109 v.1.3, we're targetting passing all the webservice related modules of JavaEE 6 CTS TCK with the final 3.4.0 release.

JBossWS-CXF 3.4.0.CR1 includes the recently released Apache CXF 2.3.0, which in turn comes with multiple major new features (as well as bug fixes).

Finally, the Maven plugin for the JBossWS JAXWS tools (wsconsume / wsprovide) has also been released in a new 1.0.1.GA version, which supports the SPI of the latest available 3.4.0.CR1 stacks and adds a fork mode option for effectively using the tools with JAXWS 2.2.

The Maven artifacts for all the released components are available on the JBoss public repository; please give them a try!

com.sun.net.httpserver transport using JAXWS 2.2 HTTP SPI

2010-08-26T05:35:00.000-07:00

In the previous post I've written about Apache CXF and JBossWS-CXF implementation of JAXWS 2.2 HTTP SPI. From a container point of view, a bit of additional coding is required for making an existing http server compliant too.

Similarly to what Jitendra Kotamraju did for Grizzly, I've just created a small project for using the JDK6 httpserver with this HTTP SPI, basically allowing any JAXWS 2.2 stack implementation to be used on top of it (not just the JAXWS RI as mentioned here). The project only runtime dependency is the JAXWS 2.2 API, so it's completely vendor agnostic (the project testsuite uses Apache CXF just for the sake of testing with a JAXWS 2.2 impl).
So, the following is now possible using any JAXWS 2.2 compliant implementation:


import com.sun.net.httpserver.HttpServer;
import javax.xml.ws.spi.http.HttpContext;
import org.jboss.ws.httpserver_httpspi.

HttpServerContextFactory;

..

HttpServer server = HttpServer.create(new InetSocketAddress(8080), 0);
HttpContext context = HttpServerContextFactory.createHttpContext(server, "/ctx", "/echo");

Endpoint endpoint = Endpoint.create(new EndpointBean());
endpoint.publish(context); // Use httpserver context for publishing
server.start();
//invoke endpoint
endpoint.stop();
server.stop(0);

The binaries for the project are on JBoss' Maven repository.

Implementing JAXWS 2.2 HTTP SPI on Apache CXF

2010-08-26T04:24:00.000-07:00

JAXWS 2.2 specification introduced a compact HTTP SPI; that defines the minimal set of required information a http server container and a JAXWS stack implementation need to share for allowing an endpoint deployment and invocation.

Previous JAXWS specification already included API for simplified endpoint deployment in a JSE environment:


Endpoint endpoint = Endpoint.create(new EndpointBean());
endpoint.publish("http://localhost:8080/jaxws-endpoint1");
//invoke endpoint...
endpoint.stop();

.. as well as a Endpoint publish(Object obj) method for allowing the JAXWS RI (only) to deploy an endpoint on top of JDK6 httpserver. However, this was not portable and different JAXWS implementation could actually support different and vendor specific http context implementations passed in that object instance in publish(Object obj). For instance, Apache CXF - despite being JAXWS 2.1 compliant - didn't have a specific implementation for the publish(Object obj) method, but just of the publish(String s) one.

With JAXWS 2.2 the specification added a Endpoint publish(HttpContext ctx) method and the other classes/interfaces defining the HTTP SPI together with the HttpContext. A JAXWS 2.2 implementation is supposed to be able to deploy an endpoint on top of any http container that also supports the JAXWS 2.2 HTTP SPI.

Thanks to a joint work of Daniel Kulp and me, the current trunk for Apache CXF now supports this JAXWS 2.2 HTTP SPI. This means you'll soon be able to perform a quick deployment and test of your endpoint using Apache CXF (or JBossWS-CXF, of course ;-)) on top of the JAXWS 2.2 compatible http server you prefer.

As a proof of that, I've added a testcase leveraging Jitendra Kotamraju's Grizzly transport bridge project for deploying on top of Grizzly http server, while still having the whole ws invocation being handled by CXF:


import javax.xml.ws.spi.http.HttpContext;
import com.sun.grizzly.http.embed.GrizzlyWebServer;
import org.jvnet.jax_ws_commons.transport.grizzly_httpspi.GrizzlyHttpContextFactory;

..

GrizzlyWebServer server = new GrizzlyWebServer(8080);
HttpContext context = GrizzlyHttpContextFactory.createHttpContext(server, "/ctx", "/echo");

Endpoint endpoint = Endpoint.create(new EndpointBean());
endpoint.publish(context); // Use grizzly HTTP context for publishing
server.start();
//invoke endpoint
endpoint.stop();
server.stop();

.. but the same would have worked with other compatible containers (just to mention one, there's a project for making Jetty compatible with the jaxws 2.2 http spi).

The whole JAXWS 2.2 support is being included in Apache CXF 2.3 and JBossWS-CXF 3.4.0 which should come out soon... in the mean time you can give the latest snapshots a try! Feedback is welcome :-)

Maven plugin for JAXWS tools

2010-03-01T07:24:00.000-08:00

JBossWS comes with JAXWS tools for top-down and bottom-up webservice development.

Starting from today, a Maven plugin is available for easily embedding tools' invocation into your own project's pom.xml:

<build>
<plugins>
  <plugin>
    <groupId>org.jboss.ws.plugins</groupId>
    <artifactId>maven-jaxws-tools-plugin</artifactId>
    <version>1.0.0.GA</version>
    <configuration>
      <wsdls>
        <wsdl>${basedir}/test.wsdl</wsdl>
        <wsdl>${basedir}/test2.wsdl</wsdl>
      </wsdls>
      <targetPackage>foo.bar</targetPackage>
      <extension>true</extension>
    </configuration>
    <executions>
      <execution>
        <goals>
          <goal>wsconsume</goal>
        </goals>
      </execution>
    </executions>
  </plugin>
</plugins>
</build>

this makes wsconsume parse the specified wsdl files and generate java sources for the SEI, wrapper, etc. The classes are then compiled together with all the other ones in your project.

Similarly you can use wsprovide, see the example below:

<build>
<plugins>
  <plugin>
    <groupId>org.jboss.ws.plugins</groupId>
    <artifactId>maven-jaxws-tools-plugin</artifactId>
    <version>1.0.0.GA</version>
    <configuration>
      <verbose>true</verbose>
      <endpointClass>org.jboss.test.ws.plugins.tools.wsprovide.TestEndpoint</endpointClass>
      <generateWsdl>true</generateWsdl>
    </configuration>
    <executions>
      <execution>
        <goals>
          <goal>wsprovide</goal>
        </goals>
      </execution>
    </executions>
  </plugin>
</plugins>
</build>

The plugin has sensible defaults, in particular for computing the classpath to be used before invoking the tools; you just need to make sure your project declares dependencies on a jbossws stack (which you most probably already do, if you have ws endpoints there).
So it's really just a matter of declaring the plugin in the pom.xml and running ;-)
All stacks (JBossWS-Native, JBossWS-CXF, JBossWS-Metro) are supported by the plugin.
A couple of additional complete sample pom.xml files are available on the SCM, for instance take a look at this.
Enjoy!

Extending JBossWS-CXF/Metro with JAX-RPC

2010-02-23T12:44:00.000-08:00

As you all know, Apache CXF and Glassfish Metro do not include JAX-RPC functionalities. While this is not a major issue considering users should be moving to JAX-WS for many reasons, Java EE 6 still include JAX-RPC and JBoss AS needs to provide implementation for it in order to achieve certification.

While JBossWS-Native stack includes JAX-RPC features, in the direction of further improving the JBossWS integration layer for running different WS stacks on top of our AS, we need to provide a way of supporting jaxrpc deployments when JBossWS-CXF (or JBossWS-Metro) is installed in the AS.

We've thought about possible ways of achieving this and the most viable one appeared to be leveraging the JBossWS-Native stack for providing JAXRPC functionalities, while leaving JAX-WS processing to the other installed stack. Implementing this idea basically implies being able to install multiple webservice stacks at the same time in the AS. JBossWS-Native and JBossWS-CXF/Metro need to coexist at runtime and deal with requests depending on the kind of endpoint those are meant for.

In order to deploy multiple stacks on JBoss AS, we needed to:

fix the deployment process: JAX-RPC deployments need to go through JBossWS-Native deployers, while JAXWS ones need to be dealt with by JBossWS-CXF deployers. There's also some kind of intersection between the two groups, as JBossWS comes with some common features that need to stay centralized (the endpoint registry, for instance);
ensure libs from the two deployed stacks can live together: this is quite important speaking of WS as a *lot* of things depends on Service API loading (which depends on what libraries define the current classpath).

Fixing the deployment

The deployment processing issue has been solved basically leveraging the current architecture of ws deployers in JBoss AS. JBossWS comes with a parse stage deployer (that deals with optional webservice.xml descriptor parsing) and a quite fine-grained group of real stage deployers (that performs all the analysis, setup, etc. required for the user endpoint to be properly used on the AS). The former and some of the latters are stack agnostic, meaning they don't have or do anything specific to the ws stack (Native, CXF, Metro) currently installed. Some of the real stage ws deployers, instead, are stack specific and change from stack to stack. The images below present schematically what JAX-RCP / JAX-WS deployments go through during the JBossWS deployment (of course the full deployment involves and requires other non-ws deployers to enter the game):

Adding a couple of flags (using attributes in the *-jboss-beans.xml descriptors) to stacks' deployers for marking them as being able to deal with jaxrpc/jaxws deployments, we've been able to make them run just for the deployments they're meant for. Thanks to the AS deployers' inputs/outputs and the current JBossWS deployers' modularity, there's been no need to provide implementation of new deployers, a proper combination (with the right ordering) of the already existing ones is fine. We end up with new jboss-beans.xml descriptor defining new deployer chains to be installed depending on the selected stack; jaxrpc and jaxws deployments are identified and go through the right deployers that are able to work on them.

Making stack libraries coexist

As previously mentioned, the blocking issue regarding allowing two JBossWS stack to live together stands in the factories/services specified in META-INF/services/... (Service API loading) into stacks' jars. We coped with this moving all the "offending" service configurations (i.e. those that have different values in different stacks) to descriptor only jars.

Those jars (actually only those required for jaxrpc processing) are then isolated in a specific location in application server using a separate classloader declaration (jboss-classloading.xml) and explicitly added to the classpath just for jaxrpc deployments using an additional integration deployer during the describe stage.

Basically we end up with two slightly different classpaths configured at describe stage for different deployment types. This way, when the classloader is created for the current deployment in classload stage, the proper stack is implicitly selected for dealing with it. Below you see the obtained schema:

Now... try it out!

The solution introduced above has just been included in JBossWS-CXF 3.3.0.Beta1 and JBossWS-Metro 3.3.0.Beta1 and is targeted for JBoss Application Server 6.
You just need to checkout the current JBoss AS trunk (or wait for JBoss AS 6.0.0.M3) and the tag for JBossWS-CXF/Metro 3.3.0.Beta1. Build both AS and WS stack (it's just a matter of few commands) and you're ready to go. You can play deploying jaxrpc and jaxws archives on the AS, with formers being handled by JBossWS-Native and the latters by JBossWS-CXF/Metro.
Feedback is welcome :-)

JBoss AS 6 M2 is out.. what about WS?

2010-02-17T01:53:00.001-08:00

Just a brief message to remind JBoss AS 6 M2 has just been released. You can read about that from Brian and Rich, many interesting news come with it.

If you're wondering what changes AS 6 M2 includes in terms of web services, basically we pushed multiple JBossWS component upgrades there.

Among the others, JBossWS Native 3.2.2 improved performances while the 3.3.0.Beta2 currently in AS 6 M2 is a first step in the direction of supporting what's required for Java EE 6.

So stay tuned... and give JBoss AS 6 M2 a try, it's worth it.

JBossWS 3.2.1.GA is available

2009-11-05T06:25:00.000-08:00

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 :-)

Simplifying use of JAXB Introductions

2009-10-15T04:07:00.000-07:00

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.


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) 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:


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

JBossWS performances: improvements coming in 3.2.1 and stacks comparison

2009-10-01T02:53:00.000-07:00

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):

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).

JBossWS 3.2.0.GA is available

2009-08-28T05:17:00.000-07:00

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:

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)

Detailed documentation is available in the renewed JBossWS area of the JBoss community wiki.
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

JavaEE 5 CTS: JBossWS-CXF finally gives great results!

2009-06-01T06:26:00.000-07:00

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.

JBossWS-Native 3.1.2.GA released

2009-05-08T08:39:00.000-07:00

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.

Java Application Server Day 2009

2009-04-23T04:31:00.000-07:00

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.

JBossWS 3.1.1.GA released

2009-04-15T09:05:00.000-07:00

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:

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

Please refer to the release notes for further details:

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:

http://jbossws.jboss.org/mediawiki

And now... let's start working on JBossWS 3.2.0!

JBoss to provide support for Apache CXF

2009-03-26T01:29:00.000-07:00

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.

JBossWS-CXF and WCF interoperability

2009-03-13T07:47:00.000-07:00

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!

JBossWS 3.1.0.GA released

2009-03-03T02:12:00.000-08:00

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:

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.

This means now users can really leverage JAX-WS 2.1 additions (EndpointReference, WebServiceFeature, etc.) on JBoss AS with every supported stacks. You all know how easy and handy is enabling WS-Addressing and MTOM/XOP encoding with @Addressing and @MTOM ;-)

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:

http://jbossws.jboss.org/mediawiki