Beyond the browser: Web Services hold key to the Internet's future

Setting the Web Services scene

The Web is Dead. Long Live the Web Service. Over the next year, expect the noise concerning Web Services and the technologies that underpin them to become deafening. For Web Services are slated to become the new model by which companies will supply services - and that includes financial information, transactional services and applications - via the Internet, using technologies built on open industry standards.

Unlike the Web of today, which is essentially a platform for the delivery of information for viewing by humans, Web Services are designed to provide a "programmatic" interface to services, so that other programs may access them, across the Internet.

Does this paradigm sound familiar? In financial trading firms, the "green screens" of the past have now been replaced by digital datafeeds that drive specialized display and analytic applications. Now, that evolution is being re-enacted on the Internet, in a more generalized way, using open standards.

In financial services, many Web Services will be created. For example, an information vendor such as Reuters could create Web Services for such facilities as stock quote inquiry/display, for displaying a ticker of stocks, and for charting a stock. All of these services can be called - across the Internet (or a private intranet) - from a simple 'stub' application to create a fully functional trader workstation.

Getting better services

Service-based approaches are not a new concept in the software world. Object oriented design is based on an architecture where objects provide services to other objects. But to date, object technology has been largely proprietary - like Microsoft's Distributed Component Object Model (DCOM) - or complex, as the Common Object Request Broker Architecture (CORBA) is often characterized.

Moreover, with these existing technologies, both the service provider and the services consumer need to be using the same object scheme, because the protocols used to interact among objects are specialized. And as the final nail in the coffin of these legacy object models, the protocols they use are difficult to deploy across the Internet, especially where companies deploy firewalls.

Taking an open standards approach means that anyone using Web Services will not be locked in to a particular vendor. For example, a Web Service built using Microsoft server technology could be accessed by a user running any kind of workstation: a PC running Windows, a Sun Microsystems workstation running Unix, or from Linux or Apple-based computers.

And even better: Web Services will make it easier for users with mobile devices, like PDAs, WAP phones, eBooks or Tablet computers to access services. All that's needed is the same conformance to standards at both ends of the communication.

Co-operation among the heavyweights

Web Services are set to succeed because of the backing they are getting from IT industry heavyweights like Microsoft, Sun, IBM, and others. It's unusual to find much agreement among that group of companies, but with Web Services they are all adopting the same mantra: "Cooperate on standards. Compete on implementation."

So long as those major players stay honest, it seems inevitable that the entire Internet economy - and today that's the global economy - is set for a total technology and business model redux. Which, as it happens, is a great thing: there's nothing like a makeover to give a boost to a weak economic climate.

Of course, cynics believe that it's only a matter of time before there's a major falling out between the likes of Microsoft and Sun. And for those that remember the Java experience, there's certainly a precedent for that. But so far, all the major players have been putting their weight behind creating true open standards, through the auspices of the Worldwide Web Consortium, or W3C. Some standards are already pretty much set, while others require more work. Over the next few months, the main components will become stable enough for widespread adoption.

The competition between the Microsofts and Suns and IBMs comes in the technologies that each is building to support Web Services. The major initiatives from these companies include:

• .Net from Microsoft. This initiative includes a set of servers for providing Web Services, a new desktop operating system called Windows XP (formerly codenamed Whistler), new operating systems for handheld devices, and personalization services, such as Hailstorm.
• Sun's Sun ONE (Open Network Environment) offering, which is based on Sun's existing Java technologies. One element is the Sun ONE Webtop, a Web Services-based implementation of Sun's StarOffice productivity suite.
• IBM is building a set of Web Services offerings based on its WebSphere product suite, which includes a Java-compliant application server.

Standards, standards, standards

So just what are these standards, which are so important to Web Services? They include:

• Standards for the actual communication of data across networks. The most common one being HTTP - for HyperText Transfer Protocol.
• Standards for the structuring of data passed across the network. Here, the eXtensible Markup Language (XML) is being adopted.
• Standards for supporting the display of data delivered as XML on a wide range of devices. The eXtensible Style Language Translation (XSLT) function will likely be used for this.
• Standards for delivering the structured data on an application-to-application basis. The standard here, for the moment, is SOAP - for Simple Object Access Protocol.
• Standards for the way that Web Services can describe themselves, how they can be accessed, and what they offer. The standard being backed is WSDL - for Web Services Description Language.
• Standards for the way that Web Services advertise their availability, and how users may locate them. The Universal Description, Discovery and Integration (UDDI) initiative is likely to deliver the standard here.

Let's take a closer look at what some of these standards are, how they work, and where they are heading.

XML: getting the data delivered

At the lowest level, a transport protocol like HTTP is used. HTTP is the protocol used on the Internet by the Web to communicate between browsers and Web servers, and it may be freely used through firewalls. But Web Services do not mandate the use of HTTP. For communication with wireless devices, other protocols will likely be employed.

What Web Services do require is that XML is used to structure the data that is transmitted across the network. XML was adopted as a standard by the W3C in February 1998, and its specification may be freely downloaded from the consortium's Web site.

Just like HTML (HyperText Markup Language), XML is a markup language. But whereas HTML is used to control the way the content of a documents (especially Web pages) are displayed, so XML is used to define the structure and meaning of the content of those documents so that the contents may be processed by an application.

Once again, this sounds familiar to the world of financial market data managers. The early digital feeds were page based, so that to extract specific items (e.g. currency rates) required that the application 'scrape' the page at known coordinates to extract the information. Later, record-based feeds came into being where specific data items were uniquely identified as fields within each record.

XML has its origins in another markup language called SGML (for Standard General Markup Language), which was invented by IBM, and became an ISO standard in 1986. SGML was designed to allow text data to be stored in one format, and then published in a variety of ways - e.g. a description of a new product might be published as an update bulletin for existing users, and as a portion of a catalog for prospects.

Once the Web was invented, Web publishers found they had similar issues to print publishers. But SGML is a very complex language, and so a cut-down version was proposed, by two individuals: John Bosak (from Sun) and Dave Hollander (from Hewlett-Packard, and now at Contivo), and this led to the XML standard from the W3C.

Similar to HTML, an XML document consists of 'tags' that are wrapped around raw data, and which may be embedded to multiple levels. So XML documents are readable by humans, and are coded in a character set like ASCII. Unlike HTML, the creator of XML documents isn't restricted in the tags that may be used. And new tags may be created to provide descriptive meaning to the tag contents.

Here is a simple example of information for a stock:

<Stock_Information>


</Stock_Information>

Moreover, the tags can actually be used to define not just pure content, but also to specify a function that needs to be executed, or a result of a function. In this way, XML can replace some of the functions found in distributed object systems, like the Remote Procedure Call (RPC) found in CORBA.

Again, an example, of a simple request and response for stock information.

The request might be:

<Request_Stock_Information>


</Request_Stock_Information>

Resulting in this response:

<Result_Stock_Information>
<Stock_Information>

<Identifier>IBM</Identifier>
<Last_Trade >123.45</Last_Trade>
<Current_Bid>122.00</Current_Bid>
<Current-Ask>123.75</Carrent_Ask>

</Stock_Information>
</Result_Stock_Information>

In an XML interaction between two or more parties, tagging of data is only useful if all the sending and receiving parties agree on the usage and meaning of the same tags. To achieve this, all those involved in the interaction reference what is known as a Document Type Definition (DTD), which essentially contains the master list of tags, and specifies what type of information they contain, and what frequency and embedding rules apply. Standard XML tools (freely available) may then be used to ensure that an XML document confirms to the DTD that it references.

Within the financial services marketplace, a lot of work is underway to adopt XML for applications such as research publication, executing of transactions, and straight-through-processing. This effort is being undertaken both by individual vendors, and also consortia of banks, brokers, institutional investors and vendors. As a result, an alphabet soup of new XML vocabularies have been created, including NewsML, RIXML, FpML and FIXML. More information on these projects is given in the following table.

Major XML projects in financial services
FIXML: FIXML is the XML version of the existing FIX (Financial Information Exchange) protocol that is widely used to link sell-side brokers to buy-side institutional investors, mainly for equities transactions. www.fixprotocol.org.
FpML: FpML is the Financial products Markup Language, being created by a consortium of users and vendors involved in the OTC derivatives marketplace. Initial focus has been on interest rate derivatives, but equity and FX markets are now being addressed. www.fpml.org.
IRML: IRML - the Investment Research Markup Language - was founded by Multex.com with the aim of standardizing the exchange of financial research information between the research creators, vendors and the clients, including buy side institutions, corporations, and individuals. The consortium now has a broad base of membership. www.irml.org.
MDDL: The Market Data Definition Language is being created by a working group of the Financial Information Services Division of the Software and Information Industry Association. Its aim is to create a XML vocabulary for real-time and periodic financial price data, including time series. www.fisd.net.
NewsML: NewsML is an XML vocabulary for the distribution of multi-media news content. It was originally created by Reuters, but is now managed by the International Press Telecommunications Council. www.iptc.org.
RIXML: Overlapping somewhat with IRML, RIXML - for Research Information eXchange Markup Language - involves brokers and their asset manager clients. The initial focus of RIXML is on equity research, and covers some areas of monetary policy and economics. www.rixml.org.
SWIFTML: The Inter-bank payments and securities confirmations group SWIFT is creating swiftML, primarily to support STP in the securities area. www.swift.com.

XSLT: making XML work with different devices

As well as the XML standard itself, the W3C has been pushing ahead with many related standards, including the eXtensible Stylesheet Language. In particular, XSL Transformations (XSLT) have been getting a lot of focus, since this technology is used to transform XML into viewable markup languages like HTML for browser viewing, or WML for mobile users running WAP phones.

XSLT documents are used in conjunction with runtime XML translators, to convert XML documents into a different format, including non-XML formats. For instance, a research report on a company might be coded as an XML document, allowing searching for particular information elements (such as revenues, profit, margins), and allowing for comparison on companies based on these criteria.

This XML document could also be processed by XSLT to produce a number of viewable output formats, including HTML for Web publishing, PDF for distributing via email, or Postscript for print publishing.

XSLT can also be used to transform XML into other non-viewable formats, which might be needed in an STP environment, where a trade confirmation message from an order-routing network in FIXML might need to be converted into swiftML for confirmation with a counterparty.

SOAP and WSDL: allowing applications to interact

As previously mentioned, XML can be used to describe either raw data or processes. The SOAP initiative is designed to create a standard way to exchange XML messages and to describe what is contained in a message and how it should be processed.

SOAP is itself an evolving standard, which has its origins in work involving Microsoft, UserLand Software and Developmentor in 1998. IBM and others joined the effort in early 2000, and co-authored the SOAP v1.1 specification that was submitted to the W3C in May 2000.

Now, the W3C is using SOAP as the basis for work on its own full open standard in this area, known as XML Protocol, or XP. Work on XP is still at the working draft stage within W3C, and when it becomes a full standard, SOAP's backers are expected to support it.

Already, another important standard in the world of XML - ebXML (for electronic business XML) - has determined to incorporate SOAP into its specification, rather than to re-invent the wheel. ebXML is co-sponsored by the United Nations and is concerned with setting standards for global business eCommerce.

Along with SOAP, another work-in-progress standard is WSDL, which is an XML-based standard for describing Web Services - what they offer, how to access (or 'bind' with them, to use accepted terminology) and how they can be used. WSDL was created by Ariba, IBM and Microsoft, and submitted to the W3C in September 2000.

UDDI: supporting online business relationships

Had enough buzzwords yet? Let's recap: With Web Services, XML is used to structure data, SOAP is used to transport the XML and make remote function calls - so creating a Web Service, and WSDL is used to describe the Web Service to the outside world.

But to whom (or, rather, what) will WSDL be describing those Web Services? How do users of Web Services actually find the Web Services they want to make use of? One way is to reference the Web Service through its IP address, but rarely is that known, as is the case with traditional Web sites.

That's where UDDI comes in, as a searchable directory service through which Web Services can publish their existence, and users can find them. As with WSDL, the UDDI specification came from the Ariba, IBM and Microsoft team, but it is still being developed by that group (with the backing of more than 200 other companies) and has yet to be submitted to the W3C for formal review and ratification.

UDDI services contain three kinds of information, known popularly as the white, yellow and green pages. White pages contain information about Web Services, and how to locate them. Yellow pages provide categorization, and green pages provide detailed technical information needed to integrate Web Services together. Of course these white, yellow and green services are accessible in a programmatic way. In fact, UDDI services are themselves Web Services, with a defined interface involving 16 SOAP messages.

Already, the founding three have created their own publicly available prototype UDDI services, but in reality many UDDI services will be created. Some may be very open services, like Yahoo, while others will be essentially private UDDI services creating closed user groups of communities.

For public services, security is an issue, especially where SOAP messages are causing code to run on client machines. As well as the issues of 'trust' there are issues of quality. How does a company wishing to purchase a commodity differentiate between five, or fifty, or five hundred Web Services providers of that commodity? Most likely, trusted companies - perhaps a Dun & Bradstreet - will assign ratings to Web Services so that quality can be more readily determined.

In financial services, where relationships are key to driving wholesale market order flow, expect UDDI services to be formed by communities of trading partners. And entry to those communities will be based very much on those partners being established, well known and trusted in the offline world. And legal requirements will also be met - most likely is an offline manner for some time to come.

All of which goes rather against the grain of the hype surrounding Web Services, which portrays a world where partners do business having just met online. In all probability, the financial services model will prevail. And once again, the Web and Web Services pioneers will be learning that it's all been done before, on Wall Street of course!

Where to learn more about Web Services
XML	www.xml.org
SOAP	www.w3.org/tr/soap
WSDL	www.w3.org/tr/wsdl
UDDI	www.uddi.org
Xmethods	www.xmethods.com

Pete Harris is President of Lighthouse Partners, a New York-based marketing strategy company working with developers of advanced technology, and its deployment in financial services. Lighthouse created the www.xmlonwallstreet.com Web site, an online resource focused on XML's use in the financial services marketplace.