LT: And when everything is a Web application that has to be up 24x7x365, how do you do testing?
MD: It's a real issue—one that our telecom customers have had for many years, by the way. .NET provides a standardized approach for how to test distributed Web applications, but new challenges remain. Say you depend on a given Web Service. Then its vendor publishes a new version of the Web Service with a different compute/sum analytic metric. Then the next time your application calls this Web Service, the updated function breaks your application, causing it to crash.
So now these testing issues cross companies and organizations—that's the big change. The way we expect most reliable services to work, they'll still have a configuration management issue. As a consequence, a Web Service vendor might have to provide several iterations of a mission-critical service at once until all customers have tested the latest version thoroughly. The core of what it means is the basic change control and configuration management issues are still there.
.NET is trying to provide standard ways for vendors to talk about this to one another about change control, and we're trying to make sure our tools scale up. This relates to modeling as well, with defining what a Web Service is supposed to do. If you have a good spec for what the Web Service does, I can test against the spec. We're never going to achieve nirvana here, but with the modeling there's more decoupling—our teams don't have to coordinate as much. The same holds true if I'm a paying customer running a mission-critical component against your service.
LT: You're implicitly raising the issue of working in heterogeneous environments, as most of our readers do to varying degrees. What is .NET bringing to that party? Sometimes Microsoft has appeared to be pretending no one else exists.
MD: Microsoft isn't just doing .NET separate from the rest of the industry. It's trying to provide open standards. For example, Microsoft and IBM are cooperating on a lot of standards having to do with the Web, such as UDDI. It's the only way we'll be able to get financial services providers to support Web Services.
Even if you're just using Web Services internally, testing and configuration issues arise, but when you cross organizational boundaries such issues become much more interesting. And not just for new projects. Either internally or across multiple organizations, some can be old legacy systems you're making available as Web Services.
LT: It's nice that IBM is playing ball with Microsoft regarding .NET. How about bitter rivals like Oracle and Sun?
MD: This is where the Web Services thing works. Web Services operate at a higher level than EJB and the like. You can make the interchange based on XML. So it becomes less critical how the underlying application is integrated. You can leverage the Web Service mechanisms, then migrate to common technologies later on if needed. No magic required here.
本文地址：http://com.8s8s.com/it/it46152.htm