Developing Windows Clients

When developing Microsoft Windows clients, you interact with the SAS System’s Integrated Object Model (IOM) using the Microsoft Component Object Model (COM). Because of support for it in the operating system, in all the leading programming language products under Windows, and in most Windows applications, COM is the predominant mechanism for software interoperability on the Windows platform.

For the benefit of Windows applications, the SAS System manifests its Integrated Object Model as a COM component that uses the Automation type system. Microsoft calls this type of COM component an ActiveX component or an OLE Automation server.

Manifesting the SAS System as an ActiveX component has a number of benefits:

• It can be called from a wide variety of programming language environments such as Microsoft Visual Basic (including Visual Basic for Applications and VBScript), Microsoft Visual C++, Borland C++Builder, Microsoft Visual J++, Perl, Borland Delphi, and others.
• SAS processing can be invoked from the macro language of many popular applications including those in Microsoft Office.
• The programming language skills most commonly used to build solutions in the Windows environment can also be applied to developing solutions that involve the SAS System.
• Operating system-level security, configuration and management are the same for the SAS System as for other applications and systems utilities.

In addition to these standard advantages for integration via COM, the SAS System Integrated Object Model offers a superior capability that is not commonly available to ActiveX components. This function, known as the IOM Bridge for COM, provides the ability to transparently run the server on non-Windows platforms. Using this bridge, a Windows application can request SAS analytical processing against the often voluminous data on a UNIX or OS/390 server and receive the results without knowing that the SAS System is processing the request on a non-Windows platform. Given the heavy use of non-Windows servers to store and process large-scale enterprise data, this is a significant advantage.

The exact interfacing technique used by Windows language products has evolved over the years. The initial approach documented in COM was to support calls from Visual Basic through an interface known as IDispatch. When using the IDispatch interface, calls into an interface go through a single method (IDispatch:Invoke) and then the appropriate implementation code is looked up at runtime. This technique was compatible with early versions of Visual Basic, but was sub-optimal because of the amount of runtime interpretation involved in a method call. To improve performance, subsequent versions of Visual Basic and other languages developed the ability to call methods directly. This is known as v-table binding. Besides yielding better performance, v-table binding is also the most natural approach for COM calls from C++. The IOM implementation of ActiveX component interfaces uses the dual interface layout that provides both IDispatch and v-table binding. This gives the best performance from newer language implementations, but still supports the Dispatch technique for client languages (including VBScript and JScript) that use the older, sub-optimal approach.