Availability Guide for Application Design

Designing Applications for Change
Availability Guide for Application Design—525637-004
10-5
Considering Portability Requirements
database management systems, the initiative of the X/Open SQL group has given rise
to products such as Microsoft Open Database Connectivity (ODBC). ODBC access is
provided today for NonStop SQL/MP. Support for these client tools will be provided in
NonStop SQL/MX for both the NonStop operating system and Windows NT Server. By
definition, such client applications are portable between database management system
versions unless the developer includes vendor-specific extensions in the statement
syntax. Similar functionality can be expected in other environments such as Java
Database Connectivity (JDBC) for the NonStop Server for Java product.
Tuxedo APIs
Tuxedo is the leading open transaction processing monitor product available.
Developed by AT&T, its ownership has moved from USL to Novell to transactional
middleware specialist BEA. NonStop Tuxedo Release 1.1 for Windows NT supports
version 6.4 of the Tuxedo API, and NonStop Tuxedo Release 2 for the NonStop
operating system supports version 6.2 of the Tuxedo API.
The Tuxedo API is particularly rich—providing remote procedure call, conversational,
and message-queuing forms of interprocess communication, as well as implementing
the three-tier client/server model (discussed in Application Architectures and
Processing Types on page 10-8) via its /WS subsystem.
Any application that remains within the Tuxedo transaction monitor with SQL APIs will
prove highly portable to any of the Tuxedo implementations available on the NonStop
operating system, Windows NT Server, or other platforms. The key factor is to avoid
direct application code dependency on any operating system or other architectural
features that may limit its applicability to specific implementations.
Communication Subsystem APIs
The communications side of computing was the first to push standardization.
Unfortunately, that standardization took two directions, neither of which involved the
APIs by which communication services were invoked. Communications standardization
focused on two aspects:
•
The formats and protocols (FAPs) defining the bitstreams and control structures by
which the two ends of the connection would successfully communicate
•
Layering, or creating successive levels of abstraction where the FAP of one layer
could transparently communicate with its peer level over any lower-level
implementation
The latter is typified by the seven-layer OSI model. Efforts are now under way to
standardize the APIs for the upper levels of specific communication subsystems,
including CPI-C for SNA or BSD and Winsock sockets for TCP/IP on X/Open and
Windows systems.
The absence of formal standards for communications APIs means that their direct use
in portable applications must be protected by isolation. Access should be at the higher,
more abstract levels or through middleware. Direct communication subsystem access,