Web services are the hottest technology going right now. Microsoft's recent release of Visual Studio .NET has quickly transformed Web services from a cool-looking white-board "markettecture" to a real architecture. Even longtime Microsoft rivals such as Sun Microsystems and Oracle are pursuing their own versions of the Web services paradigm. Network administrators need to understand this new technology to support and leverage it within their existing network infrastructures.
Web Services Inside Out
Web services use standard Internet protocols and data formats to extend a component-based programming model across the Web. You use HTTP to access Web services, which are Web-based components and applications built on four core technologies: XML; Simple Object Access Protocol (SOAP); Web Services Description Language (WSDL); and Universal Description, Discovery, and Integration (UDDI).
XML, a self-describing tag-based language, is the foundation of the Web services architecture. Its main value lies in the fact that it is a platform-independent data-transport mechanism. SOAP is an XML grammar that specifies how data and commands are sent between applications. WSDL is another XML syntax that applications can use to query one another about the names and properties of the Web services that they support. UDDI is a directory mechanism for Web services that fills a role much like Active Directory's (AD's) role on a LAN. UDDI lets a Web services application dynamically discover available Web services that it can use. Combining these technologies results in a platform-independent architecture that lets you construct an application from ready-to-use Web services built by many different vendors and distribute that application across the Web.
Preparing for Web Services
Web services are for real, and they hold the potential to revolutionize business-to-business (B2B) communications. They also open up access to your organization's data and infrastructure in much deeper ways than any previous technology because they allow direct program-to-program access to your applications and data from the Internet. As an administrator, you need to be particularly concerned with two aspects of Web services: deployment and security. The deployment aspect of Web services is the easy part. You essentially just need to deploy the .NET Framework to the target application server (which can be running Windows .NET Server, Windows 2000, or Windows NT 4.0), then perform an xcopy of the application. .NET applications are self-describing, and you don't need to run application installations or remotely register any components.
Planning for Web services security is more challenging. The paramount security considerations are restricting Web services access to authorized users only and preventing unauthorized parties from viewing data. You need to secure Web services at many levels, including the network level (at which you'll probably want to use Secure Sockets Layer—SSL—for data confidentiality and set up your firewalls to filter SOAP traffic), the OS level (at which you'll need to establish a user authentication mechanism and ACLs to govern resource access), and the application-development level (at which you'll specify the permissions of individual Web services methods and resource access).
Incorporating new technologies such as Web services into your applications takes time, and working out the details of using those technologies in cooperation with your business partners takes even more time. You can use that time to understand the deployment and security challenges associated with Web services. Past and upcoming articles in Windows & .NET Magazine will help. Plus, you can learn more about Web services at http://msdn.microsoft.com/library/default.asp?url=/nhp/default.asp?cotentid=28000442.
