This week's giveaway is in the Spring forum. We're giving away four copies of liveProject: Protecting User Data with Spring Security and OAuth2 and have Laurentiu Spilca on-line! See this thread for details.
i have a web service deployed to axis2 on websphere and the same web service deployed to axis2 on glassfish v2.
the client is a desktop application generated and written in C# using VS2003.
the client works well with the service on websphere which it was originally designed for. but not with the service on glassfish.
the WSDL generated for both services is exactly the same. the only difference i could find is in the response messages.
this is the response message from the service on websphere:
notice that xmlns value appears in all the properties (bookingRef, jobID, printerName, qty).
and here is the same response from glassfish
notice that only the bookingRef has the xmlns
my service is a POJO without any annotations. it is wrapped as .aar
A. why is this happening although i'm deploying to a common denominator on both app. servers which is the axis2.war ?
B. how do i make the response from glassfish matches the one from webshpere? where do i have to change and what?
The problem most likely is coming from the fact that your C# code expects elementFormDefault="qualified" in the XML schema, which means all elements must be qualified by their namespaces, they cannot inherit the namespace of their parent. WebSphere is putting namespace correctly but Glassfish isn't. This doesn't mean Glassfish isn't working correctly.
To find out what's really happening, I need to see the schema that is used in the WSDL. Do you have an inline schema or a separate schema file that is imported? Could you put your schema code from all the 3 WSDLs? If you don't know whether you have inline or imported schema, paste the 3 WSDLs.
If you are familiar with schemas and how to read them, look for elementFormDefault in C#, WebSphere and Glassfish schemas. Is it defined? Does it have the same value everywhere?
Finally, are you using JAX-RPC or JAX-WS on WebSphere and Glassfish side?
i'm not using any ws api for this web service. it is just a POJO deployed to axis2.war which generates the WSDL and takes care of the rest. i want to know where is this difference in the response coming from as those responses are serialized by axis2.war on both websphere and glassfish? is there any way i can keep the web service the same and make axis2 produce the same response it produces when it was deployed on websphere.
as for the client, it was generated by MSVS2003 by adding a "Web Reference" to the C# project. changing the client code is out of the question as it has been deployed in many locations including remote areas.
here is the wsdl (it is the same autogenerated wsdl of the serivce on both app servers).
Hmm.... We know why you get the error. In your schema, you specified elementFormDefault="qualified", which means each (global and local) element of the generated XML must be qualified (belong to a namespace). In your SOAP response from Glassfish Axis, jobID, printerName and qty are not qualified, nor do they belong to a default namespace so C# code gives an error.
Since you are using Axis (as opposed to WebSphere or Glassfish web service container) in both places, I am surprised to see the different responses getting generated. Clearly, the response from Glassfish Axis is wrong. I can't tell exactly what's going on because I can't see the code, packaging and deployment details but try the following:
1. How are you instructing Glassfish to use Axis as opposed its own web service container? Simply packing Axis in your war file wouldn't do the trick
2. If you can, try removing elementFormDefault and attributeFormDefault from your schema and see what happens
3. Are you sure you are using the same version of Axis in both WebSphere and Glassfish?
4. Consider dropping Axis. Personally, I have never liked Axis. It doesn't use standard packaging, it doesn't generate standard artifacts, running it in a different container is almost always painful and you have to package the whole thing with your war file
Thank you for your reply, i'll try out some of what you pointed out.
i'm using the same version of Axis2 which is 1.2 on both servers.
one thing though, i'm not packing Axis2 in my war file, i simply deployed Axis2.war as a web application on glassfish. my web service is nothing more than a simple java class that contains my business logic in public methods (no WS API what so ever, just pure business logic and DB code). i package my classes in a jar then rename it as .aar and deploy it using the Axis2.war deployed on glassfish, it automatically generate the WSDL,XS etc. that is why i was surprised the responses looked a bit different from axis2 on webshpere.
i'm welling to drop Axis2 as long as i can find a way to keep the same wsdl/ response structure of my legacy web service since i can't touch the client code for any adjustments( i'm quite novice when it comes to WS )
If you can't change the client, suggestion 2 may NOT be for you because that will require regenerating the client (although I was quite hopeful on suggestion 2).
I am interested in exploring this little bit more in the interest of testing for interoperability. Tonight I will 'try' to take your WSDL and generate a service out of it on both Glassfish and WebSphere and see what happens (no guarantee that I will have time to do this tonight). What version of WebSphere are you using? If you are using WAS 6.1, do you know if you have the web service feature pack installed on it? If you have 6.1 with the feature pack or 7.0, your WebSphere would use JAX-WS. If you have an earlier version, it will use JAX-RPC. I want to make sure I do my local test on an environment similar to yours. My test will compare SOAP response messages between WebSphere and Glassfish without using Axis.
I am sincerely hoping that dropping Axis will solve the problem because Glassfish does extensive testing for interoperability with Microsoft platform on its Metro stack. WebSphere, behind the scene, uses the same JAX-WS implementation as Glassfish so hopefully they will generate the same SOAP that will work with .Net.
In the meantime, instead of creating a jar, create a war file out of your project. Put @WebService annotation on your class that has web service methods, deploy it in Glassfish and test the web service. If you have Netbeans, it's quite easy to do this. If you don't have Netbeans you can either download it (for free at netbeans.org) or make sure you include sun-web.xml and appropriate libraries in the classpath of your war. This will deploy your class as a web service in Glassfish without Axis. Let me know if you need more help with this.