Chintan Rajyaguru

Ranch Hand
+ Follow
since Aug 19, 2001
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
1
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Chintan Rajyaguru

Ulf Dittmer wrote:

For example, you can't deploy a war file with a web service on Apache Tomcat.


Why not? Axis is a web app, so it can be part of any war file you care to deploy.

All that is needed to deploy a WS is a servlet container that supports whatever version Servlet API version is required by whatever SOAP stack you happen to use. For example, if you're using Metro (or the JAX-WS reference implementation, or Axis 2), then Tomcat 5.5 running on Java 5 will do nicely.



Ulf is right. I meant, Apache Tomcat by itself is NOT a web service container. It is a Servlet container. To run web services on it, you will have to 'package' the web service container (e.g. Axis) along with your application.

Sounds like the original probelm is this: the web hosting provider is making Tomcat available to the website it is hosting. Based on what I have seen in the past, the hosting provider is probably making WEB-INF (for classes) and webapp (for JSP) available in your account. You want to deploy a war file that has web service in it.

If I understood your problem correctly, you need to create a war file with your application, package Axis libraries along with your war file and drop the file in WEB-INF in your account. Finally, if you don't know already, ask your hosting provider for the URL to access your servlets/JSPs, which will determine the web service URL as well. Finally, I would start with a simple servlet/JSP before dropping a war with a web service in it.

Hope this helps.
14 years ago
I am assuming you have a war file with web service code in it. You need a compatible server to deploy the war file to. For example, you can't deploy a war file with a web service on Apache Tomcat. If it has axis, you might be okay. Also, depending on the web service runtime you are using, you may have to deploy the web service itself. For example, AXIS has an admin console, which will accept the service as aar file. Finally, you may have to configure the endpoint.
14 years ago
Typically when you deploy a web service, its url shows up in Glassfish logs in Console view of Eclipse.
Rajamani,
You understood it right but your example needs to be modified. First of all, input message part refers to a 'global element'..., this means that
(1) the message must refer to an 'element' as opposed to 'type'
(2) it must be a global element. Global elements in XML are defined as outer level elements (it has no parent element)
(3) the name of the element in schema must be same as the name of the operation for the input message. The convention is to represent output message with an element that has the name 'operation name+Response'

Example:
In WSDL
<message name="sayHello">
<part name="parameters" element="tns:sayHello"/>
</message>
...
<portType name="HelloWorld">
<operation name="sayHello">
...
Note: (1) part refers to an element as opposed to a type (2) the local name of the element (sayHello) is the same as the operation name

In schema
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<xs:schema version="1.0" all the namespaces>
<xs:element name="sayHello" type="tns:sayHello"/>
...

Note: sayHello is a global element

Now comes the important question:
1. Why do you think these rules apply to document and not RPC style?
2. Why do you think these rules apply to wrapper style?
If you know the answers, you won't have to remember the rules.
Hint: What would happen to two methods in a single class with identical signatures without these rules?
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.
14 years ago
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
14 years ago
I am not familiar with WebLogic but are you sure your client code is correct? Is the line ws.getMyAppWebServiceEndpointPort("username", "password"); allowed in WebLogic client? I am not aware of any method that takes username and password as arguments. May be it is WebLogic specific.

Look at the code 401 description here. Assuming your username and password are correct, try hitting the WSDL URL in a browser. You should be asked for username and password in a popup and see what happens.

Finally, do you have to set any proxy settings when you run from WebLogic?
14 years ago
William is correct. But I would like to expand on what he said.

Web service works in request/response style so when you invoke a method, it will send you the response of that method. If you must combine the responses you could write a proxy that will invoke 4 methods separately, intercept their responses and combine them.

Having said that, your design seems little bit awkward. Why would you want to combine the 4 responses in one XML? Are you sure you have designed your service correctly?
14 years ago
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?
14 years ago
If you can use .Net client to invoke JAX-RPC, JAX-WS client should be much easier. And it actually is. Use the WSDL exposed by your JAX-RPC service to generate a JAX-WS client. Let us know if you run into any specific issues.
14 years ago
With the limited information you have given, I would say NO. It's not an ideal approach. You should use handlers. Handlers are to a web services what filters are to a servlet. They can intercep SOAP request and response and do things with them. Is there any reason why you must use filters?
14 years ago
Deepika,
You want to read chapters 2, 3 and 9 from the specification available for download at http://jcp.org/en/jsr/detail?id=224. Give it a try, it is not as hard to read as people think. I read the specs when I took SCDJWS beta.

Specifically speaking, you are right. The binding has changed so RMH won't be of much help. The handler framework has also changed. RMH is a great book but for SCDJWS 5, I would use it only to read about SOAP, WSDL etc. In fact, in the past I wrote a message on this forum with details on what to read from the RMH book for SCDJWS 5. Try to search with my name and see if you can find it.
Try Overview section here: https://jax-ws.dev.java.net/nonav/2.1/docs/UsersGuide.html

Also, chapter 1 of JAX-WS specification has a section on goals, which describes new features of JAX-WS.
One could also ask, why use anything else when Axis is around for a long time as [sort of] a standard web service tool? But I do agree with you purely based on personal choice and other observations.

My problems with Axis:
1. EJB based endpoints are difficult to implement
2. It doesn't follow the JAX-RPC packaging structure
For more insights, see here.

On the other hand,many tools that support web service, use Axis behind the scene. For example, Vitria, an integration tool, uses Axis. Informatica PowerCenter, an ETL and data integration tool, uses Axis. Sometimes, to interoperate with these tools, you have to use Axis. In one of my projects, we wanted to invoke a web service on Vitria from WebSphere but we had an XML type that was only supported in Axis. We couldn't use WebSphere JAX-RPC implementation.

When should you choose Axis?
1. If you want a light weight web service container
2. When you want to or have to package the web service container with your application. Remember, you can package Axis with your web app and deploy it in [say] WebSphere. This way, your code won't use WebSphere web service container, it will use Axis

Metro and Glassfish are great tools. In fact, that is what I use when I am not bound by my client's requirement to use something else. It's just that Axis got more attention as the early entrant in the market. Plus, there is a ton of 'how to' available on using Eclipse + Axis.
14 years ago