The Edge of the Puzzle. In the spirit of, "There's no such thing as bad press," Akamai's announcement is at least getting some attention. Dave Winer asks why Akamai announced .NET services as opposed to Web services. After all, he points out, isn't the whole idea that they can be called from any web-services client?
Scott Loftesness (a payment-processing and financial-services guru with Glenbrook Partners) takes exception to the example used by Akamai's VP of Product Marketing, Robert Ball. "Ball obviously doesn't understand how the world's credit card processing actually takes place. What a silly example!" It certainly is. So what's a good one?
How about web services as components of portals? Today, most portals build web pages bottom-up. The components are manifested as HTML fragments that are then assembled into personalized pages. But newer portal servers obtain each component's data in XML by calling an associated web service. The portal then handles the formatting and delivers composite pages. Some of the web services will return high-volume performance-sensitive data such as the usual suspects: stock quotes, weather, etc. These will be implemented as read-only RPC-style web services.
Organizations and even branch offices will deploy portal servers to meet the needs of their employees and partners. These will be thin servers in that they'll only handle formatting. The content they display will all be retrieved from remote sources using XML-based web services.
Last week I spoke with Carl Ledbetter, Novell's CTO. The company is refocusing (yes, again!) on their Dir XML portal server that works very much in this manner. Novell's initial target verticals are financial services, government and healthcare. Canada, for instance, has an e-government initiative it characterizes as "just one window; no wrong doors."
[Aside: I love UserLand Software's Radio, and hope it continues to evolve as a personal/desktop portal based on web services.]
Last week, Mirror Image Internet (an Akamai competitor) announced its Application Delivery Network (ADN) that hosts both .NET and J2EE applications at its Content Access Points (CAPs). I got a preview last month when I spoke with Bob Hammond, MII's GM, Web Services and Senior Vice President. His plans are to focus on the ISVs who are used to delivering their product on CD-ROMs, and therefore have no experience with the 24/7 operations web services will require. MII wants to be an outsource web-services publisher or "fulfillment house" (my term). They'll handle delivery, QoS, security, authentication and billing.
Will it be important for web services to run from the edge of the Internet, or is this just a case of the content-delivery network (CDN) vendors trying to find another way to leverage their huge investments in infrastructure. (Akamai, for instance, now operates more than 13,000 servers in more than 1,000 networks in 63 countries. Mirror Image Internet operates a more centralized network of 17 high-capacity CAPs.) Certainly, the delivery of many web services will be outsourced, but it's too early to tell who will take the lead in providing that capability.
Posted Tuesday, April 16, 2002 5:05:17 PM