I have the following issue with my JAX-WS Ri webservice:
Let's say an external user wants to connect to the webservice with an url. During the request (which passes through a load-balancer and has SSL-offloading), the service is accessed on a OC4J container, which generates a WSDL that returns to the client. However, the returning WSDL contains URLs that contain the name of the internal machine instead of the external url. This results in a scenario where other programs cannot link to our WSDL, as they cannot fully download it (see drawing for clarification).
How can I make the WSDL accessible for external users? (i.e. trick the service into generating url's using the externalurl.com reference, rather than its machine name?)
For what it's worth: In Tomcat you can specify proxyName and proxyPort for a Connector. How can this be achieved in OC4J?
You can provide an oracle-webservices.xml file along with your application to override the default binding settings of the OC4J container.
You can find more information here.
Related
Initially WSDL location was given using which I generated the server classes in the client side. Now the server side is deployed as a war file at a different port. We must be able to load wsdl from the new location without modifying the client side code.
It was actually pretty simple. Since I was new to web service I felt it to be an herculean task.
What I did was stored the new WSDL access URL inside a property file and then loaded the value into the project.
We are trying to consume SOAP service (in Java application) which has different end points in prod and pre-prod environments. We generated the client code using wsimport and trying to override the endpoint using binding provider.
Binding provider works fine in pre prod environment ( auto generated code was from pre prod environment wsdl) But when we try to do the testing in production environment , binding provider is not able to override the endpoint.
In production environment it throws " Connection failed when it tries to connect to pre prod".
We learned that binding provider needs access for pre prod wsdl and prod wsdl to override the endpoint. Due to security group restrictions we cant access proprod wsdl from prod.
We also tried to read the end point by calling the service from prod wsdl at run time but port information in wsdl is hardcoded to some IP address and can't be changed and fixing prod wsdl is beyond our control.
Is there any other way to override the endpoint at run time?
You can either use UDDI like solution and keep versioning for your SOAP endpoints or you can use gateway service. This single service will direct the call internally to different services at runtime.
I prefer UDDI because it allows lots of flexibility.
refer: https://docs.oracle.com/cd/E17904_01/admin.1111/e15867/uddi.htm#OSBAG392
Main cause for the problem was stubs were having hardcoded QA endpoints. I modified the client stub code, Removed the hardcoded end-points from proxy generated code and Binding provider started working fine.All other solutions were time consuming and environment level changes were required for using gateway services.
Backstory:
I have a WSDL that was created by the customer (non-negotiable) that mixes several web standards into a single service. This one soap service has four soap ports that refer to bindings in referenced (wsdl:import) WSDL files that import XSDs resulting in a dependency tree that is significantly complex.
Since this is done by imports, the top level WSDL isn't that big. WSDL2Java and wsimport choke on it, but I have a library of the schemas compiled into JAXB objects to work with. So I created a CXF service that has all of the required operations and I was able to test it with SoapUI (it imported the top level WSDL fine since it didn't have to make java classes).
Since all the soap ports point to the same address, and that service handles all the operations from the various ports, the client doesn't know that the server thinks all the operations belong to the same port.
Problem:
This breaks down when it comes to CXF generating the WSDL. It puts all the operations on one port with the same namespace. In the customer provided WSDL, the service, ports and bindings are not all in the same namespace. I have tried to supply the service with the WSDL using the #WebService(wsdlLocation="") annotation, but it tries to parse it and match it to the code (as it would in a sane world).
Question:
I would like to intercept/override the http://example.com/service?wsdl operation and return the customer provided wsdl. Is there a way to do this in CXF?
I ended up splitting the ports out into separate services, but I still needed a custom WSDL that had info for all the ports. The way to do this with CXF is to create an interceptor.
I followed the example of the CXF interceptor that regularly handles WSDL generation: http://grepcode.com/file/repo1.maven.org/maven2/org.apache.cxf/cxf-rt-frontend-simple/2.4.0/org/apache/cxf/frontend/WSDLGetInterceptor.java. I read in my custom WSDL and replace the placeholder hostname with the hostname that comes from the request URL.
You need to then add the custom interceptor when you make your service (I use spring for my configuration). More info on that at http://cxf.apache.org/docs/interceptors.html.
I want to build a web services client that takes wsdl link as the input and generates java classes. I know we can do this directly using Netbeans IDE where we provide the wsdl location during project setup. But I want the wsdl location to be provided when the client starts running. How do I do this?
Is the location that will be provided just used to specify the SOAP endpoint (for a web service whose WSDL was known at development time), or will it be a completely arbitrary WSDL?
In the first case, the web service client that was created by Netbeans has methods that accept an alternate SOAP endpoint URL. You can call those to use the client with a server whose location is not hard-coded in the client.
If however, the WSDL describes a completely unrelated service, how are you going to write Java code against it? You cannot use any interfaces derived from the WSDL (because they are not known at development time). You could only have a very generic SOAP client, where the user almost directly types in the XML that will be sent.
We have a large system of physical devices which all run a web service for control and a central control system for controlling these devices. I need to make a substitute for such a physical device in order to test the controlling unit. How will I go about running more than one instance of a test device on a single computer. The protocol used in SOAP with a wsdl written in stone. In addition to the webservice each test device needs a webserver to monitor state and generating events.
My first approach is to embed jetty and use axis2 for webservices, but I am having some trouble making that fly. I managed to get the axis2 SimpleHttpServer working with a webservice, but as far as I can tell SimpleHttpServer will not let me run Servlets or let alone wars. Is there a better approach I am missing?
I considered making a proxy server listening on any number of ports and forwarding the request to a webservice to a central webservice with an additional paramater saying which port the request originated from, but since the wsdl is writting in stone I can not pass this paramater along.
EDIT: I am using Netbeans to generate a webservice for me. Works as a charm but not enough for my project. For some reason wsimport chokes on the wsdl. I don't understand how Netbeans can deploy to the bundled Glassfish server, but if I drop the generated dist/my-project.war into tomcat the webservice doesn't work. Much less show up in web.xml. What am I missing?
Be aware that if you route your network requests through a SOCKS proxy, you can essentially redirect even hardcoded names and ports in the SOCKS proxy to whatever you need.
Axis2 is not meant to be used as a servlet container, so using SimpleHttpServer doesn't help you there.
But Jetty is a full featured Servlet container. If you want to make it work, you have to run your Wars with Jetty. (Or any other servlet container, but Jetty is perfectly fine)
I'm not Jetty expert, but this should work:
Server server = new Server(8080);
Context root = new Context(server, "/", Context.SESSIONS);
root.addServlet(new ServletHolder( yourServletInstance ), "/*");
server.start();
(Taken from Jetty Wiki)
Ok I've figured out a solution. I can use Glassfish. Then I deploy the same webapp multiple times under different names. Then I have a small proxy made in glassfish which listens on a number of ports and then translates the request to one of the instances running i glassfish.