I have already turned off the firewall. We are using windows XP to serve this client.
Very Bad Idea - unless your organization is already protected by a set of fire-walls protecting the intranet from the internet.
You do not want to invite more trouble than you already have.
The fact that web services use HTTP is one of the advantages of the technology so opening your firewall on port 80 for http and port 443 for https should be enough.
Customizing Windows Firewall How to manually open ports in Internet Connection Firewall in Windows XP If possible, you may even want to configure IP address filters on your Web Server to restrict it to accesses from your client(s).
Some of the confusion may come from the overloading of the terms "Request" and "Response". There are the service request and service response - then there are the HTTP request and HTTP response. You may want to review the following articles to get some of the concepts and terms clarified (to help communication in this
thread):
Asynchronous operations and Web services, Part 2 Asynchronous operations and Web services, Part 1: A primer on asynchronous transactions Looks to me that you are running a "Request/reply operation with posting" setup.
If that is true your client's Service request will start with an HTTP request to your web site/service and ends with an HTTP response (marked as a
Reply in the above article) returned from your web site/service to your client.
I think what I am more worried about is what do I do to make sure I recieve a request from them.
They should not assume that their service request has been received, unless they receive an HTTP response (Reply) from your service indicating the request has been successfully received. Ideally that reply will contain a service request
correlation id which they store and you log in case of any future problems. They should not assume that you received the service request if:
The did not get an HTTP response (in effect the service request is incomplete). They received an HTTP response code other than 200 OK or 202 accepted. The response they received contained a SOAP fault (This is usually associated with a 500 Internal Server Error response code anyway).
One of the parameters that are in wsdl document is userId. I assume this id is being sent by the client so we can identify him.
One thing I don't see you mentioning is the WSDL of
your web service, the one that your client is sending the service requests to. That WSDL would tell you if and where that user ID is supplied.
The solution is that he will going to send us a different Id and thats how we'll know it came from another server so when we are done processing we will send a response back to this second server not the first one
That requires that you have a previously agreed on user ID to service response destination mapping. I presume they do not want to include the service response destination in the service request for security reasons?
In any case
you should be able to configure the endpoint address for your service response with the javax.xml.rpc.Stub API on the JAX-RPC generated stub that you are using. Call the _setProperty(
String name, Object value) in the
Stub interface to set the
ENDPOINT_ADDRESS_PROPERTY property.
[ November 10, 2005: Message edited by: Peer Reynders ]