JAX-WS, via JAXB v2.0, adds support for MTOM, the new attachment specification. Microsoft never bought into the SOAP with Attachments specification; but it appears that everyone supports MTOM, so attachment interoperability should become a reality.
The handler model
The handler model has changed quite a bit from JAX-RPC to JAX-WS.
JAX-RPC handlers rely on SAAJ 1.2. JAX-WS handlers rely on the new SAAJ 1.3 specification
15.The other main difference is that JAX-WS has performance advantages as it uses Asynchronous communication as opposed to synchronous in JAX-RPC.
Web services communication is defined in two design paradigms – namely JAX-RPC and JAX-WS.
JAX-WS allows for asynchronous communication as opposed to procedural blocking responses. Also the serialization and deserialization of XML data is done more efficiently and faster using the latest JAXB 2.0 implementation which is much more performing than the its predecessors.
JAX-WS is multi protocol compatible i.e. support of SOAP 1.1 and 1.2.
JAX-WS makes heavy of Java annotations as described by the JSR-181 specification which simplifies client implementation and readability.
In this article we will discuss different ways and methods of improving performance in an enterprise Java based application specifically concentrating on the Web services Integration layer.
Let’s briefly start by discussing the different methodologies of performing Remote Procedural Calls (RPC) from a JEE Application integration tier perspective, and then delve into performance pros and cons for each.
Document and literal style Web services using JAX-RPC and JAX-WS
Wire speed solutions for example DataPower devices
Concurrency using Asynchronous communication and passing contextual information to spawned
threads and Asynchronous beans.
Web service interface best practices for performance gains
Introduction to SOAP and Web services
SOAP was originally intended to be a cross-Internet form of DCOM or CORBA. The name of an early SOAPlike technology was WebBroker – Web-based object broker. It made perfect sense to model an inter-application
protocol on DCOM, CORBA, RMI etc. because they were the current models for solving inter-application interoperability problems.
These technologies achieved only limited success before they were adapted for the Web. RPC models are great for closed-world problems. A closed world problem is one where you know all of the users, you can share a data model with them, and you can all communicate directly as to your needs.
Scalability was comparatively easy in such an environment: you just tell everybody that the RPC API is going to change on such and such a date and perhaps you have some changeover period to avoid downtime. When you want to integrate a new system you do so by building a point-to-point integration.
On the other hand, when your user base is too large to communicate coherently you need a different strategy.You need a pre-arranged framework that allows for evolution on both the client and server sides. You need to depend less on a shared, global understanding of the rights and responsibilities of a participant. You need to put in hooks where compliant clients and serves can innovate without contacting you. You need to leave in explicit mechanisms for interoperating with systems that do not have the same API. RPC protocols are usually poorly suited for this kind of evolution. Changing interfaces tends to be extremely difficult. Integrating services typically takes complicated software “glue” which is the motivating factor behind extending the capabilities of the first-generation Web services framework for the enterprise.
Second generation SOE
The vast amount of second-generation Web service specifications that have emerged, position SOA as a viable successor to prior distributed platforms. Their feature sets continue to broaden, as do vendor-sponsored variations of the specifications themselves. The continuing maturity of theses standards and their implementations sets the stage for the viable evolution of a Service-Orientated-Enterprise (SOE). The generation Web service specifications are listed below which can be embedded and used as part of either JAXRPC or JAX-WS:
Business Process Execution Language for Web services (BPEL4WS)
SOAP with Attachments (SwA)
Extensible Access Control Mark-up Language (XACML)