However, any developer working on a three-tier application can tell you that components for the middle tier are scarce.
That's changing, thanks to the Web. "The Web is a huge accelerator to the three-tier paradigm," says Greg Hope, Component Object Model (COM) group product manager at Microsoft. Client components save developers time by encouraging reusability. Throw some ActiveX controls together in Delphi or Visual Basic, and you have an application. On the server, they go a step further. If you build your middle-tier business logic from small, quick-to-write components, you can just replace parts when they are superseded. "You can stage it all on the middle tier, and it's instantly deployed," according to John Dawes, group product manager for Netscape Enterprise Server. Not only that, if your application breaks into neat chunks, it's easier to spread the load across multiple servers.
Microsoft calls it Web computing. Netscape calls it (in a somewhat cumbersome w
ay) Crossware. And it sounds great--on paper. But a ream of incompatible interfaces and untested standards can face middle-tier developers. Disputes follow everything from network component models--ActiveX, JavaBeans, COM, Common Object Request Broker Architecture (CORBA), IIOP, remote method invocation (RMI)--to transaction systems--Customer Information Control System (CICS), Tuxedo, Microsoft Transaction Server.
Where is the matrix that makes sense of all the combinations of Web servers, component models, and programming platforms? It doesn't exist. In fact, it can't yet exist--the equations are still too complex, and the data too sparse. However, some analysis of the technologies involved can help you make some decisions about how you should implement server componentware.
Three Tiers for the Web!
The classic two-tier client/server-computing model off-loads work from enterprise servers by separating presentation and calculation from data. Two-tier programming gave rise to rapid applica
tion development (RAD) tools such as PowerBuilder and component models such as Microsoft's Visual Basic custom control (VBX), both of which eased user-interface (UI) development. In short, two-tier development made components real.
However, two-tier architectures had problems when it came time to upgrade an application or distribute load processing. Enter three-tier architectures, separating presentation from business logic from data. Developers could still use components, but the available components were still largely targeted at UI development. Middle-tier developers were left out in the cold.
The Web is beginning to change that. Originally conceived as a two-tier system, demands for dynamic content quickly turned it into a three-tier system. The Web's original middle tier was made up of applications that use the Common Gateway Interface (CGI). CGI enabled you to extend a Web server to access nearly any OS-level function, using development environments as simple as a shell script and as complex
as C++. Also, because CGI is portable, applications you wrote for an Apache server could usually run against Netscape or Microsoft servers with little or no porting. CGI programs were the first pieces of Web componentware.
Once developers realized what CGI could do, some amazing applications began to appear. The Illustra database, for example, had a CGI interface (the Web driver) that let developers write Web pages that could access a SQL database. If they could write SQL and HTML, they could create a client/server application.
Why was this a good thing? There were three reasons. First, the client--a Web browser--was virtually universal. Second, distribution of the application was as simple as clicking on a hyperlink. Finally, you could administer all that code centrally. The Web had solved three of the largest problems facing client/server computing in a single swipe. Needless to say, all the database vendors quickly followed suit.
It wasn't perfect, however. In particular, invoking CGI ap
plications can be very slow. To solve that and to give developers access to server internals, Netscape and Microsoft created server-specific APIs. Netscape Server API (NSAPI) and Internet Services API (ISAPI) enabled significant speed improvements. They also enabled more kinds of
Web components
.
ActiveX
Paralleling the client world, which first saw components as VBXes and OLE Controls (OCXes), server components came in two main forms: Netscape server plug-ins and Apache modules. These component systems work fine but are restricted to specific Web servers. Thus, they aren't tapping into a broad base of component development talent. To fix that, we enter the present (ActiveX) and future (JavaBeans) of server components. These models aren't just for specific servers, and in fact aren't just for servers at all, but are just popular ways to package software as components.
In an absolute ActiveX world, clients run Active Desktop (an integral part of Windows from NT 5.0 onw
ards), where embedded ActiveX controls can provide a UI to remote services. These components send requests via either HTTP or COM and Microsoft's Advanced Data Connector (ADC) to a middle-tier application server. There, Active Server Pages (ASPs) may employ server-side Visual Basic scripts to query a SQL database via ActiveX Data Objects (ADOs). The ADOs generate dynamic HTML pages for returning the query results to the client and call server-side ActiveX components running under Microsoft Transaction Server (MTS) that perform any application processing (see the figure
"The ActiveX World"
). Note that the client and server pieces of this picture are entirely separable.
The key to this picture is MTS, which will be integrated into Microsoft Internet Information Server (IIS) 4.0. MTS provides an environment for executing distributed applications built from ActiveX components communicating with each other via the COM protocols. You can write a component as a single-user ActiveX DLL and
simply install it into MTS, which will run it as a secure multiuser application.
MTS handles all the management of sharing, processes, and threads. It maintains pools of threads, network sessions, and database connections, automatically recycling them when they're no longer being used. All the components that make up an application can share these resource pools. Consequently, using MTS may actually improve performance compared to stand-alone execution, in both time and memory (see the sidebar "Microsoft's Efficient Transactions").
Don't sell IIS short, however. By itself, it manages a pool of threads and a file cache on behalf of multiple services: the Web server, news server, and FTP server. It can also cooperate with ODBC 3.0 connection pooling.
Enterprise JavaBeans
The Enterprise JavaBean architecture looks similar, although with three differences. First, unlike Microsoft, JavaSoft isn't supplying a full transaction-server environment (it's relying on big names such as IBM and B
EA). Second, JavaSoft is sticking to an OS-independent architecture, relying on the cross-platform nature of the Java Virtual Machine (JVM). Third, it isn't real yet.
Java began as a platform-independent language for creating client-side applets that run inside your Web browser. Release 1.1 of the Java Development Kit (JDK) adds vital features such as object serialization and database access; and you can get a servlet API to make it equally suitable for writing server-side programs (servlets). Of course, JavaSoft also has a component model called JavaBeans. Put it all together, and you get what JavaSoft announced in April: the Java Platform for the Enterprise.
The Java Platform for the Enterprise consists of a suite of APIs such as JDBC (database connectivity), JNDI (directory services), and JTS (transaction services). Key to the Java Platform for the Enterprise are Enterprise JavaBeans. "Enterprise JavaBeans is an extension to the JavaBeans model targeted at the middle tier," says Sharada Achant
a, product line manager for the Java Enterprise Platform at JavaSoft. Enterprise JavaBeans take the lightweight JavaBean model and extend it with multiuser security and resource management similar to that in the ActiveX model. (To Web-enable Enterprise JavaBeans, you need a Java-capable Web server; see the sidebar "A Java Web Server".)
The initiative's architecture places Enterprise JavaBean components on top of the Enterprise JavaBean Executive, sometimes called the BeanStalk (see the figure
"Java Enterprise Architecture"
). The Executive, in turn, gives Enterprise JavaBeans access to APIs (e.g., JDBC and JNDI), remote objects (e.g., through IIOP or Java RMI), and transaction services. Part of the attraction of the Enterprise JavaBean architecture, according to Achanta, is "the developer doesn't need to know about Java interface definition language [IDL], JTS, multithreading, or security--the Executive run time abstracts APIs and remote object calls."
Enterprise JavaBeans need
some kind of transactionally aware execution environment such as a transaction processing (TP) server or database engine. So far, the likes of Sybase, BEA, IBM, Oracle, and Tandem have all at least voiced support for the Enterprise JavaBeans, if not yet writing the necessary extensions to their products.
The Java model of distributed computing is coming together. The JavaBeans API offers a format for creating reusable, platform-neutral Java components (and they can interwork with other component standards such as ActiveX and the nascent OpenDoc). The Java RMI and Java Serialization interfaces allow such components to migrate around the network, heedless of what hardware platform they land on, and then control each other remotely. Using RMI calls, an applet running on your client can control a servlet more directly and efficiently than is possible using HTTP. Enterprise JavaBeans provide a high layer of abstraction as well as features suited to multiuser execution.
Currently, Enterprise JavaBeans
are a specification and some prototype code at JavaSoft, according to Achanta. Support, however, appears to be strong, and the specification is moving quickly (it should be available during this quarter). If all goes well, Enterprise JavaBeans could be a good server-side component solution, especially for heterogeneous environments.
There are other component initiatives from players such as the Object Management Group (OMG) and IBM (see the sidebar "IBM Takes on Objects"). According to sources at both, however, they seem to be leaning heavily toward some kind of adoption of the JavaBeans model. Netscape, too, is behind JavaBeans, effectively making it a Microsoft-versus-everybody contest.
Do It with Transactions
The issue of competing component models aside, as we move closer to this service-based model of distributed computing, it becomes impossible to ignore the issues of robustness, reliability, and quality of service. Having easy access to both local and remote services means that mo
re jobs will involve multiple, geographically spreadout resources.
The reliability of the links in this application span the whole spectrum from highly reliable (your local disk), through variable performance (your LAN, depending on load), to transient, slow, and unreliable (the Internet connection). Any attempt to automate such an application must deal with the possibility that one or more of the connections may fail, as otherwise you will end up with a half-finished job and data left in an inconsistent state.
The mainframe world has learned how to deal with this issue by deploying TP monitors. A TP monitor manages all the processes involved in performing a job and makes the whole job into an atomic transaction (i.e., a transaction that must succeed completely or fail completely). In case of a failure in any part, the TP monitor will undo any partial changes that were made and then restart the whole transaction and try again. The cliché example of a task that needs atomic transactions is
moving money between two bank accounts. A failure after the first account has been debited but before the second has been credited would lose the customer's money. After such a failure, the transaction must be rolled back to undo the original debit before trying again.
Mainframe TP monitors such as CICS, Tuxedo, and Encina are ferociously complex pieces of software--in effect, they're distributed OSes. They've evolved within a model of a few huge servers supporting thousands of clients each, and they may manage messaging, load balancing, fail-over after hardware failure, and restarting as part of maintaining the integrity of data operations.
A TP monitor is usually partnered with message-queuing software that ensures that information sent between applications can never be lost due to communications failures. Message-queue managers (e.g., IBM's MQSeries) define various levels of secure messaging protocol between applications (e.g., synchronous, asynchronous, and store-and-forward), which can work a
cross different kinds of OSes and communications links, including wireless ones. One application sends a message to another by placing it into a queue. It can then continue processing without waiting for a reply. The queue manager guarantees that the message will be delivered once and once only, so if any link fails, any queued messages will be sent once it is restored.
The service-based distributed-computing model implies there will be more, smaller servers than are usual in mainframe on-line TP and more complex connectivity among them. To apply the principles of TP in such an environment means developing distributed TP monitors and messaging services that are integrated with the component software model. Ideally, the whole environment should have commit/roll back and exactly once delivery characteristics.
TP guru Jim Gray (now at Microsoft) has described mainframe TP monitors as being "more like the mortar between rocks in a wall than they are like glue" because of the large granularity of the a
pplications they manage. TP monitors for the service-based network need to have a much finer granularity, right down at the level of individual components and even individual method calls.
Big strides are being made toward this goal. At a briefing in London on Microsoft's COM-based Active Server strategy, James Utzschneider, program manager for COM, said, "The name Transaction Server doesn't do it justice. The product does automatic load balancing, security, thread management, connection pooling, and component management. Now that MTS is being integrated into NT, it defines the programming model for building business applications in Windows."
MTS also automatically manages the transactional behavior of your components, with full rollback semantics, in a way that is much simpler to program than is normal with TP monitors. To make any ActiveX component transactional, a programmer need only set its transactional property to Transaction Required and then call one of the API routines (SetComplete or Se
tAbort) at a point in the code where the transaction should either be complete or have failed.
In other words, MTS is not just about financial transactions. It's the manager within which all server-side ActiveX components ought to be deployed, for reasons of efficiency as much as reliability and security. MTS will shortly be joined by Microsoft's own message-queue server (code-named Falcon).
Another product poised to aid the service architecture is BEA's Tuxedo. Tuxedo is widely used to implement large, mission-critical distributed applications in the banking and financial industries. It's not unusual to build Tuxedo-based systems with over 1000 physical servers handling 25,000 clients.
Tuxedo is now available in a native NT version, and it's accompanied by a new tool called BEA Builder for ActiveX, which lets developers see Tuxedo services as ActiveX objects from NT or Windows 95 clients. You can build the client applications using Visual Basic, PowerBuilder, or Delphi and still have access
to all the powerful Tuxedo features such as access- control lists (ACLs) for security, the EventBroker for publish-and-subscribe communication between applications, and Management Information Bases (MIBs) for application management. PowerBuilder also allows you to access legacy systems based on CICS or IMS via theTuxedo middleware.
In March, BEA purchased Digital Equipment's ObjectBroker object request broker (ORB) and its Desktop Connection technology. Desktop Connection lets you write applications that will work with any CORBA 2-compliant transaction manager. According to BEA's CTO Alfred Chuang, "Developers can now create interactive applications that take advantage of two different object systems--CORBA and ActiveX--without retraining or having to write extra code."
The next step for BEA will be seen in Tuxedo's successor, code-named Iceberg, due in September. Iceberg will be object-based and both COM- and CORBA- compliant. "Tuxedo today is procedurally driven and not object-oriented," says C
huang "But in Iceberg, we want to hide all these procedural interfaces." Why? If you're following the COM, CORBA, or Java development model, you are fundamentally writing stateful applications-- the application at all times has control of the state of the transaction.
"When you're deploying something in a lot of places, a complex system with massive transactions that involve many different components, that's a really painful thing to have to clean up if the transaction fails," says Chuang. Load balancing and the ability to group these objects onto a single physical server and move them around are going to be very critical to scalability. "What you really want to do eventually is to hand over the management of all these objects to the system and have them run in a stateless environment."
Other commercial CORBA Object Transaction Monitors (OTMs) that offer transaction services compliant with the CORBA 2 standard are starting to appear on the market, too. A recent example is Iona Technologies' Orbix/
OTM, which incorporates Transarc's Encina Object Transaction Engine.
For more on transaction monitors, see the feature article "Guaranteed Delivery" [not available on-line until the end of October].
Run Over the Network
Once you have components running on your Web server, there's still the not-so-small matter of getting these components to talk to each other over the network. At the simplest level, you can pass one component URL-encoded information from another. However, more elegant solutions abound. Microsoft's COM is probably already familiar to Win32 programmers. Netscape is using the CORBA IIOP for its interobject communication. JavaSoft is pushing Java RMI.
Right now, the main network object models are Microsoft's COM, JavaSoft's Java RMI, and the OMG's CORBA IIOP (see the sidebar "The CORBA Connection"). These models aim to be platform-neutral by forcing objects to communicate only by calling each others' methods, which are exposed via an abstract interface that's defined in
an IDL.
COM and CORBA use almost identical IDLs, both of which are derived from the Open Software Foundation's (OSF) Distributed Computing Environment (DCE). Programming tools then compile these interfaces into proxies, stubs, and type libraries that a developer can access from the actual applications development language, such as C++, Visual Basic, Java, or Smalltalk. For a Java RMI, Java itself is the IDL (which works because the language is itself platform-neutral). This simplifies development both conceptually and in practice.
Most of us will be familiar with components through COM, which underlies the ActiveX components that you can deploy from C++ and Visual Basic programs, and from Office applications. How a COM object calls methods in another COM object depends on where they are running. If they are in the same process, they can call each other via pointers. Objects running in different processes interact via proxy objects and stubs that pack and unpack the call parameters into a standard
format for transmission. Communication between components running on different machines takes place via remote procedure calls (RPCs)--the core technology inside distributed COM.
In all these cases, however, the client object's method doesn't need to know the details of how the communication is done (location transparency.) Proxies and stubs provide a static link between components, but COM also enables components to discover and call new interfaces at run time. This is the basis of ActiveX. You can assemble an application by dragging and dropping components that have no prior knowledge of each other onto the same form. Automation between, say, Microsoft Word and Excel works because these Office applications make their key internal functions visible to other programs as COM objects.
CORBA works through software engines called ORBs. Whenever one object needs to call another, it sends a message to an ORB, which handles the whole transaction on its behalf. An ORB can translate between different data
formats, processor-endianisms, and other attributes, making CORBA objects processor-, OS-, and language-independent. CORBA makes no distinction between client-side and server-side objects: They're all just objects. The basic CORBA 2 ORB specification doesn't deal with issues such as concurrency, integrity, and security, all of which must be provided as separate CORBA services. For example, transactions are handled via OTMs that work alongside an ORB.
Java, like COM, provides a mechanism for components to discover each other's interfaces at run time, but they can also run on different platforms by virtue of the JVM. JavaBeans can also run as applets outside any container application, and Java Class Loaders can download any libraries a component needs along with the component. Consequently, JavaBeans don't need to be registered the way that ActiveX components do, which makes them very suitable for building highly dynamic systems. JavaBeans score over ActiveX in the more flexible way that they can interact
with application builder tools.
Java applications can use RMI to call methods in components on remote machines. RMI resembles COM. If all goes according to their plans, cooperation among JavaSoft, Netscape, IBM and others will also also make it possible for JavaBeans to communicate using CORBA IIOP, opening the way to provide secure transactions via a CORBA-compliant OTM.
In theory, COM, CORBA IIOP, and Java RMI could all be platform-neutral component standards. But the commercial reality is different. First, while CORBA and Java are available for a variety of platforms, issues with their interoperability remain to be found and ironed out. Microsoft has so far implemented COM only for Windows platforms (although Digital, Hewlett-Packard, and Software AG are all working on ports to other OSes).
Just Plumbing
The service-based architecture, for all its advantages, still has some problems facing it. One example is object management. A service-based application could consist of some A
ctiveX controls running in MTS and an Enterprise JavaBean connected by JavaScript executing on either the client or the server. JavaScript itself is an object, with properties, methods, and events. By what mechanism can anyone manage that mess? Right now, the answer is none. Directory services such as LDAP and Microsoft's Active Directory will provide some relief, but not enough.
And, of course, there's the overwhelming problem that most of what we can get today is plumbing. For all their promise, these object models and APIs aren't at the level that we've come to expect, thanks to client-side ActiveX controls that we can twist together in minutes to create applications (although many vendors are working toward that). Not only is it plumbing, much of it is incompatible--for example, JavaBeans can't run in MTS, and ActiveX controls can't run in CICS.
But you have to start somewhere. Which architecture do you adopt? It depends on the size of your application, your existing hardware, your software en
vironment, and whether your application's function is stable or highly changeable. For example, Java servlets are a very good choice for those applications that might now be done by CGI scripts, such as reformatting tables retrieved from a database. The investment is small, so you just throw them away and rewrite them as requirements change.
If your site is already Windows-based, ActiveX under MTS looks like a sensible way to go, whereas CORBA ORBs may make more sense for large Unix installations and industrial-control applications. The telecommunications industry is strongly committed to CORBA, particularly in Europe, which might be an influence for some people. If you use Java extensively, you'll likely work extensively with JavaBean components and RMI.
To some extent, your decision will be affected by the market in shrink-wrapped components. Here, Microsoft has the advantage of its dedicated band of third-party vendors such as Sheridan and MicroHelp, already experienced in VBXes and OCXes, who
are gearing up to produce server-side components. Wall Data's server-based ActiveX screen scraper is another example of an ActiveX server component. With it, an HTML client can render green screens without any client-side ActiveX intelligence. But the sheer enthusiasm of the Java world is a powerful force, and the list of off-the-shelf JavaBeans on sites like
http://www.gamelan.com
grows daily.
Web Components
