ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.


AddThis Social Bookmark Button

Chatting in XML Financial Messages

by Dmeetry Raizman

According to conventional wisdom, the only way for parties to exchange financial transactions is asynchronous messaging, primarily because each party uses its own, different, largely incompatible core application software. In this heterogeneous application environment, transmission and reception of messages remains the only way for disparate applications to communicate.

One-to-one message transfer is a static solution. It allows data to be sent back and forth between applications, but users cannot interact in real-time. Essentially, an event occurs in one application, then an appropriate message is pushed to another application for processing. The messaging is asynchronous: the receiving application does not send any message back nor does the sending application expect a return message immediately. The response comes later, asynchronously, and communication is possible only at the level of data exchange.

Such communication between applications resembles what happened before the invention of the telephone when, in order to communicate, people sent and received telegrams. Anyone who wanted to make a decision dependent on remote information had to send a telegram and wait until the reply message arrived. These limitations of the communication system influenced the way people did business, preventing compression of the trade time cycle to less than a couple of days. Today, the typical securities trade cycle is T+3.

While disparate applications communicate in this telegraph-like way, the typical application integration software consists of application adapters, message handling, routing, data translation, format transformation, and management of asynchronous flows of message exchange. Systems implement batch processing through an event-driven application scenario:

  • monitor message reception;
  • transform the message;
  • analyze previous messages;
  • make decisions about message routing: either forward the message to its destination application or hold it until a different message is received.

This scenario requires significant processing time. Consequently, traditional messaging fails to provide microsecond responses from the time a customer initiates a request to the time he can receive an accurate reply.

It is said that "T+1 aligns the efficiency of the clearing and settlement process with the efficiency and effectiveness customers have come to expect from the front-end of the trade process" (SIA T+1 Business Case - Final Report - Release 1.2 August 2000, p. 3).

Comment on this articleWhat do you think of this author's approach; and have you used it in your development efforts?
Post your comments

Suppose that telegram-like messaging technology can be replaced. Assume that the messaging application enables you to locate a message that was just issued by the trader. It also immediately appoints a broker to handle the business data of this message and provides an entire browser-based online contextual data view showing you all previously-issued, related messages.

In such a situation, the broker can make the business decision, execute it, and notify the trader in real time. The trader can access the data immediately, analyze it contextually, and confirm the deal to the broker. Indeed, software that supports trading could establish real time chat lines between the parties involved in the trade process (broker-dealer-custodian-customer). Instead of sending messages and waiting for a reply, the parties can chat in real time. Accordingly, the length of the trade process can be compressed significantly.

Where Do We Start?

The value of XML is much more than just providing a unified message format, which allows parties to exchange financial transactions. Using XML, it is possible to establish financial real-time chat lines.

Before XML, data collections persisted on the global network in the form of HTML pages. The only way to access the data was to view these pages with a browser. This resembles viewing microfiche films, i.e., pictures of data, not the data itself. In order to be extracted, data should be presented in a predefined format. Such a presentation seriously limits its usefulness. Regrettably, these HTML collections are generally unprocessable, i.e., there is no way to provide universal software for extracting data from HTML pages.

The tools to build, test, and deploy business web sites are in short supply. Many developers focus more on building attractive rather than useful sites. The existing tools fail to address the entire software lifecycle (design, development, deployment, and maintenance) in a way that is consistent and efficient.

By providing a means of separating actual data from the presentation of that data, XML offers an indispensable common foundation for extraction of data from heterogeneous structured data sources. XML allows documents to be obtainable and viewable in a contextually aggregated form.

Java and XML

Java and XML
By Brett McLaughlin
1st Edition June 2000
0-596-00016-2, Order Number: 0162
498 pages, $39.95

XML is an essential aspect in the new circumstances. However, XML by itself is not enough for enabling coherent and semantic data viewing. An appropriate XML-enabled software technology is required for this challenge. It is a key to the next generation of the Web, and it offers

  • a way to unlock information, so that it can be organized, programmed, and updated;
  • a way to distribute data in more useful ways to a variety of digital devices;
  • a way for sites to collaborate and provide a constellation of services, able to interact with each other.

In particular, such software should do the following.

  • Support several XML collections of data which are entirely accessible, processed, and presentable in the context of the required functionality.
  • Many vendors claim to be able to solve the problem involved in accessing disparate data sources, but they are actually taking information from one system and transfering it to another. As a result, there's a substantial hold up in the trade cycle. New business actualities require qualitatively different solutions while data is pulled live from existing data sources. It is no longer about better or faster data transport. It is about leaving the data where it is, providing a real time and high-impact pathway for obtaining data contextually.
  • Facilitate companies in deploying relevant fragments of their business data, ensuring the data is completely "understood" by any party.
  • Gather multiple sources of information that are located anywhere on an IP-network, so as to enable seamless data access. This will also allow integration of any group of data sources into a homogeneous pool of information.
  • Transform the web-based data collections from a read-only into a read/write platform, enabling users to interactively retrieve, browse, create, and modify information.

The following section explores the possibilities of such an application.

Pages: 1, 2, 3

Next Pagearrow