|
|
|
|
The browser gets some competition
Microsoft's .Net initiative has more angles than a starving dot-commer selling banner ads. ("It's software by subscription, a new way to build apps, a consumer identity service--and a dessert topping!") One of my favorite .Net angles is the "twilight of the browser" pitch. The thin client is history, says Microsoft. Browser-based HTML forms are a big letdown compared with real applications--and they create nasty bottlenecks by centralizing all processing on the server. Instead, Microsoft says, we should be using real applications that take advantage of all that excess processing power "on the edge of the network." Translation: Browsers should be replaced by Internet-enabled Microsoft fatware running on your desktop PC. ![]() It may seem like a wacky proposition, but it got a small boost last week when Microsoft released its Office XP Web Services Toolkit and Smart Tag Enterprise Resource Kit as free downloads. Both take advantage of the fact that much enterprise development is nothing more than customization of Microsoft desktop applications using Visual Basic. The Web Services Toolkit enables you to search for Web services and integrate them into an Office document. The Smart Tag kit contains sample code and white papers to assist Smart Tag SDK users (and help them build their own annoying little menus that pop up over key words or spreadsheet cells). So what, you ask? Well, think of how you use your browser at work. On the public Internet, you probably browse headlines and do very little scraping of real data, because that's too inefficient. But inside the firewall, you may well browse an enterprise portal that aggregates information and applications you need to do your job. And what happens when you need to crunch data from the portal in a spreadsheet or use it in a Word document or PowerPoint? You probably scrape it piece by piece. A lot of people, including me, believe that the near-term benefit of Web services will primarily be easy enterprise application integration. If you can use Web services to shunt data directly from enterprise apps into an Office document, you'll waste less time scraping and benefit from continually updated documents. The Toolkit lets low-end developers who use Visual Basic for Applications (VBA) do exactly that, simply by discovering and integrating with Web services through the VBA editor. For the Toolkit integration method to work, however, Web services need to be exposed in a Universal Discovery, Description, and Integration (UDDI) directory. Which brings me to the second point: While UDDI directories have been touted as open repositories available to all on the public Internet, their truly productive application thus far has been within enterprises, where they expose Web services that provide an XML-based point of integration with legacy applications. Of course, you need to control who has access to which UDDI directory. But with proper security, simply exposing all that stuff and having users grab what they need for their desktop apps--in place of tedious point-to-point integration--certainly holds the potential to lighten the load for IT. The direct link to Office applications is no accident. Microsoft has wanted its productivity applications and operating system, not the browser, to be your window on the Web since the Internet first took off. As usual, Microsoft's motives spring from a desire for more control over the user experience and less exposure for other brands. But along the way, it's provided a clever shortcut to bring the power of Web services to your desktop. Does souping up Office with Web services sound like an intriguing idea? Or should all that XML stuff stay in the back office for now? Let Us Know here.
More Office News |
|
Click below for more developments and tutorial articles:
Send mail to
webmaster@infomatek.com with
questions or comments about this web site.
|