Delphi SOAP programming was a hot-topic in 2002. And Delphi 7, the current release at the time, was shipping with a series of webservice demos. These were still part of the product until Delphi 2007, and Delphi 2010. These days REST+JSON is a bigger deal than SOAP,but SOAP is still an incredibly important part of the "business integration" layer of the internet. My employer's products give me a first-hand view of the importance of SOAP. It will remain an important part of internet-based B2B connectivity, for the future. Yes, JSON+REST will also be used, but Delphi developers these days need to know both, because eventually someone will need a SOAP server or client interface to your big in-house or vertical market Delphi application. SOAP based services are incredibly important.
However, a strange thing happened; The Web App Debugger (WAD) which was always the weirdest part of the WebServices architecture in Delphi, went away. That left you with WAD-based demos that didn't work any more, and CGI based demos that required either Apache or IIS with CGI support, to run Delphi apps through an external web server. Hardly an easy way to develop, prototype, or demo web-services. Then Delphi 2010 introduced (and XE and XE2 continue to have) the ability to have the SOAP Web Services new-application wizard make an INDY VCL server. That made the server application into a tiny normal VCL application. While that's still not the best way to deploy a large-scale production environment, it's pretty useful for debugging, and can also be a reasonable way to deploy certain very-lightweight (internal LAN, not internet-facing) SOAP server systems, for 1 to 100 concurrent connections, or so.
Anyways, the demos were just plain not anywhere to be found in Delphi XE, and are still gone from XE2. When I needed to make a SOAP server and client and make them talk, there wasn't a demo anywhere to be found that ran in Delphi XE. Now XE2 is the current version and the mess continues. I asked a question almost a year ago (June 2011) on stackoverflow, that got a lot of not-quite answers, and a few links to tutorials, but no code, and no demos.
So I fixed the demos, and I've posted them on CodeCentral. They're here (item 28789) on CodeCentral. I have tested all of them on Delphi XE, and tested most of them on XE2, and they all build on both, and run perfectly well on XE. If anybody finds any bugs in them, please email me (my email address is in the readme).
I intend to update that code-central article with new versions when needed, if new Delphi language changes make it possible. My next SOAP demo will be VisualStudio/WCF/C# interop demo between Delphi and C#/WCF. I would like to add a Java interop demo too. I'm awaiting word from Embarcadero if they'll allow me to turn this set of demos into an open-source project so that we can get Delphi+SOAP demo contributions from all over the place.
I hope you find them useful if you are interested in SOAP programming with Delphi XE, and are wondering where all the demos for SOAP applications programming went.
Hi Warren! Thank you for your efforts in Delphi SOAP; I've recently had to look into SOAP for Delphi for a larger project at work. The historical feedback I find is that SOAP for Delphi is improperly implemented, buggy and leaks memory. Could you give me your input on that, please? I am hopeful that the current implementation is usable.
ReplyDeleteHello Henri,
ReplyDeleteThe current implementation is quite usable, and stable, and if it leaks memory it's because you have done something wrong when you imported the WSDL. The defaults that you can choose among in the WSDL are important, and you must know a bit about how to use the WSDL import tool properly before you can use it. This is why people think it's improperly implemented. The defaults in WSDL import are hardly user friendly. Secondly, the results of an WSDL import sometimes need some manual changes. This requires some skill and knowledge.
The biggest alternative WCF for .Net benefits from the managed memory model and the .net reflection capabilities of .Net, and therefore binary and memory management issues that you might find more challenging in a pure native environment (Delphi) are easier in .Net. But .net is a big fat runtime, and you get to deal with .net runtime bugs instead.
Delphi is far far easier to produce and consume SOAP with than, for example, Visual C++, the nearest competitor for native code, and far faster in overall code performance than .Net. So for me, Delphi and SOAP are still viable. However debugging it is difficult until you install some tools. At least get Fiddler2 on your computer.
Warren
Thank you Warren :)
ReplyDeleteType a = class(TRemotable)
ReplyDeleteprivate
published
end;
b = class(b)
private
published
end;
Hi, you have any sample where use TRemotable descends...
The clients fail connect and the wsdl import is incomplete...
Thank's
This comment has been removed by the author.
ReplyDelete