The JBossWS project is a working example of how the open source development model can lead to real innovation while delivering enterprise level software. JBossWS is a framework for providing webservice features on top of JBoss AS. Instead of just implementing functionalities from scratch, JBossWS provides an integration layer for running three supported open source ws stacks (including Apache CXF and Glassfish Metro) on JBoss Application Server. While this is of course possible thanks to the WS world being quite specified by standards, the whole architecture is interesting because of its ability to both act as a testing framework for the supported stacks as well as the field for delivering additional cross-stack features. I'm going to present in details the architecture layout as well as describe how it allows users to really have an open choice on what stack to run their services on, while getting benefits from common management, tooling, additional features etc. On the other side, I'll introduce and provide samples of how this development model also benefits the supported stacks' communities thanks to the collaboration with them.

1. JBoss Web Services
Alessio Soldano
alessio.soldano@jboss.com
Principal Software Eng.
JBoss - Red Hat
April 28th, 2010

2. Who is Alessio?
● JBoss WS[1] committer since early 2007
● JBoss / Red Hat employee since end of 2007
● JBoss Web Service Lead, 2008
● JBoss AS[2], JBoss Wise[3] contributor
● Current Red Hat representative at JSR-224 EG
and W3C WS-ResourceAccess WG
● Apache CXF[4] committer since 2009
[1] http://www.jboss.org/jbossws [2] http://www.jboss.org/jbossas
[3] http://www.jboss.org/wise [4] http://cxf.apache.org

3. What is JBoss WS?
● “Just” a feature-rich JAX-WS compatible ws stack
till early 2008...
● a web services framework providing
integration layers for 3rd party ws stacks on top
of multiple JBoss AS versions
– CXF, Native and Metro stack
– AS 5.x, AS 6.x target containers

4. The benefits of standards / specs
W3C standards allow for interoperability
● WS-Security <s:Envelope...>
<s:Header>
● WS-Policy <o:Security...>
● WS-Addressing <u:Timestamp u:Id="..">...</u:Timestamp>
<o:BinarySecurityToken...>...</o:BinarySecurityToken>
● ...
<e:EncryptedKey...>...</e:EncryptedKey>
<e:ReferenceList...>...</e:ReferenceList>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
Defined way to: ...
</Signature>
● format messages
</o:Security>
● advertise services </s:Header>
● ... <s:Body>...</s:Body>
</s:Envelope>

5. The benefits of standards / specs
JCP specs give us common dev API
● JSR-224 / JSR-181 (JAX-WS)
● JSR-109 (WS for JavaEE)
EndpointService service = new EndpointService(
● JSR-101 (JAX-RPC)
wsdlURL, serviceQName);
● JSR-261* (JAX-WSA) Endpoint port = service.getEndpointPort();
● ... String retObj = port.echo(“Hello World”);
@WebService(name = "Endpoint", serviceName = "EndpointService", targetNamespace = "http://org.jboss.ws/wsref")
@SOAPBinding(style = Style.DOCUMENT, use = Use.LITERAL)
public class EndpointImpl {
@WebMethod(action = “echo”)
public String echo(String input) {
return input;
}
}

6. Reasons for integrating
● really good open source implementations
already available - NIH syndrome
● focus on added value
● open choice (features, performance, ...)
● ... a lot of Web Services specifications!

7. Reasons for integrating

8. Who benefits from this move?
● The JBoss community:
– different choices depending on needs
– greater joint community support
– core devs can work on added value
● The integrated ws projects and their community:
– additional tests
– bugs detection and fix
– ...

9. JBoss WSF: high level overview

10. Web Service Framework
● Management ● Tooling
– console – common JAXWS tools
– endpoint registry – project generator
– records system – Eclipse integration
● Configuration ● AS integration
– address rewrite – authentication
● Features – authorization
– JAXBIntroductions
● Common deploy
– Common JAX-WSA JSR- ● Common testsuite
261 API

11. Do I really need your integration
layer?
● Home-brew solutions for running CXF / Metro on
JBossAS might work for specific usecases, but
you...
– need to embed the stack in your apps
– will suffer from classloading issues
– can just use pojo endpoints
– have no webserviceref injection in ejb3
– loose additional WSF features ;-)
– ...

12. How it works - deployment
● POJO endpoint
<web-app ...>
@WebService(...)
<servlet>
public class MyEndpoint {
<servlet-name>TestService</servlet-name>
public String sayHello() {
<servlet-class>org.jboss.test.ws.jaxws.samples.MyEndpoint</servlet-class>
return "Hello World!";
</servlet>
}
<servlet-mapping>
}
<servlet-name>TestService</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
</web-app>
● EJB3 endpoint
@WebService(...)
@Stateless
public class MyEndpoint { Create metadata to
public String sayHello() {
return "Hello World!"; deploy jboss-web app
}
}

13. How it works - deployment
● Parse or generate proprietary descriptor
– jboss-cxf.xml for CXF stack (Spring conf)
– sun-jaxws.xml for Metro stack
● Setup different endpoint servlets for each
stack
– extending CXFServlet for CXF stack

14. How it works - runtime
● Request handlers: called by enpdoint servlet
to serve GET / POST requests; delegate to
– CXF ServletController
– Metro ServletAdapter
● Invokers: route invocation to JBossAS (JBoss
EJB3 layer for ejb3 endpoints)
– configured during proprietary descriptor
processing / creation

15. How it works - runtime
Request
Endpoint servlet
RequestHandler
WS-* ...
Invoker
CXF JBoss
or AS
Metro
JAX-WS
... handlers
Response

16. More on deployers...
JBoss AS 5 deployers gives high flexibility
● multiple webservice deployers generated
– stack agnostic deployment aspects
– stack specific deployment aspects
– extensibility, separation of concerns, ...
● two webservice stacks at the same time
– JAX-RPC support with CXF / Metro

17. CXF: additional integration hooks
● Bus configuration: CXF runtime behaviour is
controlled by the current Bus; we can set:
– custom resource resolvers
– custom transport factories
– custom CXF Configurer bean
– ...
● Spring Namespace Handlers: we can change
configuration namespace to default bean
mapping
– override / extend core CXF beans

18. Some links...
● http://www.jboss.org/jbossws
● http://community.jboss.org/wiki/JBossWS
● http://jbossws.blogspot.com/

19. Q&A