Appendix D

Deploying Tango Applications

Some Issues When Creating and Deploying Tango Applications

With the speed and power of Tango, creating Web-based applications is easier than ever. However, when you have created a Tango application on the development machine, how do you deploy it in such a way that customers, co-workers, or Internet users can use it? This appendix is designed to detail several possible deployment scenarios as well as anticipate problems you may experience and to help minimize the time required to deploy your application.

This appendix covers the following topics:

• Global Issues
• Migrating Your Database
• Multi-platform support
• COM objects
• ODBC data source
• Scenarios
• Case 1: Corporate Intranet
• Case 2: Internet
• Case 3: ISP
• Case 4: Internet via your own Tango Server
• Cross-Database Deployment.

[back to top]

Global Issues

There are a few issues that can affect your application deployment regardless of which one of the following scenarios you chose. These are items that you should keep in mind during both the development phase as well as the deployment phase.

Migrating your database

You have created an application and most probably created your database, complete with tables and fields, on your development machine. To avoid potential problems from porting to conversion, it is recommended that your development machine reflect the setup of your production machine.

For example, if your production server is running Pervasive SQL 2000, you should develop your database in the same environment. If your production server is running Windows NT, you should develop your database under Windows NT.

If you must deploy on a database other than the one you developed your application with, see below for a list of do's and don'ts.

Multi-platform support

If you plan to resell your application to run on multiple platforms, avoid utilizing Tango meta tags that are platform specific.They are clearly identified in the Meta Tags and Configuration Variables manual.

COM objects

COM objects can greatly expand the capability of your Tango application through the simple drag and drop and object introspection available in the Tango Editor.

However, using a COM object ties your application to running only on the Windows operating system. If you decide to scale to a Solaris server, or need to run your application on the Macintosh platform, portions of your code will need to be revised to remove the COM objects.

JavaBean objects do not have the limitations of Windows platform dependence that COM does, so if multi-platform support is important to you, you may want to use JavaBeans wherever possible.

Creating an ODBC Data Source Name (DSN)

Moving your Tango application from one server to another means that a ODBC DSN (Data Source Name) likely needs to be created on the target server. A DSN identifies your database to the system, along with the name of the database driver to use and other configuration information. Your Tango application connects to this DSN and therefore does not need to know the particulars of the database driver. How this DSN is created on the target server depends on the deployment scenario. Creating the DSN is discussed in each of the scenarios that follow.

[back to top]

Scenarios

Case 1: Corporate Intranet

The most basic case: You have created a Tango application and want to deploy it to an internal company Web server for internal use. The information in this section applies to all the other scenarios as well.

If you have access rights to the Web server machine, copy or FTP your application files to the Web server. Tango Editor can automatically move your Tango application via FTP to a target server. If you do not have the appropriate permissions on that target server machine, you may need help from the owner of the target server.

The Tango application must reside in a directory on the Web server where execute permissions are allowed, because these application files are executed by Tango Server.

Once the application files are copied, then next step is to create a system ODBC DSN that points to your application's data source. How this DSN is created varies.

• If you have physical access to the machine, you can create the DSN at the target server using an ODBC Administrator utility or through other means.
• If you do not have access, your network administrator may make available a Tango application file which allows creation of the DSN over the network. The administrator's decision on whether to allow this will be based on how much security they deem necessary on the target server.

Other scenarios probably require you to submit a request to the IS department to have the DSN created.

Case 2: Internet

You have created a Tango application and would like to deploy it to in such a way that people can access it from the Internet. This is similar to Case 1; however, in today's security conscious environment, most businesses protect their networks behind a firewall. A popular configuration is to put your Tango application on a Web server outside a firewall, and your Tango and database servers inside the firewall,. To set up your Tango application in this configuration, follow these general steps:

1. Move your application and database files to the Web server (see Case 1).
2. Have the firewall administrator modify the firewall's configuration and assign you a specific port on the firewall. This port then passes through the firewall directly to Tango Server.
3. On the Web server, manually modify the file t4client.ini in the configuration directory so that the following line has the IP address of the firewall and the port number assigned to you by the firewall administrator:

   TANGO_SERVER=xxx.xxx.xxx.xxx, Port=xx

4. If you have access to config.taf on the machine where Tango Server is running, add the IP address of the firewall to the ValidHosts listing; otherwise, you need to have your Tango server administrator add it.
5. Create a ODBC system DSN as described in Case 1.

Case 3: Internet via a Service Provider

You have created a Tango application and want to deploy it to your Internet Service Provider (ISP) so that it is accessible via the World Wide Web. One of the first steps here is to pick the right ISP. Of course, your ISP must be running Tango Server. The best ISP for you likely runs the same operating system and, more importantly, uses the same database product as you have chosen for your development work. If you have a match between operating system platform and database, your deployment cycle for your Tango application is shortened.

This case is similar to Case 1, a corporate Internet, but you likely have the support, procedures, and experience of the ISP to help you. Just like case one, the steps are:

• Move your Tango application and database files to the target server
• Create an ODBC DSN.

The best thing to do in this case is to contact your ISP and request the procedures for deploying your Tango application.

Case 4: Internet via your own Tango Server

You have created a Tango application and want to run it on your own Tango Server. This is one of the most exciting options that is now feasible with high-bandwidth Internet connections. Now, with an affordable connection, such as ADSL or cable modem, running your own Tango Server (and Web server) in the home office is very practical.

For mission critical applications, you can co-locate your Tango Server with an ISP such that you take advantage of their secured, monitored facilities with dedicated network bandwidth. Prices for co-location vary widely, so shop around.

For cable modem connections, the main obstacle can be having a dynamic IP address (you are assigned a new IP address each time you connect to your Internet service provider). There are several options you can choose from.

• Ask your ISP to assign you a static IP address. This is a set address that is given to your machine on a permanent basis. This is a good solution for small business and is usually quite affordable.
• Use the services of a dynamic IP company. These companies can provide you with a program that efficiently updates domain name services (DNS) to keep your server's changing IP known on the Internet.
• A creative way to handle this dynamic IP scenario for non-mission critical servers is to have a simple script that runs at system startup. The script can grab the IP address and FTP a file with the new address to another Web server. An HTML file on that server can include the file that is sent by FTP from the dynamic server. This is a bit of a kludge and the more robust options are the ones listed previously.

[back to top]

Cross-Database Deployment

This section discusses the issues revolving around changing the database underneath your Tango application. With a little advance planning, this is possible; however, without any advance planning, you may run into some problems.

If you intend to build a Tango application that can run across multiple database backends, this section is of value to you. If you want to do a one-time migration of your database from one vendor to another, this section may be of less help. In the latter case, you may benefit from a data migration and transformation tool, or you may want to simply mirror the database schemas and write a simple Tango application that selects all the data out of one database and inserts it into another database.

Database Capabilities

Databases have different capabilities. They support different levels of SQL grammar and offer different features to the application developer. It follows then that if you use a special facility in one database platform, it may not be available on another. Here are a few that stand out:

• Referential integrity and cascading deletes
• Auto-incrementing identity types
• Stored procedures and triggers
• Advanced SQL syntax like OUTER JOIN.

Each of the facilities above may be very useful to the developer; however, if database portability is a concern, make sure the features you depend on are available in all your target vendor solutions.

The Do's

• Do describe your database schema in SQL statements; that is, build a SQL script that creates all your tables and indexes. This gives you something to port between database platforms rather than starting your schema definition from scratch.
• Do know the differences in SQL dialect between the target database platforms, or stick to basic SQL statements. Tango provides you great leverage here by adhering to standards in the SQL produced by Tango actions. However, Tango also lets you define your own SQL statements.
• Do look for tools that help you with the transformation of the database between vendors. For instance, Microsoft Access databases can easily be saved as Pervasive.SQL 2000 databases by choosing Save as/Export, selecting ODBC, and then connecting to the database with the Pervasive.SQL 2000 ODBC driver.

The Don'ts

• Don't use stored procedures and triggers unless performance mandates it. These almost never port without problems between database vendors.
• Don't use data types in your applications that are unavailable across all target database systems. You may need to design for the lowest common denominator in some cases.

For example, if auto-incrementing types are not available across all databases, but you need a unique, system generated ID as a key in one of your tables, you need to add this logic to your Tango program to guarantee the uniqueness of a new ID that is inserted.