BY BROUGH TURNER

No, this is not about two-digit date codes! Rather, it’s a look at emerging distributed component architectures for electronic commerce and how they will affect the way we develop software for telecommunications applications.

The next stage in the evolution of information technology is becoming clear. It is distributed software components that support large, complex, distributed electronic commerce applications using distributed, networked computers — PCs and enterprise servers for now, but eventually including computer- based household devices (phones, set top boxes, appliances). This technology has been brewing for some time as object-oriented programming has gained favor and object management technologies such as Common Object Request Broker Architecture (CORBA) have evolved. Over the next two years, we should finally see widespread deployment of software development environments that leverage this technology and drive new applications in commerce and in telecommunications.

There are (at least) two camps, and dozens of independent players, competing to provide the software tools and standards that will make these new applications possible. Today the major competition is between Microsoft and a coalition of Sun, IBM, Netscape, and Oracle. However this battle turns out, corporate computing will never be the same. More to the point for CTI � readers, telecommunications applications will never be the same. The issue is not TAPI, JTAPI, or S.100 as APIs for computer telephony (CT). This is about the total programming environment that developers of telecommunications applications will use in the year 2000.

Open telecommunications developers already leverage a great deal of technology from the world of information technology (IT) — PCs and the wide array of hardware components available in the PC market, plus a vast amount of software, including operating systems, compilers, interpreters, databases, and so on. The telecomspecific details, however, continue to be platform-dependent.

The CT developer has a choice of operating systems and APIs. There are also dozens of companies with scripting or GUI development environments for those who want to work at a higher level. But once a CT developer chooses a development environment and an API, a great many options fall away. More significantly, everyone who has built large and/or scalable systems for public network deployment has had to define their own strategy for inter-processor coordination, for high availability, for message storage, for administration, for billing, and so on. Now, as the tools to support large distributed electronic commerce applications emerge, the CT developer who pays attention and leverages these tools will gain a substantial lead.

A BATTLE — WITH WHAT OUTCOME?
Surprisingly, neither Microsoft nor Sun/IBM/Netscape/Oracle have done a good job at articulating their respective distributed e-commerce system visions. Instead, most of their public posturing, and most press coverage, has been on the battle of "pure" Java versus Microsoft’s Java, or on the conflicting premises: "Java is a complete environment" versus "Java is just another language." Predicting a winner is risky. What’s more important is to understand the range of possible outcomes and to be prepared to prosper in any scenario.

Having said that, I’ll go ahead and predict a middle ground. Microsoft will keep gaining market share and mind share, but the existence of non-Microsoft enterprise servers together with an expanding range of new client devices will keep alive the need for a platform-independent programming environment. This diversity will prevent Microsoft from controlling everything.

What do I mean by new client devices? Under this heading, I include PDAs, such as 3Com’s PalmPilot; set top boxes; future telephone sets (as outlined in my January column, "New Paradigms For The PBX"); and new devices not yet invented. Until and unless Microsoft displaces Sun, IBM, and HP in the enterprise and the Internet backbone, and takes control of the operating environment for all the myriad devices that will emerge over the next few years, there will be a market for a platform-independent development environment like Java.

THE VISION(S)
While I have yet to see it articulated in one place by Microsoft, the combination of several current Microsoft initiatives provides one rather compelling vision of how distributed electronic commerce, and other large distributed applications, will work in the future. Roger Sessions, an independent author, presents much of this picture in his book COM And DCOM (assuming you can wade through an overly cute presentation that brings software components to life as "gnomes").

The Java group does little better. Sunsoft (on their Web site, java.sun.com, for example) implies that the "open, platform-independent, object-oriented nature of Java technology" will allow developers to build distributed systems and solve problems that previously seemed "unthinkably complex." Having made that grand statement, the technology detail remains focused on Java the language.

Regardless of whether either side can articulate their vision, there is plenty of activity. Each side is combining ideas from object-oriented programming, security, directories, object brokers, distributed programming, queuing, transaction processing, CPU clusters, and high-availability systems. The results will be substantially better tools for building large, distributed telecommunications applications.

SOME DETAIL
Microsoft is basing its architecture on software components — software entities that encapsulate useful functions without being tied to a specific larger program or a specific execution environment. In the Microsoft model, components conform to COM, the Component Object Model, and DCOM, which extends COM across multiple processes — processes running on remote computers, for example.

COM defines how to encapsulate functionality and expose the interfaces through which a component’s functionality may be accessed. Components themselves are implemented in a variety of languages such as Java (Visual J++), C++, or Visual Basic. In the Microsoft view, components communicate with each other using Microsoft Message Queuing (code-named Falcon). They are managed by the Microsoft Transaction Server (code-named Viper). They work with a variety of other Microsoft products such as SQL Server. And the whole ensemble can be made reliable and highly available using the Microsoft Cluster Server (code-named Wolfpack). Today, it’s partly real and partly vision, but when completed, it will form a powerful architecture for large, scalable, distributed applications.

COMPONENTS
Since the dawn of computers, programmers have been evolving ways to partition a problem and reuse software written by others. Over the decades, they’ve developed subroutines, separate compilation and linking, dynamic linked libraries, client-server architectures, and now components. Under COM/DCOM, all knowledge of what a component does is encapsulated with the component. And access to a particular instance of a component can be arranged, at execution time, by an independent, distributed-component management system.

The result promises to be a modular, highly scalable, distributed system that is easily upgraded, even in the field. At a minimum, COM allows one to implement user interfaces in a GUI-focused language like Visual Basic (VB) while implementing application or business logic in C++ or Java. The VB-based user interface and the Java-based business process logic are separate components, but with COM they can exchange messages and work together seamlessly. With DCOM, the individual components can be readily moved from one computer to another and can be shared across substantial distances. And eventually, there will be a wealth of components from the IT world that CT developers can leverage to speed their projects.

SCALABILITY
It’s not enough to define how to distribute components without considering efficiency and scalability. As the number of ports, the number of callers, or the number of transactions increases, one would like to add additional equipment and directly improve performance. Unfortunately, it doesn’t always work that way.

Without careful design, doubling the number of processors may yield only a small percentage gain in the number of transactions per second. In the Microsoft vision, the Microsoft Transaction Server (MTS) provides a scalable means to manage components. While the first release of MTS lacks some features, eventually it will manage pools of objects (instances of components). And, if you follow some simple rules in designing your components, the resulting architecture is indeed linearly scalable for additional instances of your components.

MTS supports distributed transactions and distributed access to databases. Both are important for Interactive Voice Response systems that typically serve as the communications front end to a database, for example, or to a transaction processor that’s executing transactions on the caller’s behalf.

SCALABILITY AND HIGH AVAILABILITY
Finally, the Microsoft Cluster Server (MSCS) directly addresses both scalability and availability. While the current version of MSCS supports only two computers and lacks load-balancing, future ver sions are expected to handle more computers and perform load balancing.

Of course, clustering is not new. Digital Equipment and Tandem have been providing it on other operating systems, and more recently, on Windows NT systems. What’s different is Microsoft’s market clout. We can expect hardware and software vendors to conform to MSCS specifications, with the result that high-availability platforms will come closer to PC price points.

SECURITY
Security is a critical issue for electronic commerce, but it is also essential for large, distributed telecommunications applications — applications that must operate on multiple computers connected over public networks (PSTN or Internet). As a basic platform, Microsoft has already made Windows NT a relatively secure operating system for business purposes. From the beginning, NT has qualified for a C2 rating by the National Computer Security Center. But the key security issues for distributed components are handled by the Microsoft Transaction Server (MTS). MTS provides the means to administer security levels and authorization for components. MTS also supports client impersonation, that is, the temporary assignment of security rights based on the rights of the client who invokes the component.

For WAN security, especially secure message transmission, Microsoft has the CryptoAPI architecture. CryptoAPI targets the full range of security issues including digital signatures for authentication (and non-repudiation), key management, and key exchange.

MORE THAN JUST TAPI 3.0
As discussed in On The Horizon last November, Windows NT 5.0 and TAPI 3.0 look like viable solutions for developing computer telephony applications in 1999 and beyond. But for large, distributed, or scalable systems, much more is needed. Now it appears the rest of the pieces are coming together, admittedly in competing flavors from Microsoft and from the Java community. Regardless of who wins the components battle, it is clear we’re on the verge of major change in the way we develop large, distributed applications. And, given this new information technology, telecommunications solutions based on open computer technology are now poised to penetrate every part of our telecommunications infrastructure.

Brough Turner is senior vice president of technology at Natural MicroSystems, a leading provider of hardware and software technologies for developers of high-value telecommunications solutions. For more information, call Natural MicroSystems at 508-620-9300 or visit the company’s Web site at www.nmss.com. E-mail to the author (rbt@nmss.com) is also welcome.