Tag Archives: jax-ws

Differences between JAX-RPC and JAX-WS

by Kuldip Bajwa

The main differences between JAX-RPC and JAX-WS are listed below:

  • SOAP 1.2 as opposed to SOAP v1.1 (backward compatible).
  • JAX-RPC and JAX-WS support SOAP 1.1. JAX-WS also supports SOAP 1.2.
  • The WSDL 1.1 specification defined an HTTP binding, which is a means by which you can send XML messages over HTTP without SOAP. JAX-RPC ignored the HTTP binding. JAX-WS adds support for it.
  • WS-I’s Basic Profiles
  • JAX-RPC supports WS-I’s Basic Profile (BP) version 1.0. JAX-WS supports BP 1.1. (WS-I is the Web services interoperability organization.)
  • New Java features
    1. JAX-RPC maps to Java 1.4. JAX-WS maps to Java 5.0. JAX-WS relies on many of the features new in Java 5.0.
    2. Java EE 5, the successor to J2EE 1.4, adds support for JAX-WS, but it also retains support for JAX-RPC, which could be confusing to today’s Web services novices.
  • The data mapping model
    1. JAX-RPC has its own data mapping model, which covers about 90 percent of all schema types.Those that it does not cover are mapped to javax.xml.soap.SOAPElement.
    2. JAX-WS’s data mapping model is JAXB. JAXB promises mappings for all XML schemas and the current JAXB implementation is much quicker then its predecessors.
  • The interface mapping model
  • JAX-WS’s basic interface mapping model is not extensively different from JAX-RPC’s; however:
    1. JAX-WS’s model makes use of new Java 5.0 features.
    2. JAX-WS’s model introduces asynchronous functionality.
  • The dynamic programming model
    1. JAX-WS’s dynamic client model is quite different from JAX-RPC’s. Many of the changes acknowledge industry needs:
      1. It introduces message-oriented functionality.
      2. It introduces dynamic asynchronous functionality.
    2. JAX-WS also adds a dynamic server model, which JAX-RPC does not have
  • MTOM (Message Transmission Optimization Mechanism)
  • 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
    1. The handler model has changed quite a bit from JAX-RPC to JAX-WS.
    2. 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.

In short:

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

Achieving a more performing Web services middle tier

by Kuldip Bajwa

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.

These include:

  1. Document and literal style Web services using JAX-RPC and JAX-WS
  2. Wire speed solutions for example DataPower devices
  3. Concurrency using Asynchronous communication and passing contextual information to spawned
  4. threads and Asynchronous beans.

  5. 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:

  1. WS-Coordination
  2. WS-Transaction
  3. Business Process Execution Language for Web services (BPEL4WS)
  4. WS-Reliable Messaging
  5. WS-Addressing
  6. WS-Policy
  7. WS-Policy Assertions
  8. WS-Policy Attachments
  9. WS-Attachments
  10. SOAP with Attachments (SwA)
  11. WS-Security Framework
  12. Extensible Access Control Mark-up Language (XACML)
  13. WS-Federation
  14. WS-Secure Conversation
  15. WS-Authorisation
More, to follow in next article !!!!