I'm adding a service reference using a WSDL and XSDs on a local drive. I've done this many times in the past and the client class generated derives from System.ServiceModel.ClientBase. For some reason, the only client class I get is derived from System.ServiceModel.DuplexClientBase.
I've tried unchecking "Allow generation of asynchronous operations" but I still only get one client class derived from DuplexClientBase.
How can a get a "normal" client derived from ClientBase?
I just tried one of the other WSDLs again and it generated the "normal" non-duplex client. Is there something specified in the WSDL that forces a duplex client only?
The WSDL defined one out of several operations with an output element only. When I removed this operation and re-generated the proxy, it created a non-duplex client as expected. Luckily, we do not need the "blahNbrChg" operation.
<wsdl:portType name="BlahPortType">
<wsdl:operation name="blahNbrChg">
<wsdl:output message="tns:blahNbrChgSoapOut"/>
<wsdl:fault name="fault" message="tns:soapFault"/>
</wsdl:operation>
<wsdl:operation name="xxxControl">
<wsdl:input message="tns:xxxControlSoapIn"/>
<wsdl:output message="tns:xxxControlSoapOut"/>
<wsdl:fault name="fault" message="tns:soapFault"/>
</wsdl:operation>
Related
I deployed exactly the same WS-proxy in 4.5.1 and 4.6. With 4.5.1 it works correctly, but with 4.6 I get:
ERROR - AxisEngine The endpoint reference (EPR) for the Operation not found is /services/registro.registroHttpSoap11Endpoint and the WSA Action = . If this EPR was previously reachable, please contact the server administrator.
The source is the following:
<proxy xmlns="http://ws.apache.org/ns/synapse" name="registro" transports="http" statistics="disable" trace="disable" startOnLoad="true">
<target>
<outSequence>
<send/>
</outSequence>
<endpoint>
<address uri="http://localhost:15080/SIGEM_RegistroPresencialWS/services/ServicioRegistroWebService"/>
</endpoint>
</target>
<publishWSDL uri="http://localhost:15080/SIGEM_RegistroPresencialWS/services/ServicioRegistroWebService?wsdl"/>
<description></description>
</proxy>
What do I have to do for 4.6. to make it work?
Thanx.
To enhance ESB performance pass-through transport has been enabled by default starting from ESB 4.6.0 version that is not the case for ESB 4.5.1. It seems your proxy service depends on SOAP body based dispatching but pass-through transport does not support for SOAP body based dispatching. SOAP body based dispatching build the message body and use first element's local name for dispatching which effect to proxy performance badly that is the reason it was not supported in pass-through transport. We are in a process to fix this limitation for future ESB releasees without loosing any advantage of pass-through transport.
BTW for the moment you can use one of the following workarounds.
When sending a messages to the proxy service append operation name to the endpoint URL
e.g - http://serverName/app/serviceName/operationName
Modify client level code to send expected SOAPAction value ( like Try-It case)
I'm not sure your backend service's WSDL defined "" as the value of SOAPAction if that is the case you may modified the backend service to have value other than "" per each operation. AS an example for JAX-WS services you can use #WebMethod annotation for this.
e.g - #WebMethod(action="XXXX")
Note : In case if your backend WSDL defining a value other than "" for SOAPAction while your client send message with SOAPAction="" then it's a violation of service contract by the client and need to be fixed on client level.
I have faced the same problem with wso2 ESB 4.7 and the web service is also developed by me for the company.
What worked for me is adding soapAction attribute to wsdl soap:operation element like below.
<soap:operation soapAction="http://localhost:8080/MyWebApp/services/hello" style="document"/>
We have CXF based SOAP web services and we are hitting these services from SOAP UI with no problem. With one of these services, I setup a ProxyService on barebone WSO2 ESB 4.6.0. The proxy service seems to be working with the "Try It" option from the admin console. When I try to access it from SOAPUI, the WSO2 ESB starts complaining that
"The endpoint reference (EPR) for the Operation not found is /services/HelloWorldProxyService and the WSA Action = . If this EPR was previously reachable, please contact the server administrator."
Now, when I change the endpoint URL in SOAPUI as http:// hostname:8280/services/service-name.port-name/operation-name things start to work.
Does anyone know how to fix this issue? Are there configuration options on the WSO2 ESB which will let us use traditional SOAPUI with WSO2 ESB?
You can point the proxy service url(you can view this, via service dashboard of the particular proxy) in soapui and for the "action", in the insequence of the proxy define a property call;
. header name="Action" value="soap action"
Here is the guide on vailable properties
http://wso2.org/project/esb/java/3.0.0/docs/properties_guide.html
I have the same problem if I put operation1 at the end of WS URI (http://somedomain.com/WebServiceProxyName/operation1), but post a SOAP message body with constructs for another operation(operation2,3,4,5...) it works!!!
Sample
POST http://somedomain.com/..../operation1 HTTP/1.1
....
....
<soap:Envelope ...>
<soap:Header/>
<soap:Body>
<ws:operation2>
</ws:operation2>
</soap:Body>
</soap:Envelope>
Try to change the (original) WSDL and put the soapAction there:
You can define it as an attribute of the http://schemas.xmlsoap.org/wsdl/soap/:operation element in the binding section, e.g.
<wsdl:binding name="healthcheck-1.0.0SOAP" type="tns:HealthCheck100PortType">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="doHealthCheck">
<soap:operation soapAction="http://www.xyz.ch/healthcheck-1.0.0/doHealthCheck"/>
I am exposing a wcf service over https from iis 6. I have verivied, as best I understand, that the binding is correctly set in iis (yes, positive that the site id is '1', and have done iisreset).
when I run this:
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC>cscript.exe //NoLogo %sys
temdrive%\inetpub\adminscripts\adsutil.vbs enum W3SVC/1
this is in the list:
SecureBindings : (LIST) (1 Items)
":443:dev.mydomain.com"
When I open the url to the service, I can see that it is correctly generating a url to the wsdl:
this:
https://dev.mydomain.com/virtual.directory/servicename.svc
specifies this url for svcutil.exe:
https://dev.mydomain.com/virtual.directory/servicename.svc?wsdl
However, when I inspect the wsdl itself, it stops using the domain, and replaces it with the machine name in this section of the wsdl xml:
<wsdl:service name="servicename">
<wsdl:port name="BasicHttpBinding_servicename" binding="tns:BasicHttpBinding_servicename">
<soap:address location="http://machinename.inernaldomain/virtual.directory/servicename.svc"/>
</wsdl:port>
</wsdl:service>
Is my problem a web.config issue, or an IIS issue? Also, why does it change the soap address to http from https?
Stupid mistake... I named my binding in the web config, but did not specify that binding to the service. All I had to do was clear the name of the binding . The simplified configuration for wcf services makes it so you dont have to specify a binding. In my case I just did not realize it was not seeing my binding (no error), and was using defaults. http://msdn.microsoft.com/en-us/library/ee530014.aspx
I have a WCF service. I built from an xsd file from another department. All it generated was classes, which I inturn modified to match our "standards". I need to see if the wsdl for that function matches the xsd, well actually the wsdl for one of the inputs, matches what they gave us.
http://localhost:26535/EDeliveryOrderSvc.svc?wsdl
shows the wsdl for the entire service. the section for my function:
<wsdl:operation name="CreateOrUpdateOSSOrdersFromEntityInput">
<soap:operation soapAction="http://[redacted]/EDeliveryOrderSvc/CreateOrUpdateOSSOrdersFromEntityInput" style="document" />
<wsdl:input>
<soap:body use="literal" />
</wsdl:input>
<wsdl:output>
<soap:body use="literal" />
</wsdl:output>
</wsdl:operation>
doesn't tell me anything about the input parameters. Am I missing something simple?
You should see a line in the wsdl that says:
http://localhost:26535/EDeliveryOrderSvc.svc?xsd=xsd2
or some such, go there to see the schema info.
I am trying to add a web service reference to my C# application in Visual Studio. The web service is hosted on Sun's GlassFish server. Unfortunately Visual Studio produces the following warning when I try to add the service reference:
Custom tool warning: The following Policy Assertions were not Imported:
XPath://wsdl:definitions/wsdl:binding[#name='SecurityWebServicePortBinding']/wsdl:operation[#name='RegisterUser']
Assertions:
<wsat:ATAlwaysCapability xmlns:wsat='http://schemas.xmlsoap.org/ws/2004/10/wsat'>..</wsat:ATAlwaysCapability>
Apparently it cannot understand policy assertions in the WSDL published by the GlassFish server. Here's an excerpt from the WSDL:
<?xml version='1.0' encoding='UTF-8'?>
<definitions
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:wsp="http://www.w3.org/ns/ws-policy" xmlns:wsp1_2="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="http://test/securityservice.wsdl"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://schemas.xmlsoap.org/wsdl/"
targetNamespace="http://test/securityservice.wsdl"
name="SecurityService">
<wsp:Policy xmlns:wsat="http://schemas.xmlsoap.org/ws/2004/10/wsat" wsu:Id="SecurityWebServicePortBinding_AuthenticateUser_WSAT_Policy">
<wsat:ATAlwaysCapability />
<wsat:ATAssertion xmlns:ns1="http://schemas.xmlsoap.org/ws/2002/12/policy" wsp:Optional="true" ns1:Optional="true" />
</wsp:Policy>
<wsp:Policy xmlns:wsat="http://schemas.xmlsoap.org/ws/2004/10/wsat" wsu:Id="SecurityWebServicePortBinding_RegisterUser_WSAT_Policy">
<wsat:ATAlwaysCapability />
<wsat:ATAssertion xmlns:ns2="http://schemas.xmlsoap.org/ws/2002/12/policy" wsp:Optional="true" ns2:Optional="true" />
</wsp:Policy>
...
<binding name="SecurityWebServicePortBinding" type="tns:SecurityWebService">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" />
<operation name="RegisterUser">
<wsp:PolicyReference URI="#SecurityWebServicePortBinding_RegisterUser_WSAT_Policy" />
<soap:operation soapAction="RegisterUser" />
<input>
<wsp:PolicyReference URI="#SecurityWebServicePortBinding_RegisterUser_WSAT_Policy" />
<soap:body use="literal" />
</input>
<output>
<wsp:PolicyReference URI="#SecurityWebServicePortBinding_RegisterUser_WSAT_Policy" />
<soap:body use="literal" />
</output>
<fault name="UsernameExistsException">
<soap:fault name="UsernameExistsException" use="literal" />
</fault>
</operation>
</binding>
...
</definitions>
If I remove all the policy elements from the WSDL, Visual Studio is able to consume the service without any problems (in fact earlier I used to write the WSDL by hand and never put the policy statements). So my questions are:
Why is GlassFish insisting on adding the policies? Is there any way to suppress them?
Why is Visual Studio not able to consume the WSDL with the policies?
ws-AT (Atomic Transactions) seems to be part of the SOAP specification which WCF does not know about.
There is some information here - http://schemas.xmlsoap.org/ws/2004/10/wsat/
Update: Actually WCF is aware of the ws-AT spec, but doesn't support it fully (http://schemas.xmlsoap.org/ws/2004/10/wsat/). I suppose this is because WCF has alternatives which use OleTransactions.
Ok, I figured out why GlassFish is adding the ws-AT policies. My web service is being generated using an EJB (see below):
#Stateless
#WebService
public class SecurityWebService {
...
}
Since the default transaction attribute for a stateless EJB method is REQUIRED, GlassFish is making the web service method transactional too (see here for details). Not the behavior I want, but that's how it is!