NonStop Systems Introduction for H-Series RVUs Abstract This manual gives new users an orientation to HP NonStop™ systems by describing their use in real-time enterprise solutions. Real-time enterprise solutions are based on zero latency enterprise frameworks.
Document History Part Number Product Version 540083-001 N.A.
NonStop Systems Introduction for H-Series RVUs Glossary Index What’s New in This Manual vii Manual Information vii New and Changed Information About This Manual ix Who Should Use This Manual What Is In This Manual x Notation Conventions x Figures Tables vii ix 1. Introduction The Adaptive Enterprise 1-2 The Real-Time Enterprise 1-4 The ZLE Framework 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. Integrity NonStop NS-Series Server Architecture (continued) Contents 7. Integrity NonStop NS-Series Server Architecture (continued) Parallel Processing for High Performance Easy Expansion of Data 7-16 7-15 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.
Figures (continued) Contents Figures (continued) Figure 4-4. 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 6-12. 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. Figure 7-10.
Tables Contents NonStop Systems Introduction for H-Series RVUs —540083-001 vi
What’s New in This Manual Manual Information NonStop Systems Introduction for H-Series RVUs Abstract This manual gives new users an orientation to HP NonStop™ systems by describing their use in real-time enterprise solutions. Real-time enterprise solutions are based on zero latency enterprise frameworks.
What’s New in This Manual New and Changed Information NonStop Systems Introduction for H-Series RVUs —540083-001 viii
About This Manual NonStop systems are a family of computer systems based on a common architecture and operating system. NonStop systems differ in price and processing power, but they all provide the same environment for developing and executing applications. These systems provide an environment for developing and executing complex applications. The newest NonStop servers are the Intel® Itanium®-based HP Integrity NonStop NS-series servers.
What Is In This Manual About This Manual What Is In This Manual . Table i. Summary of Contents Section and Title Contents Section 1, Introduction Introduces the concepts and components of realtime solutions and the zero latency enterprise frameworks on which these solutions are based. Section 2, Requirements of Real-Time Solutions Introduces the requirements of real-time solutions in general and provides background information for the remaining sections.
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). NonStop systems are unique because of their combination of fault tolerance, high performance, data integrity, and scalability. Integrity 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.
Introduction The Adaptive Enterprise Adaptive Enterprise is about leveraging IT to not only support change, but to embrace it. It’s about driving business strategy and business processes into the underlying applications and IT infrastructure to fuel business success.” An Adaptive Enterprise dynamically links IT and business strategy so that IT is automatically driven by changing priorities. As a result, you gain an IT foundation that is an enabler for business change.
The Real-Time Enterprise Introduction The Real-Time Enterprise A real-time 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; that is, the responses to the events occur in real time.
The Real-Time Enterprise Introduction purchases with the company and has never experienced any credit problems. However, in this case, as the clerk enters the customer’s 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, 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 Real-Time Enterprise Introduction These systems cannot satisfy the requirements of a real-time 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 Framework Introduction For a simple example of how a real-time solution 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 Framework Introduction In Figure 1-3, the ZLE framework resembles a wheel, with the various operational business systems at the outer rim and the real-time 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 Framework Introduction solution 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 Framework Introduction • • Message routing. This allows the real-time solution 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. Steps in this process include: 1.
The ZLE Framework Introduction The next section explores the stringent requirements that a real-time solution imposes on a computer system.
The ZLE Framework Introduction NonStop Systems Introduction for H-Series RVUs —540083-001 1-12
2 Requirements of Real-Time Solutions The business environment shown in Figure 1-1 on page 1-5 imposes a formidable set of requirements on a real-time solution.
Requirements of Real-Time Solutions Data Integrity The solution 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 these reasons: • • • • • A hardware failure such as a processor failure or communications line failure can halt transactions in progress.
Requirements of Real-Time Solutions Data Security check the customer’s credit card transaction history, including purchases, refunds, and exchanges. The real-time 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.
Requirements of Real-Time Solutions Consolidated View of All Data handle the increasing volume of transactions with no loss of 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 Real-Time Solutions 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 shows how the real-time 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 Real-Time Solutions 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. A centralized, consolidated repository of data can provide other benefits.
Requirements of Real-Time Solutions Current View of All Data interact with customers, and in response, make recommendations 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. Current View of All Data A real-time solution provides immediate access to consolidated information from all over the business.
Requirements of Real-Time Solutions 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 real-time solution is enabling all these disparate systems to work together.
Support for Industry Standards Requirements of Real-Time Solutions 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 Real-Time Solutions 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 Real-Time Solutions Standard Component Models Providing the services required for application integration is an enormous challenge. As discussed earlier, the variety of applications that must be integrated is large. To meet this challenge, HP supports three major application servers for use in ZLE frameworks: • • • NonStop Tuxedo NonStop CORBA Java 2 Platform, Enterprise Edition (J2EE) running under BEA WebLogic Server Note.
Requirements of Real-Time Solutions Support for Heavy Transaction Volumes and Mixed Workloads applications. In a component-based architecture, real-time applications are assembled from software modules called components. An example of a standard component model used in HP real-time solutions is the J2EE platform. J2EE provides a development environment in which developers use graphical drag-and-drop techniques to assemble applications from components called beans.
Requirements of Real-Time Solutions Support for Expansion and Growth An architecture that supports zero latency operations must be able to handle massive numbers of transactional inserts and updates, batch extracts, online transaction processing (OLTP), and massively parallel queries against the same database tables concurrently without degrading performance levels. It must be able to perform different types of functions and process different kinds of workloads in parallel and around the clock.
Requirements of Real-Time Solutions Decision Support Figure 2-4. Growing Real-Time Solution 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 real-time solution is expanded to include an additional Integrity NonStop server and services.
Requirements of Real-Time Solutions Decision Support Figure 2-5. Decision Support in a ZLE Framework Real-time 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 real-time data is extracted for data mining and then routed back to the real-time solution: 1.
Requirements of Real-Time Solutions 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 real-time 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 frameworks. 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 framework.
The Application Server Environment • • • Built on NonStop Core Services Incorporating third-party applications and services into the ZLE framework Enabling efficient communications between the business systems and real-time applications Managing and monitoring transactional access to the real-time data store. HP has offered a succession of application server environments over the years.
The Application Server Environment Evolution of the Application Server Architecture Figure 3-1. Application Server and Core Services Real-time hub Data integrity: TMF Application server: WebLogic Server NonStop Tuxedo NonStop CORBA Transaction services: TS/MP or Application Server components Operating system services: NonStop Operating System Database access: SQL/MX VST016.
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 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.vsd In the client/server architecture, presentation services and part of the application logic are placed on the PC, and the rest of the application logic and the database management functions are placed on the Integrity NonStop server.
The Application Server Environment Multitiered Architectures 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. This architecture forms the basis for the application server environments described later in this section. Multitiered Architectures The previous example shows what is known as a two-tiered architecture, consisting of a presentation layer and business application layer.
The Application Server Environment Multitiered 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 Multitiered architectures are commonly used by today’s applications servers, such as WebLogic Server and NonStop CORBA.
The Application Server Environment Multitiered 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 easi
The Application Server Environment Application Server Functions Figure 3-5. Multitiered 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 Integrity 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 real-time 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 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 application server in use, there might 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. Figure 3-9 shows how a simple application could be distributed across a three-processor system. In this figure, three clients are attached to processor 1. Server A also runs in processor 1.
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 frameworks that form the basis for real-time solutions. They are presented in the order in which they were introduced by HP.
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 Integrity NonStop server: • • • • Scalability Fault tolerance 24X7 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 encapsulated 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) 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 Multitiered 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 NonStop CORBA objects IIOP EJB EJB Pathway servers JPathsend VST039.
The Application Server Environment WebLogic Server and the J2EE Platform Figure 3-19. RTID Application Running in WebLogic Server SAP client applications Integration server NonStop server SAP adapter WebLogic Server JMS adapter Loader bean Data cleansing service Real Time Information Director Web server Web application 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 RTID program A typical sequence of events for incoming data for this application might be: 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 The Role of Web Services in Application Integration be used to connect the various business applications to a framework of a different base, but the greatest benefit of a framework is provided to applications written using that framework’s API. (For example, Tuxedo-based applications work best in a NonStop Tuxedo integration framework.
The Application Server Environment Web Services Architecture database. The solution: implement the NonStop TS/MP server class as a Web service so that it can be readily accessed by other components that require that service. For another example, consider a company that has these business systems, each performing a different part of the business process: • • • • • One system manages materials requirement planning. Another system manages materials inventory control.
The Application Server Environment Web Service Providers As the figure shows, the basic Web services architecture consists of three main components: • • • The services The service requesters, or clients The services provider We now examine these components in greater detail. The services are software modules that perform common business functions.
The Application Server Environment Web Service Providers be used to link disparate systems both inside and outside of an organization. SOAP has the advantage of being relatively easy to implement. This has made it popular throughout the industry. SOAP provides the communication protocol for communication between clients and services. SOAP messages and data are formatted as extended markup language (XML) documents.
The Application Server Environment NonStop Systems Introduction for H-Series RVUs— 540083-001 3- 36 Web Service Providers
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 develop and use, but they were not powerful enough for a high-volume production environment. The basic contribution of SQL/MX to the real-time application environment is high performance and ease of use. The following discussion focuses on the other features of this powerful product. Easy Navigation Between Relational Tables SQL/MX uses the relational database model: two-dimensional tables consisting of rows and columns.
The Relational Database Management System Logical Views of Data Figure 4-1. An 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 clustering key. The clustering key value must be unique for each row, so that SQL/MX retrieves data from only that row when the clustering 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 such as 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 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 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 SQL/MX automatically 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. The Java Database Connectivity (JDBC) API provides universal data access for the Java programming language. The JDBC API consists of a set of classes and interfaces written in Java that provide a standard API for application developers.
The Relational Database Management System Workstation Access to SQL/MX NonStop Connectivity Services (NonStop MXCS), which enables developers to use the popular ODBC interface in client applications. This product is commonly used in decision support and data mining environments, where decision makers typically use PC tools to extract information from databases for use in making strategic business decisions. Figure 4-6 shows the role of the NonStop MXCS in allowing workstations to access SQL/MX databases.
The Relational Database Management System Portability of SQL/MX Applications NonStop MXCS can also be used with client applications written for Microsoft SQL Server or Sybase SQL Server, which is a workstation-based API. SQL Server provides the same capabilities for workstations that ODBC does for PCs. Portability of SQL/MX Applications SQL/MX applications are applications that contain embedded SQL statements within host language code.
The Relational Database Management System • • Data Distribution The node that uses system B has one table partition containing rows for customers 5001 through 7500. The node using system C has a single partition containing customer numbers 7501 through 10000. The database shown in this figure illustrates these features of SQL/MX partitioned tables: • • • Local users can add, change, or delete data in any local partition of the database.
The Relational Database Management System SQL/MX Support for Decision Support and Data Mining Figure 4-7. SQL/MX Distributed Database NonStop server A NonStop server B Customer numbers: 1-2500 Customer numbers: 5001-7500 2501-5000 NonStop server C Customer numbers: 7501-10000 VST051.vsd SQL/MX Support for Decision Support and Data Mining SQL/MX supports the traditional and Object-Relational Data Mining (ORDM) approaches to data mining. An overview of these two approaches follows.
The Relational Database Management System ORDM Approach Because decision support applications often involve 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.
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 real-time 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? 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 Specifying a TMF Transaction in a Program To take advantage of TMF benefits in applications, programmers simply bracket the program statements that constitute a transaction with a pair of statements that indicate the beginning and end of the transaction. TMF treats the entire bracketed transaction as a single unit of recovery.
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 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 is $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. However, 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, and 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 /* Begin Transaction */ tpbegin(. . .) ... Display dialog box Accept data to update database:bonus rate, low salary, high salary ... /* Send message to server */ tpcall(. . .) Process reply_messages ...
6 The NonStop Operating System 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 Operating System Application Services underlying operating system. Note also that processes in either environment can access objects, such as files and other processes, in the other environment. And both environments allow programmers to develop applications that support the requirements of real-time applications, such as fault tolerance, data integrity, and distributed processing. The core services (TS/MP, SQL/MX, and TMF) all support processes in either environment. Figure 6-1.
The NonStop Operating System • • • • Application Services Create and execute processes 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 Operating System Programming Environment Simplifies Application Development 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 Operating System Programming Environment Simplifies Application Development The ETK client program provides a graphical user interface (GUI) that runs on the PC. Thus, you can use the inexpensive PC hardware for program development, which leads to better utilization of your Integrity NonStop servers. ETK is an extension package to Visual Studio.NET.
The NonStop Operating System Network Operations Through ETK, you can access tools to compile, run, and debug your programs. Programs are written and compiled on the PC and transferred to the Integrity NonStop server for execution. Using ETK, you do not need to remember specific command and parameter names and all the various options. ETK greatly simplifies and streamlines the entire program development process.
The NonStop Operating System Network Operations Figure 6-4.
The NonStop Operating System Cooperative Systems A separate copy of the operating system runs inside each processor. This distributed operating system blurs the physical boundaries between processors by making it possible for a process running in any processor to access system resources in any other processor or input/output location.
The NonStop Operating System 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-5 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 Operating System 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 these steps: 1.
The NonStop Operating System Removal of Physical Boundaries Figure 6-6 shows requester-server relationships among process A, the processor monitor, and the disk process during new process creation. Figure 6-6. Requesters and Servers in the Operating System Create a process Allocate disk space (Server) Process A (Requester) Processor monitor (Server) (Requester) Disk process VST076.
The NonStop Operating System 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 Operating System Easy Transition to Distributed Processing In Figure 6-8, 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-8.
The NonStop Operating System 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 Operating System 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-9 shows the transmission of “I’m alive” messages by the message system in a three-processor system. Figure 6-9.
The NonStop Operating System Process Pairs checkpoint 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 Operating System 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 Operating System 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 Operating System Transparent Access to Network Resources Figure 6-11. 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 operating system was specifically designed to blur processor boundaries in a local multiple-processor system.
The NonStop Operating System Transparent Access to 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-12. The Network as a Single System Local system Remote system \MOON \JUPITER \SATURN \NEPTUNE \EARTH \EARTH.$TERM \NEPTUNE.$DATA VST082.vsd As Figure 6-12 shows, the names of NonStop systems begin with a backslash (\).
7 Integrity NonStop NS-Series Server Architecture The previous section, Section 6, The NonStop Operating System, showed that the NonStop operating system supports the NonStop application server environment with a powerful, reliable message system. The NonStop operating system and its Expand network extension constitute the software architecture of Integrity NonStop NS-series servers.
Integrity NonStop NS-Series Server Architecture Software and Hardware Views of Architecture called NonStop Blade Elements in the NonStop advanced architecture. Each NonStop Blade Element houses two or four microprocessors called processor elements. A logical processor consists of one processor element from each NonStop Blade Element.
Software and Hardware Views of Architecture Integrity NonStop NS-Series Server Architecture Figure 7-2.
Software and Hardware Views of Architecture Integrity NonStop NS-Series Server Architecture an end point, a fabric is a complex web of links between electronic routers that provide a large number of possible paths from one point to another. Figure 7-3.
Fault Tolerance of Integrity NonStop Servers Integrity NonStop NS-Series Server Architecture Fault Tolerance of Integrity NonStop Servers The hardware, operating system, and application environment of Integrity NonStop servers work together to meet all the demanding requirements of a real-time enterprise, such as fault tolerance, system expandability, and high performance.
Integrity NonStop NS-Series Server Architecture Interconnected Multiple Processors The system achieves fault tolerance for the user’s database by ensuring that data transfers between processes and storage devices can take place over two separate and independent paths. In this way, if a component in one of the paths fails, the system can use the other path to access the database.
Interconnected Multiple Processors Integrity NonStop NS-Series Server Architecture Figure 7-5. Dual Data Paths Between Processors 5 6 7 8 ServerNet X fabric 11 2 3 4 ServerNet Y fabric LSU 0 LSU 1 LSU 2 LSU 3 PE 0 PE 1 PE 2 PE 3 PE 0 PE 1 PE 2 PE 3 PE 0 PE 1 PE 2 PE 3 Logical Processor 0 Logical Processor 1 Logical Processor 2 Logical Processor 0 PE = Processor element VST093.
Integrity NonStop NS-Series Server Architecture Dual Access Paths for I/O The ServerNet interface, shown for 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. ServerNet packets are the form in which messages travel from source to destination through the ServerNet fabric.
Dual Access Paths for I/O Integrity NonStop NS-Series Server Architecture Figure 7-6. Dual Data Paths to I/O Hardware 4 5 6 ServerNet X fabric SAC ServerNet addressable controller (SAC) SAC SCSI bus SAC ServerNet addressable controller (SAC) SAC ServerNet Y fabric 1 Processor 0 ServerNet interface 2 3 Processor 1 ServerNet interface VST094.
Integrity NonStop NS-Series Server Architecture Low-Latency Routing provides fault tolerance by ensuring that if one path fails, continuous communication can continue through the other path. Either way, the existence of two paths to the I/O hardware ensures continuous availability for input/output operations. Low-Latency Routing In Figure 7-5 on page 7-7 and Figure 7-6 on page 7-9, you can see that sometimes a message needs to go through several routers to arrive at its destination.
Mirrored Disk Volumes Integrity NonStop NS-Series Server Architecture Figure 7-7. 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 an Integrity NonStop server because applications are constantly accessing and updating the databases that reside on disk drives.
Integrity NonStop NS-Series 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 Integrity NonStop server contains a number of mechanisms to minimize the effects of power failures.
Integrity NonStop NS-Series Server Architecture ServerNet Clustering for Availability and Performance recover from the failure. Under some failure conditions, it can be necessary to stop normal operations of a PE. A process known as reintegration is used to start processing in a PE where processing has been stopped due to either a failure or a service action.
ServerNet Clustering for Availability and Performance Integrity NonStop NS-Series Server Architecture Figure 7-8. 4-Node ServerNet Cluster Cluster switch External ServerNet X fabric Cluster switch External ServerNet Y fabric X Y Y X ServerNet interface ServerNet interface Node 1 Node 2 X Y Y X ServerNet interface ServerNet interface Node 3 Node 4 VST096.
Integrity NonStop NS-Series Server Architecture Cost-Effective System Expansion Cost-Effective System Expansion You have seen that the architecture of Integrity NonStop servers provides continuous availability for applications. The replication of hardware components throughout the system and the implementation of system and user processes as process pairs achieve a high degree of fault tolerance for the NonStop application environment.
Easy Expansion of Data Integrity NonStop NS-Series Server Architecture Figure 7-9. Linear Scalability of Integrity NonStop Servers 8 7 Relative performance 6 5 4 3 2 1 0 1 2 3 4 5 Number of processors 6 7 8 VST097.vsd Easy Expansion of Data You have seen that the Integrity NonStop server accommodates growing use of an application or set of applications by expanding in cost-effective increments.
Integrity NonStop NS-Series Server Architecture Easy Expansion of Data system or on different systems. Both database files and conventional files can be partitioned. Each partition of a file holds a particular range of records and is physically distinct from any other partition. However, all the partitions belong to the same logical file and applications view a partitioned file as a single entity. Because a file can span multiple disks, multiple I/O requests from users can be serviced concurrently.
Easy Expansion of Data Integrity NonStop NS-Series Server Architecture improved response time for all users and higher total system throughput of record updates on all three systems. Figure 7-10 shows the three partitions of the database. For simplicity, only the author field of each record is shown. Each partition can have a different system name and volume name, but all the partitions must have the same subvolume name (PART in the figure) and file identifier (PARTFILE in the figure).
Glossary adapter. A program used in zero latency enterprise framework architectures to enable the operational business applications to communicate with the applications and services on the real-time hub. Adapters translate data and transaction requests from the native format of the sending application to the format required by the real-time hub and vice versa. API. See application programming interface (API). application. A complete set of programs that perform a function.
Glossary central processing unit (CPU). central processing unit (CPU). Historically, the main data processing unit of a computer. A NonStop system has multiple cooperating processors rather than a single CPU, although processors are sometimes called CPUs. See also processor. checkpoint message. A message from a primary process to a backup process that keeps the backup process up-to-date on the state of the application. client. An application program that requests services to be performed.
Glossary database. database. A collection of tables containing data, all objects that depend on the tables, and all catalogs in which the tables and objects are registered. database consistency. The state of a database in which items satisfy established criteria. For example, an account balance must equal credits to the balance minus debits to the balance. When the database satisfies these criteria, it is considered to be consistent.
Glossary EJB EJB. See Enterprise JavaBeans (EJB). EJB container. A container that provides a runtime environment for enterprise beans that includes security, currency, life cycle management, transaction, deployment, and other services, according to the component contract of the J2EE architecture. Enterprise Application Integration (EAI). Technology employed by a ZLE framework to transmit information between business applications and the real-time data store. enterprise bean.
Glossary GUI. GUI. See graphical user interface (GUI). heterogeneous network. A network consisting of components following different protocols and often manufactured by different vendors. For example, a heterogeneous network consists of computers that have different application programming interfaces (APIs) and different protocols. homogeneous network. A network consisting of components following the same protocol and manufactured by the same vendor. HP NonStop operating system.
Glossary LAN. LAN. See local area network (LAN). linear expandability. The linear relationship between the number of processors in a NonStop system and the performance of the system. That is, adding a processor to a NonStop system adds an entire processor’s worth of performance to the system. link. An open of a server process within a server class. The server can then provide services to a client process. link management.
Glossary NonStop Blade Element NonStop Blade Element. In the NonStop Advanced Architecture, a CPU entity consisting of two or four processor elements in a single enclosure. NonStop CORBA. The infrastructure and development environment for enterprise-wide, distributed-object applications that run on NonStop servers. NonStop CORBA is an HP implementation of the Common Object Request Broker Architecture (CORBA) defined by the Object Management Group (OMG) for objects programmed using Java and C++.
Glossary Open System Services (OSS). Open System Services (OSS). An open system environment available for interactive or programmatic use with the NonStop operating system. Processes that run in the OSS environment use the OSS application program interface. Interactive users of the OSS environment use the OSS shell for their command interpreter. The OSS API and shell are similar to those provided by the UNIX operating system. ORB. See object request broker (ORB). OSS. See Open System Services (OSS).
Glossary processor. processor. A single central processing unit in a NonStop system or network of systems. A single system can contain from 2 to 16 processors. In NS-series servers, a processor consists of one or more processor elements from each NonStop Blade Element executing a single instruction stream. A duplex processor has two processor elements forming a logical processor. A triplex processor has three processor elements. The terms “processor” and “logical processor” are synonymous.
Glossary response time. 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. The amount of time it takes to receive a response from the system after initiating a request message (for example, by pressing a function key). ride-through power backup.
Glossary ServerNet cluster switch 16-processor limits of a single server, achieving comparable speeds for internal and external ServerNet communication. ServerNet cluster switch. A network switch that provides the physical junction point to enable a NonStop server to connect to a ServerNet cluster. ServerNet fabric. An interconnected collection of ServerNet routers that provides communications between processors, and between processors and I/O components in a single system.
Glossary TCP/IP communication between processors and I/O devices in a single system. The extent of a SAN is defined by a pair of ServerNet fabrics. See also ServerNet fabric and Expand. TCP/IP. See Transmission Control Protocol/Internet Protocol (TCP/IP). terminal. An I/O device capable of sending and receiving information over communications lines. throughput. The number of transactions a system can process in a given period, such as one second. TMF.
Glossary zero latency enterprise framework zero latency enterprise framework. The HP architectural framework that enables companies to deploy applications that can take advantage of real-time information. It comprises a multilevel architecture centered on a virtual hub, called the real-time hub, that caches and routes information. Within the real-time hub resides a persistent realtime data store and a variety of technologies to keep the data store in sync with all the systems it integrates. ZLE framework.
Glossary ZLE framework NonStop Systems Introduction for H-Series RVUs —540083-001 Glossary -14
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-10 OSS 6-1 Tuxedo 3-18 WebLogic Tuxedo Connector (WTC) 3-27 Application server defined 3-1, Glossary-1 functions of 3-9 NonStop CORBA 3-19 NonSto
Index D Core services 3-2 Cursors, 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 enrichment 2-6 Data integrity provided by TMF 5-2 required by real-time solutions 2-2 Data manipulation language, SQL/MX 4-6 Data mining support in real-time solutions 2-14 support in SQL/MX 4-13 Data security 2-3 Data store characteristics of 2-4/2-7 defined 1-8 Data transformation in a ZLE framework 1-9 Database management systems define
Index F F J Fabric, ServerNet See ServerNet fabric Failover of clustered servers 3-16 Fault tolerance for I/O 7-9 in NonStop servers 7-5/7-13 required by real-time solutions 2-1 Files audited 5-5 partitioned See Partitioned files recovery of 5-1, 5-12 J2EE and EAI components 1-10 multitiered architectures in 3-24 overview of 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 Connectivi
Index M M Media failure 5-12 Memory cache 5-10 manager 6-8 Message routing in a ZLE framework 1-10 Message system 6-11, 7-8 Messages checkpoint 6-14 interprocess 6-17 Messaging middleware 2-9 Mirrored disks 5-6, 7-6, 7-11 Modular expandability processing capacity and I/O 6-6 supported by message system 6-17 system and network 7-15 Monitor process 6-8 Multiple processors in client/server architectures 3-14 Multitiered architecture 3-23 MXCI 4-7 MXCS See NonStop Connectivity Services (MXCS) N Network, node
Index Q Performance (continued) of SQL/MX 4-1, 4-11 required by real-time solutions 2-3 Personal computers (PCs) access to SQL/MX databases 4-9 in client/server architectures 3-4 Portability in real-time solutions 2-12 of CORBA objects 3-21 of Enterprise JavaBeans 3-26 of J2EE applications 3-24 of OSS applications 6-3 of SQL/MX applications 4-11 Primary process 6-14, 6-15, 7-5 Process management in client server architectures 3-11 Process pairs 7-5 Processes backup 6-14 disk 6-10 primary 6-15 user 6-8 Pro
Index T ServerNet adapter dual-ported 7-6 for I/O expansion 6-6, 7-4 ServerNet addressable controller (SAC) defined 7-9 dual-ported 7-9 interface to SCSI 7-9 ServerNet clustering 7-13 ServerNet fabric bandwidth 7-8 defined 6-6, 7-2 massive expandability 7-8 simultaneous transmissions 7-8 structure of 7-8/7-10 throughput 7-8 ServerNet node 7-9 ServerNet node ID 7-6 ServerNet packet 7-8 ServerNet router defined 7-8 low latency 7-10 Servers in client/server architectures 3-4 in operating system 6-10 Server,
Index U Transactions (continued) failure of 5-1 local 5-4 online 5-1 recovery 5-3 TMF 5-1 Triple modular redundancy 7-2 Triplex system 7-2 TS/MP 5-14 Tuxedo application programming interface 3-18 as integration framework 1-10 industry-standard transaction monitor 3-18 U UDDI registry 3-34 Unit of recovery 5-3 Unit of work 5-2 UNIX 6-3, 6-4 UPDATE statement, SQL 4-6, 4-7 WLS See WebLogic Server Workflow in a ZLE framework 1-10 Workstation access to SQL/MX databases 4-9 Wormhole routing 7-10 Write-in-cach
Index Z NonStop Systems Introduction for H-Series RVUs —540083-001 Index -8
