Java Web service client can't connect to BPEL webservice when SoapUI can

Question

I am experiencing the following error and after extensive research on the matter with a few similar issues, none seem to help.

My error:

    com.sun.xml.internal.ws.client.ClientTransportException: HTTP transport error: java.net.ConnectException: Connection refused: connect
    at com.sun.xml.internal.ws.transport.http.client.HttpClientTransport.getOutput(HttpClientTransport.java:121)
    at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.process(HttpTransportPipe.java:142)
    at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.processRequest(HttpTransportPipe.java:83)
    at com.sun.xml.internal.ws.transport.DeferredTransportPipe.processRequest(DeferredTransportPipe.java:105)
    at com.sun.xml.internal.ws.api.pipe.Fiber.__doRun(Fiber.java:587)
    at com.sun.xml.internal.ws.api.pipe.Fiber._doRun(Fiber.java:546)
    at com.sun.xml.internal.ws.api.pipe.Fiber.doRun(Fiber.java:531)
    at com.sun.xml.internal.ws.api.pipe.Fiber.runSync(Fiber.java:428)
    at com.sun.xml.internal.ws.client.Stub.process(Stub.java:211)
    at com.sun.xml.internal.ws.client.sei.SEIStub.doProcess(SEIStub.java:124)
    at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:98)
    at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78)
    at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107)
    at com.sun.proxy.$Proxy33.onboardPerson(Unknown Source)
    at com.paychex.corp.fileloader.FileloaderMain.callWebService(FileloaderMain.java:202)
    at com.paychex.corp.fileloader.FileloaderMain.main(FileloaderMain.java:104)
Caused by: java.net.ConnectException: Connection refused: connect
    at java.net.PlainSocketImpl.socketConnect(Native Method)
    at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
    at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213)
    at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
    at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
    at java.net.Socket.connect(Socket.java:529)
    at java.net.Socket.connect(Socket.java:478)
    at sun.net.NetworkClient.doConnect(NetworkClient.java:163)
    at sun.net.www.http.HttpClient.openServer(HttpClient.java:411)
    at sun.net.www.http.HttpClient.openServer(HttpClient.java:525)
    at sun.net.www.http.HttpClient.<init>(HttpClient.java:208)
    at sun.net.www.http.HttpClient.New(HttpClient.java:291)
    at sun.net.www.http.HttpClient.New(HttpClient.java:310)
    at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:987)
    at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:966)
    at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:841)
    at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1031)
    at com.sun.xml.internal.ws.transport.http.client.HttpClientTransport.getOutput(HttpClientTransport.java:109)

My client is generated from wsimport using the WSDL file that IS visible from the active service. Code connection sample: URL and service name, etc are correct, can't list for security

URL url = new URL("http://correctserviceurl?WSDL");
        QName qname = new QName("http://correct servicelocation","nameofService");
        CorporateEmployeeOnboardingService service = new CorporateEmployeeOnboardingService(url, qname);

        //CorporateEmployeeOnboardingService service = new CorporateEmployeeOnboardingService();
        CorporateEmployeeOnboardingProcess process = service.getICorporateEmployeeOnboardingProcess();
        OnboardRequestType onboardRequest = new OnboardRequestType();

/**
         * TESTING SECTION FOR PROCESS CALL
         */
        //create necessary complex types:
        GregorianCalendar gregorianCalendar = new GregorianCalendar();
        DatatypeFactory datatypeFactory;
        datatypeFactory = DatatypeFactory.newInstance();
        XMLGregorianCalendar testDate = 
            datatypeFactory.newXMLGregorianCalendar(gregorianCalendar);
        testDate.setYear(1991);
        testDate.setMonth(4);
        testDate.setDay(3);
        AssignmentComplexType testAssignment = new AssignmentComplexType();
        testAssignment.setHiringManagerID("123445");
        //set person to send
        person.setSSN("333-33-3333");
        person.setFirstName("testFname");
        person.setLastName("testLname");
        person.setDOB(testDate);
        person.setHireDate(testDate);
        person.setAssignment(testAssignment);
        /**
         * end testing section of the person creation
         */
        onboardRequest.getPerson().add(person);//add a person to the array of people for the request
    ServiceResponse response = process.onboardPerson(onboardRequest);

As stated SoapUI can send this same test information and get a perfectly valid request from the service. All information the same. I have been digging around for awhile and confirmed that there is no proxy, both are same bit (32/64 in this case both 32), service name and WSDL are correct and objects are named properly, etc. I did further debugging trying to get around this awful error code that has seemingly no usable information and using wireshark compared the SoapUI request to the java request to find that SoapUI was using POST and the java client was using GET which has me leaning on this right now as the source of the generic refused connection error.

The service is using BPEL to run and was created using BPEL so all code was basically generated. I will be looking at the Get/post find as of now but wanted to get this out there as I am doubtful it could be the cause.

Any help is greatly appreciated. Let me know if I forgot any key information I might be able to share.

EDIT

I wanted to add that I am able to access the endpoint URL in the web browser from the machine that I am using to try and connect to the BPEL service. It seems the issue is solely with the client generated from the WSDL stubs I got using wsimport for the service's WSDL.

Edit 2: Development/Progress

The issue seems to be that the client is sending the response to local host even after setting up the qname to the correct address. I am now trying to figure out where this local host is being set. Any ideas on this development would be greatly appreciated.

Answer 1

It's been a while, but I believe this line: URL url = new URL("http://correctserviceurl?WSDL");

Needs to read: URL url = new URL("http://correctserviceurl");

Answer 2

K! This one was an issue with BPEL I believe. Quite frustrating. Apparently after initializing the service in the following lines:

URL url = new URL("http://serviceaddresshere?WSDL");
        QName qname = new QName("http://servicelocationaddress","NameOfService");
        CorporateEmployeeOnboardingService service = new CorporateEmployeeOnboardingService(url, qname);

        CorporateEmployeeOnboardingProcess process = service.getICorporateEmployeeOnboardingProcess();

BPEL gets the request with the service WSDL and the CORRECT address. However, BPEL seems to think "O? you want this service, here you go I'll give you that, only the WSDL you want is wrapper, so here's the REAL WSDL." In plain english, you get back the BPEL WSDL that it thinks is for the service, and this has the Localhost address in it. Now I tried changing the address in this WSDL but BPEL through errors up the wazzoo. So the work around was adding in this line after the process variable is make: (AKA THE FIX)

((BindingProvider) process).getRequestContext().put(Dispatch.ENDPOINT_ADDRESS_PROPERTY, "http://the serviceaddress");

Bassically you set the endpoint AGAIN after you make the process, because BPEL overwrites what you sent it the first time. This is of course a sort of work around, but the process now works good. If you can think of a way to bypass this work around and dynamically fix the service so we don't have to keep changing the service WSDL when we move ti to new enviornments like Dev, etc. I am all ears. Thanks and as always I will read comments for suggestions. =)

Answer 3

You can use bpel configuration plans to switch between environments.

Configuration plans are the recommended option to use for making composites environment specific.

Efficient use of configuration plans can greatly reduce the work required per process.

A configuration plan can be generated from the composite.xml file.

Please consider this link:

http://biemond.blogspot.com.br/2010/02/web-service-references-and-soa.html