DCOM Explained
by Rosemary Rock-Evans
Digital Press
ISBN: 1555582168   Pub Date: 09/01/98

Previous Table of Contents Next


The Component Market

One area in which everyone is hoping a market will develop is in the provision of third-party horizontal and vertical components—components which can be reused in applications. A number of groups within Microsoft have already started development of ActiveX components for both horizontal and vertical applications. The Office Components Group (OCG), for example, is developing ActiveX components for use with Office.

The object/component market is an intensely confusing one at the moment, however, because there are so many different types of objects. If a company is to use objects in an application, it needs to be able to use objects from third parties, its own developers, other companies, and so on. Most developers make the assumption that an object is an object and that the development of an application is simply a matter of “plugging in” the objects from all these sources. But it is not as simple as this.

As we have seen, to “plug in” an object you need middleware (or its tool equivalent) to support the interobject communication, and the key to intercommunication is the interface the object presents to the middleware. Middleware products are geared towards the acceptance of only one type of interface.

The way the interface is defined is thus key to interoperability between objects. If the interface and IDL are the same, then all objects, whether they come from Microsoft, CORBA vendors, Netscape, Lotus, JavaSoft, IBM, or any other company, will be able to communicate with other objects using any middleware. If the interfaces differ, the customer will only be able to use the middleware which supports that interface and will only be able to use objects with that type of interface.

Unfortunately, what we have seen over the years is a proliferation of the ways in which objects can be defined until we now have numerous incompatible means by which object interfaces can be expressed. The ones I have identified are:

  CORBA IDL-and CORBA objects
  DCE-XIDL objects
  Microsoft IDL-with OLE, ActiveX, VBX, OCX, OLE Automation objects
  OpenDoc-from IBM/Apple
  JavaSoft’s Java Beans components
  Netscape’s LiveConnect objects
  IBM’s PARTS (for use with Visual Age)
  SOM Objects-which are different from CORBA objects
  Tool vendor’s objects—every tool has its own definition of an object
  Proprietary ORB objects—each of which are defined using different interface definition languages—OIL, CDL, and so on
  IBM’s PartPaks objects—which are also based on Visual Age

With this number of object types around (and the list is growing), third-party object market may never get off the ground because third-party companies will be totally confused as to which standard to go for, and people like yourselves—the buyers—won’t know what they are buying.

I suspect that Microsoft themselves may end up being the best source of reusable components in the future with a few smaller vendors adding niche horizontal market widgets rather than vertical market widgets. This suspicion is supported by the companies which currently provide ActiveX components. Practically all of them are providing widgets for use in the GUI interface rather than vertical market application components. The companies providing widgets include:

  ABACO (CAD functions)
  ADDSoft (scheduling)
  Apex Software (grid)
  Blue Marble (mapping)
  Bits per Second (graphics engine)
  Classic Software (Btrieve access)
  Contemporary Software (Calendar, Date, etc.)
  Crescent Software (numerous from statistics to curve fitting to grids and queries)
  Crystal (reports)
  Distinct
  dLSoft (barcode)
  FarPoint (buttons, spreadsheet, tabbed card)
  KL Group (charts)
  LEAD Technologies (image handling)
  MediaArchitects (image handling)
  MicroQuill (database access)
  ProtoView (charts, date, time, gauge, button controls, Explorer add-ons)
  Sandstone (lexical analysis and parsing)
  Sax Software (Exchange add-ons)
  Software Fx (charting)
  Sheridan (calendar, indexes, notebook)
  Smithware
  VideoSoft
  Visual Components

Tools

Keys to the success of ActiveX and the use of components in general is how many tools help the developer to build ActiveX components. Although I recognize that this sort of information quickly gets out-of-date, I decided it would be helpful to show you which tools can be used at the time of writing to develop ActiveX components.

ActiveX components can currently be developed using:

  Microsoft Visual Studio 97-which includes Microsoft Visual Basic 5.0, Microsoft Visual C++ version 5.0, Microsoft Visual J++, Microsoft Visual FoxPro 5, and Visual Interdev
  Delphi-Borland
  Micro Focus Visual Object COBOL
  Synon Obsydian
  Fujitsu COBOL

(Note that PowerObjects from Oracle and Power++ from PowerSoft/Sybase can host ActiveX controls which are installed as custom controls but cannot be used to build them.)

Microsoft states that as long as their Visual Studio 97 set of tools is used, Win32-based applications can be developed that will run on all Windows 32 platforms (95, NT workstation, and server) as well as over the Internet. Notice, however, that all these tools essentially run on the Windows platform currently, so the developer is likely to have to do his or her development on the Windows NT platform, then port and adapt the components when he or she deploys them on other platforms. Although languages such as Visual Basic 5 provide considerable automated support for the development of the DCOM commands, on the whole, the programmer does need to know how DCOM works in order to get it to operate effectively—for example, the use of threads.

In non-Windows environments, there are no short-cut GUI-based widgets, wizards, or tools to hide the IDL, the API, or any of the other interfaces to DCOM itself—transaction server, MSMQ, security, and so on. You do have to know what you are doing to use DCOM, and to get the best from it you need to understand every command and interface and how it is used.

Microsoft recognizes that the DCOM interfaces used by developers are currently quite difficult to use and may not be capable of being mastered by programmers used to procedural (and simpler) languages or 4GLs. As such they are concentrating effort on hiding the object-based interface with tools—their own and third-party tools. It is still early days here—more improvements in Visual Studio as well as third-party tool improvement should be expected.


Previous Table of Contents Next