The intermediate tier

Over the past few years, companies around the world have been implementing middleware to help resolve a critical problem: The legacy applications that are vital to running their business also are endangering their future because those applications cannot be readily modified to suit changing requirements.

Today's telephone service providers, in particular, face an incredibly fast-moving market. Deregulation, increased competition and consumer demand for new services are forcing telephone companies to react quickly to market changes. Traditional legacy systems cannot be modified quickly or cheaply.

Object technology for new applications is certainly one solution, but the time and cost required can be prohibitive. In addition, these technologies may not offer the robustness or performance necessary for mission-critical systems. Service providers need a solution that lets them continue using the legacy systems in which they have invested, and simultaneously create and deploy the new mission-critical systems that will support future growth.

Conceptually, middleware vendors have the solution: an intermediate tier that links legacy systems to new applications in order to get the best of both worlds. However, middleware has not lived up to its early promise because it has been difficult to use, administer and carry forward. It also has lacked the performance and robustness that mission-critical systems demand.

Until now, many companies have evaluated middleware based on five central requirements: ease of implementation, tools, flexibility, accessibility and value.

To support mission-critical services and systems, the next generation of middleware must do even more-it must provide real-time performance, guaranteed delivery and industrial-strength robustness, ease of use for ongoing development, and flexibility.

Let's get serious Message-oriented middleware products typically deal with tens or perhaps a few hundred transactions per second. For customers looking to middleware to help them offer new mission-critical services, that is inadequate by at least an order of magnitude. More businesses need to implement real-time systems; therefore, middleware needs to provide real-time performance.

A new real-time telecommunications billing system, for example, might take high volumes of customer detail records from a switch, parse them, generate multiple events and update several databases, all in less than a second. New Internet-based businesses are springing up every day, bringing with them the need for a new kind of enabling technology. An Internet trading service would lose customers and open itself to lawsuits if, for example, a customer traded electronically when the stock read $23 3/8 on the computer but ended up paying $26 7/8 because of the time lag before the trade was processed.

Middleware can handle a high volume of transactions per second by real-time performance (Figure 1). Such performance can be achieved by combining several features, including queues to provide flexible throughput, in-memory data caches, compiled event management logic and software backplane architecture. An example of the latter is the Tibco Information Bus, Softwire's distributed services environment.

Guaranteeing the delivery of events is increasingly important for almost all businesses. Itemized bills and cut-throat competition have underscored the need for telecom companies to keep track of all customer detail records-or risk losing revenues.

Middleware in this kind of setting must guarantee that it delivers all the messages it receives to their final destinations. Transaction-based middleware can compensate for local failure by using the log to roll back a transaction and roll forward once an alternative is established.

Sometimes this transaction handling will be synchronous, as with transaction processing monitors, which are control programs that manage the transfer of data between multiple terminals.

Synchronous transactions have two significant weaknesses. Batch-oriented legacy systems are not easily compatible with transaction processing monitors. And with two-phase commit, which synchronizes distributed data through a handshake mechanism, adding nodes exponentially increases the probability that no transaction will be committed because of a regional failure.

An asynchronous approach can deliver a high throughput using queue-and-catch-up and can mimic a synchronous system when necessary. An asynchronous middleware platform can be virtually synchronous, but a synchronous platform can never be virtually asynchronous.

Timing should be a feature that can be tuned according to specific requirements, rather than an inflexible constraint built into the heart of the middleware. Together, the use of queues and logs guarantees that every event will be accounted for and will ultimately reach its destination.

Make it robust Imagine that there is a complex piece of middleware linking a variety of live systems, and suddenly a key database goes down. The middleware needs to find and implement the appropriate rule to deal with the problem. It must fail over to a different database, or queue the transactions until the database comes back up. It also needs to insulate other components of the system-including itself-from the local failure.

Middleware should never go down-not even when bringing up new versions. It should be fault-tolerant software that runs on standard Unix and NT platforms with minimal attention from the systems administrator.

Self-healing software is a relatively new concept, and there is much to be learned from the experiences of the fault-tolerant hardware vendors. There is no fundamental reason why software should not aspire to the 99.999% reliability expected of telecom networks, power grids and certain defense systems.

Middleware at this level has yet to be implemented in real-world systems, but the direction for the future is clear. Customers need this kind of robustness, and middleware must provide it if it is to ameliorate, rather than compound, the problems experienced by information technology groups across the globe.

Simplification is also key. Graphical user interface (GUI) tools have helped cut down the application backlog for client-server systems, and businesses also would like to harness their productivity for middleware applications. Information systems managers are increasingly aware that projects built around hand-written code essentially place the entire system at the mercy of the weakest programmer on the team.

Today's GUIs, by contrast, create reliable and reasonably efficient code that can be modified and carried forward as requirements change. Yet middleware has not taken advantage of the improvements in GUI tools. Too much middleware today still imposes primitive programming environments, difficult-to-use functionality, too many application programming interfaces, and a lack of intuitiveness that makes Unix look positively user friendly.

Although desktop applications development tools-such as PowerBuilder from Sybase's PowerSoft subsidiary-cannot yet provide the requisite functionality to generate middleware-style code, there are a number of suitable tools on the market such as Project Technology's Bridgepoint Analyst object modeling environment. Even Visual Basic should quickly reach the point where it will be an appropriate tool for middleware applications. Support for off-the-shelf tools will in turn lead customers to adopt middleware solutions sooner.

In addition to enabling use of off-the-shelf tools, middleware should provide the kinds of simulation, audit, debug and performance tuning capabilities we expect from good development environments. As middleware becomes more critical to bet-your-company systems, it must provide the developer services that ensure the deployed code is up to its task.

The old approach of using models to generate non-performing code, then hacking the code into shape, was inefficient and one-way. Once the code was hand crafted it no longer mapped to the model, and hence the model became useless. The goals of efficiency and reuse require a code generation architecture that provides the ability to create the code you want while maintaining the one-to-one relationship with the object model (Figure 2).

This approach lends itself well both to using off-the-shelf GUI tools and providing object templates for those GUI tools to use. For example, the code generator that links to the GUI tool could provide SNMP publish objects, persistent store objects that would map variations to particular vendors' databases.

These templates ought to be thoroughly debugged and performance tuned. They will grow in complexity to become templates for simple applications such as customer detail record parsing, Internet publishing and stock price monitoring.

This approach makes obsolete the object-oriented battle between compiled code, which is fast, and interpreted code, which is more flexible. In the code generation model suggested above, compiled code delivers high performance without sacrificing flexibility because the model can be modified and new code generated for insertion into the runtime. Such middleware could even permit on-line versioning, initiate new code and have the old version gracefully fail over in a seamless handoff.

Beyond the Unix box The dangers inherent in a closed, proprietary system are widely known, and so is the solution-open systems. However, many people define open systems as those that run on three flavors of Unix.

Perhaps a more useful definition of open systems is interoperability, which means being fundamentally independent from information technology fads. Companies that bet their systems on a distributed computing environment or open systems interconnection, for example, incurred huge ongoing costs, both in absolute terms and in foregone opportunities. Middleware should insulate the customer from information technology fads, not contribute to them.

Middleware should not be affected by the protocol or type of interface the customer is using. It should act as a backplane, providing reliable connectivity. Companies then should be able to plug interfaces into the backplane, such as a CORBA engine, an SQL engine and an HTTP engine, without requiring rewrites or upgrades.

The ideal architecture should support many-to-one and one-to-many connectivity. The former might involve connecting multiple interfaces to a single set of middleware, while the latter might include connectivity from one set of middleware to multiple applications, databases and hardware components. By maintaining the logic of connectivity-for example, when this event appears, do X, Y and Z-in one place, multiple complex applications can be tied together through interfaces without requiring a laborious rewrite each time something changes.

In the telecommunications world, such middleware might sit between the network and the legacy operations support systems and accept events from central office switches. When a switch event occurs that is associated with a call type owned by the legacy billing system, the middleware would pass it to that system just as though it were not mediating at all. However, when an event appears that is associated with a call type that does not belong to the legacy system-for example, a quality of service-based data traffic service-then the middleware would pass this event to a new modular system designed to handle this type of event.

The middleware also may be involved in the ultimate reconciliation between disparate billing systems to help create a single customer bill. In principle, there is no limit to the degree of modularity this approach can support-a critical advantage for businesses that can no longer accurately predict their systems needs several years in advance (Figure 3).

As companies introduce new call types corresponding to new services, developers enhance the object model to build new application models to manage the billing, provisioning and support of such services. Developers also create additional interfaces to correspond to the new application models.

Middleware's critical role here is to enable companies to add these new application modules quickly and without having to rewrite existing systems. Just by modifying the event handling logic in the middleware-using the existing object model created in the GUI-companies can offer new services in a matter of hours or days rather than weeks or months.

Ultimately, middleware products are poised to offer systems integration in a box. The alternative-large, expensive teams of programmers-will be less viable as telecom companies need to offer new services more quickly. In today's increasingly competitive environment, the time delays associated with traditional project implementation are no longer acceptable.

Middleware is poised to step over this breach, but in order to do so, the newest requirements for middleware must be taken to heart and reflected in off-the-shelf products. That is the central challenge for tomorrow's middleware offerings.

Allan M. Lees is President and Chief Executive Officer of Softwire, Larkspur, Calif.