OLE-ENABLED MIDDLEWARE

Many people think that middleware should take a back seat in our new Web-enabled world. However popular that sentiment may become, don't get caught in this trap. Middleware is the plumbing and wiring of our client/server applications. Plumbers and electricians see dollar signs when they get called to a house with faulty plumbing and wiring. Neglect the middleware, and you could be headed for the same costly repairs.

The issues that limit current middleware technology are complexity and cost. Message-oriented middleware (MOM), transaction-processing (TP) monitors, object request brokers (ORBs), and other middleware flavors require a heavy integration effort to get them up and running. Developers and architects often find themselves knitting together a solution rather than finding middleware and application components that simply "snap together." What's more, the cost of many middleware layers can be as much as several thousand dollars a client, not including the cost of the integration and deployment effort that naturally occurs when making a middleware solution work.

Things could be getting better. Microsoft recently moved into the high-end middleware business. Unlike ODBC, Microsoft's new products are built for enterprise-level client/server development that includes transaction processing, model-independent database access, and an asynchronous messaging communications layer -- all, of course, based on OLE and Microsoft's Component Object Model (COM).

If you know Microsoft's history, you'll know that Microsoft is very good at taking high-end technology and turning it into an easy-to-use, inexpensive commodity. This month I examine three of the latest COM-enabled middleware products: OLE DB, Microsoft's new TP monitor (code name: Viper), and Microsoft's MOM (code name: Falcon). I'll answer the question: Can Microsoft be successful in the high-end middleware market?

OLE DB

When using OLE DB, the database simply becomes a component known as a data provider. Any component that exposes methods through an OLE DB interface using a native data format is considered a data provider, including relational databases (using ODBC), an ISAM file, text file, email, Microsoft Word, and a data stream. (See Figure 1.)

The idea is to create an individual OLE DB component object to deploy additional features that are layered on top of the data providers. These individual OLE DB components are called service providers. Service providers are like query processors; they enable applications to take advantage of providers that interconnect different combinations of data (homogenous or heterogeneous). The data, no mater which model (object-oriented, relational, multidimensional, and so on), exists as a single view.

The other side of data providers are OLE DB data consumers. Data consumers are applications written to a single data provider or generic consumers that work with any number of data providers. For example, Microsoft's Excel, Word, and Project can become data consumers.

ODBC is still a part of the mix, but it's simply a mechanism for communicating with relational databases from OLE DB. (See Figure 2.) Microsoft plans to update the ODBC Driver Manager with an OLE DB provider (code name: Kagera) to make OLE DB compatible with any ODBC-accessible database. When it becomes available, Kagera will give OLE DB data consumers access to relational databases while expanding on the types of applications that can access ODBC drivers.

So how do you program OLE DB? Those of you interested in the technical detail will be happy to know that OLE DB provides 55 new interfaces grouped into seven object types: DataSource, DBSession, Command, Rowset, Index, ErrorObject, and Transaction. An object type is simply a set of methods that an object must expose. For instance, you can define the Transaction objects using a group of methods that any data consumer can request from a transaction service. (For more information about OLE DB, see Ken North's article, "Database Programming with OLE and ActiveX," DBMS, November 1996, page 87.)

Chances are, most of you won't have to deal with the OLE DB interface directly. Microsoft is grooming a new set of products and development environments that let developers build client/server applications using OLE DB hidden behind many easy-to-use layers. This OLE DB interface is analogous to the relationship with ODBC and development tools. Visual Basic 5.0, entering beta this year, is the one to watch.

Viper

To take a run at the TP monitor product market, Microsoft brought together senior TP talent from TP companies such as Tandem Computers Inc., Prologic Computer Corp., IBM, Digital Equipment Corp., and Stratus Computer Inc. Microsoft also mixed in existing OLE/COM talent native to Microsoft. The idea was to create a product that's component-based, distributed, highly scalable, and easy to use and administer. For those of us from the traditional TP monitor world, "ease of use" and "TP monitor" are terms you never use in the same sentence.

Microsoft built Viper from the ground up as a runtime environment for both enterprise and Internet applications. Like other TP monitors, Viper will provide transparent distribution, reliable updates of data, and a scalable development environment. Unlike other TP monitors that rely on unique or proprietary programming interfaces, Viper provides a COM component-based application model designed to support deployment of ISV and custom-developed applications. What's more, Viper can leverage the distributed component object model (DCOM) to provide distributed TP. Viper will access Web server functions through ISAPI (Internet Server Application Programming Interface).

What I can make of Viper right now (not much information is available) is that it's really a transaction-oriented repository for COM components or ActiveX components. (See Figure 3.) The ActiveX components are akin to transaction services that exist inside a TP monitor environment. The ActiveX components are invoked as transactions, managed by the Viper environment. There are two simple outcomes when an ActiveX transaction service is invoked: It's all done, or none of it is done; and neither outcome leaves the system in an unstable state. Moreover, Viper manages concurrency and processing loads as you would expect from any self-respecting TP monitor. Viper runs on top of Windows NT and Windows 95, and applications will be written to run on Viper using any number of COM-enabled development environments. In addition, Viper provides store-and-forward queues and lets developers deliver messages immediately or delay delivery for a later time.

You're already seeing the influence of Viper today. Viper's Distributed Transaction Coordinator (DTC) is already a part of SQL Server 6.5. DTC lets developers distribute autonomous transactions across multiple SQL Servers, and it provides automatic recovery services as well.

Falcon

Falcon is MOM, so it's naturally able to handle interprocess communications asynchronously. An interface call to Falcon, therefore, won't block the processing of your application as it awaits a call to return, as is the case in the world of RPC-based middleware such as DCE. Falcon does not require that the target processor actually be working when the message is sent, because MOM uses a queuing mechanism that stores messages for delivery when the processor is again active. Of course, Falcon and Viper are joined at the hip with ActiveX. Falcon provides an ActiveX server side and a client-side set of components.

. The first beta release of Falcon is now in the hands of 100 beta testers; it includes Falcon's ActiveX control, which can act as a proxy to Falcon's low-level messaging mechanism. Thus developers can use any tools that work with ActiveX components to deliver Falcon-based applications.

Falcon is Web-enabled as well: it links to Web-based application development via the COM interface, and its user interface looks like a browser itself. Browser-based applications will be able to dispatch messages. Microsoft is already looking to provide an interface to IBM's MQSeries MOM and CICS TP monitor.

COM-Enabled World

I see each middleware product serving a specific need. Falcon will provide just another messaging middleware solution, offering an "information bus" of sorts for disbursed applications that need to share information. Using the COM interface, Falcon already has many tools that can make use of Falcon without new libraries, APIs, or DLLs. Viper will provide low-end TP monitor services for existing Windows NT shops, but the jury is still out as to how Viper will handle larger user loads, which is the real value of TP monitors. OLE DB will provide another layer of abstraction for data access, but most client/server developers won't exploit the power of OLE DB --they really just need to get at the data and can take or leave OLE.

Missing from Microsoft's middleware arsenal is the ability to deploy Microsoft middleware solutions on non-Windows platforms. The company always says it will provide this capability, but it never does. The real power of middleware is the ability to use a common application communication layer in both homogenous and heterogeneous computing environments. When choosing Microsoft, you could be limiting your options.

Although some of you may be terrified by the thought of Microsoft owning the data services, the middleware layers, and the client development tool and the operating systems, this situation could be an opportunity in disguise for Microsoft to throw down the gauntlet for others in the high-end client/server market. Also, traditional two-tier client/server developers who were reluctant to enter the complex and confusing world of TP monitors and MOM may find that Viper and Falcon are the entry-level products they waited for. I certainly took notice.

Figure 1.

--Any components that expose methods through an OLE DB interface using a native data format are considered data providers, including relational databases (using ODBC), ISAM files, text files, email, Microsoft Word, and data streams.

Figure 2.

--ODBC is still a part of the mix, but it's simply a mechanism for communicating with relational databases from OLE DB.

Figure 3.

--Viper is basically a transaction-oriented repository for ActiveX components. The ActiveX components are akin to transaction services contained inside a TP monitor environment.

---

* Microsoft Corp., Redmond, WA; 800-426-9400, 206-882-8080, or fax 206-936-7329; www.microsoft.com.

---

---

David S. Linthicum is a widely published author, speaker, and computer science professor, and technical manager with AT&T Solutions in Vienna, Virginia. You can email David at 70742.3165@compuserve.com, or visit his home page at http://ourworld.compuserve.com:80/homepages/D_Linthicum/.

---