Web Techniques: Competing for Directory Services

Competing for Directory Services

By Michael Floyd

Back in 1994, NeXT called them Portable Distributed Objects. Microsoft called it the Component Object Model (COM), IBM called it the System Object Model (SOM), and Apple called it OpenDoc. Later, many of these companies (except, of course, Microsoft) formed an industry consortium known as the Object Management Group, and the technologies converged to become the Common Object Request Broker Architecture (CORBA).

The idea was to create an architecture that let applications plug in to an "application bus" and invoke the services of other apps. Because it was object-oriented, messages were passed to make requests, which could be serviced by specialized software components, or objects. An important feature of this pipe dream was that objects could interoperate between applications, independent of the platform on which the application ran. Of course, this dream was never fully realized.

Today, these interoperable objects have taken on new names. One is called Web Services, and is coupled with a complimentary technology called Universal Discovery Description and Integration (UDDI). Web Services let companies publish components and services in a directory that other Web applications can search. Once a company locates a suitable service, it can employ the service (presumably for a nominal fee) to perform specific tasks. Notably, many of the same players, including IBM and Microsoft, are back in the game pushing Web Services, and analysts believe that these have the potential to change the way applications (and hence, business transactions) are conducted on the Internet.

The other technology, ebXML, is a joint initiative of OASIS and the United Nations (UN/CEFACT). ebXML is a set of specifications that together form a modular electronic business framework. The vision of ebXML, according to OASIS, is to "enable a global electronic marketplace where enterprises of any size and in any geographical location can meet and conduct business with each other through the exchange of XML-based messages." While ebXML has a broader focus than Web Services, the two technologies overlap significantly. Because many companies that support Web Services are also OASIS members, at the very least, it makes for interesting theater. This month I'll examine the salient features of Web Services as well as two implementations of it—the Web Services Toolkit from IBM and the Web Services implementation built in to Microsoft's .Net Framework.

About Web Services

Web Services are essentially black boxes capable of performing specific tasks, such as calculating an insurance premium or securities trade. They are self-describing modules that are URL addressable, and can combine with other services to create larger applications. These range from a simple process to a full-blown software product or application. So, these Web applications can be dynamically changed, thereby creating new Web services. Applications can be accessed through a network connection and invoked at run time. Because applications call services only when they need them, you get a sort of just-in-time application integration. This can all be done without prior knowledge of which components are required, and often without prior programming.

If it takes hold, the market for Web services could be huge. Small companies with specialized expertise can offer their services without draining the talent pool in their efforts to develop full-blown applications. Larger organizations would benefit because they could tap into these specialized components instead of doing their own research and development to arrive at the same results.

For Web services to work, several things must come together. Everyone must agree on a means of communication. That is, the methods for identifying, accessing, and invoking services must be standardized. That's where XML, or more specifically, the Simple Object Access Protocol (SOAP), comes in. Originally developed at Microsoft for inter-application communication, SOAP is an XML vocabulary for describing commands and parameters that can pass between browsers and Web servers. The client sends a request to the server to invoke an object, and the server sends back the results. The request and the results are sent as SOAP-formatted messages, which are stuffed in the HTTP header. Because it's based on XML and HTTP, SOAP is completely independent of an operating system, programming language, and object model.

Where are these services and how do you find the ones that meet your needs? The details I uncovered on this subject are still sketchy, but the general consensus is that some sort of distributed catalog will be mirrored at various locations. Entries in the catalog will use the XML vocabulary, UDDI. Web-service providers will be able publish information in the catalog that details company information, particulars about the service, and finer points such as the location of the service and how to invoke it.

Implementing Web Services

IBM's Web Services Toolkit provides a runtime environment, demonstration programs, and examples of how to design and execute Web-service applications that can find one another and collaborate in business transactions without programming requirements or human intervention. The toolkit includes a fully functioning client API that can be used to directly access a UDDI registry. The client API uses the UDDI4J API (oss.software.ibm.com/developerworks/opensource).

The toolkit also adds several technical previews including the COM pluggable provider—an Apache SOAP pluggable provider that takes incoming requests to the SOAP server and assigns them to a COM object. Another beta, the Web Services Management Technology Preview, introduces an interface that lets you manage SOAP server resources. Also, there's the SOAP Chaining Framework, which demonstrates how Handlers (code modules) can be chained before and after the actual Web service that's being invoked. Handlers let other nonspecific actions to be performed such as logging and security authentication.

Also included is a Web Services browser that lets you view a complete UDDI registry as a directory tree. According to the documentation, the browser lets you browse through Web services published with the Web Services Client API, publish and unpublish services, and view and save descriptions of services. The browser is a separate plug-in to the IBM XML and Web Services Development Environment alpha technology (WSTK) (www.alphaworks.ibm.com/tech/wsde). The WSTK demonstrates how some of the emerging technology standards like UDDI and Web Services Description Language (WSDL) work together and provide simple examples of Web services.

Nothing but .Net

Microsoft approaches Web services by building them into its next generation .Net Framework. The goal for the .Net Framework is, in part, to enable you to create new services and build Web applications from those services. From an architectural point of view, there's a common-language run time built on top of operating system services that manages the running of code. It's called a common run time because it handles code written in any programming language. The run time also supplies services you can use in your own development and aids in the deployment of applications developed with the framework.

Above the common-language run time sits a services framework, a set of class libraries that can be called from any of these programming languages. To facilitate this, the classes comply with a set of naming and design conventions. The services framework provides a base set of class libraries that include collections, I/O, string, and numerical classes. Other classes that are of more interest to programmers than to Web developers let development tools access debugging and profiling services. The base class library also lets you access operating-system services such as networking, threading, graphics, and cryptography.

One important feature of the services framework is the data-access class library, which employs the latest generation of ActiveX Data Objects, called ADO+. You may recall from my previous columns (see my article "Much ADO about XML," May 2000), that ADOs—like most components or objects—are simply black boxes that encapsulate specialized knowledge to connect to ODBC databases and OLE DB data sources. ADOs also let you add features to navigate records, perform queries, and update data sources without extensive programming. Externally, they have interfaces that let you perform all of these functions without needing the specialized knowledge required to perform the operations directly. As a Web-application developer, you only have to drop an ADO object into your ASP page and specify a data source to begin communication with that data source. Data sources can be relational, Indexed Sequential Access Method (ISAM), or hierarchical databases. In fact, ADO can use virtually any data source as long as you have an ODBC-compliant driver.

On the surface ADO+ looks much like ADO. However, ADO+ is designed to work within the .Net Framework, and integrates XML more tightly. For example, data can be manipulated as either XML or relational data regardless of how it's actually stored. ADO+ also adds XML reader capability (similar to the reader found in SAX), and allows you to create an in-memory relational view of your data, called a dataset.

A couple of application-programming models sit above the services layer. Both provide higher-level components and services. One I'll mention is WinForms, which lets you target Windows applications. The other is a Web-application model that employs an enhanced version of Active Server Pages (ASP), called ASP+ Web Services. As the name suggests, this is a high-level programming model for building Web Services with ASP+. If you're familiar with ASP development as a Web developer, then you'll feel right at home with ASP+ Web Services. ASP+ Web Services also hide the programming details of SOAP, SCL, and other specifications for creating Web Services. Unfortunately, space doesn't permit a full discussion of ASP+. So, I'll leave that for a future column.

ebXML

While Web Services let you create Web-based components and UDDI lets you advertise them in a searchable catalog, ebXML provides a standard framework by which business systems can support the execution of transactions. Thus, ebXML is more focused on businesses that need to locate, establish agreements, and conduct transactions with customers and trading partners. The ebXML schema provides a small set of elements that let businesses collaborate through a set of ebXML business transactions. The preliminary system was demonstrated recently at XML One in London.

On the surface, it seems that ebXML has different goals than Web Services and UDDI. Judging by the specification, ebXML is much broader and far more ambitious in its approach. It's anticipated that business partners will use the ebXML schema to create business process specifications. These specifications can be generated from either Unified Modeling Language (UML) diagrams or XML documents. The schema lets partners define business transactions in XML using a set of predefined patterns. These patterns determine the actual exchange of messages and business signals between the partners.

The specification includes extensive documentation that mandates transport, routing, packaging, and Trading Partner Agreements (TPAs). However, it's the Registry Repository specifications that have led some to believe that there's significant overlap between ebXML and the coupling of Web Services and UDDI.

High Expectations

Because ebXML is such an ambitious project, it's taking longer for specifications to fall into place, making it more difficult to develop a reference implementation. Meanwhile, the evolution of Web Services from software components, combined with the immediate availability of tools and source code, seems to be striking a chord with all developers, including Web developers. And while these technologies aren't mutually exclusive, they do represent some significant overlaps in functionality. As I said, it makes for interesting theater.

Michael is the author of "Building Web Sites with XML" from Prentice Hall, and teaches Beyond HTML's "Dynamic XML" training course. He is also the architect of the Rocket XML framework and carries the honorary title of Editor At Large at Web Techniques. You can reach him at mfloyd@lifestylesSantaCruz.com.