Click here to load reader

Jax Rpc Versus Jax Ws

  • View
    463

  • Download
    5

Embed Size (px)

DESCRIPTION

Jax Rpc Versus Jax Ws

Text of Jax Rpc Versus Jax Ws

JAX-RPC vs JAX-WSJava API for XML-Based RPC (JAX-RPC) is a Legacy Web Services Java API, it uses SOAP and HTTP to do RPCs over the network and enables building of Web services and Web applications based on the SOAP 1.1 specification, Java SE 1.4 or lower, or when rpc/encoded style must be used. You can use the JAX-RPC programming model to develop SOAP-based web service clients and endpoints. JAX-RPC enables clients to invoke web services developed across heterogeneous platforms. Likewise, JAX-RPC web service endpoints can be invoked by heterogeneous clients. JAX-RPC requires SOAP and WSDL standards for this cross-platform interoperability. JAX-RPC lets people develop a web service endpoint using either a Servlet or Enterprise JavaBeans (EJB) component model. The endpoint is then deployed on either the Web or EJB container, based on the corresponding component model. Endpoints are described using a Web Services Description Language (WSDL) document.

(This WSDL document can be published in a public or private registry, though this is not required). A client then uses this WSDL document and invokes the web service endpoint. JAX-RPC in J2ee 1.4 supports 4 types of stubs and invocations: static stub, dynamic proxy, Dynamic Invocation Interface (DII) and Application client. Static Stub Client Web service client makes a call through a stub, a local object that acts as a proxy for the remote service. Because the stub is created by wscompile at development time (as opposed to runtime), it is usually called a static stub. Example: Invoking a Stub ClientStub stub = (Stub) (new MyHelloService_Impl().getHelloIFPort()); stub._setProperty (javax.xml.rpc.Stub.ENDPOINT_ADDRESS_PROPE RTY,endpoint_address_string); HelloIF hello = (HelloIF)stub; System.out.println(hello.sayHello("Duke!") );

Dynamic Proxy Client In contrast, the client call a remote procedure through a dynamic proxy, a class that is created during runtime. Although the source code for the static stub client relies on an implementation-specific class, the code for the dynamic proxy client does not have this limitation. Example: Dynamic Proxyjavax.xml.rpc.Service service = ServiceFactory.newInstance().createService (...); com.example.StockQuoteProvider sqp = (com.example.StockQuoteProvider)service.ge tPort(portName, StockQuoteProvider.class); float price = sqp.getLastTradePrice("ACME");

Dynamic Invocation Interface Client With the dynamic invocation interface (DII), a client can call a remote procedure even if the signature of the remote procedure or the name of the service is unknown until runtime. In contrast to a static stub or dynamic proxy client, a DII client does not require runtime classes generated by wscompile.

Example: Dynamic Invocation Interfacejavax.xml.rpc.Service service = ServiceFactory.newInstance().createService (...); javax.xml.rpc.Call call = service.createCall(portName, "getLastTradePrice"); // This example assumes that addParameter and setReturnType methods are not required to be called Object[] inParams = new Object[] {"ACME"}; Float quotePrice = (Float)call.invoke(inParams);

Application Client Unlike the stand-alone clients, for an application client, because it's a J2EE component, an application client can locate a local web service by invoking the JNDI lookup method. Example: Application ClientContext ic = new InitialContext(); MyHelloService myHelloService = (MyHelloService) ic.lookup("java:comp/env/service/MyJAXRPCH ello"); appclient.HelloIF helloPort = myHelloService.getHelloIFPort(); ((Stub)helloPort)._setProperty(Stub.ENDPOI NT_ADDRESS_PROPERTY,args[0]);

System.out.println(helloPort.sayHello("Jak e!"));

Service Endpoint Model JAX-RPC supports a client model for the service consumer, and a service endpoint model for the service producer. Application-Level Interaction Modes JAX-RPC specifies three client application interaction models: * Synchronous request-response two-way RPC * Asynchronous (non-blocking) requestresponse two-way RPC * One-way RPC

JAX-WSJAX-WS 2.0 is the successor of JAX-RPC 1.1 - the Java API for XML-based Web services. If possible, JAX-WS should be used instead as it is based on the most recent industry standards. What remains the same?

Before we itemize the differences between JAX-RPC 1.1 and JAX-WS 2.0, we should first discuss what is the same. * JAX-WS still supports SOAP 1.1 over HTTP 1.1, so interoperability will not be affected. The same messages can still flow across the wire. * JAX-WS still supports WSDL 1.1, so what you've learned about that specification is still useful. A WSDL 2.0 specification is nearing completion, but it was still in the works at the time that JAX-WS 2.0 was finalized. What is different? * SOAP 1.2 JAX-RPC and JAX-WS support SOAP 1.1. JAX-WS also supports SOAP 1.2. * XML/HTTP 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 o 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. o 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 o 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. o JAX-WS's data mapping model is JAXB. JAXB promises mappings for all XML schemas. * The interface mapping model JAX-WS's basic interface mapping model is

not extensively different from JAX-RPC's; however: o JAX-WS's model makes use of new Java 5.0 features. o JAX-WS's model introduces asynchronous functionality. * The dynamic programming model o JAX-WS's dynamic client model is quite different from JAX-RPC's. Many of the changes acknowledge industry needs: + It introduces message-oriented functionality. + It introduces dynamic asynchronous functionality. o JAX-WS also adds a dynamic server model, which JAX-RPC does not have. * MTOM (Message Transmission Optimization Mechanism) JAX-WS, via JAXB, 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 o The handler model has changed quite a bit from JAX-RPC to JAX-WS. o JAX-RPC handlers rely on SAAJ 1.2. JAXWS handlers rely on the new SAAJ 1.3 specification.

JAX-RPC versus JAX-WSIntroduction Web services have been around a while now. First there was SOAP. But SOAP only described what the messages looked like. Then there was WSDL. But WSDL didn't tell you how to write web services in Java. Then along came JAXRPC 1.0. After a few months of use, the Java Community Process (JCP) folks who wrote that specification realized that it needed a few tweaks, so out came JAX-RPC 1.1. After a year or so of using that specification, the JCP folks

wanted to build a better version: JAX-RPC 2.0. A primary goal was to align with industry direction, but the industry was not merely doing RPC web services, they were also doing message-oriented web services. So "RPC" was removed from the name and replaced with "WS" (which stands for web Services, of course). Thus the successor to JAX-RPC 1.1 is JAX-WS 2.0 - the Java API for XML-based web services. What remains the same? Before we itemize the differences between JAX-RPC 1.1 and JAX-WS 2.0, we should first discuss what is the same.

JAX-WS still supports SOAP 1.1 over HTTP 1.1, so interoperability will not be affected. The same messages can still flow across the wire. JAX-WS still supports WSDL 1.1, so what you've learned about that specification is still useful. A WSDL 2.0 specification is nearing completion, but it was still in the works at the time that JAX-WS 2.0 was finalized.

What is different?

SOAP 1.2

JAX-RPC and JAX-WS support SOAP 1.1. JAX-WS also supports SOAP 1.2.

XML/HTTP 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. (WSI is the web services interoperability organization.)

New Java features o 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. o 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 o 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 tojavax.xml.soap.SOAPElement.

JAX-WS's data mapping model is JAXB. JAXB promises mappings for all XML schemas. The interface mapping modelo

JAX-WS's basic interface mapping model is not extensively different from JAX-RPC's; however: JAX-WS's model makes use of new Java 5.0 features. o JAX-WS's model introduces asynchronous functionality. The dynamic programming model o JAX-WS's dynamic client model is quite different from JAX-RPC's. Many of the changes acknowledge industry needs: It introduces message-oriented functionality. It introduces dynamic asynchronous functionality. o JAX-WS also adds a dynamic server model, which JAX-RPC does not have. MTOM (Message Transmission Optimization Mechanism)o

JAX-WS, via JAXB, adds support for MTOM, the new attachment specification. Microsof

Search related