It describes briefly about reusing the common services to make Webservices

1. JAX WS using CXF
Kayalvizhi K
1

2. Agenda
 Requirements
 Why CXF?
 Proposed Architecture
 How To Implement?
 POC
2

3. Requirements
 Exposing CS as Web Services
– Without Code Changes
– With ensured Security
 Why should CS be exposed as WS?
– For making it accessible for different clients
running on different platforms
– For making it accessible on various transports
(HTTP, JMS etc...)
3

4. Why CXF?
 Generating WSDL from POJO
 Spring Integration
 Support for RESTful services via HTTP
Binding
 WS-* Support
4

5. Alternatives to CXF
 Apache AXIS 2 - A little heavyweight, especially
in the deployment
 Sun Metro - Spring integration may not be
production ready
 JBoss Web - Tight EJB3 integration; No direct
Spring integration
5

6. Proposed Architecture
Client
Adapter
Container
Service Common Services
6

7. How to Implement?
 Annotate
– Interface
– Implementer Class
 Configure JAXWS Endpoints for various
transports (HTTP & JMS)
 Configure CXF Servlet
 Deploy application (which generates WSDL)
 Test the services
7

8. POC - Features
 Publishes endpoints for HTTP & JMS
Transport
 Ensures WS-Security using Interceptors
 Uploads Binary Data / Large Files using MTOM
8

9. Appendix I: Acronyms
# Acronym Description
1 CXF Combination of two projects (Celtic and XFire)
2 JAX WS Java API for XML Web Services
3 JAX RS Java API for RESTful Web Services
4 SEI Service Endpoint Interface
5 MTOM Message Transmission Optimization Mechanism
6 CS Common Services
7 REST Representational State Transfer
8 WSDL Web Services Description Language
9
9 POJO Plain Old Java Objects

10. Appendix II: Why MTOM?
 Problem: With Text Encoding, it uses base 64 encoding
format which can inflate the message size by 30%. This can
be a heavy penalty while carrying large binary attachments.
 MTOM
– extracts the base64Binary data from the SOAP message
and packages it as separate binary attachments within the
MIME message, in a similar manner to e-mail attachments
 Ref:
– http://docs.oracle.com/cd/E12840_01/wls/docs103/webser
v_adv/mtom.html
– http://publib.boulder.ibm.com/infocenter/cicsts/v3r2/index.j
sp?topic=%2Fcom.ibm.cics.ts.webservices.doc
%2Fmtomxop%2Fdfhws_attachments_overview.html
10

11. Appendix III: Known Issue
No JMS address information in WSDL for JMS Transport
We prefer to use 'JMSConfigFeature approach' for exposing
services in JMS Transport instead of 'SOAP over JMS'
approach as it involves no changes in WSDL/ Java Code.
And the JAX WS Annotations does not have any ref. To JMS
transport
Ref:
– http://cxf.apache.org/docs/soap-over-jms-10-support.html
– http://cxf.apache.org/docs/using-the-jmsconfigfeature.html
– http://jax-ws.java.net/jax-ws-ea3/docs/annotations.html
11

12. Appendix IV: POC – Load Testing
 SOAP UI Tool is used for load testing the POC
 The following parameters are set to execute it for 60 s
– Threads: 5
– Strategy: Simple
– Test Delay: 1000 (ms)
– Random: (0.5)
 Ref:
– http://www.soapui.org/Getting-Started/load-testing.html
– http://www.soapui.org/Load-Testing/load-test-window.html

13. Appendix IV: POC – Load Testing (continued)
1. Load Test Report - JAX WS
Operation min(ms) max(ms) avg(ms) bytes bps
getPatient 2 11 3.83 127190 2122
getDoctor 2 9 3.35 119290 1990
getAppointment 3 17 5.44 208955 3486
deleteAppointment 2 8 3.14 99540 1660
createAppointment 3 20 5.22 200265 3341
updateAppointment 4 62 6.95 208165 3473
Overall 16 127 27.96 963405 16075

14. Appendix IV: POC – Load Testing (continued)
2. Load Test Report – JAX RS with JSON payload
Operation min(ms) max(ms) avg(ms) bytes bps
getPatient 2 8 2.37 21728 362
getDoctor 1 8 2.77 15520 259
getAppointment 2 14 4.48 74496 1244
deleteAppointment 2 137 3.28 1552 25
createAppointment 2 244 5.25 74884 1250
updateAppointment 3 34 5.74 74496 1244
Overall 13 445 23.93 262676 4388

15. Appendix V: Decision – JAX WS/ RS?
Parameter JAX WS REST
Weight Heavy Light
WS-Standards Supports No Support
Implementation Takes time as Faster & Easier
Cycle understanding the standards
takes more time
Documentation Less as is based on standards More as is tailor-made
Maintenance Easier Complex as is derived
from standard-less
development

16. Appendix V: Decision – JAX WS/ RS? -
Continued
Parameter JAX WS REST
Integration with other Easier as they follow Need to write adapter for each
Apps/ 3rd Party standards integrating application
Payload Efficiency Always XML Flexible and efficient when
combined with JSON
Ref:
– http://docs.oracle.com/javaee/6/tutorial/doc/gjbji.htmll
– https://devcentral.f5.com/weblogs/macvittie/archive/2008/12/0
– http://blogs.captechconsulting.com/blog/jack-cox/soap-vs-
rest-mobile-services

17. Appendix VI: Other References
 http://docs.oracle.com/javaee/6/tutorial/doc/gijti.html
 http://predic8.com/axis2-cxf-jax-ws-comparison.htm
 http://cxf.apache.org/docs/index.html
 http://cxf.apache.org/docs/jax-rs-and-jax-ws.html
 http://cxf.apache.org/docs/ws-security.html
 http://cxf.apache.org/docs/mtom.html
 http://www.crosschecknet.com/intro_to_mtom.php
17

18. Thank you
18