Previous Page | Next Page

Components of SAS Integration Technologies

Using IOM to Develop Applications


IOM Scenario

One of the chief benefits of building component-based applications by 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 following figure. 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.

Clients of SAS Software Server Components

[deployment configuration]

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 that are written in Visual Basic, Java, C++, Delphi, and PowerBuilder. Further, any desktop application container that supports Visual Basic for Applications (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 the Microsoft 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:

The following figure depicts the object hierarchy for these interfaces.

Workspace Object Hierarchy

[IOM hierarchy]

In the figure, 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 by using the SAS Output Delivery System can use 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 uses 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. 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.

Previous Page | Next Page | Top of Page