Existing client-server systems must now compete with Enterprise JavaBeans, application servers and web browsers.

By Robert Hunter

In 1995, when Integral, a Palo Alto, Calif.-based software vendor, released a skeletal Internet risk management system called RiskNet, few people in the financial technology world paid much attention. Aside from a few “gee-whizzes” at trade shows, the product wallowed in obscurity. But now, with American commerce in the throes of the Internet revolution, the same people are quietly starting to adapt Internet technology to their legacy systems—and, in some cases, are moving to full-scale Internet architectures.

Why the sea change? Virtually everyone acknowledges that the Internet will play a major role in risk management in the next century. Hard-core believers argue that the Internet has already emerged as the simplest, cheapest data-distribution mechanism ever created, allowing for massive scalability and, at the cutting edge, massive parallel-processing power. For a firm struggling to solve problems within existing client-server systems, the benefits seem almost too good to be true.

The main limitation of the current client-server technology is scalability. In a client-server system, everything moves in a flat line, with the client’s desktop applications linking directly to the central database server. At heart, it’s a one-on-one system. Each time the system has to perform high-intensity calculations—such as, say, a portfolio-wide profit-and-loss—it is necessary to copy all the relevant data from the server to the client PC, where the calculations are carried out. That kind of data movement puts great demands on the client machine as well as the network itself. Moreover, when dozens of full-blown client applications access the database, the database inevitably slows down, reducing processing speeds for everybody.

Some banks and vendors have tried tacking front-end browser-based interfaces to existing legacy client-server systems to address the scalability issue. In the end, however, the browser still makes requests to the desktop system, which in turn makes requests to the central server. The result: the same old scalability problem. “All this makes for a nice demo,” says Harpal Sandhu, CEO of Integral, “but if you ever tried to get 200 users up and running, it would fall apart quickly.”

Another problem with client-server architectures is the lack of a single data standard. The patchwork information-technology approach taken by most financial institutions has created a financial Tower of Babel. As a result, most of the money and time spent in upgrading and integrating systems has centered on the unglamorous task of connecting disparate data together. In addition, since most front-office portions of client-server risk management systems are designed primarily for traders, few other people on the trading floor have access to vital trading information.

“Browsers connected to client-server systems make for a nice demo, but if you ever tried to get 200 users up and running, it would fall apart quickly.” Harpal Sandhu Integra

New types of thin-client architectures attempt to overcome these limitations by taking computing power off the desktop. In the standard thin-client model, Internet servers house all of the firm’s applications, while the client front end consists only of a Java-based web browser, connected through a corporate intranet. No longer burdened with a “fat” application layer, the newly weightless client can access multiple applications on servers that do the heavy lifting. Many developers have used a combination of thin and fat elements to achieve what they see as optimal performance.

Before a new Internet technology emerges, at least three things will have to come together: component-based distributed processing, data standardization and simple Internet browser deployability. The most popular component architecture—and the one quickly becoming the standard—is Enterprise JavaBeans (EJB), an extensible component model for object logic that is part of Sun’s Java Platform for the Enterprise (JPE) system. Objects are tiny bits of reusable code that migrate between applications; components are larger, more powerful and more flexible aggregations of code that are also portable across platforms and applications. JavaBeans are extensible components able to be processed by any EJB-based application. In typical implementations, EJB is the middle tier—the connective tissue linking the system’s horizontally deployed applications (called application servers or server farms) to front-end web browsers and central processors, legacy systems and so on.

The linchpin of the new EJB architecture is another major advance in Internet computing: data standardization. If EJBs are the connective tissue to a distributed, component-based architecture, the extensible markup language (XML) is its lifeblood (see “XML Wars,” Page 25). XML is a self-describing data language that emerged from SGML, the language that also gave birth to HTML, the Internet browser language. XML’s “metadata” tags describe data while transporting them, filtering legacy as well as real-time data into a single readable format. Since XML is self-describing, it is infinitely extensible. Software vendors are ebullient about the prospects. “Extra-enterprise application integration, also called web integration, is really the name of the game in applied technology now,” says Carl Carrie, president of CastleNet. “And the only way to guarantee that you can reduce time to market while successfully integrating across disparate technologies is to deliver information using metadata technology such as XML.”

“Instead of having to browse repeatedly and cut-and-past out of web pages, you’ve got an automated way of consuming that content as a separate object.” Michael Adam Inventure

The biggest boon for systems developers: XML allows integration of EJB, COM, CORBA and socket-based applications with existing applications. So while XML-based database and real-time data can flow directly to an application server farm, legacy data can be converted into XML before being sent off for processing. Carrie is optimistic about this. “The bane of risk management is getting data to and between the different applications that need them. XML will help lubricate the plumbing to make it easier to have applications talk to each other.” But not just yet: XML is so new that the industry hasn’t yet settled on a single XML convention.

Integral 4 claims to be the first EJB-based risk management system to come to market. At its most basic level, the system works as follows: real-time or database data flow into the Internet Financial Server, a Java-based platform built on standard application servers that includes the core financial objects (as well as access to databases and real-time data feeds). The Internet Financial Server selects the appropriate application servers for processing, and results are sent on to the web browser for consumption. The benefits of such a system are numerous. In addition to scalable web deployment, the system is extensible, since one EJB can be reused infinitely, so developers can create new components that make use of existing components. Perhaps most important, EJB allows for best-of-breed choices. When all systems are written using EJBs, a firm can pick and choose which applications it wants to use without sacrificing performance.

All aboard?

Many big-time vendors are betting on EJB. Application servers are popping up from such heavy hitters as IBM, Oracle, Sun and Sybase, and vendors from FinTrack to Infinity, a SunGard company, are embracing EJB en masse. “Many firms are already doing technical feasibility studies and even some initial developments of the EJB-based backbone,” says Kevin Dick, a Palo Alto, Calif.-based consultant. “In the next nine to 36 months, EJBs will spread dramatically.”

Vendors have historically been on the wrong side of the build vs. buy decision, but many believe that data standardization will change things. Most are trying to link the Internet to legacy systems any way they can. “People will focus less on products and more on components in a stream of different services,” says CastleNet’s Carrie. “Companies will become more service-oriented, and their products will not be full-fledged applications; they’ll be parts of the process. Eventually, users will click on a web page and won’t even know they’re on the Internet. The Internet will change dramatically in the next few years. There will be improved security and quality of service as public and private networks merge together as part of a grand net where users will have secure access to whatever services they want at the time, but certainly not limited to, straight-through transaction services.”

For most IT developers, it’s become clear that the future of Internet computing is now.

No-Fuss Internet Content

The Internet is tantalizingly rich with content, but most of the data are hard to manipulate and integrate with other systems. Michael Adam, chairman of Inventure.com, a provider of Internet and corporate data-aggregation services, argues that the real heart of capitalizing on the Internet lies in disaggregating Internet content, from data feeds to news. While the industry bides its time to true distributed computing, he says, Internet data can be lugged into existing desktop applications. “To the extent that I want to offer you control of the way you manipulate Internet content,” Adam says, “orthodoxy states that I need to send down snippets of Java applets so you can manipulate it directly on your desktop. For every single thing you do with my content, I have to preconfigure the capability and all the content.” His solution: the Data Browser, a product that allows users to consume data and other individual analytic objects directly on the desktop via XML and deliver the information to desktop applications such as Excel. The user opens up Excel, browses something that looks like file explorer to find content, loads the content into a spreadsheet, and the data that are loaded create a persistent link that can be parameterized and updated. “I can go to a site, place a formula in Excel that will go to get a price history and then tomorrow I can change the input parameter, update the sheet and the Data Browser will browse the site accordingly,” says Adam. “Instead of having to browse repeatedly and cut-and-paste out of web pages, you’ve got an automated way of consuming that content as a separate object and maintaining those, and of automating the connections between them, thereby saving a huge amount of time.” This pull-and-publish approach works with any web site or corporate intranet with a little code-mapping from Inventure.com—so enterprise data and analytics are fair game for the system. “If the data, analytical and presentational capabilities already on the Internet are published in a disaggregated form,” says Adam, “consumers of that content to take a range of sets of data from multiple services, draw them together on the desktop, run them through sets of analytical functions taken from a different set of sites on the Internet, and then pick up a set of presentational engines from a third set of sites to construct an analysis. The information is flowing from multiple points around the globe, is dispatched to run through analytical engines, and then is returned to that end-user’s desktop. In effect, you have true web computing.” —R.H.

Was this information valuable? Subscribe to Derivatives Strategy by clicking here!