Unable to Call a Remote WS

[jsexton0]

This is driving me crazy, I hope someone can offer a hint.

On a remote Glassfish instance is a web service I want to call from my EJB.  

1) To my EJB project I used "add external..." to add the required WSDL and XSD files.
2) In the same EJB project, I used "new web service client" and selected the WSDL.
3) In my EJB I used the resulting service and port types to try to call the web service.  

I am unable to get it to do anything other than attempt a local call to the web service, which results in a 404 error.  The Java code looks something like this:

URL url = new URL("http://remoteHost:9080/MyOpService/MyOpPort?WSDL");
QName name = new QName("http://here.com/wsdl/MyOp",
                "MyOpService");

Service srv = Service.create(url, name);
AddPersonPortType port = srv.getPort(
    new QName("http://here.com/wsdl/AddPerson", "MyOpPort"),
    MyOpPortType.class);
outData = port.myOpOperation(inData);

This, and variations I've tried insist on calling the service at localhost instead of remoteHost.

Any ideas?  Thank you
 

[jsexton0 ()]

I have quite a bit more information about this issue, but I am more puzzled than ever.  

Since I can call a local WS I know the Java and WSDLs are basicly correct.  It simply will not call the WS on a different host, no matter what I do in the Java, no matter what the WSDL retrieved by the URL I give says.

1. I searched my project folders for copies of the WSDL.  I found 18 files.  I know about three of these; the one where the WSDL was originally created and two where it was added as an external WSDL to two projects.

2. I hand edited all these files, changing the URL from localhost to a remote server.

3. Clean build and deploy and test - worked!  So I went back and changed every one of those files one at a time, doing a clean build and deploy between each edit, until I found the ONE copy that actually controls the URL the WS will go to.  By editing this one copy of the WSDL file and rebuilding, and deploying, the WS call can be finally directed to a specific server.

4. I put a comment in this file to I could find out where it land in Glassfish on a deployment, and did a build and deploy.

5. Searching the Glassfish directory, I find nine copies of the WSDL.  Fully six of these contain the comment I added.

Now, I'm just a beginner at web services technology, so I hope someone can enlighten me here.  Is there no way to point a client at a particular host without editing a local WSDL file?  This seems really, really limiting.  It just can't be true.  How do developers create WS-based systems that can be installed at various sites and configured from a configuration file or other source of properties if a WS can not be redirected in Java?

When I query for the address of the port, it has the address I want, the remote address.  Like so:

((BindingProvider)myPortObject).getRequestContext().get(BindingProvider.ENDPOINT_ADDRESS_PROPERTY));

It has pulled the remote WSDL, and has the address corecct.  None the less, when the operation method is called, it goes to localhost instead as reflected in the local WSDL.  I am completely stumped...

Thank you

[jsexton0]

The only method I've found that allows the call of a remote WS from an EJB is to 1) create a web client using a file WSDL (not a from a URL), 2) the WSDL gets deployed to Glassfish and the URL in this file will indeed control the target of the operation, regardless of what URL the Java includes and regardless of what URL is stated in the WSDL the Java retrieves from the URL in the EJB.

I have tried every method I can think of to construct the WS client in the Java, and I have tried writing a new, remote, address for a PL in a BPEL.

I am out of ideas at this point.  Do any examples exist of any method at all of calling a remote WS from an EJB, whose WSDL participates in a BPEL, that allows the hostname or IP address of the WS server to be overridden at run-time?  Or any other method of calling a remote WS that does not require a hard coded URL in a local WSDL?

Is this really an unusual thing to want to do?

We're getting desperate!

Thanks

jsexton0 wrote:

I have quite a bit more information about this issue, but I am more puzzled than ever.  

Since I can call a local WS I know the Java and WSDLs are basicly correct.  It simply will not call the WS on a different host, no matter what I do in the Java, no matter what the WSDL retrieved by the URL I give says.

1. I searched my project folders for copies of the WSDL.  I found 18 files.  I know about three of these; the one where the WSDL was originally created and two where it was added as an external WSDL to two projects.

2. I hand edited all these files, changing the URL from localhost to a remote server.

3. Clean build and deploy and test - worked!  So I went back and changed every one of those files one at a time, doing a clean build and deploy between each edit, until I found the ONE copy that actually controls the URL the WS will go to.  By editing this one copy of the WSDL file and rebuilding, and deploying, the WS call can be finally directed to a specific server.

4. I put a comment in this file to I could find out where it land in Glassfish on a deployment, and did a build and deploy.

5. Searching the Glassfish directory, I find nine copies of the WSDL.  Fully six of these contain the comment I added.

Now, I'm just a beginner at web services technology, so I hope someone can enlighten me here.  Is there no way to point a client at a particular host without editing a local WSDL file?  This seems really, really limiting.  It just can't be true.  How do developers create WS-based systems that can be installed at various sites and configured from a configuration file or other source of properties if a WS can not be redirected in Java?

When I query for the address of the port, it has the address I want, the remote address.  Like so:

((BindingProvider)myPortObject).getRequestContext().get(BindingProvider.ENDPOINT_ADDRESS_PROPERTY));

It has pulled the remote WSDL, and has the address corecct.  None the less, when the operation method is called, it goes to localhost instead as reflected in the local WSDL.  I am completely stumped...

Thank you

[Brynjar Glesnes-2]

The strategy we use in our project is to use an Application
Configuration. I can't seem to find any documentation on it (correct me
if I'm wrong!), but the short story is as follows:

1) In the CASA editor, click on the port on the BC you want to
configure. Name a Config Extension.
2) In the Glassfish Console, choose the Application pane on the
sun-http-binding JBI component. Add a configuration, the name must match
the one given in 1), the URL the one you want to target.

-----Original Message-----
From: jsexton0 [mailto:jsexton0@...]
Sent: 26. september 2008 18:55
To: nbentpack@...
Subject: Re: [entpack] Unable to Call a Remote WS


The only method I've found that allows the call of a remote WS from an
EJB is to 1) create a web client using a file WSDL (not a from a URL),
2) the WSDL gets deployed to Glassfish and the URL in this file will
indeed control the target of the operation, regardless of what URL the
Java includes and regardless of what URL is stated in the WSDL the Java
retrieves from the URL in the EJB.

I have tried every method I can think of to construct the WS client in
the Java, and I have tried writing a new, remote, address for a PL in a
BPEL.

I am out of ideas at this point.  Do any examples exist of any method at
all of calling a remote WS from an EJB, whose WSDL participates in a
BPEL, that allows the hostname or IP address of the WS server to be
overridden at run-time?  Or any other method of calling a remote WS that
does not require a hard coded URL in a local WSDL?

Is this really an unusual thing to want to do?

We're getting desperate!

Thanks


jsexton0 wrote:
>
> I have quite a bit more information about this issue, but I am more
> puzzled than ever.
>
> Since I can call a local WS I know the Java and WSDLs are basicly
correct.
> It simply will not call the WS on a different host, no matter what I
> do in the Java, no matter what the WSDL retrieved by the URL I give
says.
>
> 1. I searched my project folders for copies of the WSDL.  I found 18
> files.  I know about three of these; the one where the WSDL was
> originally created and two where it was added as an external WSDL to
two projects.
>
> 2. I hand edited all these files, changing the URL from localhost to a

> remote server.
>
> 3. Clean build and deploy and test - worked!  So I went back and
> changed every one of those files one at a time, doing a clean build
> and deploy between each edit, until I found the ONE copy that actually

> controls the URL the WS will go to.  By editing this one copy of the
> WSDL file and rebuilding, and deploying, the WS call can be finally
> directed to a specific server.
>
> 4. I put a comment in this file to I could find out where it land in
> Glassfish on a deployment, and did a build and deploy.
>
> 5. Searching the Glassfish directory, I find nine copies of the WSDL.
> Fully six of these contain the comment I added.
>
> Now, I'm just a beginner at web services technology, so I hope someone

> can enlighten me here.  Is there no way to point a client at a
> particular host without editing a local WSDL file?  This seems really,
really limiting.
> It just can't be true.  How do developers create WS-based systems that

> can be installed at various sites and configured from a configuration
> file or other source of properties if a WS can not be redirected in
Java?

>
> When I query for the address of the port, it has the address I want,
> the remote address.  Like so:
>
> ((BindingProvider)myPortObject).getRequestContext().get(BindingProvide
> r.ENDPOINT_ADDRESS_PROPERTY));
>
> It has pulled the remote WSDL, and has the address corecct.  None the
> less, when the operation method is called, it goes to localhost
> instead as reflected in the local WSDL.  I am completely stumped...
>
> Thank you
>

--
View this message in context:
http://www.nabble.com/Unable-to-Call-a-Remote-WS-tp19636854p19692407.htm
l
Sent from the NetBeans - EntPack mailing list archive at Nabble.com.