Delphi 6 Enterprise makes building WebServices a breeze. This does not mean that one can’t build WebServices with Delphi 6 Pro or even earlier versions of Delphi. It is possible. However, since no framework exists, you’ll either have to build one yourself or use a third party toolset if it is available. In this article however, I mean Delphi 6 Enterprise whenever I say “Delphi” or “Delphi 6”. Before I go on, I’d also like to say, that in order to build WebServices with Delphi 6, you don’t really need to know the finer details of XML, SOAP or WebService. Having a good understanding (of SOAP, WebServices and Delphi’s implementation) will most definitely go a long way in better designing, building and debugging WebServices. Please read the article What are WebServices if you haven’t already. This article assumes you read the above mentioned article.
Delphi’s SOAP Architecture and Implementation
As I said earlier, SOAP itself is implementation agnostic. That said, it is important to realize that different tools implement SOAP differently. This is important to remember, since the way you develop SOAP applications depends on the implementation of the development tools you are using. In this article, I attempt to explain Delphi’s implementation and architecture of SOAP and WebServices.
Before I take you into the SOAP world as Delphi sees it, I’d like to touch upon one of the advantages of exiting distributed technologies such as DCOM, CORBA and Java RMI (Remote Method Invocation).
The one thing that these technologies have in common is the concept of a “Stub”. In terms of COM and CORBA, this is a type library (IDL). One of the advantages of having a stub, besides the fact that one gets to see the interface of the object (it’s methods and their parameters, properties etc.), is that the compiler can help detect errors in code at compile time. In most implementations of SOAP this is one aspect that is missing and developers that have no real need for some of the advantages that SOAP has to offer, see no point in using SOAP simply due to this fact.
Delphi however, has the best of both worlds. Delphi’s run time type library has been enhanced and some new classes have been provided to allow for the way SOAP is implemented in Delphi. A brand new interface IInvokable two new classes TRemotable and TRIO and the Invocation Registry, make up the core of how Delphi implements SOAP. You can read about these in the on-line help.
You should also realize, that it is not required, that one accesses an “Object” in a WebService, even though SOAP has the word Object in it. Once a WebService receives a request for a certain method, how it implements this request is totally up to the WebService. It may or may not use an object in its implementation. In Delphi however, we use objects that implement Interfaces. This is not new to the Delphi developer, so when building WebServices with Delphi, you’ll find yourself in familiar territory.
Method Invocation – Object Pascal style
In Delphi WebServices, one actually instantiates an object and invokes its methods, sending it any parameters that may have been sent in the SOAP request. It all happens seamlessly. This aspect of invoking methods and sending it any parameters that the request might contain is handled by TSOAPPascalInvoker. In fact, when writing a WebService, you need only to be concerned with describing your interface and implementing it in a class. The framework does the actual instantiation and method invocation automatically.
Figure 1: Showing the SOAP Request Cycle
Refer to Figure 1
- A SOAP Request is received by a Delphi built WebService.
- The SOAP Dispatcher recognizes this to be a SOAP Request and so, hands the Request over to the PascalInvoker.
- The PascalInvoker, parses the request. After parsing the request, It figures out the class that needs to be instantiated and the method that needs to be called. It instantiates an instance of the required class and calls the appropriate method, sending it any parameters if applicable.
Similarly, when you build a client for the WebService, and your WebService returns an object, an instance of this class/Interface is automatically created for you. That’s great is it not? Yes, that’s great when you build a WebService and the client that uses this WebService. What about when someone attempts to use your WebService and he or she is using Java on a Mac for example? Here is the beauty of it. The Delphi implementation conforms to the SOAP spec. So when others call on your WebServices, they don’t see anything untoward about the response sent back by a Delphi built WebService. It’s the way that a Delphi built client interprets the SOAP message (This is handled for you by TRIO or Remote Interface Object) that is unique. In other words, when a Delphi built client application receives a SOAP message as a response to a request, it instantiates instances it requires. That’s just the way it has been implemented. Similarly, if you build a Delphi client for a non-Delphi built WebService, you still work with objects if that is how the response gets interpreted. So it doesn’t really matter what platform the WebService is running under or the tool used to build it. If you build a WebService client in Delphi you work with classes and interfaces.
The Interface Stub
Given a WSDL file (or URL to a WSDL file) Delphi is capable of interpreting/parsing this WSDL and creating the interface and class stubs for you, no matter what platform or tool the WebService is written in! This makes it really simple to use, since you get compile time checking and further, you see the “Interface” of this WebService in a language that you are familiar with. Did you hear me mention XML anywhere in all of this? That’s because, the Delphi architecture handles it all for you. What you “see” is classes and interfaces. The XML stuff happens in the background for you.
What about the WSDL
Now lets not forget the importance of publishing the interface to WebServices we develop. This is a key aspect of SOAP. For someone to use our WebService, we need to publish a WSDL file that describes our WebService in terms of a WSDL (as per SOAP Specs.). Now, we really have to work with XML, since a WSDL file is really an XML document. Well, even here, Delphi comes to the rescue. A WebService application you built with Delphi is capable of generating a WSDL file automatically based on the Interface you describe and any special types (also known as complexTypes) you may have declared. So essentially, even this aspect of SOAP is taken care of for you by Delphi.
I can image that a lot of the things I've said in this article don't make much sense. It seems to be out of context in a way. I suggest you read the next few tutorials and you'll find things will start to fall in place. Unfortunately, there is so much to be said about so many things, that I can't say much about one thing without including the other. So please bear with me.
