Using IOM to Develop Applications

IOM Scenario

One of the chief benefits of building component-based applications using the Integrated Object Model (IOM) is that it enables you to de-couple your business application logic from your presentation methods. This enables you to reuse core application functionality in multiple presentation personalities and as a result, it extends your application's deployment options.

For example, consider the illustration below. Using SAS Integration Technologies software, you can develop applications in which Web browsers, desktop GUIs, and middle-tier Web and application server presentation platforms can all become clients of SAS software server components.

Within the Web browser context, you can use client-side scripting such as VBScript, local components such as ActiveX controls, and Java applets to implement access to server components.

Similarly, you can assess server components from desktop application environments including custom applications written in Visual Basic, Java, C++, Delphi, and PowerBuilder. Further, any desktop application container that supports VBA, including those in the Microsoft Office suite and many third party offerings, can also participate.

Finally, you can deploy middle-tier Web and application servers, such as Microsoft’s Internet Information Server (IIS), Microsoft Transaction Server (MTS), and various .NET servers to host logic that accesses SAS software server components.

This level of deployment flexibility enables you to distribute your logic components across the enterprise in order to realize the performance advantages that are associated with data source co-location. This component distribution can be accomplished in a manner that is transparent to the client.

Workspace Object Hierarchy

The principal IOM interfaces of the SAS Workspace Server include the following:

• Workspace (a SAS session)
• LanguageService (submit, list/log, stored processes)
• DataService (librefs, plus access through ADO, OLE-DB or JDBC)
• FileService (filerefs and directories)
• Utilities (result packages, formats, host info)

The following illustration depicts the object hierarchy for these interfaces.

In the illustration, the number 1 indicates that that part of the hierarchy has exactly one child per parent. An asterisk (*) indicates that that part of the hierarchy has zero or greater children per parent.

The LanguageService defines methods for submitting SAS procedural scripting language statements (to execute SAS DATA and procedure steps) and for retrieving the associated LOG and LIST outputs.

Applications that produce sophisticated results such as HTML and graphs generated using the SAS Output Delivery System can utilize the ResultPackageService to retrieve collected elements. Program execution progress events such as step begin, step end, and error conditions can also be monitored with a LanguageService event interface.

The FileService defines methods for managing SAS file references (FILEREFs) and reading or writing files on the server's host file system. A client can exploit SAS external file access methods and host-specific fileref assignment options to access the wide variety of specialized features in SAS external file I/O on the various server host platforms. The DataService surfaces similar control over SAS library references (LIBREFs).

IOM utilizes standard interface mechanisms within the Microsoft COM and Java application environments to expose the object hierarchy. This enables you to use the ActiveX Data Objects (ADO) and OLE DB access protocols in the Windows COM environment. In Java environments the JDBC 2.0 access protocol is supported. These standard mechanisms provide semantic richness, including read, write, update, and query services. And all components that support the same standards can easily interoperate.

Application hierarchies are also available through specialized SAS product offerings and custom applications developed with the SAS/AF software.

SAS Integration Technologies provides the middleware necessary to connect clients and servers across multiple vender architectures, as described in Connecting Clients to IOM Servers.