Web Services Strategies

Beyond the technology, IT strategies for implementation of Web services by Doug Kaye.

More Web Services Misunderstandings. Two days ago I wrote about the misunderstanding of Web Services brought on by the hype that surrounds this technology. Based on feedback I received, and from my continued reading of what others have written, I see that the misunderstanding is widespread. Confusion shows up in two areas in particular: .NET is not the same as Web Services. .NET is much more than Web Services. .NET includes both the tightly coupled and proprietary application architecture known in previous versions as COM, as well as loosely coupled non-proprietary Web Services. But if you look deeply, you see that the former represents a far greater percentage of what makes up .NET. Furthermore, the .NET umbrella now includes Microsoft's latest version of the Visual Studio development environment--the primary IDE for anyone developing Windows-based applications. Yes, .NET and Visual Studio include support for Web Services, and this support is one of .NET's newest (and hence most notable) features, but .NET and Web Services are not at all the same thing. Unfortunately, Microsoft is doing nothing to clarify this. They, like other vendors, want their name and products to be as closely associated with these hot new buzzwords as possible. Horizontal applications are not the same as Web Services. Certain applications are frequently mentioned in the same breath as Web Services. Single sign-on, micropayments and multi-store shopping carts are perhaps the most common examples. Maybe I'm being a stickler (okay, I know I am), but these are not Web Services. Yes, it's an arguable point, but I prefer to think of these as applications--like any others--that are accessible through a Web Services interface. It's true that because of the degree of standardization they require, these applications have little value without Web Services, but in reality they're no different than any existing (legacy) application to which one adds a Web Services front end. The technologies of Web Services are integration tools. They allow applications--perhaps on very different hardware and software platforms--to communicate with one another. One might even say, "This application is available as a Web Service," but the Web Service and the application remain necessarily distinct. Posted Monday, February 25, 2002 10:34:22 PM

Are Your Legacy Apps Ready? One of the goals of Web Services is to make elements of your legacy applications available to your customers, vendors and partners. The Web Services toolkits that are just now coming on the scene are certainly up to that task; they've been designed with scalability and robustness in mind. But what about those old legacy applications? Are they up to the task? Many of my clients are anxious to jump onto the Web Services bandwagon, but they're focusing too much attention on these new technologies and not enough on their middleware and backends. Their existing applications weren't developed with the Internet in mind. Indeed, some were developed as long as 20 years ago when, for instance, it was common to design systems that would be shut down on evenings or weekends for backup. Oops! That's not going to work in the 24x7x365 world of Web Services. Suddenly, these clients are finding--much to their dismay--that they're about to be thrown into the world of high-availability systems. It's one thing to design a new Web Services front-end to meet these demanding requirements, but it's quite a different story when it comes to the legacy backends. As you develop your strategy for adding a Web Services front-end, take a good hard look at your legacy applications and determine what it's going to take to bring them up to the required levels of availability. I think you'll find this is where most of your resources will go. Posted Monday, February 25, 2002 12:41:48 AM

February 2002
Sun	Mon	Tue	Wed	Thu	Fri	Sat
					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28
Jan   Mar