Need a practical example? Try this one: you create an online store (I know that is so '90s, but bear with me). Customers visit your site and buy goods that you ship, using a carrier of your choice. Great. That is until a week goes by and no package shows up, so the customer revisits your site to track the order. You display the order information, complete with the shipper information and tracking number, allowing the customer to check on the delivery (and maybe, as you are so customer-service driven, you even provide a direct link to the shipper's site). Problem solved. Right?

Wrong! If you have an online store, the last thing you want is customers wandering off to other sites; you want them to stay and part with their hard-earned money. You never want to send them off to fedex.com or ups.com or any other site. Amazon.com doesn't do this - they show shipping information provided by those companies right in their own pages, the customer goes nowhere.

I have no idea what systems the shipping companies use, I don't know what software they use, and I have no access to it anyway (I am guessing the same is true for you). Amazon.com is a very significant player in the e-commerce space, the shipping companies are likely to work with them to provide them with access to this kind of data. But what about the rest of us? How could we do the same?

The answer is Web services (predictable, I know, sorry). If the shipping companies created a Web service that exposed tracking information, any application could submit a real-time request for the data, and then process or display it as needed right within their own pages. In other words, the client browser talks to your application; your application talks to the shipper via their Web service, retrieving the necessary information; and then your application displays it as needed.

Fantasy? Well, that depends on who you ship your products with. But some shipping companies have indeed made Web services available. It's not fantasy at all.

Web Services Lingo
Okay, so now that you know why you need Web services, let's review some of the lingo you'll need to use (drop these in conversations to sound like a seasoned pro):

When you use a Web service you consume it, and when you create a Web service you publish it.

Consuming Web Services
Enough talk, let's try this thing. In ColdFusion, Web services are consumed using the <CFINVOKE> tag. <CFINVOKE> requires the URL to a Web service's WSDL, the name of the method to invoke (a single Web service may expose multiple methods), and any required parameters.

The following is a simple example. It invokes a Web service on my own Web site - this one returns my ColdFusion Tip-of-the-Day:

<!--- Get tip for today --->
<CFINVOKE WEBSERVICE="http://www.forta.com/cf/tips/syndicate.cfc?wsdl"
METHOD="Get"
DATE="#Now()#"
RETURNVARIABLE="DailyTip">

As you can see, the Web service itself is specified using the URL to its WSDL file. ColdFusion retrieves and reads this file so as to know how to interact with the Web service, and how to call the method specified in the METHOD attribute. RETURNVARIABLE is the name of a ColdFusion variable to be populated with whatever results are returned. In this example my Web service returns a ColdFusion structure, and so DailyTip will be a structure containing the tip.

If you want to try this example you can use <CFDUMP> to display the results, like this:

<CFDUMP VAR="#DailyTip#">

You'll notice that there is no XML here, no SOAP, nothing beyond a simple tag call. ColdFusion hides all the complexity from you - it does not matter what is on the other end, what language it was written in, what data type it returns, what platform it runs on - none of that matters. All that is important is that the returned data is ready to use just like any other ColdFusion variable.

Here is another example, the same Web service call, but this time using a slightly different calling convention:

<!--- Get tip for today --->
<CFINVOKE WEBSERVICE="http://www.forta.com/cf/tips/syndicate.cfc?wsdl"
METHOD="Get"
RETURNVARIABLE="DailyTip">
<CFINVOKEARGUMENT NAME="date"
VALUE="#Now()#"/>
</CFINVOKE>

As you can see, arguments may be specified as name=value pairs in <CFINVOKE>, or passed to nested <CFINVOKEARGUMENT> tags - the choice is yours, the end result is the same.

Let's look at a complete example. Alta Vista has a translation engine named Babel Fish - pass it text and a destination language and it returns the translated text to you. The Babel Fish service requires two pieces of information, the text to be translated, and the translation mode (from what to what, for example en_de to translate English to German). See Listing 1 for a complete working application. It prompts for text and a destination language and displays the translation.

As you can see, using Web services in ColdFusion is easy. I have no idea what the Babel Fish Web service is written in or what platform it runs on, nor do I care - the important thing is that I can invoke it and it just works. And that is the beauty of Web services.

Note: Looking for a Web service to experiment with? Try www.xmethods.net.

If you are using Dreamweaver MX you'll find that Web services are even easier to use. In Dreamweaver, open the Application window, click on the Component tab, and then change the dropdown to Web services. Dreamweaver will list any known Web services (the list will be empty if this is the first time you are doing this). Click the + button and you'll be prompted for the WSDL URL of a Web service - simply enter it, and click OK. Dreamweaver MX will retrieve the WSDL, process and parse it, and will then display a tree of Web service methods and arguments. Then all you need to do is drag the desired method into your ColdFusion code, and Dreamweaver will create the <CFINVOKE> call for you automatically.

Publishing Web Services
Now that you know how to consume Web services, let's look at how to create and publish them. ColdFusion MX makes creating Web services incredibly easy - they are created as ColdFusion Comp-onents (explained in detail in CFDJ, Volume 4, issues 6, 7, and 10).

Here is a simple ColdFusion Component. The file is named random.cfc, and it contains two methods: (1) Get returns a random number and (2) GetRange returns a random number within the specific range. (Okay, not the most glamorous examples, but they'll have to do). See Listing 2 for the code.

The CFC code itself is rather simple. Get accepts no arguments and returns whatever is generated by Rand(); GetRange() accepts two required numeric arguments and passes them to RandRange() returning the results. This CFC can be used within your ColdFusion code using <CFINVOKE>, <CFOBJECT>, or CreateObject().

So what makes this a Web service? The answer is the ACCESS level. Each of the <CFFUNCTION> tags has ACCESS="remote". Any ColdFusion Component methods with an ACCESS level of remote can be accessed remotely - as Web services; it's as simple as that.

What about the WSDL file you need? ColdFusion does that too. The WSDL URL is the URL to the CFC with ?wsdl appended to it. I saved my random.cfc in my test directory, so the WSDL URL is http://localhost:8500/test/random.cfc?wsdl.

Listing 3 is sample code showing this CFC being used as a Web service.

Of course this particular CFC could be invoked as a CFC rather than as a Web service (and probably should be as it is ColdFusion and it is local). But with no extra work, the ColdFusion Component can also be used by:

• Other ColdFusion servers
• .NET
• Java
• PHP
• Client-side Flash

Conclusion
Web services are all the rage right now. While the hype will die down a bit, all indications are that this is an important technology and one that will play an important role in application development now and in the foreseeable future. And best of all, as a ColdFusion developer, you have nothing to lose and lots to gain - it does not get much better than that.