There Is Something New Under the Sun

Believe it or not, something very, very hot has been incubating in the software and technology world. This new trend may have a major impact on the way we do business and manage data. Despite the tech wreck of the last two years, software developers have been hard at work, fleshing out a new concept of technology integration known as Web services. We can understand more about Web services by considering the difference between the design and assembly of a car and a computer!

Cars and computers
Cars are designed and assembled in a mostly custom fashionevery moving and structural part has been individually designed to fit with every other part. The car may have one major function, driving, but it has many minor ones, such as raising and lowering the windows, playing the radio, and heating the passengers. Sure, some standard parts are required, such as spark plugs and oil filters. But each particular car requires specific-model partsany others may not function properly, or may damage the car. Although mass produced, most pieces on the modern car cannot be interchanged from model to model, and very little can be interchanged between different car manufacturers.

The modern personal computer has a completely different design and assembly. The PC is mostly assembled from a set of standard components. Starting with the motherboard, a PC can be assembled by plugging in a power supply, fan, hard drive, floppy disk, CD-ROM, Ethernet card, memory boards, USB ports, and more. Any of these components can be selected from a wide variety of different manufacturers. Any CD-ROM drive that meets the required specifications will be of a particular length, height, and width to fill the slot on any computer chassis. It will read standard CD-ROMs and will output data using a particular communication protocol. The PC can therefore be assembled from a limitless number of different components. Furthermore, the PC is extensiblemore of some components can be added, and new components can be added when they are developed. For example, a Compact Flash (CF) reader used for reading photo files from digital cameras can be added to PCs that were assembled long before the CF reader was developed. The reader can plug into the USB port and a software driver can be loaded that communicates with the CF reader and accepts the data.

The interfaces in a PC are standards-based, specific, and dont change from version to version. Regardless of the manufacturer, the various components work by plug and play.

Building software
How does our analogy relate to software and Web services? In the past, we created software much as we built a car. In fact, we used some of the same words to describe some parts of the product (and I dont mean Windows!). Lets think in terms of clinical trial data management software. We often describe the core database of such software as the database engineit is the software that drives the car. However, an engine alone is pretty useless without the rest of the car. A car also needs a chassis to hold the engine, a frame for safety, a body for comfort, and many, many controls to interact with the engine and with the various other components.

Similarly, the database engine needs a user interface to interact with it as well as security components, various functional controls and components that interact with the database engine, and a reporting module (not unlike the speedometer and dashboard). Each component works smoothly with the others because they were designed and assembled that way.

The design of traditional software includes proprietary interfaces whenever data are passed from one software program to another. The interface has been carefully hand designed and tested. It is specific not only for particular software, but often for a specific version of each software program. Whenever a new version of either software is installed, it is necessary to completely rewire any connections of the software to other programs. Finally, any connections outside the walls of a particular companyto partners and collaboratorswill require a special kind of hard wiring, with a great deal of built- in security.

Now, contemplate a clinical trial data management system of the future that is designed less like a car, and more like a PC. Each component of the system (say for example, electronic data capture, coding, reporting, and adverse event reporting) is designed to meet an input and output specification for data and metadata. The exact design is not fixed, just the input and output specifications. As long as it meets the specification, each software component can be modified, have functionality added, or even be substituted by another productwith minimal disruption to the overall system.

This is the kernel of the vision of Web services. Web services is a very popular buzz phrase in technology that describes developing an approach to the ways that business software communicate with one another. Web services have many different aspects and can therefore be confusing to the uninitiated. Put simply, Web services utilize Internet standards based on the eXtensible Markup Language (XML) to connect unrelated software programs or data sources. In the most simplistic sense, Web services provides the plug and play environment for connecting software programs together so that they work seamlessly, without intense data manipulation and programming. In a more advanced implementation, Web services provides a framework in which a computer program can seek out a data source on the Internet, connect to the source, and request and receive the dataall without a single human intervention. How is this possible? I will explain and provide some interesting examples.

eXtensible Markup Language
The core of Web services is the XML language. XML has become a standard in technology and is the basis for the evolving clinical data standards effort, CDISC (Clinical Data Interchange Standards Committee). XML allows the tagging of information content without regard to presentation of the data. This is exactly the opposite of HTMLthe lingua franca of Web pages. HTML tags the presentation of the data, without regard to content. An example of HTML might be:
<b>This is bold</b> and <i>this is italic.</i>

A Web browser interprets the information in brackets and displays the Web page in the appropriate form:

This is bold and this is italic.

That is how a Web page works.

XML will tag content in a similar fashion:
<?xml version=1.0?><price> <europe> <retail>850</retail> <wholesale>450</wholesale> <units>E</units> </europe> <unitedstates> <retail>750</retail> <wholesale>399</wholesale> <units>$</units> </unitedstates></price>

An XML query of this information would return $750 if the requester wanted the U.S. full price and E450 if the requester wanted the discount price in Europe. This data can then be displayed on a Web page, entered into a database, or used in a software calculation. The XML tags categorized the data so that its content could be understood and used.

XML is a very powerful language for exchange of any type of data. If two software programs can each understand the particular dialect of XML being exchanged, they can seamlessly work together. This is the underlying principle of Web services.

Business-to-business Web services
The first type of Web services is what I will call business-to-business Web services, which allow programmers to build a connection between two software programs without major modifications to either program. The developers create a middleware program that takes requests for data from the first program and converts them into a form of XML that can be transported over the Internet to a second program. The request is transported in simple text, using HTTPthe same protocol that Web pages use.

The most common transport protocol for the XML in HTTP is known as the SOAP (Simple Object Access Protocol). Since SOAP uses HTTP, it can easily pass through firewalls, just like a Web page, with essentially no security risk. A second middleware program associated with program 2 receives the requests from program 1, communicates them to program 2, takes the response from program 2, converts the response to XML and sends it back to program 1 where the middleware will once again convert the information into a form useful for program ^1.

Although it may sound complex, this mechanism has a number of important advantages. First of all, the two communicating programs are completely independent of one another. Since the XML transport language is completely platform independent, similarities in operating systems or architectures are not required. One program can operate on Windows XP and the other program on Linux.

Secondly, the underlying programs can be modified and new versions installed or even replaced wholesale with no consequences as long as the underlying connection to the middleware stays the same. Finally, the original software programs can be located across the world from one another, each protected by a firewall. In fact, the underlying programs 1 and 2 dont even need to be physically located anywhere near the middleware. Thus, the security of any underlying data or software is preserved. All the middleware needs to know is the structure of the data request (GiveMeDiscountPriceUS) and the structure of the response (HereIsDiscountPriceUS).

This type of Web service is being used by many companies to connect internal software and to connect to business partners. An article in the 9 December 2002 Wall Street Journal discusses how JetBlue Airways is using Web services to provide pilots automatic updates to their instruction books from anywhere in the world. Instead of carrying a large notebook where they rip out outdated pages and replace them with new ones, this is done automatically by connecting to the Internet and making a request of a Web service. The updates are automatically downloaded and inserted into the electronic manuals. No more paper manuals. The company is planning on distributing flight information to pilots this way, and linking up to their parts manufacturers and fuel suppliers.

It isnt hard to see how this concept could be deployed in clinical trial systemslinking up data management systems with EDC systems, financial systems, clinical trial management systems, and clinical supply systems. A major advantage to this approach would be the substitution of any of these systems with another without the need to engineer or validate the various interactions of the systems.

Broadcast Web services
Web services goes well beyond business-to-business application. A second type of Web services, which I will call broadcast Web services, is the place where Web services is getting the most attention from the media and computer community. In this model, a database owner or software developer creates a middleware interface to their data and advertises it on public or private lists of Web services, called UDDI (Universal Description, Discovery, and Integration) servers. The UDDI server acts like the phone bookthe white pages, yellow pages, and green pages combined. A company with a new Web service would advertise the type of service available, and the location and methodology for querying the service. In theory, anyone can go to the UDDI, search for a type of service, and build a simple tool to access the data. More importantly, a middleware program should be able to automatically search UDDIs and configure itself to receive the data without human intervention.

Excellent examples of these types of broadcast services already have been developed. Microsoft, SAP, and IBM all have UDDI servers available. There are a number of noncommercial UDDI servers as well (see www.xmethods.com, for example). Some broadcast Web services may charge a fee per transaction, but others are free. On Xmethods UDDI you will find examples of Web services that include airline scheduling, package delivery tracking, weather reporting, currency exchange, and translations.Google has opened up its search engine as a Web service, and several companies have built alternative search engines on this data. The results are amazingtry www.staggernation.com/ gawsh/ or www.touchgraph.com/ TGGoogleBrowser.html/ for a fascinating look at how Google data can be reinterpreted. Although these may seem trivial, they are the earliest examples of a coming revolution in the way that we build software.

Imagine a future concomitant medication Web service. A clinical trial safety software program might automatically seek out coding for a concomitant medication by consulting a UDDI directory for coding programs. The UDDI would specify the location of the coding Web service and the communication interface for requesting the service. Many such coding Web services might exist, distinguished perhaps by cost per transaction, specialty area, nationality, or other criteria. The appropriate UDDI would be chosen automatically, a request made, processed, and returned with the conmed coded without any human intervention.

Web services may sound a lot like the old standards storyone that CDISC is making notable strides in surmounting. Certainly, clinical data standards will play a role in clinical trial-related Web services, but only as the vernacular of XML that is being used. In fact, the concept for Web services has been around for years. What is new is that Web services is rapidly being widely implemented. The Web services story is about much more than data standards. Web services is the structure and process that will allow true interoperability and seamless integration of the entire landscape of clinical trial software.