Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

JBossWS Project by Alessio Soldano


Published on

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.

  • Be the first to comment

  • Be the first to like this

JBossWS Project by Alessio Soldano

  1. 1. JBoss Web Services Alessio Soldano Principal Software Eng. JBoss - Red Hat April 28th, 2010
  2. 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] [2] [3] [4]
  3. 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. 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=""> Defined way to: ... </Signature> ● format messages </o:Security> ● advertise services </s:Header> ● ... <s:Body>...</s:Body> </s:Envelope>
  5. 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 = "") @SOAPBinding(style = Style.DOCUMENT, use = Use.LITERAL) public class EndpointImpl { @WebMethod(action = “echo”) public String echo(String input) { return input; } }
  6. 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. 7. Reasons for integrating
  8. 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. 9. JBoss WSF: high level overview
  10. 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. 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. 12. How it works - deployment ● POJO endpoint <web-app ...> @WebService(...) <servlet> public class MyEndpoint { <servlet-name>TestService</servlet-name> public String sayHello() { <servlet-class></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. 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. 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. 15. How it works - runtime Request Endpoint servlet RequestHandler WS-* ... Invoker CXF JBoss or AS Metro JAX-WS ... handlers Response
  16. 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. 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. 18. Some links... ● ● ●
  19. 19. Q&A