apache camel cxf - change soap:address location - web-services

I need to expose soap service on jboss fuse server. What I am tring to do is replicate an existing developed soap service.
Existing Browser URL:
http://ip:8027/Services/Interface/WebServices/TestService.serviceagent?wsdl
Existing Endpoint URL:
http://ip:3456//Services/Interface/WebServices/Service.serviceagent/ChangeCustomerBasicEndpoint1
According to my understanding the above Browser URL can be accessed in browser and WSDL can be viewed.
Similarly we can use this Browser URL in SOAP-UI to get the WSDL and the Endpoint URL is where the request is sent to - right ?
I am able to expose the soap service, by using following code
<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
xmlns:cxf="http://camel.apache.org/schema/blueprint/cxf"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0 ">
<cxf:cxfEndpoint
address="http://ip:8027/Services/Interface/WebServices/TestService.serviceagent?wsdl"
id="testEndpoint" serviceClass="pk.com.test.app.TestService">
<cxf:properties>
<entry key="publishedEndpointUrl"
value="http://ip:3456//Services/Interface/WebServices/Service.serviceagent/ChangeCustomerBasicEndpoint1"/>
</cxf:properties>
</cxf:cxfEndpoint>
Every thing is working fine, to the point when I sent the request from SOAP-UI. I get connection refused
because my publishedEndpointUrl has different port and url.
Any help on how to handle this ?

The publishedEndpointUrl will always override the cxf:cxfEndpoint address attribute.
And the wsdl address would be publishedEndpointUrl + "?wsdl"

Related

How to get rid of passing "username and password" in web service call to Pentaho transformation?

I have a requirement where 'XML-response' will be passed in web service call as parameter and it executes a transformation where XML is shredded.
I have designed the transformation in kettle and for accepting web-service request to execute transformation, Carte is up and running on my server.
So, From Server A, client is hitting web-service using URL which is something like below :
http://localhost:8081/kettle/executeTrans/?trans=C:\Carte-test\test_2.ktr&response_xml=<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<persons>
<person>
<id>1</id>
<firstname>Samatar</firstname>
</person>
</persons>
On Dev Server B, Carte is up and running and requisite transformation is executed.
But there is a glitch. How to pass "https"(secure connection) rather than "http" in the URL construct i.e. how to make the web service call secure.
My client is obstinate about it.
P.S - We are using "Pentaho 5.4 community edition and hence - no PDI :(" on server B and no Kettle Installation on Server A
Any suggestions!!
Since there is no notes in documentation how to run Carte most simple way to secure it is to run behind proxy.
Use some Apache, Nging, Caddy configure https protocol and configure proxy to Carte.
As well u can configure basic http authentication on webserver.
Yes, you can do that, and it is perfectly well documented on pentaho website. Here you have the instructions to setup a carte server with ssl :
https://help.pentaho.com/Documentation/6.0/0L0/0Y0/060/060/010#Configuring_Carte_Servers_for_SSL

Duplicating a same SOAP webservice in Camel

A SOAP webservice is been exposed by a system. I have got a wsdl file of the webservice. Im able to send request and get response from soap ui. I want to duplicate this wsdl SOAP webservice in my camel routes deployed in servicemix, thereby making my ESB expose a similar webservice as the system's webservice. THis way many systems access this webservice to contact the system.
How do i duplicate a webservice using wsdl file of the system??
To duplicate webservice, exposed by a system, you can use http proxy route, based on jetty:
<route id="ServiceProxy">
<from uri="jetty:http://0.0.0.0:8186/service/?disableStreamCache=true&matchOnUriPrefix=true&continuationTimeout=900000&httpClient.timeout=120000"/>
<to uri="jetty:http://{{app-server.host}}:{{app-server.http.port}}/service/?bridgeEndpoint=true&throwExceptionOnFailure=false&continuationTimeout=120000&httpClient.timeout=900000"/>
</route>
You can write the same route on JavaDSL.
Found solution - Concept is cxf-proxying
Having a wsdl of the system, create a similar wsdl with the Endpoints defined according to the localhost and port number.
Save the wsdl in your local project,
provide the path to wsdl in pom, for converting wsdl to java by mentioning in the cxf-codegen-plugin.
create cxf consumer bean with details of local wsdl file
<cxf:cxfEndpoint id="consumerProxy" address="http://remote:port/service/"
serviceClass="com.remote.service.RemoteService" endpointName="c:RemoteService"
serviceName="c:RemoteService" xmlns:c="http://remote/namespace/">
<cxf:properties>
<entry key="dataFormat" value="MESSAGE" />
</cxf:properties>
</cxf:cxfEndpoint>
create cxf producer bean with details of remote wsdl file
<cxf:cxfEndpoint id="producerRemote" address="http://localhost:9001/service/"
serviceClass="com.remote.service.RemoteService" endpointName="c:RemoteService"
serviceName="c:RemoteService" xmlns:c="http://remote/namespace/">
<cxf:properties>
<entry key="dataFormat" value="MESSAGE" />
</cxf:properties>
</cxf:cxfEndpoint>
The proxy routes can be like below
from(cxfEndpoint("consumerProxy"))
.to(cxfEndpoint("producerRemote"));
Sending a request to localhost will be consumed by cxf endpoint - consumerProxy and sent to the cxf endpoint - producerRemote.
The response is sent back the reverse way.

Which is better to generate the WS client from the WSDL URL or from the WSDL file?

I am using a wsdl file sent to me via email to generate a WS client application but I wonder if it is better to have the WSDL hosted on a server and to use an URL to request it.
Actually, I requested the URL but apparently this WSDL don't have one and I can ask to create an Url for the wsdl if it is really necessary.
Can you tell me please what are the benefits of using the WSDL Url to create a WS client ?
There is not difference for you how to generate WS client. In both cases this is just WSDL document, no matter where it located is.
I see only one benefit direct accessible WSDL against WSDL file - WSDL will be always actual and and all web service changes will be reflected to WSDL document.
If you using axis 2, you can try call your webservice with ?wsdl suffix to get WSDL document
if this your webservice url
http://localhost:8080/axis2/services/StockQuoteService
This is wsdl location
http://localhost:8080/axis2/services/StockQuoteService?wsdl

How to identify cxf web service end point

I am trying to creating web service using wsdl first approach and CXF. I am able to generate java file from wsdl and deploy the war file to tomcat server. However, I don't see any soapaction in the generated file. How do I identify the end point url for this web service?
thanks,
Usually in CXF you use Spring configuration to configure endpoint, as described in JAX-WS Configuration. Usually address is relative, e.g.
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:jaxws="http://cxf.apache.org/jaxws"
xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd">
<jaxws:endpoint id="classImpl"
implementor="org.apache.cxf.jaxws.service.Hello"
address="/helloService"/>
</beans>
Address is local to you web app context root.
Assuming that name of you web application is SomeWebApp and the server is available at localhost:8080 then web service should be published at http://localhost:8080/SomeWebApp/helloService. You can test it retrieving WSDL at: http://localhost:8080/SomeWebApp/helloService?wsdl. This URL can be used to create SOAP UI project (the tool that I really recommend for exploring and testing SOAP services).
If you don't use Spring to configure endpoint or you still can't access web service please provide more details about your configuration.

Webservices - SOAP vs. "XML over HTTP"

I have a general web services question and I'm hoping you can help me clear up my confusion on the subject.
I am working with a web service that the host is calling an "XML over HTTP service". They claim that this service is NOT a SOAP service, yet the response is a SOAP envelope response. The service is currently invoked via HTML form post; here is the HTML form and response:
HTML:
<FORM name=TestForm action=http://intranet/TheWSMethod enctype="text/plain" method="POST">
<TEXTAREA name=Data rows=22 cols=91 type="text" style="position: absolute; left: 78; top: 69; width:752px; height:330px"></TEXTAREA>
<INPUT type=xml>
<INPUT type=submit value="Transmit">
</FORM>
RESPONSE - SOAP Based?
<?xml version="1.0" encoding="UTF-8" ?>
<soapenv:Fault xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<faultcode>soap-env:Server</faultcode>
<faultstring>9001</faultstring>
<faultactor>/TheWSMethod</faultactor>
<detail> ... </detail>
</soapenv:Fault>
The host tells me that there is no WSDL for this process, which is where my confusion begins.
So my question is, whether or not there is/should be an existing WSDL? (i.e. are they pulling my leg or do they not understand what I am asking) or is it possible to not have a WSDL for this type of service?
SOAP is just a specialization of XML over HTTP and that response you posted does indeed look like a SOAP response (a SOAP fault actually).
This looks like a big misunderstanding, so don't assume they are pulling your leg. Try asking your question in a different way.
As for the WSDL, if this is indeed a 100% SOAP web service, do note that it is not mandatory to have a WSDL for a SOAP web service.
A web service is just an application that exposes a set of operations over the network. In order to call these operations you need to know what their name is, what parameters they expect, what types the parameters have etc, so that you know how to build your client stub.
This means the web service needs to be documented or else you would not know how to write the code that interact with the web service. This documentation can be a Word document or a PDF and you could build the client manually from that (which involves writing a lot of plumbing code for that client stub of yours) OR the documentation could be a WSDL file which unlike a PDF or Word document can be fed to a tool to generate the stub plumbing code for you automatically.
The WSDL describes the web service - and it's good practice to provide one - but the web service exists separately from the WSDL.
WSDL is mainly a locator to the web service. You can optionally generate client classes from it using some tool to access the web service.