White Papers                  Home |  White Papers  |  Message Board |  Search |  Products |  Purchase | News |  


The Web at your service



By Rick Strahl



Last Updated: 12/10/2001



Web Services are coming and although the concept of remote access to server side logic isn't anything new, the topic has gotten a whole new meaning over the last few months especially in light of Microsoft's unveiling of the .Net platform. New initiatives are throwing the focus squarely at making business logic available in a standard manner over the Internet using a variety of 3-4 letter acronymned technologies. The key technologies are XML, HTTP and the Simple Object Access Protocol (SOAP).


And it's about time. Up until recently the Web has been used mainly for HTML based content, which has made it very hard to consume data available on the Web in applications. Think about how much useful information is available on the Web and then think about all the times you decided to not use it because of the hassles of having to parse HTML or worse yet having the site change the layout and ruin your use of the data.


XML and new protocols running on top of it are finally taking a step to provide a unified platform that makes information exchange between separate business entities a more seamless process. Using technologies like SOAP can make it drastically easier to share information between clients and servers or servers and servers. Where before you had to tightly couple application logic, generic Web Services can allow you to publish information broadly and with a specific service description that describes what services are provided. This opens up the world not only for pure Web based applications but also for standalone desktop applications that are too complex to run inside of a browser.


The latter point is an important one Web Services allow applications, that want to take advantage of the Web, to move back to the desktop. While there are many advantages to Web only applications, many shrink wrap, vertical and commercial applications are simply too rich to be run entirely in a browser environment. Many users also are much better served by a rich Windows application as opposed to a dumbed down HTML/DHTML interface. Web Services make it possible to continue using desktop technology but retrieve part or even all of the data from the Web all the while providing the same functionality to browser and server only based applications.


The idea behind Web Services is deceptively simple: It's really nothing more than making a remote method call you pass parameters to and return a result from. A function call over the Web! No more messing around with packaging up and unbundling parameters into XML and back the plumbing takes care of that for you. The next generation of software will implement the Web as seamlessly as older applications implement methods and functions that are compiled into one and the same executable. In the future, everything will be connected. All the time. It'd better be!


Creating and consuming Web Services will be easier than ever in the future with .NET and Vstudio.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 based service description and receive information in a similar way you would 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 almost as easily with just a few lines of code. It's not quite as simple as setting a Web Reference, but it still only takes a few lines of code. This leaves you to mainly worry about implementing your business logic rather than dealing with the plumbing of the network and its 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 we were building and moved many of us into n-Tier development, Web Services 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 from there it can 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 today will come 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 united whole. It promises to do for Web applications what the Web browser did for interactively using the Internet. It isn't going to happen overnight, but the promise is there and the future for it looks very bright.


The details aren't all there yet. The SOAP spec is still in flux and various different implementations barely work with each other I can't tell you how much time I've spent making my custom SOAP client/server implementation work with others as every one interprets the spec differently. That has to be fixed and soon in order for Web Services to succeed. There is no official specification for discovering what services are available 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 basically provides links to the Service Descriptions and acts as a sort of 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 the fast track. DISCO is hardly a specification either the current spec document is very scant. You can check it out on the MSDN XML site. Microsoft with .NET is charging ahead here using these unofficial standards which means that for now at least .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 also a number of rough spots that still need addressing. The SOAP spec for example does not make any concessions for security and there's no standard security beyond what HTTP provides. At this point any security configuration is pushed to the application code rather than the plumbing where it belongs. Obviously security is a big issue, because SOAP and Web Services essentially allow you to execute code on the server. Figuring out who's calling and what rights the client has is crucial to keep the fun loving criminals at bay! There are other issues: how is state managed, how can a Web Service participate in transactions and how do you effectively test and monitor your Web Services to make sure they are running reliably and keep on running. SOAP sidesteps these issues, although there are discussions and proposals for how this might be handled in future versions of the spec.


Also understand that developers are giving up some control with Web Services. If you consume services that are being made available from another site it's out of your immediate control. The site could go down, 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 that aren't 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 as you can address most of them via custom code just as you can 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 great. They allow you to modularize your applications and share the data they can provide. There are many business opportunities for those that deal with data services and even with the current limitations getting familiar with these technologies is vital.



For comments, you can post a message at:



Rick Strahl is president of West Wind Technologies on Maui, Hawaii. The company specializes in Web and distributed application development and tools with focus on Windows 2000 and Visual Studio. Rick is author of West Wind Web Connection, a powerful and widely used Web application framework for Visual FoxPro and West Wind HTML Help Builder. He's also a Microsoft Most Valuable Professional, and a frequent contributor to FoxPro magazines and books. He is co-publisher and co-editor of CoDe magazine, and his book, "Internet Applications with Visual FoxPro 6.0", is published by Hentzenwerke Publishing. For more information please visit: http://www.west-wind.com/.


Amazon Honor System Click Here to Pay Learn More





  White Papers                  Home |  White Papers  |  Message Board |  Search |  Products |  Purchase | News |