Wading into mUDDIer water
In early Web services implementations, modules will be hosted on a company's intranet and used to assemble and interact with local enterprise applications.
This will be possible through use of WSDL (Web Services Description Language) and UDDI (Universal Description, Discovery, and Integration), two other evolving Web services standards that will eventually provide a mechanism for describing Web services and documenting the way in which applications interact with them.
WSDL describes the protocols and formats that each service uses, while the proposed WSFL (Web Services Flow Language) describes workflow relationships between those services. UDDI, on the other hand, provides for searchable directories of WSDL information, which will allow Web services enabled applications to find and use the components they need.
While XML and SOAP define the inner workings of a Web service, UDDI is the real enabler for interoperable Web services. It will provide a means for software to search out and find the services it needs, weighing up competing offerings to identify one that's best suited for the business's requirements.
As in your normal phone book, Web services are organised within a UDDI directory as white pages (by addresses and contacts), yellow pages (by industry classification), and green pages (where services are listed based on descriptions that include XML version, encryption type and an XML Document Type Definition).
Use of UDDI within an enterprise environment may promote re-use of individual components by allowing disparate development groups to leverage the work and experience of other business units.
Ultimately, this could enable far faster application development if, for example, an internal logistics organisation published hooks into its system for other business units to use.
In this way, Web services could ultimately prove to be an enabler for component reuse in ways that simple object-oriented development has never managed to achieve.
That's because object reuse within OO environments requires a working knowledge of each module's interfaces and design; WSDL, on the other hand, effectively provides a consistent way of documenting those modules and publishing that documentation in a readily accessible format.
Consistent with the hype that has accompanied Web services in general, starry-eyed vendors believe widespread public implementation of UDDI will eventually lead to the development of online marketplaces where access to Web services is bought and sold with impunity.
The theory goes something like this: vendors and business partners, having developed what they feel to be best-of-breed application components offering some novel take on a specific purpose, will decide to offer them to the global market by publishing them as Web services.
For example, an inventory management system needing to pass data to a standard shipping module could look up Australia Post's available Web services and pick the one corresponding to the type of delivery required.
A payroll service provider, on the other hand, could expose its systems to the Net for trusted (and paying) customers to link to directly.
If the application can't decide which is best, a UDDI browser will allow humans to manually search, compare and specify services to be used based on listings of the services contained therein.
Because they'll be hosted by the Web service provider, use of the modules will involve all manmanner of extra due diligence to address quality of service, disaster recovery planning, and even contingency plans should the Web services supplier go out of business. It's like the application service provider (ASP) delivery model married equally unsuccessful B2B exchanges and produced Web services as their offspring.
A good example of the applicability of Web services can be found in the ATO's recently announced Australian Business Register (ABR) project, which builds on Microsoft .NET infrastructure to provide a centrally managed platform for business authentication that will be made available as a Web service to other government departments and relevant organisations.
Two years in the making, ABR is not completely finished and has not been publicly discussed; an ATO spokesperson, somewhat irritated that Microsoft and Accenture had spoken publicly on the project, declined to comment on it for this article.
Maintaining a central register of business information, accessible to trusted outside parties' applications on an as-needed basis, is an excellent example of the way that Web services can hide the complexity of an organisation's underlying infrastructure whilst allowing it to be polled for relevant information.
Of course, the ATO is a known and trusted entity; buying access to modules from smaller or unknown organisations introduces a whole new range of issues.
"More and more we rely on modules to do stuff," says Peter Pritchard, Asia-Pacific regional manager with development and testing tools giant Compuware, who believes necessity will drive Web services' earliest adopters.
"Vendors are going to get a reputation for providing good, solid modules that work. You do a lot of things that have no competitive advantage, and I think SMEs are going to do this first because they often can't afford to build entire applications themselves."
While it's reasonably well understood in theory, UDDI is far from completion. A number of vendors-including Antarcti.ca Systems, Cape Clear Software's ClearConnect, Mind Electric GLUE, Systinet WASP, and the open-source jUDDI-now offer UDDI development tools. For managing UDDI registries, look to Peregrine Systems, RealNames, ResolveNet, and Riskebiz Internet Services. Sun will release its first UDDI product soon.
Such products may provide early frameworks for implementing UDDI directories, but do little to address concerns about Web services security.
That's because the standards for enabling Web services security are still largely unwritten. In April, Microsoft, IBM, and VeriSign finally debuted the first: WS-Security, which enables encryption of data being passed between Web services and integrates SOAP with the W3C's existing XML Security and XML Encryption standards.
Microsoft and IBM plan to release six more Web services security standards in the next 18 months. WS-Policy, WS-Trust, and WS-Privacy will allow data to be certified based on the sender's identity or internally defined business policies whilst meeting privacy obligations.
WS-Secure Conversation, WS-Federation, and WS-Authorization will provide a high-level security interface designed to promote seamless communication between secure environments.
No matter how good the security standards may be, potential Web services customers mustwork particularly hard to make sure their data remains safe at every point within the loosely affiliated universe of Web services that are envisioned to make up next-generation applications.
Although this naturally requires considerable technical skill, it's also going to demand involvement of business experts with the knowledge to build robust security. And this, as is always the way, will take considerable time and effort.
"Web services absolutely will create new security weaknesses. These services are not being designed by bankers," James Molini, chief executive of security firm Brink's Internet Security, recently told CNET.
"Many services we see, especially those built by smaller firms, are not actually built using real financial security people. As a result, sometimes they don't really know how to even comply with federal regulation regarding the security of their system."
