Hi,
All the method/operation names are now prefixed by the service name and “___”. Is this an option that can be disabled or is it a regression in the latest release?
HI.
This was done to satisfy document literal naming conventions. In this case third-party importers (like native Delphi for example) produces more simple code.
Hi Slavad,
Can you explain to me how this is better?
Consumer code for native Delphi and .NET looks ugly and this actually breaks my API for existing 3rd party clients (they use native importers). I cannot update my production code to this version! No other SOAP WS framework I have worked with does this to WSDL.
I looked at uRODLToWSDL.pas and do not see an option to disable this on the TROSOAPMessage component.
Hi.
Old clients should work without changes with new server. What third-party client you are using?
My customers use mainly .NET, PHP, Python, and Java clients to natively consume the SOAP API built with RemObjects SDK. If I extend my API and my customers regenerate interface code from my WSDL, then they will need update everywhere in their code where the operation names changed. The new operation names are terribly ugly. I need to update all my API documentation with the ugly operation names and I still do not see how it produces simpler code.
RemObjects SDK uses Document/literal wrapped style. It is described for example here http://www.ibm.com/developerworks/webservices/library/ws-usagewsdl/index.html. But old wsdl didn’t match to rule 4 (Input Wrapper Element name should match with Operation name). Native Delphi wsdl importer in this case produces unnecessary classes.
Dear Slavad,
is it possible to add a property to use the old operation names? For use is more important to have a “pretty” names than to follow the Document/literal rules. Our problems are the same than Genasys problems.
Thank you,
Mario
Hi.
We will add possibility choose what naming convention use, this is logged as 59382.
Thanks!!!
When are you planning to make a release with that property? We are planning a new version on december and we need this property.
Best regards
I am not sure that it will be included in our next release but if not we will send you a fix.
Dear Slavad,
I’ve tested the new version with the new property. It works correctly if I published the web services using encoding sRPCEncoding (SOAPMessage). When I use encoding sDocumentLiteral I can not consume the web services from an application created in C#. The server is made in Delphi using RemObjects. The client is made in C# and I’m not using RemObjects. The WSDL definition uses the “short names” but it seems that C# is expecting to receive the “long name” MyServiceName____Sum".
Best regards,
Hi.
Sorry for delay. This issue was fixed. Give us your email and I’ll send you fixed source file.
Dears,
after receive and test the fix, we found another problem. Our clients uses our server to consume the web services and create custom applications. After the update, that custom applications receive and error “Deserialize”. It seems that internally the names are still using the new long name despite we set the property to use the short names. Then, it is necessary to recompile ALL custom applications to consume the web services. It is a critical bug for use because our clients have hundreds of applications to “migrate” and, by contract, we give them backward compatibility.
Hi,
can you give your RODL and example of actual and correct server response, please?
You can send it to support@remobjects.com
I also have a problem with this version. The webservice is compiled with the new version of uRODLToWSDL.pas, SOAP, document literal. When the webservice is consumed in c# and it does a call to the webservice, it’s receives a message “parameter name cannot be empty” .
This happens on IIS 6. I also tested this with IIS7 and IIS8, it seems to work correctly on those.
************** Exception Text **************
System.ServiceModel.CommunicationException: The server committed a protocol violation. Section=ResponseHeader Detail=Header name is invalid —> System.Net.WebException: The server committed a protocol violation. Section=ResponseHeader Detail=Header name is invalid
at System.Net.HttpWebRequest.GetResponse()
at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)
— End of inner exception stack trace —
Can you send a small test case, please? You can send it to support@remobjects.com
Testcase is in the mail
Sorry,
I prepared a small test and I can’t reproduced the error that I mentioned. I suppose that I made a wrong test the first time. So the file that you send me with the fix works perfectly.
Best regards,
Mario