The IT Strategy Letter
A digest of Doug Kaye's weblogs for the week ending April 22, 2002
Get your own free subscription and have the IT Strategy Letter delivered direct to your inbox every week.
| Contents: |
Web Services Strategies |
Web Services Strategies
|
Web Services at the Edge. Last week saw a number of announcements by content-deliver network (CDN) vendors regarding their hosting and delivery of web services. The first announcement was from Akamai, the company that pioneered and continues to lead the content delivery network market. Akamai inked deals with Microsoft and McAfee that will see Akamai deploy .NET services on its network of 13,500 edge-of-'Net servers. In the spirit of, "There's no such thing as bad press," Akamai's announcement is at least getting some attention. Dave Winer asked why Akamai announced .NET services as opposed to Web services. After all, he pointed out, isn't the whole idea of web services that they can be called from any web-services client? Scott Loftesness (a payment-processing and financial-services guru with Glenbrook Partners) took 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. |
|
|
| Novell on Portals. I spoke
with Carl
Ledbetter, Novell's CTO. The company is refocusing (yes, again!)
on their DirXML
portal server that works very much in the manner described above.
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." Posted Tuesday, April 16, 2002 5:05:17 PM |
|
|
| Mirror
Image. Also 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. |
|
|
|
When to Dive Into Web Services. In last week's newsletter, I linked to my preliminary essay on how to determine the optimum time to get started with web services. In addition to Julian Bond's insightful comments, Phil Wainewright pointed out a flaw in my methodology. Using the example of the recent announcement and rapid adoption of Google's SOAP-based search API, Phil writes, "at this rate the O'Reilly book should be out by the end of the month." (I love it!) Perhaps some context will help, although I certainly need to improve the model and its explanations. I'm not looking at the consumer's side of such a very simple web service. For something like this, it's hardly worth even suggesting a methodology, for as Phil says, it could be implemented--start to finish--in an afternoon. But I am including within the methodology's scope the ROI and timing for Google, the producer of the service. The service requires only XML and SOAP. WSDL isn't required, but it is supported. So it's well down on the curve, not at the upper-left as Phil suggests. The O'Reilly SOAP book is out and SOAP 1.1 is final. Security (authentication only, no encryption) is handled within the application itself, so there is no dependence on any emerging standards. There are no QoS issues, no transactional integrity problems, and no need for auditing or management. Google hasn't address version control control, for example. If they change the API, our client code will likely just break. [Update: A WSDL file is included with the developer's toolkit, and consumer apps that use it have some protection against version issues.] That's great with trivial applications, but what about commercial-grade web services for which this isn't acceptable? I suggest they're much closer to that top-left corner of the curve, and hence it may be premature for some (not all) organizations to implement at this time.
Part of the problem is that web services mean so many different things to so many people. It's not going to be a one-size-fits-all world. But there's little risk to Google of their service being deployed too soon, and I believe the model and methodology apply correctly to Google's situation.
|
|
|
|
Service
Grids. Phil Wainewright has pulled together a number of
ideas regarding the use of service grids to guarantee the quality,
reliability and security of the web services. These are the same
requirements addressed by the CDNs and ADNs (see above). |
|
|
|
Hailstorm Ain't Dead Yet. According to Gartner, "Despite recent news reports, Microsoft’s business plan continues to be to charge for, and make money from, HailStorm — now known as .NET My Services."
|
|
|
Web Hosting Strategies
|
Acts
of God: Sorry, That's Beyond Our Control. Here's my new
guest editorial at The Web Host Industry Review, in which
I discuss off-net SLAs and force majeur. "Isn't protection
for your web site against such risks one of the reasons you selected
your vendor?" (I've got an index of my
other guest editorials on web hosting matters.) |
|
|
|
Data Insurance. This is a good overview of insurance coverage by Kevin Savetz for losses from content liability, network security breaches, business interruption and data loss. Insurance is an important component of any risk-management policy, but surprisingly, AIG--who claims 75% of the market--says it has only 1,500 clients for this type of insurance. Do you know what coverages your company has? Is your general business insurance sufficient, or should you consider data-specific coverage? [Source: New Architect Magazine.]
|
|
|
|
WebTalkGuys Radio Show.
On May 18, 2002, I'll be joining Rob and Dana on their weekly
program. WebTalkGuys can be heard on CNET
Radio in Boston (890AM) Saturdays 1pm and Sundays 10pm and
San Francisco (910AM) Saturdays 10am and Sundays 7pm, on KLAY
1180 AM in Seattle/Tacoma and via the XM Satellite Network (Channel
130). WebTalkGuys is also available on the NexTel Wireless Web
service through XSVoice. |
|
|
The IT Strategy Letter is published weekly by Doug Kaye. The content is identical to Doug's weblogs.
| Options: |
Subscribe |
|
|
|||||||||
|
