Question: What's the importance of middleware? Answer: It's everything to enterprise client/server development. Why? Several reasons. First, we need a common application communications and data interface layer that everyone can agree on and that can link seamlessly into all application development environments. This means that each application must be able to locate and use shared business logic and data without a lot of hunting around.
Second, a middleware layer has to be reliable. It needs to provide failover and recovery services to assure that transactions are not lost and business critical applications keep on humming. Third, middleware should be able to communicate with several data sources -- either homogeneous or heterogeneous -- at the same time and manage common constraint logic between the data sets. Finally, the middleware layer should be easy to use, removing the developer from the complexities of the underlying platform, network, and database.
The fact is that few middleware products meet all of the criteria I just mentioned. Although some virtual system middleware layers, such as a few of the message-oriented middleware (MOM) products, ORB-based middleware products, and RPC-based middleware, can live up to the first three of my requirements, few can live up to the fourth. Thus, in seeking the path of least resistance, we return to the traditional two-tier middleware model, relying on proprietary, easy-to-use, but limiting middleware solutions. The business logic exists on the client and the data on the server. Wouldn't be nice if we did not have to make the tradeoff?
If you've been reading my column over the last few months, you'll notice that there is a trend in bringing traditional high-end middleware services such as MOM, TP monitors, ORBs, and complex call-level interfaces (CLIs) into the realm of commodity distributed systems development. Microsoft is wrapping its entire product line in COM or DCOM, including the new Transaction Server TP monitor and the Falcon MOM product. Of course all of the Microsoft tools will seamlessly integrate with these product using COM, and the rest could be client/server history if Microsoft has its way. It often does, you know. Microsoft is very good at turning high-end, complex, and expensive products into affordable commodities. Other vendors are moving in this direction as well, some layering value on top of COM or CORBA infrastructures, others adding just another proprietary product to the client/server mix.
When looking at Midas from afar, you'll notice that it's really a set of language- and platform-independent brokers that run between the client and the server (the middle tier). Midas offers high-end middleware services such as failover and recovery services, as well as primitive load-balancing capabilities and the ability to define shared application services at the middle tier. If this sounds a lot like a TP monitor to you, you're right, but the value proposition is ease of use and tool integration.
When drilling down into the features of Midas, you'll find three types of brokers that the developer may leverage: Remote DataBroker, Business ObjectBroker, and ConstraintBroker. Each broker serves its own purpose in the Borland multitiered application development architecture. (See Figure 1, page 24.) Midas draws heavily from Microsoft's DCOM technology and is thus limited to a homogenous Windows environment.
The client portion of the Remote DataBroker is a small (140KB) DLL. The application uses this DLL to access the middle-tier application servers, which can connect to any number of databases through the Borland Database Engine (BDE). Databases supported include Oracle, Borland InterBase, Microsoft SQL Server, Sybase, Informix, and IBM DB2. In addition, Remote Data Broker is able to provide database concurrency and integrity controls, performing functions such as notifying clients if the row in client memory has changed since it was retrieved as well as managing concurrent updates to the database. When JBuilder finally hits the streets, it will be able to use Remote DataBroker as well.
There are several components at work here, including Object Factory, Object Agent, and Object Explorer. Object Factory is a server-side component that functions as an OLE Automation client acting as a proxy OLE Automation client for the remote client. The Object Agent resides on the client, acting as a proxy OLE Automation server for the remote server. The Object Explorer lets developers and users explore and view all available objects identified in the registry. Object Explorer also provides import and export facilities so that clients can share objects among applications.
Business ObjectBroker gives you the ability to keep track of several application servers that may be running identical objects and to manage the process load among them. Business ObjectBroker is able to measure the current load on the servers and determine where to place the application-processing load. When a client application needs a service, an ObjectBroker is able to return a reference to an application object running on the server with the lightest load. This means dynamic load balancing and the ability to reroute clients around application server problems, such as a down server.
At the heart of ConstraintBroker is a data dictionary where you maintain all of the data integrity rules. Once the constraints are in the data dictionary, the Remote DataBrokers are able to peer into the data dictionary to determine if a database operation meets all of the defined business rules. For instance, if you're adding data that violates a rule, Remote DataBroker would return the error and not the database itself.
The advantage of ConstraintBroker is that it lets you place data integrity logic in a database-independent location. Developers need not define business logic using database-dependent mechanisms such as stored procedures and triggers. However, if other apps will update the PB, it will be prudent to use a trigger. What's more, because the violation is caught at the middle tier, the database is not bothered with error processing and not as much load is placed on the network. The data dictionary provides a mechanism to add custom constraints and customer error messages. Borland's SQL Explorer provides the management tool to update and maintain the data dictionary.
Several other products provide such services, including TP monitors such as Microsoft Corp.'s Transaction Server and BEA Systems Inc.'s Tuxedo (now available for Windows NT). CORBA-enabled ORBs are also an option here, and you'll find that they are a better fit when dealing with heterogeneous environments. Midas is basically DCOM-enabled ORB technology wrapped in a canned architecture and built into several very good tools (including Delphi, JBuilder, and C++Builder).
So where's the value? Well, if you're a die-hard Borland developer (and I know a lot of you are out there), the Midas product will provide a nice glide-path to three-tier client/server development from your Borland tool of choice. We'll see the value first with Delphi 3.0; however, it will eventually provide the plumbing and wiring to tie together all of Borland's products. Thus Midas is Borland's enterprise client/server solution, providing a product that has the power to scale up to thousands of users. That's the value. If you're not a Borland shop, Midas should be a consideration but not a slam dunk. For instance, if you're a Microsoft shop, the COM-enabled products (namely Transaction Server) from Microsoft would be an alternative. If you're running a hodgepodge of platforms, technologies, and vendors, then neither of these solutions would be a good fit. For largely heterogeneous environments, you're better off with high-end middleware solutions that are able to link very different systems. My favorites are MOM and TP monitors.
Midas is a trend, not an innovation. The trend is for low-end (two-tier) client/server tool vendors to offer high-end middleware solutions that add value to their tool sets. The company may be downsizing and cost-cutting its operations; however, Borland clearly sees that mastering multitiered application development is the future of client/server. I agree.
