When Sun Microsystems Inc.'s Scott McNealy and Microsoft Corp.'s Steve Ballmer announced last month that the two companies had agreed to work on interoperability between their systems, they already had a good head start. That's because both companies already support Web services standards in their development tools.And with Sun and Microsoft now working on the same side of the fence, support for those standards is bound to get stronger.'The whole standards area is going to be one where this is potentially a game changer,' said John Fowler, Sun's software chief technology officer. 'Microsoft and Sun have been so diametrically opposed on standards for such a long time; the patent cross-licensing agreement opens up the opportunity to work together with Microsoft on things at a whole new level.'Nobody should be happier about this new level of cooperation than the federal government. If any organization in the world has a need for simpler software integration, it's the government.With so many disparate systems and a congressional mandate to establish a sound, integrated information systems architecture, agencies seem to be ideal candidates for systems built on Web services.Web services are based on Web communications standards and, in most cases, Extensible Markup Language. They build integration points between software running on disparate and distant information systems. Using Web services, one system can call on the functionality of another to retrieve or process information'anything from a simple database query to a complex workflow.In theory, Web services could be used to integrate systems across agency boundaries, connecting to other federal, state and local government systems, and even the systems of major services and goods suppliers'in essence providing a single, unified architecture for everything the government does.But that brave new world is still far from a reality. While many agencies are piloting Web services for targeted applications, the approach is just beginning to get a foothold within government. And there are a number of hurdles left to clear before Web services gain widespread acceptance as a part of government IT.Still, there is some momentum. 'Federal customers are more conservative, but the trend is picking up,' said Kristin Weller, executive vice president for product development for WebMethods Inc., a Web services integration software vendor.Perhaps the highest-profile government Web services project to date is the Defense Department's EMall, a procurement portal based in part on WebMethods' software. The EMall currently handles more than $1 million in transactions every week.Web services standards have been evolving for quite some time. WebMethods submitted the first specification, the Web Interface Definition Language (WIDL), to the World Wide Web Consortium (W3C) in 1997. As a result, there are a wealth of tools available for building applications that use Web services.Unfortunately, it's often harder to sort through which standards apply to the application you're building than it is to find the right development tool. Overlapping standards have been proposed over the past few years by various standards bodies, including the W3C, the Organization for Advancement of Structured Information Standards, and the United Nations Center for Trade Facilitation and Electronic Business.The resulting technologies range from the relatively simple, such as Simple Object Access Protocol (SOAP), to the increasingly complex, such as E-Business XML. The CBDI Web Services Roadmap provides an exhaustive, but not necessarily complete, list of the current standards in the Web services world. To check it out, go to and enter 236 in the GCN.com/search box.WebMethods may have started the ball rolling for Web services with WIDL, but things didn't hit critical mass until the release of SOAP, a standard first developed by DevelopMentor Inc. of Torrance, Calif., IBM Corp., Microsoft and UserLand Software Inc. of Los Altos, Calif. SOAP is a more general-purpose standard than WIDL. First submitted to the W3C in 2000, it uses HTTP to deliver an envelope of XML-formatted requests for a specific function, or method, of a remote application.The protocol is now part of a set of Web services specifications known as the WS-Basic Profile, an interoperability standard published by the Web Services Interoperability Organization (WS-I). WS-Basic also includes the Web Services Description Language (WSDL) and the Universal Description, Discovery and Integration (UDDI) registry service.WSDL is a flavor of XML used to describe the connecting points for SOAP Web services. It describes the structure of a Web service in a way that can be processed by software'such as Cape Clear Software Inc.'s SOA Editor'to create an interface to it. A WSDL file includes information about the schemas used by the service to understand information passed to them, and everything else required to build the right SOAP envelope to deliver a request.Although the content of a WSDL file describes the bits and bytes of a Web service, UDDI describes Web services in a more human-readable form. A UDDI directory lets Web service users find the Web service they're looking for'including the WSDL file that shows how to connect to it'via a search interface or by browsing through a directory.Often, if the UDDI directory is configured to do so, Web services can be invoked directly from their listing, using the WSDL file in the listing to create an interface.SOAP and the WS-Basic profile can be used to create Web services at a very atomic level; ebXML is designed to be a Web services replacement for traditional electronic data interchange systems. The DOD EMall, for example, uses the ebXML standard for its financial transactions.An ebXML Web service is designed to take in highly structured XML documents based on a shared dictionary, or schema, and process them as a whole rather than getting requests for specific application methods. An ebXML document could be the equivalent of a purchase order, invoice or shipping document, formatted specifically to the standards of a particular agency.One of the major concerns surrounding Web services is security. Though they can use a variety of secure transports to carry data from point to point'including Secure HTTP and IP Security tunneling'there's been no standard way to handle such things as a request's level of access.That's where Security Assertion Markup Language comes in. SAML is yet another XML framework, designed to exchange information for authentication and authorization for access to a Web service.Since Web service requests often go across domains, SAML tries to handle cross-domain authentication. A Web request would be accompanied by a SAML authorization generated by a SAML authority'an authentication server that asserts, or vouches for, the access level of the user or application making the Web service request. That authorization level is mapped to an authentication system on the receiving end of the request, and the request is processed, or rejected, accordingly.The General Services Administration has recognized SAML's value to the government. GSA's E-Authentication Initiative has opened an interoperability lab and has certified three authentication technology vendors as test providers of SAML 1.0 authentication for Web services: Hewlett-Packard Co.'s Select Access, ShareID from Oblix Inc. of Cupertino, Calif., and Sun ONE ID Server.The interoperability tests are the first step in providing Web services secure enough to meet the government's needs'and then the federal government and Web services might really be a perfect match.
Web services can help you piece together a unified system, though standard and security hurdles remainA little or a lotwww.gcn.comDirect hitIdeal pairingKevin Jonah, a Maryland network manager, writes about computer technology.