I am trying to consume the Exchange 2010 Web Service interface using JAX-WS. I'm using JAX-WS 2.2 RI (Metro 2.0). 2.1 exhibited the same problem.
I am running into trouble with Exchange, which returns "HTTP/1.1 415 Cannot process the message because the content type 'text/xml;charset=utf-8' was not the expected type 'text/xml; charset=utf-8'." as a reponse (2.1 quoted the charset value, otherwise same response).
Apparently I need to dictate the exact Content-type header for Exchange to be happy.
Is there a way for me to do this without forcing me to manually rebuild the dependency? I currently rely on published maven artifacts, and would like to continue doing this if at all possible.
The consuming process is a regular J2SE app, with no containers in sight. I have control of the application and can add pretty much anything required to the applications scope, but can not add out-of-process items like proxy servers. The client classes were generated from local WSDL, but the charset specification is derived from constants declared in the jaxws RI implementation, not the generated code. The resulting HTTP transport is thus handled by the standard http/https client from Sun JRE5 or JRE6.
From this thread (giving a cached link, because currently java.net forums are down), it appears that the fault is ultimately that your Exchange Web Service 2010 demands a space after the semicolon - something NOT part of the w3c spec.
A solution might be to put something (depending on your setup) in front of the metro to change the header.
You could try some of the following approaches:
Use reflection to change the Metro constant.
Use AOP (I can't tell you how exactly)
See where is this constant defined in Metro, create a package javax.xml.ws.etc (or com.sun.etc.. in your sources, and copy-paste the source for that class, changing the constant.
Related
I am learning web services in Java. I would like to know the uses for the following 4 classes with the help of a very simple use case - WebServiceFeature, AddressingFeature, MTOMFeature, RespectBindingFeature.
Suppose, I am publishing a web service which will list all States in the United States. How would I utilize these 4 classes?
Java API for XML-Based Web Services (JAX-WS) Version 2.1 introduced the concept of features as a way to programmatically control specific functions and behaviors.
WebServiceFeature as per Java Doc
A WebServiceFeature is used to represent a feature that can be enabled or disabled for a web service.
The JAX-WS specification will define some standard features and JAX-WS implementors are free to define additional features if necessary. Vendor specific features may not be portable so caution should be used when using them.
AddressingFeature as per Java Doc
AddressingFeature represents the use of WS-Addressing with either the SOAP 1.1/HTTP or SOAP 1.2/HTTP binding. Using this feature with any other binding is undefined.
This feature can be used during the creation of SEI proxy, and Dispatch instances on the client side and Endpoint instances on the server side. This feature cannot be used for Service instance creation on the client side.
MTOMFeature as per Java Doc
This feature represents the use of MTOM with a web service.
Also
JAX-WS supports the use of SOAP Message Transmission Optimized Mechanism (MTOM) for sending binary attachment data. By enabling MTOM, you can send and receive binary data optimally without incurring the cost of data encoding needed to embed the binary data in an XML document.
RespectBindingFeature as per Java Doc
This feature clarifies the use of the wsdl:binding in a JAX-WS runtime. This feature can be used during the creation of SEI proxy, and Dispatch instances on the client side and Endpoint instances on the server side. This feature cannot be used for Service instance creation on the client side.
This feature is only useful with web services that have an associated WSDL.
Use Cases - unfortunately, see the Java Docs - I only say unfortunately as with me developing web services for several years now - I've never needed to use "WebServiceFeature,AddressingFeature, MTOMFeature, RespectBindingFeature" - they're for niche use cases which I dont believe most developers need to deal with. The most beneficial one I see would be the MTOMFeature but if you simply want a web service that lists all of the United States - you wouldn't likely need anything that elaborate.
Some Use Case Findings
MTOM: Using JAX-WS, you can send binary attachments such as images or files along with web services requests. With your example of States - you could have a web service that request that sets/updates each a picture of the states state bird and a base64 encoded audio file of the state song - the picture and song could be MTOM attachments.
AddressingFeature: This looks like it's just used when either the web service or web service client need to use WS-Addressing. I'd imagine trying to integrate with a third party web service that requires the use of WS-Addressing in which case your client you write would need to specify it's use
RespectBindingFeature: You can use the RespectBindingFeature to control whether a JAX-WS implementation is required to respect the contents of a Web Services Description Language (WSDL) binding that is associated with an endpoint. By implementing the feature, RespectBindingFeature, you have specified to enforce adherence of the contents of a WSDL binding that is associated with an endpoint for your JAX-WS application. The actual enforcement of the use of the WSDL document specifications, when they are provided, at run time has not been well defined in versions of the JAX-WS specification previous to Version 2.1.
WebServiceFeature: this is the parent class for the other features. The use case I imagine would only be the facts that the sub-classes inherit from it.
I have a weird problem: I have a central Web Service client that calls web methods on thousands of embedded Web Service servers. We recently discovered that the Web Service servers have a bug that make server crash if the XML request is exactly 0x4000 long. This does not happen very often, but with thousands of devices it happens every day, making the whole solution erratic.
The middle term solution is to fix the bug on the servers, but with thousands of firmware to flash this solution is not easy to deploy in few days.
The short term solution is to modify the XML request if it is exactly 0x4000 long and to pad it with a space character or something like that.
So, the XML is generated by JAX-WS (all classes were generated from Web Server manufacturer's WSDL), and I just call an interface annotated with #WebService with methods annotated with #WebMethod, #WebResult, ....
FYI: this the JAX-WS version.
/**
* This class was generated by the JAX-WS RI.
* JAX-WS RI 2.1.3-hudson-390-
* Generated source version: 2.1
*
*/
My question is how can I tinker the XML generated by this call to check its length and modify it if needed?
You could use client-side SOAP Message Handlers to solve your problem.
Check the following link: https://docs.oracle.com/cd/E21764_01/web.1111/e13734/handlers.htm
Is it possible to have an Axis 1.1 client talk to an Axis2 web service endpoint? From my understanding, web services work by passing XML SOAP messages back and forth using the schema specified by the service's WSDL, but I'm unsure as to whether or not these versions of Axis utilize different versions of the web service specification that would stop them from talking. Any thoughts?
Alright, using Axis 1.1 to communicate with an Axis2 web service works just fine. I generated the stubs using Axis 1.1, created a Client class, and tested. Axis 1.1's API doesn't offer some of the same functionality that my previous Axis 1.4 allows, specifically in the ParameterDesc class, where you can specify if web service method parameters are nillable or their minOccurs, but my calls seemed to work just fine.
All in all, it can be done with (what appear to be) basic WSDL definitions, however, I'm unsure as to whether or not Axis2 utilizes new functionality that Axis 1.1 cannot accommodate due to Axis 1.1's aged API...
Oh, and one last note, I needed to use SOAP 1.1 stubs for my request. I'm not 100% sure why since my responses were coming back as SOAP 1.2, but there you have it.
In general your understanding is correct,i.e. that if a client adheres to the WSDL description it should be able to contact the web service.
But Axis1 and Axis2 use by default different encodings which are not compatible.
Axis1 uses RPC (which is obsolete) and Axis2 uses doc/lit.
So the oposite of what you ask i.e. an Axis2 client communicating with an Axis1 server will not work.
For the reverse (and what you ask in the post) I am not really sure.
Did you try to generate the stubs using the WSDL?
Did you get any errors? If you got no errors in stub creation, I believe you could give it a try.
I was taking a look at WebSockets last week and made a few thoughts on how to implement the server side with the Java Servlet API. I didn't spend too much time, but ran into the following problems during a few tests with Tomcat, which seem impossible to solve without patching the container or at least making container specific modifications to the HttpServletResponse implementation:
The WebSocket specification mandate a defined message in the 101 HTTP response. HttpServletResponse.setStatus(int code, String message) is deprecated without mentioning a usable replacement. After changing the default Tomcat configuration, I made Tomcat honor my message string, but since the method is deprecated, I'm not sure if this will work with other servlet containers.
The WebSocket specification require a specified order of the first few headers in the HTTP response to the connection upgrade request. The servlet API does not offer a method to specify the order of the response headers and Tomcat adds its own headers to the response, placing a few of them before any headers, which are added by the servlet implementation.
Since the content length of the response is not known when committing the header, Tomcat automatically switches to chunked transfer encoding for the response, which is incompatible with the WebSocket specification.
Am I missing something obvious, or is it really not possible to integrate WebSocket server endpoints in a servlet based web app?
There is an implementation in Jetty. We can hope that tomcat and jetty find a compatible API.
The Glassfish Atmosphere project will do what you want. There is a servlet you can define to do all the work.
jWebSocket claims to run as a Tomcat application. Unfortunately some files are missing in the binary distribution of jWebSocket. Some people are trying to recompile jWebSocket and get the necessary files, since the source code is available. All in all, jWebSocket does not seem as a reliable product.
Yes there is a very good one (open source and completely free): http://www.jWebSocket.org
I need to "dive into JAX-WS programming".
So, I played around with Netbeans, after 20 or so erroneous attempts,
finally managed to let a web service client execute a web service.
I noticed, that a lot of code is generated, especially JAXB classes
for the web service response.
My current task is, to write a web service and web client completely
by hand.
Is JAXB required at all? Is is part of the standard anyway? What would happen without it?
EDIT:
Seems that the answer is given here
You can see Developing Web Services with Java 2 Platform, Enterprise Edition (J2EE) 1.4 Platform
I took a wsdl and used eclipse to generate the service, serviceLocator, ws interface, ws binding stub, ws proxy, and then the client code. I added a main method and was able to hit the webservice successfully.
I used this tutorial as a guide with the url below and no, there are no jaxb objects as I'm not pulling any objects back in the simple example I used. I was just hitting some methods that pulled back a boolean value.
http://px.pats.no/px/Eclipse_tutorial.html