JAX-WS Webservice Endpoint and Client

By -

JAX-WS based Webservice and Client Design Options.

JAX-WS stands for Java Api for XML Web services. JAX-WS supports both SOAP 1.1 and SOAP 1.2.
The following section tries to snapshot the different ways we can use JAX-WS to write both Web Services and Clients.

What is Web service Endpoint?
A web service endpoint is an server side resource that can be referenced by client and to which web services messages can be addressed.Generally, web services will have endpoint and a WSDL file to share its descriptions with clients.Clients use the web service endpoint description to generate/write code that can send SOAP messages to and receive SOAP messages from the web service endpoint.

In JAX-WS the endpoints are annotated with the javax.jws.WebService annotation or  javax.jws.WebServiceProvider annotation, but not both at a time.

Services designe options .

JAX-WS broadly supports two Webservice  models,

SEI Interface
  • Annotated with the javax.jws.WebService, where the implemented class works on abstraction, where it deals with objects (SEI)  and not underlying XML messages directly.
Here the methods to be exposed as web service are annotated with @WebMethod annotation. And JAXB objects are used to handle request and response processing. JAXB is responsible for  marshaling and 
unmarshalling the objects to XML

Provider Interface
  • Annotated with javax.jws.WebServiceProvider, and implements Provider interface. Where the service will work at XML message level.Compared to SEI, Provider is a low level Api. Here understanding the payload structure, or SOAP message structure is important.
Provider interface is typed in which the type parameter has been bound to a concrete class, e.g.

Provider<Source> or 
Provider<SOAPMessage> or 
Provider<DataSource>
The @ServiceMode annotation is used to configure the messaging mode of a Provider instance.
Like wheather the web service endpoint will be working on the whole payload or just the message part.

@ServiceMode(value=MESSAGE) indicates that the provider instance wishes to receive and send entire
protocol messages absence of the annotation or use of
@ServiceMode(value=PAYLOAD) indicates that the provider instance wishes to receive and send
message payloads only



Client Programming Model's in JAX-WS
JAX-WS broadly supports two Client models,


Dispatch Client API
Dispatch client api works directly with XML message level and we dont need to use generated Java artifacts from the wsdl.

The Dispatch client API requires  clients to construct messages or payloads as XML.
This requires a detailed knowledge of the message or message payload structure. It could be useful when we need to customize the request message.
Sometimes, generated artifcats after marshalling generates the XML which always does not work always.
This model also usefull when we need to do a lot of xml level processing like digital signing the message and modifying some of the attibutes of the xml.

Dispatch client works with following type of Objects,
  • javax.xml.transform.Source
  • javax.xml.soap.SOAPMessage
  • JAXB objects
  • javax.activation.DataSource
Use Source objects to enable clients to use XML APIs directly.Source objects works both with SOAP or HTTP bindings.
Use SOAPMessage objects so that clients can work with SOAP messages.SOAPMessage objects works with  only SOAP bindings.
Use JAXB objects so that clients can use JAXB objects that are generated from an XML schema.

Dynamic Proxy Client API
Dynamic Proxy client's works with generated artifacts from wsdl, i,e. SEI(Service endpoint Interfaces).
For Dynamic proxy we can use wsimport tool to generate the SEI classes, and use them to build the client.
Main steps for using Dynamic Proxy are as follows,
  • Create instance for SEI class ( Annotated with @WebServiceClient)
  • Get the  webservice endpoint object or the Object representing port ( Annotated with @WebEndpoint)
  • Invoke port object's operation/method (Annotated with @WebMethod)

Comments

Post a Comment

Popular posts from this blog

Converting Java Map to String

By -
Java Collections framework, String manipulation etc is something that we often encounter in Development process. For processing collections (like checking null/empty, Intersection, Disjunction) We do have some of the very use full libraries. Some of the Collection related libraries are Apche Commons Collections and Google  Collections(Guava). Problem Use Case This article explains how to convert a Java Map to String(and vice versa) using different libraries and technique. One way is to use StringBuilder(Or String) and loop though the Map and build the String by applying some sort of separator ( for key:value and entry). Here we have to take care of the null value etc. Without Any Library If we want to convert the map to a String with key value separator and also individual entry seperator in the resulting String, we have to write code for that. For a simple Map, we have to iterate though the map, take care of the null values etc. Following is a sample to get String built
Read more

Difference between volatile and synchronized

By -
volatile is a field modifier, while synchronized modifies code blocks and methods. So we can specify three variations of a simple accessor using those two keywords: int i1; int geti1() {return i1;} volatile int i2; int geti2() {return i2;} int i3; synchronized int geti3() {return i3;} geti1() accesses the value currently stored in i1 in the current thread . Threads can have local copies of variables, and the data does not have to be the same as the data held in other threads. In particular, another thread may have updated i1 in it's thread, but the value in the current thread could be different from that updated value. In fact Java has the idea of a "main" memory, and this is the memory that holds the current "correct" value for variables. Threads can have their own copy of data for variables, and the thread copy can be different from the "main" memory. So in fact, it is possible for the "main"
Read more

Invoking EJB deployed on a remote machine

By -
Invoking EJB deployed on a remote machine In case we are calling remote ejb( ejb deployed on remote machines), The JNDI lookup might lookup like, Properties env = new Properties(); env.put(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory"); env.put(Context.PROVIDER_URL, "XX.XXX.XX.XX:1099"); env.put("java.naming.factory.url.pkgs", "org.jboss.naming:org.jnp.interfaces"); Context ctx = new InitialContext(env); If we are calling local ejb then we can simply create InitialContext without any parameters. Like, Context ctx = new InitialContext();
Read more