Clarion for Windows 4.0 - Marrying SQL and Object Orientation. Presentation by Erik Pepping

by Steven Stockstill

Published 1998-10-01    Printer-friendly version

Development Trends

In recent years, Clarion for Windows (CW) has been moving toward Object Orientation, Client/Server and Internet technology. The Client/Server direction is represented by the latest developments in SQL backend support and optimized direct drivers, while the Object Orientation direction has manifested in support for Classes and Class libraries. In terms of Internet technologies, CW Internet Connect (CWIC) is TopSpeed’s answer to Internet-enabling Clarion applications.

Notice, however, that Clarion for Windows is a follower, not a leader, in leading technologies. While the rest of the world is moving to DCOM and CORBA, which are based on network protocols, remote procedure calls and objects anywhere, Clarion for Windows is not currently (natively) supporting these standards. CW is, on the other hand, emerging as best of breed in 2-tier and 4-tier Client/Server Development for Windows environments. It took a long time to move toward SQL and Object technologies. The question begs to be asked: How long will it take to make the next step (distributed computing/objects)?

The Multi-tier Approach

Three different multi-tier approaches are currently evolving: 2-tier, 3-tier and 4-tier. Clarion supports the 2-tier approach extremely well. This undesirable approach spreads the rules and logic over the client and the server. On the other hand, Clarion does not support a very common, more desirable 3-tier approach.

With the 3-tier approach, the rules and logic are all on the application server; the client is for presentation only. 3-tier Client/Server is now envisioned as being implemented with distributed objects. There are three emerging standards: DCOM (Microsoft), CORBA (Object Group) and JavaBeans (Sun). Clarion is not currently committed to any of these standards, although Active-X can be used in a limited fashion (but with difficulty). DCOM can be used on the server with Oracle PL/SQL packages, which are supplied with Oracle 8.003. DCOM also has a client component for proxy objects, object caching, and performance-related issues that cannot be supported in CW4. With Oracle, CORBA can be used on the server.

CWIC allows Clarion to support the 4-tier approach. Under this approach, the Client runs the browser (IE, Netscape), the Server runs the Webserver, which initiates the Application Broker that in turn runs the Clarion application (that access the database). In this case, the rules and logic are all programmed in the CW application, which is running on the server. This component, however, cannot be further distributed.

While Clarion supports 2-tier and 4-tier methods, it does not yet support the standard 3-tier component-based solutions. This support is lacking because CW does not support industry standards such as CORBA, DCOM and JavaBeans. How do we survive in this multi-tier/multi-standard world? The answer is object encapsulation of all multi-tier functions.

Merging CW Trends

In order to encapsulate these multi-tier functions, we must try to see our applications as an object with methods and properties. We must also see the RDBMS and application server as an object. The RDBMS is an object with a well-defined interface and messaging between the application and the RDBMS engine. There are very distinct methods such as connect, disconnect, retrieve data, update data, delete data, start a remote procedure, etc. These objects talk to each other via SQL.

The C4 Object Perspective - Local Objects

Objects can be viewed from both local and remote object perspectives. The division of labor between client and server is a guideline/example. Local objects can include the Application Object and the Connection/Security Object(s). Remote objects take the form of stored procedures which are stored in packages, each having properties and methods.

The Application Object

The Application Object contains globals (which are normally dangerous) as properties. This allows you to keep track of changes with get and set variable functions as well as allowing you to inherit from the application class to add globals specific to your application. The Application Object will also accommodate application information such as application name, help file, version, and date. Additional functionality could incorporate your implementation of SetIni/GetIni, which could also be using an Oracle DB as opposed to an INI file. This object would also house the application initialization and shutdown code.

The Connection/Security Object

The Connection/Security Object contains information about the RDBMS connection (server name, user name, password, privileges, etc.). Connection Methods would include login and connect, starting a stored procedure, table privilege queue and menu privileges (for hiding/destroying). In addition to the connection methods, error handling (specific to each RDBMS) would also be contained in this object.

Managing Different Databases

Here in lies the beauty of using objects if you want to connect to a different database (like Oracle, SQL Server, ODBC, etc.) simply add a DatabaseType property and a SetConnectString method. Use the later method to program the different connectstring settings for each database. Keep in mind that even for ODBC the connectstring differs among databases.

Remote Objects

Remote Objects take the form of stored procedures grouped in packages. They each have methods and properties. In Oracle, these are programmed as packages. A package separates the definition from the implementation. Remote objects are accessed from CW by:

• The insert trigger (automatic with add/update or delete) can be seen as the init method of the occurrence in the table object.

• Through PROP:SQL

• Through Local (mirror) objects:

Distribution of Code

Always put as much code as possible on the server. For example, don’t put the object code of the order example in CW objects! Instead call the server object or call implicitly. This will allow your code to run on any server while staying scalable. Consider how easier it may be to use CWIC when code is on the database or an application object server.

Pitfalls

• Each RDBMS has its own object code.
• Each server has its own stored procedure syntax.
• Choose your target DBMS carefully (Oracle, Sybase, Microsoft SQL Server).
• Microsoft is moving to ADO (advanced data objects). Clarion cannot link into ADO today.
• Oracle is moving PL/SQL to Javascripting. This can still be called from SQL, since it’s wrapped into the SQL processor like PL/SQL.

Conclusions

CW has a good 2-tier and 4-tier solution. For 3-tier, TopSpeed should connect to DCOM and/or CORBA. This is already possible through specific supplier solutions, but not embedded in CW. When planning your code distribution, distribute intelligently and efficiently -- the more on the server the better. Educate yourself on the RDBMS, as it pertains to linked programming on the server and CORBA/DCOM. Study the 4-tier solution (CWIC) to see how it can be applied to real world problems (CODE! – Code Once Deploy Everywhere).

Printer-friendly version

Copyright © 1999-2008 by CoveComm Inc. All Rights Reserved. Reproduction in any form without the express written consent of CoveComm Inc., except as described in the subscription agreement, is prohibited.

Clarion Magazine ISSN 1718-9942