Web Services are on the way, and although the concept of remote access to server-side logic isn't anything new, the topic has taken on a whole new meaning in light of Microsoft's recent unveiling of the .NET platform. New initiatives are putting the focus squarely on making business logic available over the Internet, using a variety of 3 and 4-letter acronymic standards. These key technologies are XML, HTTP and SOAP (the Simple Object Access Protocol).
It's about time! Up until recently, the Web has been used mainly for HTML-based content, which has made it very difficult for applications to consume data available on the Web. Think about how much useful information is available on the Web and then think about all the times you have decided to not use it, because of the hassles of parsing HTML or of having the site layout change and ruin your use of the data.
XML and new protocols running on top of it are finally taking steps to provide a unified platform that makes information exchange between separate business entities a more seamless process. Technologies like SOAP can make it drastically easier to share information between clients and servers or between servers and other servers. Instead of depending on tightly coupled application logic, you can now use generic Web Services to publish information broadly, with a specific service description that tells what services you provide. This opens up the world, not only for pure Web applications, but also for standalone desktop applications that are too complex to run in a browser.
The latter point is an important one - Web Services allow applications to move back to the desktop, even if they need to take advantage of the Web. Although there are many uses for Web-only applications, many shrink-wrap, vertical and commercial applications are simply too rich to run entirely in a browser environment. Many users are also much better served by a rich Windows application as opposed to a dumber HTML/DHTML interface. Web Services make it possible to continue using desktop technology, while retrieving part or even all of the data from the Web. At the same time, identical functionality can be made available to browser and server-based applications.
The idea behind Web Services is deceptively simple: It's really nothing more than making a remote method call by passing parameters and receiving a result in return. It's a function call over the Web! No more messing around with packaging up and unbundling parameters into XML and back - the plumbing is handled automatically for you.
Creating and consuming Web Services will be easier than ever in the future with the .NET Framework, VisualStudio.NET and other tools, where SOAP is part of a serialization mechanism for classes and methods. Creating a SOAP-based Web Service is as simple as setting a flag (an attribute in .NET-speak) on a method in a class. On the client side, you can simply point at a Web Service Description and receive information about the service, similar to how you can interact with a local COM object today.
.NET is still quite a way off, though. Today, you can use custom tools like the MS SOAP Toolkit (COM) or custom implementations like wwSOAP (Visual FoxPro), SOAP Lite (Perl) and Apache SOAP (Java and C++), that let you call and create Web Services easily with just a few lines of code. It's not quite as simple as setting a Web Reference, but it still takes only a few lines of code. This leaves you to mainly worry about implementing your business logic rather than dealing with the network plumbing and protocols.
Web Services will change the way you think about components. Like COM components over the last few years, which forced us to think outside of the current application and moved many of us into n-Tier development, Web Services will force us to think outside of the company or enclosed network environment. A Web Service has to follow a few simple and specific rules to be accessible to the outside world - but it can then be accessed from anywhere. The potential for services provided for a fee (or for free) is amazing. A lot of content that comes from within an organization today will soon come instead from dynamic services sitting on the Internet. It's a connected world, and the concept of Web Services has the potential to pull it all together into a unified whole. Web Services promise to do for applications what the Web browser did for interactive use of the Internet. It won't happen overnight, but the promise is there and the future looks very bright.
The details aren't all in place yet. The SOAP spec is still in flux and various implementations barely work with each other - we've spent way too much time making custom SOAP client/server implementations work with others, as the specs are interpreted differently. That has to be fixed, and soon, if Web Services are to succeed. For example, there is no official specification for discovering services, although there are proposals in the works as we speak. There's WSDL, which is used for describing a Web Service and its exposed interface; and DISCO, which is a very rough spec at the moment that allows Web sites to publish the Web Services they provide. DISCO provides links to the Service Descriptions and acts as sort of a service directory.
Both of these initiatives were started by Microsoft, which is getting the usual rebuff from the anti-Microsoft camp, so this process is definitely not on a fast track. DISCO is hardly a specification, anyway - the current spec document is very scant (you can check it out on the MSDN XML site). Microsoft is charging ahead with .NET, using these unofficial standards, which means that for now, .NET is not compatible with other SOAP implementations. Keep an eye on this, because developments in this area will be very important in the future!
In addition, there are several rough spots that still need addressing. The SOAP spec, for example, does not make any concessions for security, and contains no standard security other than what's built into HTTP. At this point, security configuration is pushed to the application code rather than to the plumbing, where it belongs. Obviously, security is a big issue, because SOAP and Web Services allow you to execute code on the server. Figuring out who's calling and what rights they have will be crucial for keeping fun-loving criminals at bay!
There are other issues: 1) How is state managed? 2) How can a Web Service participate in transactions? and 3) How do you effectively test and monitor your Web Services to make sure they keep running reliably? For now, SOAP sidesteps these issues, although there are discussions and proposals for how this might be handled in future versions.
Also, understand that developers are giving up some control with Web Services. You may be consuming services made available from another site that's out of your immediate control. The site could go down or the authors could decide to change the way the service is called. Heck, the site could go away completely because the sponsor went bankrupt. Relying on non-guaranteed sources not bound by contracts or other business agreements can potentially be problematic. The Web is great - until somebody pulls the plug!
Most of the current technical issues are not show stoppers, since you can address most of them via custom code as in standard Web applications. It does defeat some of the promise of SOAP and Web Services, but the rewards for using Web Services effectively are much greater. They allow you to modularize your applications and share the data they provide. There are many business opportunities for those who deal with data services, so getting familiar with the technologies, even with all their current limitations, is vital.
Some Housekeeping
Let's talk a little about CoDe Magazine: After the last issue, we received a lot of great feedback. It was mostly positive, but also provided some constructive criticism (which is always welcome). Many readers noticed the improved editing quality of our articles. Credit for this goes to David Stevenson, who has been our copy editor since the Summer 2000 issue. Our web site has also sparked a lot of interest. By the time you read this, our new online article system will be up and running. Not only will it allow you to read articles online (printed articles as well as extended versions and unprinted bonus material), but you can discuss those articles through a revolutionary messaging system that allows readers to attach comments to individual paragraphs, even as the article is still evolving! Check it out at www.codemag.com.
