Infrastructure-level Web services – Commentary
Anne Thomas Manes
When discussing Web services, most people tend to focus on the core Web services framework (the standards and protocols) and the applications that you can build with the framework. Although I have no trouble waxing profusely on these topics, I get even more jazzed when I start to think about infrastructure-level Web services. (I know. I need to get a life.)
Infrastructure-level Web services are Web services that implement part of the distributed computing infrastructure. They help other Web services communicate. In particular, these services make the Web services framework more robust. They provide such functionality as:
* Security and provisioning
* Performance management
* Operational management
* Metering, billing, and payments
* Routing and orchestration
* Advertisement and discovery
* Caching and queuing
* State management and persistence
John Hagel and John Seely Brown refer to infrastructurelevel Web services as a service grid. (I recommend their article, “Service Grids: The Missing Link in Web Services” [www.johnhagel. com/paper_servicegrid.pdf].) I’m uneasy with the name “service grid” because it inevitably causes confusion with grid computing, which focuses on making efficient use of available resources by distributing workload across a distributed computing environment. A service grid is a set of managed utility services that applications can tap into in the same way that electrical appliances tap into a power grid. The key feature of the service grid is that it makes the infrastructure-level Web service pervasive and available to everyone.
Consider security–a big, gnarly issue. For it to properly protect your environment, security can’t be an afterthought. It has to be integral to your entire IT infrastructure. More important, you have to get everyone to use it. Users and applications need a simple, effortless, preferably transparent mechanism to establish and propagate their identity. Runtime frameworks (such as application servers) need a simple, effortless, preferably transparent mechanism to determine a user’s identity and to evaluate access rights. Applications and runtime frameworks need a simple, effortless, preferably transparent mechanism to sign and/or encrypt information and to verify signatures and decrypt information. And administrators need a simple, reasonably effortless mechanism to provision and manage identities, access rights, and encryption keys.
Right now, most companies implement security on an application-by-application basis, with a different directory or user store managing user information for each application. There’s no common mechanism available to secure all your application systems. You use metadirectories to try to propagate changes across the different directories, but it still turns into an administrative nightmare. The lack of a common, cross-enterprise security infrastructure leads to errors, inconsistency, and security holes. And of course the problem only gets worse when you try to extend your application systems across corporate boundaries to connect with your customers, partners, and suppliers.
Now consider how much simpler it would be if you were using a distributed security infrastructure based on a service-oriented architecture. Imagine a set of Web services that provides simple, easy-to-use security functionality–available to all users and all applications regardless of language, platform, application, or location. These trust services include single sign-on, entitlement, signature generation and verification, and key management. From an administrative point of view, you also have policy management and provisioning services. Once you’ve defined the standard formats and APIs for these services, the functionality can be built into the runtime frameworks so that you no longer need to rely on developers to implement security properly. Security becomes automatic.
This isn’t just a glossy-eyed dream of the future. The standards community is hard at work making this stuff happen. OASIS Security Assertions Markup Language (SAML) defines standard XML formats for security tokens (authentication and authorization assertions). It also defines standard protocols for single sign-on and entitlement Web services. OASIS Service Provisioning Markup Language (SPML) defines provisioning Web services and is a framework for exchanging user, resource, and service provisioning information. OASIS Digital Signature Services (DSS) defines standard Web services for signature generation and verification. And W3C XML Key Management Specification (XKMS) defines standard Web services for key management and distribution.
Security is not the only infrastructure area moving toward Web services. OASIS UDDI defines a standard advertising and discovery service, and OASIS Web Services Distributed Management (WSDM) will use Web services to manage distributed systems.
Peer-to-peer and grid computing systems can also capitalize on a pervasive, distributed set of infrastructure-level services to manage issues such as routing, scheduling, caching, presence, localization, security, state management, and persistence. A Web services-based infrastructure solves a huge number of problems for these systems. I get chills just thinking about it.
Anne Thomas Manes is a research director at Burton Group, a research, consulting, and advisory firm, where she leads research for the Application Platform Strategies service. Named one of NetworkWorld’s “50 Most Powerful People in Networking” in 2002, and one of Enterprise Systems Journal’s “Power 100 IT Leaders,” in 2001, Anne is a renowned technologist in the Web services space. She participates in standards development at W3C and OASIS and is a member of the Web Services Journal editorial board, a frequent speaker, and author of numerous articles and the book, Web Services: A Manager’s Guide (Addison Wesley). Prior to joining Burton Group, Anne was CTO of Systinet. anne@manes.net
COPYRIGHT 2003 Sys-Con Publications, Inc.
COPYRIGHT 2003 Gale Group
