File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Web Services and the fly likes Regarding interface Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Web Services
Bookmark "Regarding interface" Watch "Regarding interface" New topic

Regarding interface

Nitin Gaur

Joined: Sep 06, 2003
Posts: 27
Hi - Below is Provider interface API description. I have some questions. Can some one please answer?
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?


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:
- Lots of details starting page 85 -
- Multiple ways of creating web services where the standard code generation tools may not work:

- 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

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 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:
subject: Regarding interface
jQuery in Action, 3rd edition