used cxf framework for webservice. It works.
however the webservice is always published in public ip and I see followin in colsole
Setting the server's publish address to be soap.udp://239.255.255.250:3702
how to change that to localhost.
appreciate any help.
Thanks,
raen
That's the WS-Discovery service that runs along side your other services to allow for discovery of the services on the network. See http://cxf.apache.org/docs/ws-discovery.html
You can remove the WS-Discovery jars from the classpath and this would be disabled.
Related
We have to publish an API and configuring a SAP WSDL inside.
When we test the connection, we have a time out.
Is there any spécial settings to configure publish an API with a SAP WSDL?
Thanks in advance for your help.
Regards.
There shouldn't be any special settings to publish a SAP-generated WSDL, but have you confirmed that your WSDL is 100% correct?
If your WSO2 installation is external (ie outside your firewall or if you're accessing WSO2 in the cloud), make sure that the URL in your WSDL is the external one and not the internal one. In particular, check the location in the port definitions for all of your services.
I have the same mule webservice application with 2 different versions deployed on the same mule server. Let's call it MuleApp.1.0 and MuleApp.1.1. The flow is as simple as the example of webservice flow on mulesoft website. Their wsdl urls are different as:
http://www.myhost.com:25101/MuleApp.1.0/Service?wsdl
http://www.myhost.com:25101/MuleApp.1.1/Service?wsdl
Both of them are working as expected when the other is not deploying on the mule server. The issue happens when I having both of them deployed on the same mule server like what I used to do in WebLogic. Now I am able to access MuleApp.1.1, but when I tried to access MuleApp.1.0, I got the error as below
07-Mar-2013:14:52:57.142 VWILVM3667 [MuleApp.1.1].connector.http.mule.default.receiver.03
WARN org.mule.transport.http.HttpMessageReceiver NA
No receiver found with secondary lookup on connector: connector.http.mule.default with URI key: http://www.myhost.com:25101/MuleApp.1.0/Service
This is supposed to be a very common versionning case. What did I miss in my config?
You can't have two different applications sharing the same HTTP port in the same Mule instance.
So what probably happens is that MuleApp.1.0 doesn't deploy properly (check the logs), which is why there is no endpoint listening on /MuleApp.1.0.
Either:
Use a different port in the two apps,
Put both flows in a single app.
Create a frontal app that listens on port 25101 and both /MuleApp.1.0 and /MuleApp.1.1 paths and that dispatches requests to MuleApp.1.0 and MuleApp.1.1 on private ports (say 25102 and 25103).
I finally deployed my application on tomcat, and replaced http inbound endpoint with servlet inbound endpoint. I configure the web.xml with servlet class org.mule.transport.servlet.MuleReceiverServlet. Now I am able to deploy multiple applications on the same port.
I'm trying to figure out how to forward web service requests from the web server to a remote application server through jms.
In my architecture there are web services client which communicate with some web server (Tomcat) which needs to forward the request to be executed on a remote application server and at the end get the result and push it back to the web service client.
Something like:
Web Service Client <-> HTTP <-> Tomcat <-> JMS <-> Application Server.
I want to use jax-ws so my methods will be called automatically in the application server.
Although I've expected this will be common approach, I didn't find any examples.
I would appreciate if someone can provide some links or tips on how such a configuration can be built.
Currently I'm using Metro but any other solution is valid as well.
Another aspect which I'm interested in, is whether I can use the fast-infoset over JMS to increase performance.
Thanks in advance,
Avner
you can try wso2MB as a JMS provider ...Check following links, would be useful
[1]http://wso2.org/library/message-broker
[2]http://pzf.fremantle.org/2011/04/introduction-to-wso2-message-broker_05.html
One option to solve it is using Apache Camel.
Then you can configure such a thing with an XML configuration file.
I have created an Axis2 web service from Netbeans and deployed it successfully in Tomcat 6 on my web server.
When I use for instance SoapUI or Taverna to consume the web service, the server offers both HTTP and HTTPS methods to invoke it. However, using the HTTPS method renders a 404 error. (Probably because there is a server admin panel running on port 8443, but that doesn't matter right now.)
The problem is that my web service clients default to using the HTTPS service. I figured the simplest thing I could do to get the basic service to work, would be to disable the HTTPS endpoint, as the HTTP version runs flawlessly and I don't need the added security. But now I've spent hours on finding out how to do that, without success. The WSDL returned by Axis2 contains entries for HttpsSoap11Endpoint but the WSDL that's bundled in my .AAR file after the build does not.
Does anybody know how to make Axis2 offer just HTTP endpoints?
In axis2.xml, comment out the https transport receiver to disable the HTTPS endpoint.
I am working on a web service project using gsoap. I am new to web services and have some basic questions.
What should be the port no. of my web service? Currently this web service is a stand alone service listening to a hard-coded port no. of 22050. Client connects to this port and everything works fine. Is this approach OK? What are the pros/cons of this approach?
Or Should my web service be a plug-in of the apache web server? In that case how does it work? Apache httpd listens on port 80, so client sends request to this port. Then how does the request get routed to my web service?
I didn't find any proper online resources on these. Any pointers would be great.
You will have to configure apache such that it knows it will be your web service. In this case you will probably give it a location. So you can configure a directive that will make sure your service is called by apache.
I.e. you will use urls that identify your service (http://.
You will then use a location directive in which you make the proper configurations. You can find more information at http://httpd.apache.org/docs/2.0/sections.html
Hope this helps.