• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

Regarding javax.xml.ws.Provider interface

 
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 215
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 215
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
My, my, aren't you a big fella. Here, have a tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic