NonStop Systems Introduction Abstract This manual gives new users an orientation to HP NonStop Systems by describing their use in zero latency enterprise architectures. The manual introduces zero latency enterprise concepts and components, describes the application integration and development environment and architecture on NonStop systems, and describes basic concepts, terms, and entities in the NonStop environment. Product Version N.A. Supported Release Version Updates (RVUs) This manual supports G06.
Document History Part Number Product Version 5270825-001 N.A.
NonStop Systems Introduction Glossary Index Figures What’s New in This Manual vii Manual Information vii New and Changed Information About This Manual ix Notation Conventions Tables vii ix 1. Introduction The Adaptive Enterprise 1-2 The Zero Latency Enterprise 1-4 The ZLE Architecture 1-7 2.
3. The Application Server Environment Contents 3.
. Transaction Management Contents 5. Transaction Management What Is a TMF Transaction? 5-1 Specifying a TMF Transaction in a Program 5-3 Local and Distributed Transactions 5-4 Audited Files and Audit Trails 5-5 Transaction Commitment 5-7 Transaction Backout 5-8 Volume Recovery 5-10 File Recovery 5-12 TMF Integration With the Application Server Environments and SQL/MX 6.
7. NonStop Server Architecture (continued) Contents 7. NonStop Server Architecture (continued) Parallel Processing for High Performance Easy Expansion of Data 7-12 7-11 Glossary Index Figures Figure 1-1. Figure 1-2. Figure 1-3. Figure 2-1. Figure 2-2. Figure 2-3. Figure 2-4. Figure 2-5. Figure 3-1. Figure 3-2. Figure 3-3. Figure 3-4. Figure 3-5. Figure 3-6. Figure 3-7. Figure 3-8. Figure 3-9. Figure 3-10. Figure 3-11. Figure 3-12. Figure 3-13. Figure 3-14. Figure 3-15. Figure 3-16. Figure 3-17.
Figures (continued) Contents Figures (continued) Figure 4-5. Figure 4-6. Figure 4-7. Figure 5-1. Figure 5-2. Figure 5-3. Figure 5-4. Figure 5-5. Figure 5-6. Figure 5-7. Figure 5-8. Figure 6-1. Figure 6-2. Figure 6-3. Figure 6-4. Figure 6-5. Figure 6-6. Figure 6-7. Figure 6-8. Figure 6-9. Figure 6-10. Figure 6-11. Figure 7-1. Figure 7-2. Figure 7-3. Figure 7-4. Figure 7-5. Figure 7-6. Figure 7-7. Figure 7-8. Figure 7-9.
Contents NonStop Systems Introduction —527825-001 vi
What’s New in This Manual Manual Information NonStop Systems Introduction Abstract This manual gives new users an orientation to HP NonStop Systems by describing their use in zero latency enterprise architectures. The manual introduces zero latency enterprise concepts and components, describes the application integration and development environment and architecture on NonStop systems, and describes basic concepts, terms, and entities in the NonStop environment. Product Version N.A.
New and Changed Information What’s New in This Manual NonStop Systems Introduction —527825-001 viii
About This Manual Notation Conventions Hypertext Links Blue underline is used to indicate a hypertext link within text. By clicking a passage of text with a blue underline, you are taken to the location described. For example: This requirement is described under Backup DAM Volumes and Physical Disk Drives on page 3-2.
Hypertext Links About This Manual NonStop Systems Introduction —527825-001 x
1 Introduction NonStop systems have traditionally been used primarily for online transaction processing applications (applications that keep the database up to date at all times by recording transactions as they occur). What makes NonStop systems unique is their combination of fault tolerance, high performance, and scalability. NonStop servers and software have been very successful in industries in which these attributes are essential to the operation of the business.
The Adaptive Enterprise Introduction There is also a close relationship between availability and scalability. Scalability refers to the ability of an application to grow while maintaining a high level of performance. The internet has demonstrated that the size and complexity of an application directly affect its availability. There are several reasons for this. A large application requires more system components, meaning more things can fail.
The Adaptive Enterprise Introduction changing priorities. As a result, you gain an IT foundation that is an enabler for business change. HP’s Adaptive Enterprise ZLE solutions are aimed at supporting business processes in a real-time manner in order to capitalize on change for a competitive advantage. With ZLE, an enterprise has immediate access to current information throughout the entire enterprise, and can respond appropriately to that information.
The Zero Latency Enterprise Introduction The Zero Latency Enterprise A zero latency enterprise is a company that has removed latency from its operations so that business events that occur anywhere in the organization can immediately trigger appropriate actions across all other parts of the company. In the business sense, latency can be defined as the time required for a transaction to complete and for the results of that transaction to be propagated to all systems and applications where it is needed.
The Zero Latency Enterprise Introduction However, in this case, as the clerk enters the customers credit card number into the company’s credit card system, a message is returned indicating that the purchase is $5.00 over the customer’s credit limit. The clerk, being unaware of the customer’s history with the company, must reject the customer’s credit card. Again, the result is an unhappy customer who deserved much better treatment.
The Zero Latency Enterprise Introduction These systems cannot satisfy the requirements of a zero latency enterprise because: • • • They are fragmented; they offer no single view of the business. The many queries of the different databases required in a zero latency environment reduce performance to unacceptable levels. They are unable to handle the large amount of historical data required for zero latency.
The ZLE Architecture Introduction For a simple example of how ZLE can improve business operations, consider what happens when a customer orders a product over the internet. In the traditional way of linking operational systems, the order application would reach into the credit card system to check the customer’s credit card balance. This could result in latency problems because: • • Interacting with one another in this manner increases the burden on the business systems.
The ZLE Architecture Introduction Looking at Figure 1-3, note that the ZLE framework resembles a wheel, with the various operational business systems at the outer rim and the ZLE hub at the center. The operational systems include all of the existing legacy systems of a business, running applications such as reservation systems, order entry, inventory, and all the other applications required for the operation of the business.
The ZLE Architecture Introduction through multiple screens and processes to obtain the required information. A ZLE system integrates these systems, so that the customer representative can obtain the necessary information through a single interface. The enterprise application integration (EAI) environment includes all the services that enable the business applications running on the operational systems to communicate with each other and with the data store.
The ZLE Architecture Introduction • • Message routing. This allows the ZLE system to get information to and from the business applications that are being integrated. It ensures that information that originates with a particular application is sent to the applications that need it. Workflow. This has to do with managing the flow of a business process as it progresses over time. For example, consider a bank customer who wants to open a new account. There are several steps in this process, including: 1.
The ZLE Architecture Introduction NonStop Systems Introduction —527825-001 1-11
The ZLE Architecture Introduction NonStop Systems Introduction —527825-001 1-12
2 Requirements of ZLE Systems The business environment shown in Figure 1-1 on page 1-5 imposes a formidable set of requirements on a ZLE system.
Data Integrity Requirements of ZLE Systems The ZLE system must be able to update operational data continuously in real time; this requires continuous availability of the data store. Critical business applications cannot afford even a second of data store downtime. Without fault tolerance, computer systems can experience downtime for the following reasons: • • • • A hardware failure such as a processor failure or communications line failure can halt transactions in progress.
Data Security Requirements of ZLE Systems check the customer’s credit card transaction history, including purchases, refunds, and exchanges. The ZLE software would return a recommendation based on its examination of the customer’s history. But the recommendation is only as reliable as the data; any missing or incorrect information in the transaction history could result in an unreliable recommendation.
Consolidated View of All Data Requirements of ZLE Systems performance. Two frequently used measures of performance are response time and system throughput. A widely accepted definition of response time is the elapsed time between user input to a system and the user’s receipt of confirmation that the transaction is complete.
Consolidated View of All Data Requirements of ZLE Systems throughout the enterprise. The data store provides a single, 360-degree view of the customer base and a single view of all operational data. Figure 2-1 on page 2-5 shows how the ZLE data store provides a unified view of data for all applications in an enterprise. Figure 2-1. Consolidated View of Enterprise Data Data store Application Application Application Local data Local data Local data vst006.
Consolidated View of All Data Requirements of ZLE Systems the transaction data to an application running on an IBM system. The data would be routed through the hub, where it would be translated to the proper format and pushed out to the IBM system and any other systems that needed the data. The hub could provide information about a customer’s previous transactions, which could be used to formulate a special offer based on that customer’s preferences.
Current View of all Data Requirements of ZLE Systems customer touchpoints (Web site, wireless device, ATM, point-of-sale device) as they interact with customers, and in response, make recommendation as to what kinds of offers those particular customers are most likely to accept. The recommendations would take into account not just historical data, but data summarizing the customer’s most recent interactions with enterprise systems.
Requirements of ZLE Systems Integration of Existing Operational Environments Integration of Existing Operational Environments A typical large corporation consists of many different application systems. One of the greatest challenges of implementing a ZLE system is that of enabling all these disparate systems to work together. This is especially difficult because these systems were designed by different development teams working without knowledge of each others tools, technologies, and design decisions.
Support for Industry Standards Requirements of ZLE Systems Figure 2-3. Application Integration Data store Integration Application Application Application Local data Local data Local data vst010.vsd The challenge of integrating and providing services for these disparate systems is a difficult one.
Requirements of ZLE Systems Services and Applications the APIs and protocols necessary to ensure that information is delivered to its intended destination. The primary advantage of products such as JMS and MQ Series is that they provide for asynchronous transmission of data, both to and from the hub.
Requirements of ZLE Systems Standard Component Models meet this challenge, HP supports three major application servers for use in ZLE architectures: • • • NonStop Tuxedo NonStop CORBA Java 2 Platform, Enterprise Edition (J2EE) running under BEA WebLogic Server The Java based J2EE platform is the most commonly used today and is discussed in greater detail in Section 3, The Application Server Environment.
Requirements of ZLE Systems Support for Heavy Transaction Volumes and Mixed Workloads Programs built using standard component models are portable: programs developed on other platforms, such as Windows or HP-UX, can easily be ported to run on the NonStop Kernel platform. And programming skills are transferable as well; developers do not need to learn new skills to develop applications for the NonStop Kernel.
Requirements of ZLE Systems Support for Expansion and Growth Support for Expansion and Growth ZLE systems be scalable; that is, must be able to grow and change as the business that uses the system changes. As the business grows or changes, the ZLE system must be able to integrate new applications, standards, and business processes. And it must do so without experiencing any loss of performance.
Requirements of ZLE Systems Decision Support Figure 2-4. Growing ZLE System ZLE framework Operational systems End users NonStop Server NonStop NonStop Server server Services Business growth vst012.vsd In this figure, as the business grows, the ZLE system is expanded to include an additional NonStop server and services.
Requirements of ZLE Systems Decision Support Figure 2-5. Decision Support in a ZLE Framework ZLE hub Operational systems NonStop server Data mining and analysis transactions Local data extraction JDBC (database connectivity) new models NonStop SQL/MX Data warehouse Local data Data store Local data vst014.vsd The following sequence summarizes how ZLE data is extracted for data mining, then routed back to the ZLE system: 1. Customers interact with the ZLE system throughout the day. 2.
Requirements of ZLE Systems Decision Support Daily sales data is tracked and stored in separate operational databases at each site. The data is then gathered and stored in the ZLE data store, and from there it is downloaded to a data mining system where rules are developed predicting the likelihood that customers in particular locations will buy particular products. The rules developed in the data mine are used to determine the amounts of various products to order.
3 The Application Server Environment This section introduces the application servers used in most HP ZLE environments. To provide a better understanding of these application servers, the discussion is subdivided as follows: • • • • Role of the Application Server outlines the role of the application server in the ZLE environment.
The Application Server Environment • Built on NonStop Core Services Managing and monitoring transactional access to the ZLE data store. HP has offered a succession of application server environments over the years. Each has reflected the state-of-the-art technology of the times, and each has provided the availability, scalability, and performance made possible by the underlying NonStop infrastructure: SQL/MP or SQL/MX database, NonStop Kernel operating system, and the NonStop server.
The Application Server Environment Evolution of the Application Server Architecture Figure 3-1. Application Server and Core Services ZLE hub Data integrity: TMF Application server: WebLogic Server NonStop Tuxedo NonStop CORBA Transaction services: TS/MP or Application Server components Operating system services: NonStop Kernel Database access: SQL/MX VST016.vsd Core services Evolution of the Application Server Architecture We now examine the history of the application server architecture at HP.
The Application Server Environment Client/Server Architecture The earliest transaction processing environment was based on an architecture known as requester-server, in which requester processes made requests of server processes. A requester process is conceptually similar to the familiar client process used in today’s architectures, except that the requester resides on the NonStop host rather than on a workstation. In this arrangement, transactions originate from dataentry terminals.
The Application Server Environment Client/Server Architecture the processing power of PCs. Figure 3-3 on page 3-5 illustrates a simple two-tiered client/server arrangement. Figure 3-3. Client/Server Two-Tiered Structure Tier 1 Tier 2 Graphical user interface Host computer Server Client Presentation Business logic and data management VST018.
The Application Server Environment Multi-Tiered Architectures As you will see later, the terms client and server are relative. A server that receives a request from a client can then make a request of another server and, in effect, then becomes a client of that server. The client/server structure made it possible for applications to handle varying workloads and grow in transaction processing capacity as the number of clients increased.
The Application Server Environment Multi-Tiered Architectures Figure 3-4. Client/Server Three-Tiered Structure Tier 1 Tier 2 Graphical user interface Host computer Client Server Business logic Presentation Client Tier 3 Host computer Server Data management VST019.vsd Multi-tiered architectures are commonly used by today’s applications servers, such as WebLogic Server and NonStop CORBA.
The Application Server Environment Multi-Tiered Architectures N-tiered architectures have all of the advantages of two-tiered architectures and also allow: • • • • Easier replacement or addition of GUI interfaces because the data capture is separated from the transaction management functions Consolidation of transaction processing management functions in a host computer while retaining access to legacy applications and databases through a different host computer More modular application programs for eas
The Application Server Environment Application Server Functions Figure 3-5. Multi-Tiered Architecture With Web Server Client Tier Business and Database Tier Java application Client-side presentation NonStop server Business logic Enterprise beans Web Tier Web server Database access Web browser Server-side presentation Servlets or JSP VST020.vsd Today’s application servers provide flexibility in creating arrangements consisting of diverse and geographically distributed client and server platforms.
The Application Server Environment Client Handling Client Handling The client tier runs the presentation portion of an application. The application server provides tools and application programming interfaces (APIs) for developing the client applications and enables the clients to access the server-side applications residing on the NonStop server. The application server environment manages the communications between multiple clients and multiple servers.
The Application Server Environment Server Handling Client applications communicate with server programs, which carry out requests they receive from clients. These servers comprise the middle tiers of the client/server architecture. The following discussion takes a closer look at these servers. Server Handling The server programs perform the business logic and database access functions required by ZLE applications and services.
The Application Server Environment Server Handling Figure 3-7. Server Processes and Communication Paths Application server environment Clients Application Server A Process and link management services Server B Server C VST022.vsd Server programs can be written in any of the high-level languages supported by HP. These include Java, C, and C++. (The specific languages that can be used depend on which application server environment you are using.
The Application Server Environment Server Handling configure two or more server classes for requests of different lengths. By separating the shorter requests from the longer requests, response time stays fast and consistent at all times. Online Reconfiguration It is sometimes necessary to reconfigure an application.
The Application Server Environment Server Handling Using the capabilities of the application server, the administrator can reconfigure clients and servers without stopping online service to users. (Note that depending on the application server in use, there may be some restrictions on the reconfigurations that can be done online). Effective Use of Multiple Processors The client/server architecture makes effective use of multiple processors.
The Application Server Environment Server Handling Figure 3-10. Expansion of Applications NonStop server Client apps Process and link management services Processor 1 Server A Database A Processor 2 Server B Database B Processor 3 Server C Client apps Database C Copy of Server A VST025.
The Application Server Environment Server Handling Figure 3-11. Distributed Processing Network node Client apps Process and link management services Processor 1 Server A Database A Processor 2 Server B Database B Network node Processor 3 Client apps Process and link management services Server C Database C VST026.vsd The application server components manage the communications links between the clients and servers and between the servers on different nodes.
The Application Server Environment Server Handling Figure 3-12. Clustered Servers Clients Network node Enterprise beans Application server instance Processor 1 Enterprise beans Processor 2 Application server instance Replicated servers Network node Enterprise beans Processor 3 Application server instance VST027.vsd This figure shows the clustered servers as they might appear in an application server environment such as WebLogic Server.
The Application Server Environment The HP Application Servers The HP Application Servers HP provides several application servers that are well-suited for use in ZLE systems. They are presented in the order in which they were introduced by HP. Each of these application servers represents an advance in features and capabilities over the previous offering.
The Application Server Environment NonStop CORBA The Tuxedo API provides distributed transaction-processing capabilities and transparent access to the fundamental benefits of the SQL/MX database and NonStop server: • • • • Scalability Fault tolerance 7X24 availability Easy manageability NonStop Tuxedo supports clients on many different platforms, including Windows, HP/UX, and Sun.
The Application Server Environment NonStop CORBA Figure 3-13. Distributed Computing Environment Tier 1 - Clients Tier 2 - Host computers with business objects Tier 3 - Host computers with data access objects Business objects Database objects Business objects Database Business objects Database objects Database vst129.vsd A program makes its request for access to objects through a component called the Object Request Broker (ORB).
The Application Server Environment NonStop CORBA these tasks are all handled by the CORBA software. Developers simply call the appropriate functions. CORBA provides many benefits, including: • • • Coexistence with existing systems. Legacy applications can be encapsulate in a C++ or Java “wrapper” that defines a CORBA-compliant interface to the legacy code. This enables the legacy applications to interoperate with new applications, thus protecting your investment in existing systems.
The Application Server Environment WebLogic Server and the J2EE Platform interface an object presents to clients. IDL is completely independent of the language used to implement the objects and clients. An IDL compiler translates the IDL source statement to the appropriate language. NonStop CORBA is the HP implementation of the Object Management Group (OMG) CORBA specification.
The Application Server Environment WebLogic Server and the J2EE Platform Figure 3-15. WebLogic Server in the Enterprise Clients WebLogic Server Application components Services Databases vst034.
The Application Server Environment WebLogic Server and the J2EE Platform WebLogic Server is Built Around Java Technology WebLogic Server implements the Java 2 Platform, Enterprise Edition (J2EE) 1.3 platform specification. J2EE is a component-based, platform-independent architecture that makes applications easy to write because business logic is organized into reusable components. In addition, the J2EE server provides underlying services essential for server applications.
The Application Server Environment WebLogic Server and the J2EE Platform Figure 3-16. J2EE Multi-Tiered Architecture Client tier Java program J2EE application Business and database tier NonStop server Business Logic Web tier J2EE application Web server Enterprise beans Database access Web browser Enterprise beans Database Servlets or JSP VST036.vsd As the figure shows, a J2EE application consists of: • • • • Client components that constitute the client presentation layer.
The Application Server Environment WebLogic Server and the J2EE Platform J2EE Applications Are Composed of Enterprise Beans A key component in the J2EE architecture is the enterprise bean. An enterprise bean is a module of Java code that contains business logic and is written according to the Sun Microsystems Enterprise JavaBean (EJB) specification.
The Application Server Environment WebLogic Server and the J2EE Platform A J2EE client can be a web client or an application client. Both types of clients provide a user interface, such as a graphical user interface, and access enterprise beans that perform the business logic on the business tier. The container provides an interface between clients and enterprise beans, and manages the execution of the Beans.
The Application Server Environment WebLogic Server and the J2EE Platform Figure 3-18. WebLogic Server Interoperability With Other Application Servers NonStop server WebLogic Server NonStop Tuxedo services WTC EJB EJB NojStop CORBA objects IIOP EJB Pathway servers JPathsend VST039.
The Application Server Environment WebLogic Server and the J2EE Platform Figure 3-19. Transmuter Application Running in WebLogic Server SAP client applications Integration server NonStop server SAP adapter WebLogic Server JMS adapter Loader bean Transmuter Web server Web application Data cleansing service Requestresponse Servlet Data store Requester bean VST100.
The Application Server Environment • • WebLogic Server and the J2EE Platform A servlet that receives requests for documents from client applications A requestor bean that processes the requests and passes them to the Transmuter program A typical sequence of events for incoming data for this application might be as follows: 1. SAP applications send data, in the form of SAP IDocs, to the integration server. 2.
The Application Server Environment Choosing an Application Server Environment WebLogic Server Applications Are Easy to Manage WebLogic Server provides a powerful Web-based Administration Console that provides system administrators with the tools they need to manage their applications. The Administration Service, an implementation of the Java Management Extension standard, provides facilities for managing WebLogic Server resources.
The Application Server Environment Choosing an Application Server Environment that framework’s API (for example, Tuxedo-based applications work best in a NonStop Tuxedo integration framework)A.
4 The Relational Database Management System The SQL/MX relational database management system is used by the transaction processing environments described in Section 3, The Application Server Environment (NonStop CORBA, NonStop Tuxedo, and WebLogic Server). SQL/MX also provides facilities, typically used for decision support and data mining operations, for querying a database directly from a workstation, without going through an application server environment.
The Relational Database Management System Easy Navigation Between Relational Tables applications. These applications were easy to develop and use, but they were not powerful enough for a high-volume production environment. To achieve high performance, programmers developed transaction processing applications based on nonrelational database management systems.
The Relational Database Management System Logical Views of Data Figure 4-1. A SQL/MX Relational Database JOB TABLE JOBCODE JOBDESC 100 MANAGER 250 ASSEMBLER ••• 900 ••• DEPARTMENT TABLE DEPTNUM 1000 DEPTNAME MGR RPTDEPT LOCATION FINANCE 23 9000 CHICAGO 1500 PERSONNEL 213 1000 CHICAGO ••• ••• ••• ••• ••• CHICAGO EMPLOYEE TABLE EMPNUM FNAME LNAME DEPTNUM JOBCODE SALARY 1 ROGER GREEN 4000 100 75500.00 23 ••• JERRY HOWARD 1000 200 37000.
The Relational Database Management System Logical Views of Data Figure 4-2. A Logical View Derived From Two Tables EMPLOYEE TABLE EMPNUM FNAME LNAME DEPTNUM JOBCODE SALARY 1 2 3 ••• ROGER GREEN 4000 100 JERRY HOWARD 1000 200 37000.00 ••• ••• ••• ••• ••• 568 3500 JESSICA CRINER DEPARTMENT TABLE DEPTNUM DEPTNAME MGR 300 39500.00 75500.
The Relational Database Management System High-Speed Indexes for Faster Access to Data High-Speed Indexes for Faster Access to Data Each row of a SQL/MX table is identified by a column or group of columns known as the primary key. The primary key value must be unique for each row, so that SQL/MX retrieves data from only that row when the primary key value is specified in a query.
The Relational Database Management System Powerful Database Language Powerful Database Language SQL/MX implements the ANSI-standard SQL database language to offer simple, powerful commands for both a data definition language and a data manipulation language. The data definition language creates, alters, and deletes the definitions of SQL/MX objects like tables, views, and indexes. This language includes the statements CREATE, ALTER, and DROP as well as other statements.
The Relational Database Management System Conversational Interface can contribute to these goals. How will the CEO’s staff find the names of the employees in each department in order to contact them? Instead of creating and maintaining elaborate lists that show who is in each department, the CEO’s staff can query the EMPLOYEE table as shown in Figure 4-3 on page 4-6 to get a report showing which people are in a given department.
The Relational Database Management System Programming Interface Figure 4-4 on page 4-8 shows the relationship between the end user and the MXCI interface. The user submits a query to MXCI and receives output data from MXCI at the display screen or printer. Figure 4-4. SQL/MX Conversational Interface (MXCI) MXCI VST047.
The Relational Database Management System SQL/MX and Applications binds the host language portion and the SQL language portion of the program into a single object file. The program is ready for use in a production environment. To compile a Java source program containing embedded SQL statements, you run the SQLJ translator. SQLJ allows you to embed static SQL statements directly in a Java program.
The Relational Database Management System Workstation Access to SQL/MX Figure 4-5. SQL/MX in Database Applications Client program Server program The server program contains SQL/MX statements. VST048.vsd Note that you can develop applications without using SQL/MX, and you can develop SQL/MX applications that do not run under control of an application server environment (such as the NonStop CORBA, NonStop Tuxedo, or WebLogic Server environment).
The Relational Database Management System Workstation Access to SQL/MX Figure 4-6. Workstation Access to SQL/MX Adjust_Salary Graphical user interface Employee name: Percentage increase: OK Cancel NonStop host Client program with ODBC calls NonStop MXCS SQL/MX VST049.vsd NonStop MXCS allows client applications developed for the Microsoft Open Database Connectivity (ODBC) interface to access SQL/MX. Microsoft ODBC is an API for PCs running in a Windows environment.
The Relational Database Management System Portability of SQL/MX Applications Portability of SQL/MX Applications SQL/MX applications are applications that contain embedded SQL statements within host language code. SQL/MX applications are easy to port to the systems of other vendors because they are written in languages that conform to industry standards: • • Embedded SQL is based on ANSI-standard and ISO-standard SQL. HP COBOL, C, and C++ are based on the ANSI standards for those languages.
The Relational Database Management System Data Distribution The database shown in this figure illustrates the following features of SQL/MX partitioned tables: • • • Local users can add, change, or delete data in any local partition of the database. For example, the user on the system A node could change the address of customer 100 or customer 2600. Local users can add, change, or delete data on any remote partition of the database.
The Relational Database Management System Active Data Dictionary Active Data Dictionary SQL/MX uses a special set of tables to record the definitions of all objects that belong to a particular database. This set of tables is called the SQL catalog. The catalog records the definitions of all the database tables in a TABLES table, the definitions of views in a VIEWS table, the definitions of indexes in an INDEXES table, the definitions of programs that access SQL objects in a PROGRAMS table, and so on.
The Relational Database Management System ORDM Approach Because decision support applications often involve very complex queries against large data warehouses, support for decision support also means supporting optimal performance and database manageability. Performance is crucial because of the size of the data warehouses and the time-consuming nature of many decision support queries. SQL/MX is designed to optimize performance for decision support applications.
The Relational Database Management System NonStop Systems Introduction—527825-001 4- 16 ORDM Approach
5 Transaction Management So far we have seen the following major components of the NonStop application server environment: • • The application servers coordinate the execution of ZLE applications and provide for communication between client programs and server programs. The SQL/MX relational database management system retrieves and updates data in relational database tables on behalf of applications and end users. Another major component of the NonStop application server environment is TMF.
Transaction Management What Is a TMF Transaction? Figure 5-1 on page 5-2 shows how a failure during the processing of a money-transfer transaction could cause the database to become inconsistent. In this example, the customer transfers $1000 from a $5000 savings account to a $50 checking account. When the transaction ends, the customer should have $4000 in the savings account and $1050 in the checking account. Figure 5-1.
Transaction Management Specifying a TMF Transaction in a Program $1050. To summarize, the purpose of TMF is to enable transactions to transform the database from one consistent state to another consistent state. Specifying a TMF Transaction in a Program How do programmers take advantage of TMF benefits in applications? They simply bracket the program statements that constitute a transaction with a pair of statements that indicate the beginning and end of the transaction.
Transaction Management Local and Distributed Transactions Local and Distributed Transactions TMF can manage transactions whether they are local or distributed. Whatever the complexity or geographic scope of the transaction, TMF treats it as a single unit of work and protects the consistency of all databases involved in the transaction. A local transaction updates records at a single location.
Transaction Management Audited Files and Audit Trails This distributed transaction is a typical TMF transaction. It begins with a BEGIN TRANSACTION statement, performs reads and writes at multiple nodes, and concludes with an END TRANSACTION statement. This bracketed unit of work is complete when the END TRANSACTION statement is executed successfully by the program.
Transaction Management Audited Files and Audit Trails Figure 5-3. Audited Files and Audit Trails Order entry system databases Mirrored audit trail Update #1 Locked Sales office Begin Before After Update #2 Locked Headquarters Update #3 Locked Warehouse VST058.vsd The audit trail shown in Figure 5-3 is a separate group of disk files that contain information about each TMF transaction against audited database files.
Transaction Management Transaction Commitment transaction with the assurance that no other transaction could have altered the same records while this transaction was in progress. Transaction Commitment Three things happen while a transaction is in progress: • • • TMF causes the operating system to lock all records affected by the transaction. The transaction performs updates by changing the values of fields in existing records, deleting existing records, or adding new records.
Transaction Management Transaction Backout Figure 5-4. Commitment of a Successful Transaction Databases Mirrored audit trail Begin Unlocked Sales Office Before After End End Transaction Unlocked Headquarters Unlocked Warehouse VST059.vsd What has really happened to the database now that the transaction is successfully completed? After transaction commitment, all the changed records are changed permanently. TMF can no longer undo the changes.
Transaction Management Transaction Backout Figure 5-5. Transaction Backout Databases Mirrored audit trail Begin Stock shortage Unlocked Sales Office End Transaction Recover volumes. Report shortage. Log additional orders until stock replenished. Before After Unlocked Headquarters Unlocked Warehouse VST060.
Transaction Management Volume Recovery Similarly, assume that before the transaction began, the accounts-receivable record for the customer showed that the customer owed a total of $1500 for all orders placed to date. After the current transaction recorded a new order of $500 in the sales-order database, it updated the accounts-receivable record to show that the new total owed by the customer stands at $2000.
Transaction Management Volume Recovery accumulate in cache (a high-speed area of main memory) before writing the whole set of records to disk in a single physical update operation. This write-in-cache procedure significantly reduces the number of writes to audited files and keeps performance high. The only problem is that when a system failure occurs, some changed records in cache might not yet be changed on disk.
Transaction Management File Recovery Figure 5-6. TMF Volume Recovery Databases Sales office Audit trail Headquarters Audit trail Warehouse power outage Warehouse power restored Audit trail VST061.vsd File Recovery You have seen that TMF volume recovery provides a quick, handy solution to the problem of multiple transaction failures resulting from a hardware failure. But in certain cases, volume recovery cannot be used to recover from the effects of a hardware failure.
Transaction Management File Recovery Figure 5-7. TMF File Recovery Databases Online Dump Audit Trail Dumped Catastrophe! Dual Media Failure Sales Office Audit Trail Headquarters Audit Trail Last Online Dump Audit Dump Tape Warehouse Warehouse Database Restored Audit Trail VST062.vSd Audit dumps are tape or disk copies of the disk files containing the TMF audit trails. The operations staff dumps the audit trail files to tape periodically to preserve space on the audit trail disk.
Transaction Management TMF Integration With the Application Server Environments and SQL/MX after-image shows a value of 330. The before-image for part B9 shows a value of 70 in the QOH field, while the after-image shows a value of 65. The archive copy of the warehouse database (the copy restored from the last online dump) does not reflect the changes made by the three transactions because the changes occurred after the last online dump.
Transaction Management TMF Integration With the Application Server Environments and SQL/MX Figure 5-8 on page 5-16 shows a typical NonStop environment based on TS/MP, SQL/MX, and TMF: • • • • The client and server are components of a NonStop Tuxedo application based on TS/MP. The data dictionary and the database containing business data are components of SQL/MX.
Transaction Management TMF Integration With the Application Server Environments and SQL/MX Figure 5-8. NonStop Application Environment: TS/MP, SQL/MX, and TMF Update Salary Bonus Rate: Accept/display data Salary Range High: Low: OK Cancel Send requests Client program Return replies Update data Server program Business data Select data Data dictionary ... EXEC SQL DECLARE salary_bonus CURSOR FOR SELECT empnum, salary FROM employee WHERE salary BETWEEN :num_low AND :num_high FOR UPDATE OF salary; ..
6 The NonStop Kernel Sections 3, 4, and 5 examined the NonStop application system environment and its major components: • • • • Application development and integration Transaction control SQL/MX relational database management TMF transaction management You saw that this environment provides powerful support for your applications by automating many functions that you would otherwise need to program explicitly.
The NonStop Kernel Application Services processing. The core services (TS/MP, SQL/MX, and TMF) all support processes in either environment. Figure 6-1. NonStop Kernel Application Environments Portable applications Guardian applications OSS environment: Guardian environment: Tools Tools Utilities Utilities Application program interface Application program interface NonStop Kernel VST070.vsd Applications can be created and executed in either environment.
The NonStop Kernel • • • Application Services Manage memory such that when a process needs more memory, it can request a block of memory; when the process is finished with the memory, it can release it back to the operating system Debug programs at both a high (symbolic) level and a low (machine) level Compile and execute programs Applications written for the Guardian environment fully support the NonStop principles.
The NonStop Kernel Network Operations path to the file or directory using the standard UNIX notation. For example, the notation /dev/src/fileb means that: • • • the file named fileb is in directory src. src is a subdirectory of directory dev. dev is a subdirectory of the root directory. The OSS environment has its own command interpreter, a version of the standard UNIX Korn shell.
The NonStop Kernel Network Operations This burden occurs because the networking software requires the computer to focus on the outside world, while the operating system requires it to focus on local peripheral devices. Two software systems are working at cross-purposes in the same computer. By contrast, the NonStop networking environment is a simple extension of the local operating system. Each node of the network is a computer that was designed for networking from the outset.
The NonStop Kernel Cooperative Systems possible for a process running in any processor to access system resources in any other processor or input/output location. Cooperative Systems As a result of the unique hardware and software design shown in Figure 6-3 on page 6-5, a stand-alone NonStop system does not view itself as a monolithic entity. Instead, it views itself as a group of processors that function as a single system.
The NonStop Kernel Distribution of Control one processor might need to communicate with a workstation attached to another processor and with a disk drive controlled by a disk process in yet another processor. Figure 6-4 on page 6-7 illustrates the requirements of the situation. The user process in Processor 1 needs to communicate with a terminal process in Processor 2 and a disk process in Processor 0.
The NonStop Kernel Requesters and Servers in the Operating System Requesters and Servers in the Operating System System processes cooperate through the message system in a manner similar to the way that application clients and servers cooperate in a client/server application. A system message is a bidirectional exchange of information that includes the following steps: 1.
The NonStop Kernel Removal of Physical Boundaries Figure 6-5 on page 6-9 shows requester-server relationships among process A, the processor monitor, and the disk process during new process creation. Figure 6-5. Requesters and Servers in the Operating System Create a process Allocate disk space (Server) A (Requester) Processor monitor (Server) (Requester) Disk process VST076.
The NonStop Kernel Easy Transition to Distributed Processing name, the operating system can determine the server’s actual physical location and send messages from the requester to the server. Disk drives, tape drives, and transaction entry devices (workstations, PCs, terminals, and so forth) are all associated with I/O processes. The message system provides an easy way for any requester process in the system to address and access any I/O server process and use its devices.
The NonStop Kernel Easy Transition to Distributed Processing In Figure 6-7 on page 6-11, the same processes are spread over two network nodes (system A and system B), but they continue to communicate through the distributed message system and Expand software. Figure 6-7.
The NonStop Kernel Support for Fault Tolerance ServerNet fabrics in the stand-alone system and over external communications lines in the network. Support for Fault Tolerance You have seen that the message system blurs the boundaries between the processors in a NonStop system and enables multiple processors to function as a single system. A process running in any processor can communicate with a process in any other processor by using the message system to send requests and receive replies.
The NonStop Kernel Process Pairs 3. If a processor notes that two time periods have passed without the receipt of an “I’m alive” message from some other processor, it compares notes with other running processors and collectively they declare the “quiet” processor to be down. 4. The other processors then take over the workload of the failed processor. Figure 6-8 on page 6-13 shows the transmission of “I’m alive” messages by the message system in a three-processor system. Figure 6-8.
The NonStop Kernel Process Pairs messages to its backup in Processor 1. If Processor 0 fails, the primary disk process fails. Processor 1 then informs the backup disk process that Processor 0 has failed, and the file system automatically reroutes requests to this disk process, which has become the new primary process.
The NonStop Kernel Support for System Expandability Support for System Expandability In addition to promoting fault tolerance, the message system supports the expansion of a NonStop system as it grows to match business growth. When a successful user application incorporates more functions or adds new users, it might require additional processing power.
The NonStop Kernel Fault-Tolerant Expand Operation communications lines. In short, the Expand software supports the message system in a network environment. Because it is based on the inherent networking capabilities of the message system, the Expand networking software is a compact, efficient body of code that works in close cooperation with the system code.
The NonStop Kernel Transparent Access to Network Resources Figure 6-10. Best-Path Routing in an Expand Network B 56000 bps 14400 bps A D 28800 bps 14400 bps C 9600 bps E VST081.vsd Transparent Access to Network Resources You have seen that the NonStop Kernel was specifically designed to blur processor boundaries in a local multiple-processor system. The file system and message system enable a process running in one processor to access the resources of any other processor in the system.
The NonStop Kernel Transparent Access to Network Resources Figure 6-11 on page 6-18 shows that authorized users can carry out operations in an Expand network as easily as in a local system. Users can access network resources using the same commands that they would use to access resources on the local system. The only difference is that a node specifier must be added to a remote program, file, or device name. Figure 6-11.
The NonStop Kernel Transparent Access to Network Resources NonStop Systems Introduction—527825-001 6- 19
The NonStop Kernel Transparent Access to Network Resources NonStop Systems Introduction—527825-001 6- 20
7 NonStop Server Architecture The last section, Section 6, The NonStop Kernel, showed that the NonStop Kernel supports the NonStop application server environment with a powerful, reliable message system. The NonStop Kernel and its Expand network extension constitute the software architecture of NonStop servers. This section examines the hardware architecture of NonStop servers and considers how this architecture supports the execution of programs in the NonStop application environment.
NonStop Server Architecture Fault Tolerance of NonStop Servers Figure 7-2. Hardware Architecture of NonStop Servers Processor 0 Processor 1 Processor 2 Processor 3 Dual ServerNet fabrics ServerNet adapter ServerNet adapter ServerNet adapter Disks VST091.vsd As shown in Figure 7-2, input/output components also tap into the ServerNet fabrics. Quite commonly, this tapping into the ServerNet fabrics occurs through ServerNet adapters.
NonStop Server Architecture Fault Tolerance of NonStop Servers Significantly, the hardware is designed to provide two forms of continuous availability when an individual component fails: • • Continuous execution of processes Continued access to databases Figure 7-3 on page 7-3 illustrates both of these design goals. Figure 7-3. Continuous Availability of a NonStop Server Processor 1 Processor 0 Primary process Checkpoint message s Backup process Mirrored disk volumes Volume s VST092.
NonStop Server Architecture Interconnected Multiple Processors the other disk. For more information on mirrored disks, see Mirrored Disk Volumes on page 7-8. The following discussions take a closer look at the structure of the ServerNet fabrics and the ways that they ensure the continuous availability of processes and databases. Interconnected Multiple Processors A NonStop system consists of 2 to 16 processors. Figure 7-4 on page 7-4 shows a simple four-processor configuration. (For now, I/O is omitted.
NonStop Server Architecture Dual Access Paths for I/O duplication of ServerNet fabrics enables processes to carry out their work by means of a continuous exchange of messages with other processes in the system. The ServerNet interface, shown in each processor, serves to convert messages coming from the message system into chains of ServerNet packets or, conversely, to convert chains of ServerNet packets into messages for the message system.
NonStop Server Architecture Dual Access Paths for I/O Figure 7-5. Dual Data Paths to I/O Hardware X Processor 0 Processor 1 ServerNet interface ServerNet interface Y X Y 1 2 3 ServerNet Y fabric SAC ServerNet addressable controller (SAC) SAC SCSI bus SAC ServerNet addressable controller (SAC) SAC ServerNet X fabric 4 5 6 VST094.
NonStop Server Architecture Low-Latency Routing a failure occurs that disables one of the pair of SACs or one of the paths, continuous communication can continue through the other path and SAC. For the second way, notice the four SACs connected to routers 3 and 6. These SACs are dual-ported, meaning that they connect to both the X fabric and the Y fabric. Dual porting provides fault tolerance by ensuring that if one path fails, continuous communication can continue through the other path.
NonStop Server Architecture Mirrored Disk Volumes Figure 7-6. Wormhole Routing Any input to any output Full duplex VST095.vdd Mirrored Disk Volumes Disk drives represent the most critical class of I/O devices in a NonStop server, because applications are constantly accessing and updating the databases that reside on disk drives.
NonStop Server Architecture Multiple Power Sources and Online Repair Multiple Power Sources and Online Repair One threat to continuous system operation lies outside the system itself: the danger of a power failure. No system is immune to a total power failure, but the NonStop server contains a number of mechanisms to minimize the effects of power failures.
NonStop Server Architecture ServerNet Clustering for Availability and Performance However, if a word of main memory gets an uncorrectable error, the operating system immediately halts the processor. The remaining processors notice the absence of “I’m alive” messages, declare the processor to be down, and take over for the down processor. ServerNet Clustering for Availability and Performance You have seen how the processors of a NonStop server communicate with each other over dual ServerNet fabrics.
NonStop Server Architecture Cost-Effective System Expansion ServerNet clusters allow multiple multiprocessor systems to work together and appear to client applications as one large processing entity. Up to 24 servers can be joined in a cluster. ServerNet clustering provides several benefits, including: • • • • Performance.
NonStop Server Architecture Easy Expansion of Data By contrast, adding another processor in a shared-memory configuration does not result in a commensurate increase in processing power, because all the processors are contending for the same memory resources. Figure 7-8 on page 7-12 shows that the performance of a NonStop server tends to increase at a linear rate as more processors are added. Figure 7-8.
NonStop Server Architecture Easy Expansion of Data database. Because a database file on one disk volume can be only so large, the utility will run up against the maximum file size limit before very long. The SQL/MX data management systems solve the problem of rapid data expansion by supporting a file partitioning mechanism. You can specify that a file reside entirely on one disk volume, or that it be partitioned across several disk volumes on the same system or on different systems.
NonStop Server Architecture • Easy Expansion of Data Records for authors Q-Z reside on the third branch system. Each of the three branches of the catalog department is responsible for maintaining the range of records in its local partition and needs to go across the network only when it needs to check records in another partition. The end result of the partitioned database is improved response time for all users and higher total system throughput of record updates on all three systems.
Glossary adapter. A program used in ZLE architectures to enable the operational business applications to communicate with the applications and services on the ZLE hub. Adapters translate data and transaction requests from the native format of the sending application to the format required by the ZLE hub and vice versa. API. See application programming interface (API). application. A complete set of programs that perform a function. application programming interface (API).
Glossary client client. An application program that requests services to be performed. In the client/server model, the client program generally resides on a workstation or personal computer and requests services of a server program on a NonStop system. client/server model. A model for distributing applications. In general, but not always, the client process resides on a personal computer or workstation and the server process resides on a more powerful server machine.
Glossary database management system (DBMS). transactions are complete. Database consistency is defined by the application, which establishes the values and relationships of database fields and records. database management system (DBMS). A product, such as SQL/MX, that serves as the interface between a user or program (for example, a server program on a NonStop system) and the database. Among its many functions, the DBMS controls access to and organization of data within the database. data integrity.
Glossary Enterprise Application Integration (EAI) Enterprise Application Integration (EAI). Technology employed by a ZLE framework to transmit information between business applications and the ZLE data store. enterprise bean. A software component that implements a business task or business entity and resides in an EJB container. Enterprise JavaBeans (EJB). A standard component model for a Java server-side framework for application servers.
Glossary HP NonStop Kernel HP NonStop Kernel. The operating system for NonStop systems. The operating system does not include any application programming interfaces. IIOP. Internet Inter-ORB Protocol. A protocol used for communication between CORBA object request brokers. interoperability. The ability to have applications and computers from different vendors (heterogeneous systems) work together on a network.
Glossary local area network (LAN). local area network (LAN). A set of computers and other electronic devices linked to create an interoffice or intersite network. message system. See NonStop Kernel message system. mirrored disk. A pair of identical disk drives that are used together as a single logical volume. One drive is considered the primary, and the other is called the backup or mirror. Each byte of data written to the primary drive is also written to the mirror drive.
Glossary object developed by BEA Systems as well as the benefits provided by the NonStop core services: SQL/MX, TS/MP, and TMF. object. The principle building block of object-oriented programs. Each object is a programming unit consisting of data and functionality. See also CORBA object. object-oriented. A software design method that models the characteristics of abstract or real objects using classes and objects. object request broker (ORB).
Glossary power-fail interrupt power-fail interrupt . A processor function that interrupts the current instruction stream, when a power failure occurs, in order to invoke a power-fail interrupt handler. This interrupt handler provides an orderly shutdown sequence that preserves the existing state of processor memory for subsequent resumption of operation when power is restored. See also ride-through power backup. primary process. The currently active process of a process pair managed by the NonStop Kernel.
Glossary requester-server model. requester-server model. A model for application design that divides the tasks of data input, data manipulation, and data output between two basic types of processes: requesters and servers. A requester sends a request to a server. The server performs the request and then replies to the requester. The requester and server can reside on the same processor or on different processors in an Expand network. See also requester and server. response time.
Glossary ServerNet cluster portion of a processor multifunction (PMF) unit, an I/O multifunction (IOMF) unit, or a ServerNet adapter. ServerNet cluster. A network of servers (nodes) connected together using the ServerNet protocol for interprocessor communication across a cluster and within its nodes. A ServerNet cluster offers linear system expansion beyond the 8-processor or 16-processor limits of a single server, achieving comparable speeds for internal and external ServerNet communication.
Glossary Subsystem Control Facility (SCF) Subsystem Control Facility (SCF). The interactive utility for configuring, monitoring, and controlling networking resources on a NonStop system. System area network (SAN). A network of processors within a single system, as contrasted with a network of many systems in an Expand network. The system area network provides the communication path used for interprocessor messages and for communication between processors and I/O devices in a single system.
Glossary volume recovery. volume recovery. A database recovery mechanism used by TMF to return a database to its most recent consistent state. TMF undoes any changes that were made to the database by transactions that were not completed. WebLogic Server. See BEA WebLogic Server. wormhole routing. A form of message routing whereby each part of a message is transmitted independently along a route and one part can be forwarded to the next node before the following parts are received.
Index A Adapters, in a ZLE framework 1-9 Adaptive Enterprise 1-2 API see Application programming interface (API) Application development in J2EE environment 3-24 in NonStop CORBA environment 3-19 in NonStop Tuxedo environment 3-18 Application integration frameworks 2-10 Application programming interface (API) Guardian 6-1 Java Transaction 3-27 JPathsend 3-27 ODBC 4-11 OSS 6-1 Tuxedo 3-18 WebLogic Tuxedo Connector (WTC) 3-27 Application server 3-18/3-32 functions of 3-9 NonStop CORBA 3-19 NonStop Tuxedo 3-18
Index D Core services 3-2 Cursors, in SQL/MX 4-7 C++ language 3-12, 3-21, 4-8 D Data integrity of 2-2, 5-2 security of 2-3 Data Definition Language (DDL), SQL/MX 4-6 Data dictionary, SQL/MX 4-14 Data enrichment 2-6 Data integrity provided by TMF 5-2 required by ZLE systems 2-2 Data manipulation language, SQL/MX 4-6 Data mining support in SQL/MX 4-14 support in ZLE 2-14 Data security required by ZLE systems 2-3 Data store characteristics of 2-4/2-7 defined 1-8 Data transformation, in a ZLE framework 1-9 D
Index F F J Fabric, ServerNet see ServerNet fabric 6-5 Failover, of clustered servers 3-16 Fault tolerance for I/O 7-6 in NonStop servers 7-2/7-10 required by ZLE systems 2-1 Files audited 5-5 partitioned see Partitioned files recovery of 5-1, 5-12 J2EE 1-10 and ZLE 3-24 multi-tiered architectures in 3-24 use by WebLogic Server 3-24 Java language 3-12, 3-21, 3-24, 4-8 technology in WebLogic Server 3-24 Java 2 Platform, Enterprise Edition (J2EE) see J2EE Java Database Connectivity (JDBC) 3-27, 4-9 Java
Index N Memory cache 5-10 manager 6-6 Message routing, in a ZLE framework 1-10 Message system 6-9, 7-5 Messages checkpoint 6-12 interprocess 6-15 Messaging middleware 2-9 Mirrored disks 5-6, 7-3, 7-8 Modular expandability processing capacity and I/O 6-5 supported by message system 6-15 system and network 7-11 Monitor process 6-6 Multifunction I/O board 7-2 Multiple processors in client/server architectures 3-14 Multi-tiered architecture 3-23 MXCI 4-7 MXCS see NonStop Connectivity Services (MXCS) N Networ
Index Q Portability (continued) of J2EE applications 3-24 of OSS applications 6-3 of SQL/MX applications 4-12 Primary process 6-12, 6-13, 7-3 Process management in client server architectures 3-11 Process pairs 7-3 Processes backup 6-12 disk 6-8 primary 6-13 user 6-6 Processing, distributed 3-4 Processing, parallel 7-11 Processors independence of 6-5 multiple 6-5 Programming interfaces SQL/MX 4-8 Q Queries, SQL/MX 4-5, 4-6, 4-7 R Recovery file 5-1 volume 5-1, 5-10/5-11 Remote Database Facility (RDF) 5-1
Index T Servlets 3-27 SQL catalog 4-14 SQL language 4-1, 4-6 SQL Server, Microsoft 4-11 SQL Server, Sybase 4-11 SQLJ translator 4-9 SQL/MX 4-1/4-14 cursors in 4-7 data dictionary 4-14 data manipulation language 4-6 documentation facility 4-14 in applications 4-9 indexes 4-5 integration with the operating system 4-12 integration with TMF 5-14 objects 4-6, 4-14 performance 4-1, 4-12 portability of applications 4-12 queries 4-5 reports 4-8 utilities 4-12 workstation access 4-10 SQL/MX programming interface 4
Index Z WebLogic Server (continued) multi-tiered architecture 3-23 WebLogic Tuxedo Connector API 3-27 WLS see WebLogic Server Workflow, in a ZLE framework 1-10 Workstations access to SQL/MX databases 4-10 Wormhole routing 7-7 Write-in-cache procedure 5-11 Z Zero latency enterprise applications 1-10 architecture 1-7 defined 5-1 standard component models used in 2-11 to describe a computer system 1-4 ZLE see Zero latency enterprise ZLE data store 1-8 ZLE hub 1-8 NonStop Systems Introduction—527825-001 Ind
Index Z NonStop Systems Introduction—527825-001 Index -8
