http://www.microsoft.com/TechNet/boes/bo/bosi/technote/bf106.htm (PC Press Internet CD, 03/1996)
| Updated: March 12, 1996 |  Go To TechNet Home Page |
Presented by: Stephen Skarlatos
Mr. Skarlatos is Vice President of Product Research and Development at Applied Information Sciences, Inc. (AIS), a services and products company specializing in the implementation of enterprise client-server architectures. With over 15 years of technical experience, Mr. Skarlatos has supported and managed many application design and development efforts for large scale transaction processing environments. Mr. Skarlatos is a recognized authority on the implementation of client-server architectures within the Unisys® mainframe community. Over the past four years, Mr. Skarlatos has led the product development efforts of UniAccess, which is a source code-based implementation of the SYBASE® Open Client and Open Server on the Unisys 2200. Currently, Mr. Skarlatos consults, and is a speaker in many forums, on the implementation of enterprise client-server systems worldwide.
Introduction
Enterprise Environments
Open Systems Definition and Status
Information Systems Architecture
Vendor Architecture Alternatives
Microsoft Architectural Solution
Programming Example
Summary
This session is designed to introduce developers and managers to integrating Microsoft® BackOffice and visual development tools with mainframe-based, legacy applications. Many other session are focused on presenting the functions and capabilities of Microsoft BackOffice and visually-oriented development tools such as the Microsoft Visual Basic® programming system. Therefore, this session will focus on the client-server architectural requirements and solution components which enable the development of two- and three-tier client-server systems.
Over the past thirteen years, Applied Information Sciences, Inc. (AIS) has specialized in the design and development of large scale transaction processing systems for mainframe customers. For the past six years, AIS has assisted clients worldwide to modernize centralized mainframe systems to enterprise client-server systems utilizing mainstream technology. The AIS approach to modernizing legacy systems to two- and three-tier client-server architectures will be described through the following sections:
The programming examples referenced in this session are contained in the files CLIENT.DOC for the Microsoft Visual Basic client program and SERVER.DOC for the mainframe server COBOL program.
Today, the information systems enterprise in many organizations can be characterized as distributed heterogeneous systems and applications that are not integrated. According to the Gartner Group, "The information infrastructure in today's typical enterprise is plagued by an 'architectural crisis' - a profusion of vendors and incompatible products. In this complex environment it has become increasingly costly to acquire, use and operate computer systems. "
In the past the customer's platform vendor, usually the mainframe vendor, resolved integration problems as a bundled cost of the mainframe platform. Now, as customers pursue the implementation of distributed, supposedly "Open Systems," customers are obtaining 'cheap iron,' which is provided in the form of unbundled platforms. Now, it is the responsibility of the customer to solve the integration problems without the financial leverage of a single vendor environment.
Every major study of IS requirements for large-scale environments in the past few years reflects this situation. All of them found the most important requirement for these environments is interoperability across heterogeneous systems and networks. Gartner's architectural crisis statement reflects the lack of a coherent definition of how the components existent in these environments should interoperate.
Examples of the enterprise environments which are the focus of this session include the following types or organizations worldwide:
In short, this session is focused on almost any organization with at least one mainframe and a minimum of several hundred end-users. Regardless of their size or IS budget, these organizations have many similarities in their system and application environments, emerging requirements, and challenges.
Most of the enterprises defined above have the following systems and applications environment:
Beyond their current system and application environments, most large enterprise organizations also have a common set of new or emerging IS requirements. AIS sees this fact today with our many customers worldwide. For example, the Swedish telecommunication firm, Telia (Sweden's equivalent of AT&T before the breakup), faces exactly the same interoperability needs as the Texas Department of Human Services. Furthermore, both these customers, and a major supermarket chain in Italy, Generale Supermartica, want to utilize the new generation of development and end-user tools. The common set of IS enterprise requirements which AIS has observed includes the following:
Regardless of their organizational functions or regions of operation, most large organizations are seeking solutions to the above stated requirements.
Large-scale modernization is required to meet the requirements of today's enterprise. This effort is complicated by the following challenges:
A common Information Systems Architecture (ISA) for the entire enterprise must be defined and followed. Therefore, all the many different parts of the IS and end-user organizations must share and support the common vision, the ISA.
Before defining an internal vision for the selection of products to move to Open Systems, customers should first decide what they believe "Open Systems" means. Open Systems means different things to different people. For example, is X/Open or Microsoft more representative of Open Systems? This question raises a myriad of issues and beliefs.
AIS believes the general market consensus on the meaning of Open Systems has evolved over the past several years. According to the Oxford Dictionary of Computing, Open Systems is "any system in which the components conform to non-proprietary standards, rather than to the standards of a specific supplier of hardware or software."
Based on this definition, Microsoft Windows would not represent an Open System. However, no other operating system is as widely used or supported, except for MSDOS®. This clearly depicts the difference between the following two types of standards:
Today, market-made, or de facto standards, play an important role in implementing Open Systems.
AIS has defined a set of tenets which reflect our view and definition of Open Systems. Our beliefs basically follow the directions of Microsoft and SYBASE. They also follow the conclusions made by Computerworld in their assessments of the last two X/Open Xtra Studies on the state of open systems.
This tenet is taken directly from Computerworld's 1993 review of the X/Open Study. Bill Laberis, Editor of Computerworld, made this statement in recognizing that the formal international standards effort for software had not resulted in any level of vendor or customer support and that IT executives need to look elsewhere for standards.
This tenet is taken from the title of an article in Computerworld. It suggests to IT executives that they look to de facto standards as the basis for architectural decisions. The clear implication is to use standards which have been accepted in the marketplace such as TCP/IP, SYBASE Open/Client and Open/Server, and Microsoft ODBC, rather than their de jure counterparts.
Whether we talk about de jure or de facto standards, this tenet holds true. Just because a product conforms with a standard does not mean it will operate with its counterpart on the network.
A good example of this tenet is X/Open DTP products. Novell®'s Tuxedo complies with the standard, but its primary functionality is dependent on a proprietary buffer type, FML. Another conforming product, e.g. Unisys' TransIT Open/OLTP for the Unisys 2200, can interact with Tuxedo but not using its primary functionality, i.e. it does not support FML buffers. Therefore, gateways must be developed between these two implementations of the same international standard in order to allow interoperability.
UNIX stopped being a synonym for open some time ago. With the demise of AT&T's UNIX System Labs and Novell's subsequent failure to unify the UNIX variants, these variants are as proprietary as any other operating system. From a market standpoint, Microsoft Windows and Windows NT operating systems are currently the most open of operating systems by virtue of their wide industry support..
Since UNIX is no longer synonymous with open, what is? AIS believes it is choice. Choice fuels competition which breeds increases in functionality and decreases in price, which were some of the original reasons for open systems. Some in the IT industry thought the path to choice was through de jure standards, but this simply has not occurred.
An architecture with the most market share support maximizes choice. If a vendor wants to maximize its market potential, that vendor ensures its product is compatible with the market leaders. In the old days, most third party product vendors developed for the IBM platforms while today they must also consider Microsoft/SYBASE and ORACLE®.
From a client-server standpoint, market support is critical to creating a long-lived architecture. No one vendor can deliver all the necessary components for an enterprise architecture. Therefore, customers must look to the market leaders with the widest market support for fully functional and long-lived solutions.
There seems to be a growing consensus for this tenet. While distributed systems were once bandied about as cost savers, IT executives have found that system management costs more than offset the hardware/software savings.
According to the Gartner Group, Open now means: "Permitting application portability, system interoperability, and enterprise-wide system manageability in a multivendor, heterogeneous environment, typically through the use of vendor-transcendent standards." This new definition is a realization that standards embraced by several vendors can allow an implementation of Open Systems. This change from the Oxford Dictionary of Computing has occurred through the reality of the marketplace.
Customers are seeking long-lived architectures with choice in all things. The AIS Tenets can be used to guide the decisions made by customers as they define their internal ISA vision and select products to implement their migration to Open Systems.
In order to fulfill the requirements and meet the challenges for today's enterprise, customers should define an Information Systems Architecture (ISA). The ISA is a set of standards, guidelines, and statements of direction that support a cohesive and unifying vision which is used during all phases of the development of discrete information systems.
The ISA should address the business or organizational functions, supporting applications, and systems infrastructure. Figure 1 is a deceptively simple depiction of the ISA.
Figure 1
This diagram is used to make the point that the applications and systems architectures have but a single mission, support the business functions. Historically, many organizations built applications using the same systems structure again and again, without seeking to redefine the systems architecture or how best to address the business functions.
Figure 2
For example, the New Hampshire Department of Transportation (NHDOT), has built mainframe-based COBOL applications for years. The incremental cost of building a new system, or expanding a current system, was very small as compared to completely re-defining, or re-hosting, their system and application architectures to better support their organizational functions. Furthermore, they felt the technology had not evolved to the point that they could capitalize on their current mainframe investments while also utilizing the latest workgroup technology. As shown in Figure 2, mainframe customers such as NHDOT have been limited to first considering their systems investment in the development of their information systems.
NHDOT, as well as many other organizations, now believe the technology exists today with reasonable cost levels to begin to modernize their current environments to meet the common set of requirements and challenges defined above. The first step being taken by NHDOT, as with most organizations, is to define an ISA beginning with their business, or organizational functions. The next step is to analyze the existing applications and new application requirements in order to define and select the systems architecture to support the new distributed applications.
The Systems Architecture component of the ISA includes the systems, networks, operating systems, system software, and application support services as shown in Figure 3.
Figure 3
The key is selecting the right Application Support Services which will support all existing systems as well as any new systems from leading vendors which may be deployed in the future. The Application Support Services are the components on each platform which allow applications to interoperate.
The International Standards Organization (ISO) 7498 Open System Interconnection (OSI) international standard for Open Systems architectures defines a layered architecture, as shown in Figure 4. In this type of architecture, work occurs in distinct components, known as layers. A layer provides well-defined services to the layer above it. A layer uses the services of the layer below it. The interface between two layers is strictly defined, and does not change. Across a network, the peer levels communicate.
Service implementation details within a layer are hidden from other layers. This means that as long as a layer's service interface is maintained, its service implementation details can be freely changed without affecting the services provided by the layer.
The Application Support Services identified above are composed of the seven-layer OSI stack and would exist on each platform to provide client-server services to applications and databases:
Figure 4
The OSI Stack sets of services can be put together into Groups (User and Network) and Sub-Groups (Interoperability, Session Management, Connectivity, and Communication). Figure 5 shows these groups in relation to the OSI Stack levels with examples of each level. (Note: Acronyms included in Figure 5 are described in more detail later and include Stored Procedure (SP), Remote Procedure Call (RPC), and Tabular Data Stream (TDS).)
.
Figure 5
The four Sub-Groups of Figure 5 make up the Application Support Services as shown in Figure 6.
Figure 6
It is the Interoperability and Session Management services which are of the most interest to this session and to the customer community for client-server architecture. Connectivity and Communications are very well addressed by the communication and network transport vendors. Correctly and fully implementing the Application, Presentation, and Session layers which make up the Interoperability and Session Management portions of the Application Support Services is the key to providing a fully functional client-server solution.
The Application layer includes service elements which provide access for an application to the services supported in the lower layers of the architecture. These are the services that are available to an application developer to build a distributed application program. Generally, these service elements are referred to as the Application Programming Interfaces (APIs) of the client-server architecture components providing the services for a given vendors products.
The Presentation layer provides for the representation of information that application programs refer to in their communication. This representation is called the transfer syntax. The Presentation layer is only concerned with the syntax of data representation, not the semantics. The common representation of data provided by the presentation layer allows application programs to use their native platform transfer syntax, and the presentation layer performs any required conversions. This presentation layer service provides platform independence across heterogeneous platforms.
The Application layer uses the Presentation layer to transfer data type representations. Any conversions required because of platform differences between a client and a server are performed at the Presentation layer. For example, representation of a floating point number varies between platforms. The Presentation layer allows a client application program to use the native floating point representation on its platform. The Presentation layer will convert the representation as required so the server can also use its native floating point representation if it is on a different platform.
The heart of an ISA is the Interoperability and Session Management services which provide the client to server interaction. The strength of vendor products which implement these services are measured by the completeness and extensibility of their APIs and the underlying Formats and Protocols (FAPs) which provide the client to server flow of information in each OSI layer. The examples in Figure 5 are from the Microsoft and SYBASE architecture. The example shows that the APIs support both SQL and RPCs and utilize TDS as their FAP.
The client-server architectures offered today by vendors provide the Interoperability and Session Management functions of the Application Support Services in an ISA. In general, most vendors offer Structured Query Language (SQL) access from a client program or tool to a remote relational database. In this scenario, all application logic is on the client platform which is interacting directly with a relational database.
Client-server architectures which interoperate with mainframes must provide a means for the client program to interact with the server-based intelligence of a mainframe legacy program. Many vendors support server-based intelligence with stored procedures. However, stored procedures are very different from RPCs. Stored procedures are usually SQL statements written for a specific vendors relational database which are stored and compiled with that relational database. This allows a client program to activate server intelligence to be executed against a vendors relational database. However, stored procedures could play a role in mainframe integration if they could make RPC calls. This would allow for true three-tier architectures.
Traditional mainframe applications are 3GL programs, usually written in COBOL, which are activated by an end-user accessing the mainframe in terminal emulation mode, as shown in Figure 7. The end-user activates the program by manually signing on to the mainframe and typing in a program name (TRANCODE) followed by data parameters (DATA, DATA, DATA). This is needed to uniquely specify the information or initial screen desired. The mainframe program is then executed and usually sends back a terminal emulation screen with the information requested or empty fields for additional input.
Figure 7
In the terminal emulation mode, all application logic is on the mainframe. In a client-server architecture, the client also has application logic which interacts with the server logic. This end-user to mainframe program interaction could be replaced by a client application sending the same calls (i.e. TRANCODE, DATA, DATA, DATA) and receiving result sets from the mainframe legacy program. This can be accomplished through the use of client and server APIs communicating via remote procedure calls (RPCs) as shown in Figure 8.
Figure 8
The goal would be modernize the mainframe legacy programs into re-useable RPCs accessible from workgroup client applications, tools, and databases. These new client-server applications would operate side-by-side with the older emulation programs until the modernization is complete. The changes to the legacy application would be to modify the program from using the terminal emulation functions to accept requests and send results to now using the server API. The rest of the legacy program could remain the same.
Many mainframe programs have the terminal emulation interface code in a single area which eases the changes. However, the creation of new mainframe programs based on portions of older programs can also be accomplished and at times could be easier than just using the original program. In addition, a control program could be built for the client-server interaction which would call the legacy programs directly. These and many other approaches can be used, but the correct approach is a matter of analysis.
In the IS marketplace, there are first-tier vendors, who control enough market share to influence the product decisions of the other vendors, and there are second-tier vendors, who cannot and do not influence the industry. Regardless of which tier they belong to, every major IT vendor adopts one or more architectures into which they integrate their products. The first-tier vendors usually define their own architecture and/or adopt architectures from other first-tier vendors, while the lower-tier vendors can only adopt architectures from the first tier vendors.
Further, these vendors usually segregate these architectures into two categories, primary and secondary. For primary architectures, the vendors spend most of their R&D dollars to make them fully functional, while for secondary architectures the vendors limit expenditures in order to get a 'checkoff.' A checkoff is necessary as a means to obtain revenue outside their primary architecture by having something to offer for the secondary architecture.
With respect to IT architectures, only the first-tier platform and RDBMS vendors have and influence in the client-server architecture marketplace. Figure 9 lists these vendors along with their better known second-tier counterparts in two adjacent tables. They are segregated by the platform which they influence most within a three-tier architecture.
Figure 9
The first-tier vendors, through the power of market share, generate choice for their customers by attracting the other vendors to their architectures. Therefore, it is to the architectures of the first-tier vendors that you have to look for choice.
Since the secondary architectures of the first-tier vendors are for the most part marketing tools, i.e. checkoffs, only the primary architectures will be considered. A careful analysis of each of these vendors, which is too voluminous to present in this session, shows the majority of first-tier vendors have selected a surprisingly small number of common architectures, ORACLE, Microsoft/SYBASE, and IBM's Encina /CICS™.
The choices made by each first tier vendor is shown in Figure 10 where the vendors are row entries while the architectures are represented by the columns. The Unisys 2200 and its primary architecture, Open/OLTP, are included for comparison purposes.
Figure 10
Figure 10 clearly shows there are only three architectures which can influence the majority of vendors. All others are only niche players (Note: the PowerPoint® presentation which is a companion to this document contains a breakdown of all the architectural alternatives offered by the primary vendors.)
The unique exception to this analysis is Microsoft. With their domination of the desktop, they influence all architectures. As discussed later under the Microsoft Architectural Solution, Microsoft utilizes the SYBASE architecture as a base of its architectural components. All other architectures must employ the Windows operating system outside of its native mode, including ORACLE, Encina/CICS and Open/OLTP, which naturally limits the functionality of the Microsoft Windows operating system within those architectures.
The primary architectures can be placed in two categories, the tightly-coupled database architectures of SYBASE and ORACLE, and the loosely coupled service architecture of IBM CICS/Encina. SYBASE and ORACLE attract most leading vendors to support their environment and IBM will more than likely attract a good share in the future.
Both SYBASE and ORACLE have added support for many services included within the IBM CICS/Encina architecture as just additional service calls in their architectures. Many customers see this as obtaining the best of the service architecture within the current leading database architectures. This could stem the tide of support for IBM and other loosely coupled service architectures in the future. For the near term, SYBASE and ORACLE dominate the client-server architecture marketplace from a customer implementation standpoint.
SYBASE has a clear lead over ORACLE in the area of mainframe integration. The ORACLE solution requires that requests go through an ORACLE database and then through an off platform gateway, either a transparent SQL gateway or procedural gateway. In either case, the ORACLE approach is aimed more at selling ORACLE databases than mainframe integration.
The SYBASE architecture allows client applications to directly interact with the mainframe. This is a major performance advantage which is imperative to most mainframe customers. Furthermore, SYBASE is also unique in their support of RPC access directly to mainframe programs. In the ORACLE architecture, SQL statements must be transformed to RPCs in the off-platform procedural gateway, which adds an unnecessary translation layer.
As stated in the Information Systems Architecture section above, architectures should be judged by the breadth of functions and support of their APIs and the strength of their underlying formats and protocol (FAPs). SYBASE is the clear winner in both areas. The SYBASE architecture is available on most leading platforms and allows both SQL and true RPC access to servers. In the SYBASE architecture, even mainframes can act as clients to remote server programs and databases.
From a legacy integration standpoint, we have shown that the Microsoft and SYBASE architecture is a leading industry solution. This section will propose and describe a solution for a typical enterprise utilizing the Microsoft and SYBASE architecture. The proposed components are as follows:
The Microsoft Windows Open Services Architecture (WOSA) is the definition and embodiment of the Microsoft vision of Information at Your Fingertips. The focus of WOSA is to provide an open environment for the development and use of Windows-based applications.
Far broader than an API, WOSA is an architecture that promotes the easy integration of Windows and Windows-based applications within heterogeneous enterprise-wide computing environments. WOSA provides seamless access to three categories of information resource services: common application services, communication services and vertical market services. Through WOSA, Microsoft makes software development faster, easier and less expensive for corporate developers, while providing developers and users with transparent access to different vendor-implementations of these information services.
For instance, by using Open Database Connectivity (ODBC), the database access component of WOSA, a corporation can build an application that will seamlessly work with more than 20 database servers on a variety of hardware platforms. This prevents a corporation from being locked-in to a single vendor for its critical database services and provides an unparalleled degree of portability and scalability for database services. In meeting these goals, Microsoft is meeting the primary benefit of an open system: greater product choice for users.
WOSA's component services are defined in cooperation with hardware manufacturers, corporate developers, and independent software vendors through the Open Process program. The WOSA effort has the backing of hundreds of industry members. Microsoft has adopted de jure specifications for WOSA where relevant. For example, the work of the SQL Access Group is the basis for WOSA's Open Database Connectivity, while the Messaging API (MAPI) supports the X.400 API Association's Common Messaging Calls (CMC). Microsoft has also worked with industry leaders to help create standard specifications where they are needed, such as the License Service API, Windows Sockets, and the Windows SNA API. WOSA is available today for all members of the Windows family.
Much as the Microsoft Office Suite and Microsoft Visual Basic offer an integrated family of client applications, the Microsoft BackOffice is an integrated server platform. BackOffice products are available today either individually or together as a family of products:
Microsoft implements their client-server architecture components of the Microsoft WOSA, ODBC, and BackOffice utilizing SYBASE technology as a base. Microsoft licensed SYBASE client-server (Open Client and Open Server) and database technology (SQL Server) to implement the Microsoft architecture. For example, the Microsoft ODBC drivers for Microsoft SQL Server utilize Open Client and the SYBASE Tabular Data Stream (TDS) for client to server interaction.
This relationship has extended the availability and market support of the components beyond the level that any one company could provide. AIS has also contributed by making the architecture available on Unisys mainframes in the same manner that SYBASE and Micro Decisionware, Inc. have done for the IBM mainframe. Each of these, and several other native implementations of the base SYBASE technology allow complete interoperability between all components from all vendors.
Strategic relationships with industry leading partners complement the Microsoft and SYBASE technology with vertical applications and an extended range of hardware platforms. Also, through the Microsoft Solution Provider and SYBASE Open Solution Partner Program, hundreds of independent software vendors provide complementary tools for statistical analysis, graphical display, CASE, artificial intelligence, query and analysis, application development, and connectivity. Since Microsoft embraced the SYBASE architecture, many leading Microsoft Windows and Windows NT operating system application and tool vendors have following suit.
Although the architecture is delivered through Open Client, Open Server, and SQL Server, it is based on the concept of programmable intelligent servers. This capability allows the server to manage data integrity and apply enterprise business rules to client requests. As we will see, mainframe legacy applications can be modernized to utilize the Open Server and become remote procedures accessible from Open Client applications or SQL Server databases.
Programmable intelligent servers operate through the execution of database RPCs. In the SQL Server, intelligent programmable services are provided in the form of a special kind of RPC, the Stored Procedure (SP). SPs are compiled programs written in the extended SQL language, Transact-SQL. SPs include the capability to make RPC calls to other Microsoft and SYBASE compatible servers. Under the Open Server, database RPCs are user-written 3GL programs which utilize the rich set of Open Server Libraries.
The Open Client is a programmable interface which manages the interoperability between the client application or end-user tool and the SQL Server or any full implementation of the Open Server. Open Client's consistent interface to the server enhances the independence of client applications from the underlying networking protocols and data sources. Open Client also includes a client network interface which supports many transport protocols and automatically formats the client's request for transmission over the selected network to the server. When an application makes a request through Open Client, knowledge of the underlying network as well as the location and source of the data is not necessary.
The Open Server provides a consistent method of receiving SQL requests or database RPCs from an application using Open Client. Upon receipt, Open Server passes the requests to a user-written application. Open Server implementations normally co-exist with high-speed relational database gateways so that client SQL requests can be directly executed against relational databases without any user written programs or intervention.
While Open Client provides users with the flexibility to use a variety of development and end-user tools, the Open Server provides users with the flexibility to access and update a variety of data sources. With Open Server, foreign data sources and applications can be seamlessly integrated. For example, a CICS/COBOL program on a IBM mainframe can become an RPC providing access to any datasource accessible from the CICS/COBOL application.
The Open Server consists of two main logical components, the Network Interfaces and Server Library. The Network Interfaces on the server manage the network connection and accepts client requests running Open Client or RPCs from SQL Server. Event-driven server utilities in the Server Library provide the logic to ensure client requests are passed to the appropriate user developed program or database gateway and are completed properly.
The Open Client and Open Server offer a complete set of services and services elements to implement the Application, Presentation, and Session Management layers of the OSI Stack and the Application Support Services of an ISA.
The following sections will only address the services of RPCs, Event Notification, Database Commands, and TDS data processing that is immediately of interest for the application programmer for the programming example provided below. Many other services including security, naming, management, error handling, etc. are too voluminous for this document. Complete descriptions of all capabilities and services are available and cited in the References section.
The Database Remote Procedure Call (RPC) service enables an application program to execute a named procedure on a remote server. The database RPC parameters can be of any data type except text or image and can be input or output. Input parameters are used to pass input arguments to a procedure call executed on a remote server. Output parameters are used to return result information following the execution of the procedure call on the remote server.
The database RPC implemented by TDS is different from traditional RPC mechanisms offered on some operating system platforms. Traditional RPC mechanisms use a static binding of input and output parameters. This mechanism is adequate if all expected results are known when the RPC is defined. However, if an RPC is used to execute a data base query (TDS database RPCs are how SQL Servers execute remote system stored procedures), the results that will be returned are not known when the RPC is defined. This makes the traditional static binding model of RPCs inadequate.
A TDS database RPC allows a client to dynamically define the input and output parameters when it is executed. The format of the input and output parameters is sent to the server at execution time. This model is much more flexible since it supports run-time definition of parameters, eliminating the requirement to statically define all parameters.
Tabular data can also be returned as a result of executing a TDS database RPC. This allows RPCs to issue database query operations and to receive the tabular data back. The format of the tabular data is defined to the client at run-time by the server. To receive tabular data with traditional RPC mechanisms requires that either all row/column information is known in advance so parameters can be defined, or a higher level protocol is defined between clients and servers to encode the tabular data stream in pre-specified RPC parameters. The RPC service uses the presentation layer's transfer syntax and transfer syntax information services and the session layer's exchange service of the Open Client and Open Server..
The event notification service facilitates inter-application communication and synchronization. The event process begins when a client sends a request to a server that the client be informed when a particular event occurs. This request is made to the server using a specific RPC call. When the event occurs, the server sends an event notification to the client. An event is defined to be the execution of a specified RPC at the server by any client. When the RPC is executed, the event notification sent to the client consists of the name, and parameters, of the executed RPC.
This service allows one client to request event notification for a specific RPC, and another client to execute that RPC. The first client will receive a notification that the RPC was executed. The server acts as a centralized notification service for all connected clients. How event notifications are used by client applications is entirely defined by the applications.
The database commands service element supports language, cursor, dynamic SQL, and bulk load database commands. These commands provide support for data base type operations against a server.
The language command service allows a client application to send a language string to a server. The language command does not specify the syntax of the language command and it does not require commands to be in a particular character set. If necessary, the character set will be converted by the presentation layer at the server.
An Open Client application uses a language command to send SQL queries to a SQL Server. When an Open Client application connects to an Open Server application, the syntax of the language command sent to the Open Server application can be anything required by the distributed application, i.e. it could be SQL or an RPC.
The most recent versions of TDS fully supports all ANSI SQL cursor commands. These commands are: Declare a cursor; Open a cursor; Position a cursor on a specified row of a table and retrieve values from that row using all specified "fetch orientations" (next, prior, first, last, absolute, and relative); Close a cursor; Use a cursor to delete a row of a table; Use a cursor to update a row of a table.
Cursors are used by client applications to control the result information returned by a database server. Cursors allow a client application to fetch only a specified number of rows from a table, not the entire table results. All cursors also contain a notion of the current cursor row. The current cursor row is where the next fetch, update, or delete will occur.
The most recent versions of TDS fully supports all ANSI SQL dynamic SQL commands. These commands are: Prepare a statement for execution; De-allocate a prepared statement; Obtain parameter and column specifications for a prepared statement; Associated input parameter and output targets with a prepared statement, and then execute a statement; Dynamically prepare and execute a statement;
The database tabular result processing service element enables servers to return tabular data to clients. "Tabular data" is data in table form: that is, multiple rows' worth of column-values. Tabular result data can be intermixed with remote procedure call results (return parameters and return status). This means that even though a client issued an RPC call to a mainframe program which accessed a flat file, the result set is rows of column values because the Open Server is converting the data types and returning sets in the TDS format. Therefore, a Microsoft Visual Basic program may interact with data from mainframes in the same way it interacts with SQL Server data.
This service element also supports delineation of result sets. This allows multiple result sets to be returned in response to a single database command. Each result set is terminated by a status indicating whether this is an intermediate or final result set.
TDS first sends a description of each column in the table that will be returned. This description includes the column data type, column name, and whether the column can be null. Following the column description information, row data is returned to the client. Multiple rows may be returned to the client without re-sending the column description information. New column description information is only sent to the client at the beginning of each tabular result set, and following each intermediate result set indication.
Columns can have any data type supported in the Data Element Service Element. The Database Tabular Result Processing service uses the presentation layer's transfer syntax and transfer syntax transformation services and the session layer's normal data exchange service.
This remaining sections of this session will demonstrate an example three-tier enterprise application and describe the application program interaction with the underlying architecture. The programming example is a three tier application utilizing the tools and components defined above. The application is the Order Entry Tracking System (OETS) which automates Order Entry functions. Within OETS, data moves seamlessly and transparently between desktop, departmental, and mainframe computers. OETS allows the end users to input customers or update existing ones, place orders, change orders, and delete orders
A Microsoft Visual Basic client application resides on a Microsoft Windows platform utilizing a local Microsoft Access database. A product database with product descriptions, pricing, and availability is stored on each departmental Microsoft Windows NT Server in a Microsoft SQL Server. A centralized mainframe server contains modernized legacy applications accessible from the Microsoft Visual Basic client and the SQL Server as RPC or SQL requests. The mainframe also houses the customer, centralized product, order, inventory, and invoice databases.
Like any Microsoft Visual Basic application, OETS is activated by running the executable from the File-Run Microsoft Windows selection or by double-clicking on the OETS icon.
Figure 11
Upon execution the program requests a user ID, password, and server name in order to sign on to the server and verify user authentication. This initiates the client to server flow and is only required once for each server.
Figure 12
Upon successful sign-on, the main Order Entry Customer Information screen is displayed to allow the end-user to select a customer for which to process an action request. The end-user may select customers by name or number. A blank selection will cause all customers assigned to the end-user to be requested. By making the selection and clicking the selection button, the Microsoft Visual Basic program builds the selection request and issues it to the appropriate server.
Figure 13
The server returns the requested information by executing the requested RPC or SQL statement and returning the results in the TDS format. The response is processed by the client application and, as shown in Figure 14, the customer information from the mainframe server is displayed.
Figure 14
The end-user may select one of the customers to use in an order processing activity. As shown in Figure 15, a customer was selected by double-clicking on one customer.
Figure 15
By clicking on the write order button (pencil point), the client program automatically creates a new order and requests product information from the departmental SQL server database by issuing an SQL statement. The results are returned in the TDS format and processed by the client application. As shown in Figure 16, a new overlay window displays the product information. The screen now shown mainframe and departmental server information together. Utilizing the Microsoft and SYBASE architecture, a three-tier interaction is taking place. Furthermore, the end-user cannot tell the data sources from one another. Information is being accessed, processed, and updated, seemlessly.
Figure 16
To complete the order process, one of the products is selected, a quantity is input, and the order request is completed by clicking on the save order button. This causes the order to be committed to the mainframe server. This interaction is displayed in Figures 16 and 17.
Figure 17
The example application described above interacts with the architecture through the Open Client APIs. The program flow of this interaction is shown in Figure 18.
Figure 18
The general functions of each of the processing blocks shown in Figure 18 is as follows:
Each of these processing blocks, or functions, is described in the CLIENT.DOC file which accompanies this document. The CLIENT.DOC includes the Microsoft Visual Basic program code which interacts with the Open Client API.
The Microsoft SQL server interacts with the Microsoft Visual Basic program through the Open Client API (Microsoft DB-Library and/or ODBC drivers). The client application may issue either SQL or Stored procedure requests to the SQL Server. SQL statements may be executed for data access, update, or deletion without any programming necessary at the server. Stored procedures may be written to add server-based intelligence to the server which can be executed by a client application request or by a SQL Server database trigger.
A stored procedure may also issue requests to other servers by issuing SQL, SP, or RPC commands. This programmability allows the SQL Server to initiate server to server interoperability to any Microsoft or SYBASE-compatible server including mainframes. Therefore, any Open Client application or SQL Server may interoperate with any other Microsoft or SYBASE-compatible server for two and three tier client/sever architecture processing. Please note that the Open Client is also available on IBM and Unisys mainframes to allow mainframe-based programs to issue SQL, SP, or RPC requests to any server.
In the programming example, the Microsoft SQL Server interacts with the Microsoft Visual Basic program via SQL. The SQL Server also includes a Stored Procedure which issues an RPC request to the mainframe to update the local product database from the mainframe.
The server programs which are activated by RPCs interact with the Open Server Libraries. The mainframe program to Open Server interaction and program flow is shown in Figure 19.
Figure 19
Each of the functions shown in Figure 19 perform the following processing:
The file SERVER.DOC contains an example server RPC program which shows the above functions and the Open Server Library calls and interaction.
The typical enterprise environment can meet their emerging IS requirements through the modernization of their legacy programs into a new generation of client/sever applications. Through the Microsoft and SYBASE architecture, new visually-oriented client applications can seamlessly interoperate with all the new or existing application platforms throughout the enterprise.
© 1995 Microsoft Corporation.
THESE MATERIALS ARE PROVIDED "AS-IS," FOR INFORMATIONAL
PURPOSES ONLY.
NEITHER MICROSOFT NOR ITS SUPPLIERS MAKES ANY WARRANTY, EXPRESS
OR IMPLIED WITH RESPECT TO THE CONTENT OF THESE MATERIALS OR THE
ACCURACY OF ANY INFORMATION CONTAINED HEREIN, INCLUDING, WITHOUT
LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE. BECAUSE SOME STATES/JURISDICTIONS DO
NOT ALLOW EXCLUSIONS OF IMPLIED WARRANTIES, THE ABOVE LIMITATION
MAY NOT APPLY TO YOU.
NEITHER MICROSOFT NOR ITS SUPPLIERS SHALL HAVE ANY LIABILITY FOR
ANY DAMAGES WHATSOEVER INCLUDING CONSEQUENTIAL INCIDENTAL, DIRECT,
INDIRECT, SPECIAL, AND LOSS PROFITS. BECAUSE SOME STATES/JURISDICTIONS
DO NOT ALLOW THE EXCLUSION OF CONSEQUENTIAL OR INCIDENTAL DAMAGES
THE ABOVE LIMITATION MAY NOT APPLY TO YOU. IN ANY EVENT, MICROSOFT'S
AND ITS SUPPLIERS' ENTIRE LIABILITY IN ANY MANNER ARISING OUT
OF THESE MATERIALS, WHETHER BY TORT, CONTRACT, OR OTHERWISE SHALL
NOT EXCEED THE SUGGESTED RETAIL PRICE OF THESE MATERIALS.
 |
Click Here to Search TechNet Web Contents | TechNet CD Overview | |
Microsoft TechNet Credit Card Order Form At this time we can only support electronic orders in the US and Canada. International ordering information. |
| Go To TechNet Home Page |
©1996 Microsoft Corporation |  Go To Microsoft Home Page |