WebServices are - No wait! I'm not going to give you yet another definition. If you're like me, you'll probably understand it better with as example. That's what I'll try and do.
So here is a simple example. Lets say, FedEx has a WebService that allows customers to get information regarding a certain package, given the shipment no. So if you access this WebService, call it's method and supply the shipment No. you'll be given the estimated date and time of receiving your package. This sort of thing is easy to perceive in terms of a web site and user interface is it not? Well, WebServices are really very similar except with one key difference. They allow for non-interactive access. That is, machine to machine communication, without the need for human intervention.
Lets say, you were building a large system and one of it's functionalities was to be able to retrieve information about a certain FedEx package given the Shipment No. What you will do then, is use the "service" provided by FedEx to do this non-interactively (without human intervention) through your system.
Lets imagine that there are other similar "services" you could utilize in your system and you'd like to use these services rather than have to build them yourself. Essentially, you are building a system by "re-using" components that someone else has built and made available to you. It does not matter to you, what platform the service is running under or what tool was used to develop it. All you really care about is that you can find out how to use the service. This means your system is effectively decoupled from these "services" since you're not tied to using these services on a certain platform or using a certain development tool.
Lets sum it up now:
- Re-useable "components".
- Platform agnostic.
- Implementation agnostic.
- Following certain published specifications/standards.
- Decoupled or loosely coupled.
That's what WebServices are all about. The ability to build distributed systems that are loosely coupled, dynamically integrated, using re-usable "components".
SOAP for the Delphi developer
SOAP (Simple Object Access Protocol) is an XML application. That's how everyone describes it. I prefer to say, SOAP is an application of XML (i.e. a way in which XML can be used). XML-RPC (XML Remote Procedure Call) is SOAP's predecessor. A company called UserLand Software developed XML-RPC back in 1998. XML-RPC later evolved into SOAP as a more mature protocol and is supported by big names in the IT industry such as, IBM, Microsoft, Sun, Apache etc.
Why SOAP
As if we don't already have our plates full with tons of other technologies/buzz words huh? Well, this one really does make sense. To better understand why, we need to take a look at what technologies SOAP intends to replace and the problems with these technologies today.
Most distributed systems today use technologies such as DCOM and CORBA. Systems built with these technologies are:
- Tightly coupled.
- Often platform specific and therefore not interoperable.
- Need to be configured on the client machines.
- Have security issues, primarily when it comes to firewalls and the ability to get past them without having to punch holes through them to get them to function normally.
SOAP sets out to try and overcome most of the issues cited above. Probably, the most important aspect of SOAP is not technology, but the fact that everyone (well, everyone that matters or can make a difference) has agreed to work together and formulate standards and adhere to them. The rest of what SOAP is, is really these specifications that everyone has agreed to abide by. So SOAP is not some fancy new technology. It is a simple technology (if you want to call it that), we're only just using our heads this time around, learning from mistakes in the past. Swallowing our egos and pride and making the effort of working with competitors to provide the rest of us with a Simple Object Access Protocol (that fit quite well didn't it?)
So SOAP sets out to achieve:
- Interoperability.
- Decoupled distributed systems.
- Easy access through Firewalls etc.
The need for configuration still remains, as this depends on the software used to build the client applications. Configuration issues related to security will most probably not exist on the client.
Essentially, if you want to use a "service" you should not need to know the platform on which this service is running and nor should you be concerned about the implementation details. This is very similar to HTTP and Web Browsers. You can use a Web Browser today and surf the world wide web without the need to know what kind of server is serving you the web pages (platform, server vendor etc.) nor how it is serving you these pages (implementation - static pages, dynamic pages, ISAPI, ASP etc.). All you should need to know, is:
- What are the methods of the service and parameters to these methods, and the types of these parameters (string, integer etc.)
- If a method is returning some information, then what are the details of that (parameters, types etc.)
SOAP is a W3C recommendation and is being supported by most of the big names in the industry (IBM, Microsoft, Developmentor, Apache, Sun etc.). To me, it looks like everything is going to be a WebService in some form or the other. Microsoft' s .NET strategy also revolves around SOAP.
Wire Protocol
SOAP is a wire protocol. What that means is SOAP is used across the wire or SOAP comes into play between the two end points. When information needs to be sent across the wire, SOAP is used. It doesn't matter what was used to send it across the wire and it doesn't matter what technology is used once it gets to the other end (You are free to use COM/DCOM and/or CORBA etc. at the client end and server end). To this end, SOAP is (transport) protocol agnostic. You're free to use any transport protocol such as, HTTP, FTP, SMTP etc. however, most implementations of SOAP use HTTP as the transport protocol. There are additional specifications for SOAP bindings to HTTP as well. I personally think, HTTP is probably going to be used by 95% of SOAP implementations (but that's my personal opinion).
For those of you who are interested and know something about HTTP, a typical SOAP packet (including HTTP header) might look like this:
Showing a typical HTTP Header and SOAP Envelope.
POST http://webservices.matlus.com/MyService HTTP/1.0
Accept: application/octet-stream, text/xml
SOAPAction: "urn:MyServiceIntf-IMyService"
Content-Type: text/xml
User-Agent: Borland SOAP 1.1
Host: webservices.matlus.com
Content-Length: 521
Proxy-Connection: Keep-Alive
Pragma: no-cache
<?xml version="1.0" encoding='UTF-8'?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/1999/XMLSchema" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:SOAP-ENC=http://schemas.xmlsoap.org/soap/encoding/>
<SOAP-ENV:Body>
<NS1:MethodName xmlns:NS1="urn:MyServiceIntf-IMyService" SOAP-ENV:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/>
<NS1:MethodParameter xsi:type="xsd:string">ParameterValue</NS1: MethodParameter>
</NS1:MethodName>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Why HTTP as a Transport Protocol
HTTP probably has the largest investment in infrastructure today. The WWW uses HTTP (Web servers) primarily. HTTP is a stateless protocol and so is highly scaleable since it can service 100s even 1000s of requests seemingly simultaneously. Most organizations today have firewalls for protection. HTTP traffic is generally allowed past these firewalls and so SOAP traffic can get in and out without the need to configure firewalls. There are some HTTP headers that SOAP messages must contain and so firewalls can be configured to block SOAP messages if so desired ( The SOAPAction HTTP header is one of them. If you look at the HTTP Header above, you'll see it there). Currently, SOAP uses port 80, which is the standard for the HTTP protocol. This may change in time, but for now it is port 80.
WebService Description Language (WSDL)
This is one of those things that the powers that be have agreed on. A language that is capable of describing a web service. Essentially, the information you are able glean from a WSDL file (it's an XML file) are:
- Where is the WebService located (the URL)
- What are the methods available
- What are the parameters and type of these parameters
- What is being returned (if anything) and what are the types
Given the above information, it should be simple enough to be able to use this service, without consideration of the platform on which the actual service is running on and it's implementation details.
Ideally, given a WSDL file for a specific WebService, you should be able to build a client application that uses the services of this WebService. If the SOAP and WSDL specs are adhered to, you have all the information you need to start using the service. Similarly, when you build a WebService, you should make sure you adhere to the SOAP and WSDL specs and publish a WSDL file so others can access your WebService without a problem.
WebServices Today and Tomorrow
WebServices have been accepted by the IT industry. There is no question about that. This is good, since it means we're all in agreement. That's the first step. As things stand today, the WebServices available to use are primarily toys. People are feeling their way around, building simple to use WebServices, while others build WebService clients to test issues such as interoperability, usage etc. As a Delphi developer, I strongly urge you to part take in this endeavor. There are a number of websites that host WebServices. My new website at http://www.delphisoap.com/ is one of them. There are others such as:
- http://www.xmethods.com/
- http://www.salcentral.com/
to name a few. Using these services listed at these sites, one can build clients for these web services using Delphi quite easily.
Please note, that things will not always be smooth sailing. This is due to a number of reasons, some of them are:
- Some of these services were built conforming to earlier specs
- Due to constantly changing specs. Delphi implementation may not always be current. I'm sure Borland on their part will do their best to release patches, fixes, upgrades etc. as soon as possible.
There are about 35-40 implementations of SOAP today. Each employing different methodologies or catering to different platforms and development tools. Most of them are free and most of them do their best to conform to the SOAP spec. At this point in time, differences in conformance are to be expected.
Let the games begin!
