This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes Web Services and the fly likes Regarding javax.xml.ws.Provider interface Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » Web Services
Bookmark "Regarding javax.xml.ws.Provider interface" Watch "Regarding javax.xml.ws.Provider interface" New topic
Author

Regarding javax.xml.ws.Provider interface

Nitin Gaur
Greenhorn

Joined: Sep 06, 2003
Posts: 27
Hi - Below is Provider interface API description. I have some questions. Can some one please answer?
javax.xml.ws
Interface Provider<T>

public interface Provider<T>

Service endpoints may implement the Provider interface as a dynamic alternative to an SEI.

Implementations are required to support Provider<Source>, Provider<SOAPMessage> and Provider<DataSource>, depending on the binding in use and the service mode.

The ServiceMode annotation can be used to control whether the Provider instance will receive entire protocol messages or just message payloads.


1) If client is sending SOAP message, I can still receive only payload by using Provider<Source> and ServiceMode as PAYLOAD?
2) If I just receive PAYLOAD, not entire message, how will I convert response into SOAP message while sending back?
3) What are the scenario in which you may want to receive Source or SOAPMessage or DataSource bindings?
4) What are the scenario in which you prefer Provider interface instead of SEI (Service Endpoint Interface) approach?

Thanks


If you don't like something, change it. If you can't change it, change your attitude. Don't complain.
R Srini
Ranch Hand

Joined: Feb 19, 2010
Posts: 215
Hi Nitin. Very interesting stuff. You may already have come across these links on the web:

- Provides the rationale: http://stackoverflow.com/questions/1730751/advantages-of-using-a-dynamic-client-with-jax-ws
- Lots of details starting page 85 - http://fusesource.com/docs/framework/2.0/jaxws/jaxws.pdf
- Multiple ways of creating web services where the standard code generation tools may not work: http://java.dzone.com/news/5-techniques-create-web-servic

- Using Provider APIs vs code generation tools is like driving manual vs. automatic vehicle.
- Payload = only the Body. Your code will not be passed the entire envelope. You will need to create the rest of the response envelope on your own.
- You use Provider APIs instead of SEI when you want to dynamically determine what gets invoked on the backend instead of creating stubs,e tc. which is static and done at compile time.

Hope that helps. Can someone else with experience in provider APIs give some example scenarios?
Nitin Gaur
Greenhorn

Joined: Sep 06, 2003
Posts: 27
Thanks Srini, That helped.

Another question - Lets say if Provider implements Provider<Source> and also retuns Source type object in response then there is no SOAP in it. It is just plain XML over HTTP. (Correct me if I'm wrong) So if I can implement JAX-WS compliant web service in this way then why do I need to carry SOAP baggage? In other words, between Provider<Source> and Provider<SOAPMessage> which one you would choose and why?
R Srini
Ranch Hand

Joined: Feb 19, 2010
Posts: 215
Ok, I don't have any real experience in this specific to JAX-WS, but here is how I interpret the documentation:

The documentation for javax.xml.ws.Provider says: "Service endpoints may implement the Provider interface as a dynamic alternative to an SEI". In other words, even though the Provider<Source> is receiving raw XML, I think that it will still be dealing with a SOAP message in order to qualify as a "service endpoint". Otherwise, it is not JAX-WS compliant and will be rejected by the web service implementation at runtime.

Also, if you look at Section 5.1 of the JAX-WS 2.0 spec, there are specific requirements for it to qualify as a JAX-WS service endpoint. The requirements are in Section 3.4: it MUST have the @WebService annotation. So my guess is that when we use ServiceMode=Service.Mode.PAYLOAD, the WS provider (I mean like Axis, etc.) will return us getSOAPBody(). And if we use Service.Mode.MESSAGE, we will be passed the result of getEnvelope(). So that is what it sounds like to me. I don't think there is getting around the SOAP part. It can't just be any XML.

From the same JAX-WS spec: "Provider is a low level generic API that requires services to work with messages or message payloads and hence requires an intimate knowledge of the desired message or payload structure."

So for example, instead of having the easy-to-develop sayHello() programming model (which is sufficient for most purposes)with static, generated code and stubs, if you wanted to parse the individual XML tags/tokens yourself, or if you wanted a very small part of a large XML, and you know exactly how to navigate to the portion of interest to you, then you may consider the whole API (DOM or whatever) as too much of a performance and memory overhead. You might then find this kind of interface useful, and your code might search the XML string for <myTag> and </myTag) and capture the contents. Just some thoughts. I have come across this situation several times where memory/performance problems dictate a different approach. Hope that explains a little, and hope my interpretation of the specs is accurate.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Regarding javax.xml.ws.Provider interface
 
Similar Threads
How can we use JAXB to marshall the whole SOAP request/response ?
JAX-WS HTTP Binding
How to get document object From SOAP Message?
Webservice implementing Provider<Source>: no difference with service mode MESSAGE or PAYLOAD
How to capture SoapRequest.xml and SoapResponse.xml