JAX-RPC client side programming

[vikas jain]

I have few doubts regarding 'generated-stub' thing.

1. The generated stub here is just a class that imlements the end-point interface. The role of this stub will be to convert the java call into a soap message and viceversa. right? This stub is not like the stub which we get in RMI, I mean this stub will not open sockets etc. right?

2. The RMH says that the stub is generated at the deployment time. But if this stub is created by reading just the wsdl file. Why can't it be generated at the client side after the deployment.

3. Also the jax-rpc comiler generates the service interface and the container (jax-rpc runtime?) provides the implementation. Now when we deploy the end-point interface/implementation, we mention that what is the jndi-name for this service and the actual service interface. when the client does a lookup,the client is returned what? The stub for the implementation of this Service Interface? Is this stub like the RMI stub?

[Peer Reynders]

Originally posted by Nikhil Agrawal:
1. The generated stub here is just a class that imlements the end-point interface. The role of this stub will be to convert the java call into a soap message and viceversa. right? This stub is not like the stub which we get in RMI, I mean this stub will not open sockets etc. right?

Of course it will open sockets - through the use of an http connection. SOAP envelopes are transported over HTTP - HTTP uses TCP/IP - so there are going to be sockets involved.

2. The RMH says that the stub is generated at the deployment time. But if this stub is created by reading just the wsdl file. Why can't it be generated at the client side after the deployment.

The <wsdl-file> inside a <service-ref> of a web.xml is only used when the application is a client.

The <wsdl-file> inside a <service-ref> of a ejb-jar.xml is only used when the application is a client.

The <wsdl-file> inside a <webservice-description> of the webservices.xml is used when the application serves the endpoint.

Which case are you talking about? If you are talking about the first two cases then it should be evident that the client stub is needed upon deployment so that you have a class that implements the interface - there is nothing to be gained by delaying the generation of the stub. In the third case a client stub isn't necessary.

3. Also the jax-rpc comiler generates the service interface and the container (jax-rpc runtime?) provides the implementation. Now when we deploy the end-point interface/implementation, we mention that what is the jndi-name for this service and the actual service interface. when the client does a lookup,the client is returned what? The stub for the implementation of this Service Interface? Is this stub like the RMI stub?

Once again I think that you are mixing service endpoint and client deployment issues. When you deploy the service endpoint nothing happens for the client. However the client can receive an object that implements the service interface from its own application server via JNDI access. That object communicates with the service endpoint that is deployed on the other application server (so I guess it serves a similar function to an RMI stub - however it uses SOAP messages over HTTP instead of RMI-IIOP).

Have a look at this

[vikas jain]

Thanks for the explanation. But may be I am too confused between J2EE web-services clients and J2SE clients. Could you please help me with the components that are required during webservice deployement and during the client access?

Let's say I have J2SE client, I just want to write one independent program to access webservice. In this case I will just be knowing the wsdl file. Now what would be the steps to use this web serice?

Say if I have a J2EE client, I want to access the webserice from a servlet. Again I have not deployed the webservice (or the webserice is in some other J2EE container), the webservice is deployed by someone else at some location. Now to access this webserive I will have to follow the same steps as I will be following for J2SE client?

Now if I have a J2EE client and the webservice has been deployed by me ( same J2EE container). Then what would be the steps?

[vikas jain]

One more doubt.I hope I am not asking the most dumb question here

Let's say we have the following service-ref element.

<service-ref>
<service-ref-element>service/BookQuoteService</service-ref-name>
<service-interface>com.jwsbook.jaxrpc.BookQuoteService</service-interfcae>
....
</service-ref>

This service-ref-element will make sure that during the deployment one instance of com.jwsbook.jaxrpc.BookQuoteService is available and is bound at "service/BookQuoteService".

Why can't we bind the the stub class here(probably because we don't know the stub class name or we can only bind the classes that behave like factory class). So that we can look for that stub class and we are not required to create one using the Service interface.

why can't we just create a new Instance of the stub class using new operator. Instead of getting one from the Service class ( Service class is acting as a factory). but is there a need for this?

[Peer Reynders]

Originally posted by Nikhil Agrawal:
Let's say I have J2SE client, I just want to write one independent program to access webservice. In this case I will just be knowing the wsdl file. Now what would be the steps to use this web serice?

Typically you would select a SOAP stack (web services are only supported by Java SE starting with version 6) and use its WSDL-to-Java tool to generate the static stub from the WSDL. You would then use the stub to access the web service. (Java BluePrints: Patterns, Guidelines, Conventions, and Code: Designing Web Services with the J2EETM 1.4 Platform: 3.4.1 Designing the Interface)

Creating Web Services with Apache Axis: 3. WSDL2Java: Generate the Server-side Wrapper Code and Stubs For Easy Client Access, for example, shows how to use the Axis 1.x WSDL2Java tool to generate client stubs that can be used by a J2SE client.

This process is described in RMH p327

Note though that there are other options. You could also use Dynamic Proxies (RMH p338) or the Dynamic Invocation Interface (DII) (RMH p344). With dynamic proxies and DII you don't need a stub because you are doing all the "tedious work" of directly dealing with SOAP requests and SOAP responses.

Say if I have a J2EE client, I want to access the webserice from a servlet. Again I have not deployed the webservice (or the webserice is in some other J2EE container), the webservice is deployed by someone else at some location. Now to access this webserive I will have to follow the same steps as I will be following for J2SE client?

You can by simply using a pre-generated stub. But the scenario that you previously described was where the application server deployment environment was responsible for generating the stub - which you could then access via JNDI during runtime and use through the service interface declared in the <service-ref>.

Now if I have a J2EE client and the webservice has been deployed by me (same J2EE container). Then what would be the steps?

Why would you even do that - it would be a waste of the application servers resources. The Java BluePrints: Designing Web Services is very clear that you should be mindful of the overhead that XML (un)marshaling imposes. It would be much more effective to access the service as a POJO or local EJB.

Now if you are going to do it anyway - there is no such thing as a "local web service reference".*** The endpoint is one component and the client JSP or EJB is another component - so nothing changes.

why can't we just create a new Instance of the stub class using new operator. Instead of getting one from the Service class ( Service class is acting as a factory). but is there a need for this?

Even when you pre-generate a stub you will usually have to get the instance that implements a service interface from a factory. This is in line with Joshua Bloch's Effective Java Item 1: Consider providing static factory methods instead of constructors. The advantages are summarized as follows:

Factory methods, unlike constructors, have names.

Factory methods, unlike constructors, are not required to create a new object each time they are invoked.

Factory methods, unlike constructors, can return an object of any subtype of their return type.

In this context it is the third point that is the most important. Writing "new MyClass()" tightly couples your code to MyClass. "MyInterface inf = myFactory.getInstance()" couples your code to the factory but the instance returned by the factory could be configured somewhere else - so this solution is more loosely coupled. Using an interface but then directly creating an implementing class negates some of the benefit of using interface as your code now depends on the interface and the implementing class - you only want to depend on the interface. It's part of Program to an interface, not an implementation and the Interface Segregation Principle (pdf).


*** There seems to be one exception. When you use dynamic proxies you can specify a <port-component-link> inside <port-component-ref>. The link points to the endpoint component in the same application. Apparently the application server will, in this case, dynamically create a proxy for local calls that bypasses the XML (un)marshalling improving performance significantly. However this optimization is not availble for static stubs or DII.
[ March 26, 2008: Message edited by: Peer Reynders ]

[vikas jain]

*** There seems to be one exception. When you use dynamic proxies you can specify a <port-component-link> inside <port-component-ref>. The link points to the endpoint component in the same application. Apparently the application server will, in this case, dynamically create a proxy for local calls that bypasses the XML (un)marshalling improving performance significantly. However this optimization is not availble for static stubs or DII.

Isn't the above is same as asked by me?

Now if I have a J2EE client and the webservice has been deployed by me (same J2EE container). Then what would be the steps?

[Peer Reynders]

Originally posted by Nikhil Agrawal:
Isn't the above is same as asked by me?

This topic started by talking about static stubs. However there are a total of three options for implementing J2EE web services clients with JAX-RPC ****:

static stub (as generated by a WSDL-to-Java generator which can be a separate tool or during deployment by the application server)

dynamic proxy

DII (dynamic invocation interface)

Static stubs are used most often because they are the easiest to use - other than the RemoteExceptions there is rarely any indication that you are dealing with something that is remote and possibly not even implemented in Java. DII is used least frequently because it forces you to build SOAP requests and inspect SOAP responses. When it comes to deployment these three options have to be configured slightly differently.

Only clients that are implemented by using a Dynamic Proxy can use collocated endpoints directly which is why there is a special configuration option for that. For DII and static stubs the web service is used just like any other web service - it doesn't matter that the endpoint is collocated with the client.

**** using SAAJ is another non-JAX-RPC option.
[ March 26, 2008: Message edited by: Peer Reynders ]

[vikas jain]

Thanks..your explanations cleared my doubts regarding server-side and client-side jax-rpc requirement.