Unit 2.1. Oracle 9iAS Architecture

The History of Oracle 9iAS

In June 2000, Oracle released a revamped version of their Application Server called Oracle 9iAS (Internet Application Server). The earlier version had fewer features and was called the Oracle (Web) Application Server (OAS). The first release of the OAS came out in 1995. The last production version of the OAS was released as version 4.0.8.2 in 1999. The OAS was desupported by Oracle in October 2002 because the new Oracle 9iAS has become the standard. The basic functionality of the OAS and Oracle 9iAS are similar but the back-end architecture and configuration are considerably different. Oracle 9iAS has a much larger array of technologies and languages it can support. You can generate Web pages using the PL/SQL Web Toolkit with the OAS but you cannot make use of PL/SQL Server Pages (PSPs). In order to fully utilize this book, you need to have the Oracle 9iAS and version 8.1.7 of the Oracle database or higher installed as your Database Server. The reasons for this are explained later in this chapter.

Oracle 9iAS primarily competes with application servers from IBM, Sun Microsystems, BEA Systems, and Microsoft. Other application servers in the market are Borland AppServer, ColdFusion, Delano e-Business Interaction Suite, Galileo, Ganjo, HahtSite, Intertop, JRun, Lotus Domino, NetDynamics, Netscape, Orion Server, PowerTier for EJB, SilverStream, Sybase Enterprise Server, Tango 2000, Total-e-Server, Versata Business Logic Server, Vision Business Logic Server, WebApp Server, and WebObjects. Before deciding which application server you will use, it is good to evaluate the features of the application server you are going to use. In this book we make use of the Oracle 9iAS; this way all components that are being used are also from Oracle Corporation.

Two-Tier Architecture

You must take a look at the basics of system architecture in order to understand the role played by the 9iAS. A very straightforward architecture is to store an application on a single machine with enough processing power to handle it. This is only sufficient for a single user. When an application is shared by many users, the architecture is split into different parts, or “tiers.” Two-tier architecture is composed of two parts, client and server, and these two tiers must communicate with each other. The “client,” or front-end, is what the user sees; it is the user’s point of entry into the system. The client tier consists of what programs are required by the client computer to access the application on the server. What the client accesses is the “server,” or back-end, which houses the database and handles requests for information. In this Client–Server model, many clients can access the same server tier, and receive consistent information.

The two-tier model has several disadvantages. The clients in a two-tier model are “fat” clients, meaning that a considerable portion of the processing power and application logic resides on the client. A client–server application requires a full installation of the client components of the application on the client PC. This involves an executable and supporting DLL files. DLL stands for Dynamic Link Library and refers to a file that is used by a number of applications to perform a common task. It saves applications from having to write repeat program code for common tasks such as printing a file. DLLs are constantly being updated and are available in many versions. These DLL files may conflict with other applications on the client. This becomes difficult to resolve since each user in a company may have a different set of applications on their PC. For this reason, maintaining client PCs in a two-tier application is very costly. An additional problem may be that clients can be operating on different platforms (such as flavors of Windows, Unix, and Mac operating systems), necessitating the deployment of platform-specific versions of applications. Administration and distribution of applications can be a nightmare for the computer support team.

Multi-Tier Architecture

The multi-tier model evolved to address the problems of the two-tier model. In a multi-tier model, a middle tier exists between clients and the database server. This middle tier often consists of an application server that contains the bulk of the application logic. Clients in this model are “thin” clients, meaning very little processing of application logic occurs on the client. Instead, the client requests information from the middle tier, and the middle tier facilitates retrieval of the information from the server, relieving the client of some of the processing load. In this architecture, application logic resides in a single tier and can be maintained easily at one location. In the two-tier model there was one set of application logic on the server and another set on the client. The architectural design of the middle tier is optimized for server functions including access to a database, so it can speed processing. The middle tier can also manage further tasks such as user authentication, caching, as address in Chapter 20, “Web Application Architecture, and balancing the requests it receives, depending on the software.

When an application is deployed on the Web, a web server must be part of the middle tier. The Web server listens for requests for Web pages from clients, which are usually Web browsers. The Web server routes a request to the application server for processing. Once the request is processed, the Web server sends the Web page to the browser that requested it. Web servers and application servers may be sold individually or as an integrated product.

Oracle’s Middle Tier

In Oracle’s multi-tier architecture, the Oracle 9iAS is the middleware, or software residing on the middle tier. It incorporates both a Web server and an application server. The Oracle 9iAS resides between the client and the back-end database and in this way moves application logic from the client; it is the central, middle tier in shared enterprise applications, providing such services as security, message brokering, database connectivity, transaction management, and process isolation.

Oracle 9iAS enables users to deploy applications on the Web. Web browsers are “thin” clients that do not need any additional software installation since they are accessing the middle tier via HTTP protocol. The only thing the user needs is a URL (Uniform Resource Locator, explained later in the chapter) to launch the application. A server tier houses the original database so that transaction processing can be optimized on the database. This multitiered model offers great savings in administration and maintenance costs when deploying applications.

The HTTP entry point to Oracle 9iAS is the Oracle HTTP Server powered by the Apache Web server. Oracle 9iAS functions both as a simple Web server and as an application server. The function of a Web server is to translate a uniform resource location (URL) into a filename on the server and send that file back to the client’s Web browser over the Internet or an intranet. The function of an application server is to run a program or a component and to generate dynamic content. This dynamic content results in an HTML file being sent back to the client’s browser. The output is the result of running a program or a script.

The Oracle HTTP Server functions as an HTTP listener and request dispatcher. Based on the Apache Server, the Oracle HTTP Server is mostly C code that runs on top of the operating system. The Oracle HTTP Server receives HTTP requests from clients and is able to serve static files from the file system. It routes those requests that are not static to other services through modules (for example, mod_plsql). These modules, often referred to as simply mods, are plug-ins to the HTTP Server. A plug-in is a program that extends the functionality of another program, and could be considered a subprogram. The mods are plug-ins that offer native services (e.g., mod_ssl, which handles a secure socket layer) or serve as a dispatcher for requests requiring external processes (e.g., mod_jserv, which dispatches requests to the Apache JServ). In addition to the compiled Apache mods provided with Oracle HTTP server, Oracle has enhanced several of the standard mods and has added Oracle-specific mods such as mod_plsql.

The middleware is able to determine to which module to hand the request based on the URL. The first section of the URL is the name of the server and the next section is the name of the module. For example, a request for mod_plsql will have a URL beginning as follows: http://ServerName:PortNumber/pls/. . . . The PLS portion indicates to the Oracle HTTP server that this is a request for the module mod_plsql.

Oracle 9iAS Communication Services are responsible for handling requests from the different clients. The Oracle HTTP Server may directly process a portion of the client requests while other requests may be routed to other components of Oracle 9iAS for processing. Oracle 9iAS can be used to support wireless technologies as well, although this book focuses predominantly on the HTTP services of Oracle 9iAS.

Oracle 9iAS provides multiple features and capabilities that are commonly supplied via separate products. An example of a recent impressive addition to the array of components is Oracle 9iAS Unified Messaging, which gives access to email, voice mail, and fax messages from any device, including computers, telephones, personal digital assistants, and pages. Oracle 9iAS is still under constant development and you will see many additional services being added and modified in the coming years.

The Client Tier

Clients access PL/SQL Web applications through a browser using the Web protocol HTTP. Oracle 9iAS application components generate HTML, which is returned to the browser and displayed as Web pages. Since Web browsers behave in a similar manner across platforms and they all read HTML and JavaScript, it does not matter what type of operating system a client Web browser is operating on.

The Database Tier

PL/SQL Web applications are developed as PL/SQL packages and procedures and stored in an Oracle database. You can access database tables through these packages and present the data as dynamic information in your generated Web pages. First introduced with the Oracle Application Server available with Oracle8i, the Oracle 9iAS provides a collection of PL/SQL packages called the PL/SQL Web Toolkit. These packages are also stored in the database and are used in Web-based application packages to generate Web page components and other related functionalities.

The Application Server Tier: The PL/SQL Gateway

The PL/SQL Gateway enables you to call PL/SQL programs from a Web browser. The PL/SQL programs run on the server and return HTML to the browser. The 9iAS acts as the intermediary between the database and the browser.

Static vs. Dynamic

A static file is the simplest type of resource the Oracle 9iAS can deliver. A static resource is just a file that resides in the directory of the file system. To make the file accessible from the Web, the Oracle 9iAS maintains a list of mappings (in a configuration file) between physical directories and symbolic aliases called virtual directories.

A dynamic Web page is where the content is selected from the database and assembled into HTML to create an html file. For example, the number of students enrolled in a class may constantly change as students sign up and later drop out. An administrator may need to see a list of students officially enrolled in a course at any given time. This information is available in the database. A dynamic Web page will show this information by querying the database. The HTML is written and then sent to the client browser of the administrator. The Web server delivers this to the client. Oracle 9iAS can deliver content for the Internet or for internal and external intranets in the form of static and dynamic Web pages.

State

When a user logs into a database, all of their activities are tracked as being part of that user’s session. One challenge for Web application developers is to maintain information from one Web page to the next in the same way that a user connected to a database has a series of transactions that can be rolled back or committed. Web browsing does not inherently preserve state. A browser requests a page, and the page is returned to the browser, end of story. The IAS can process two types of transactions, stateless and stateful transactions.

• Stateless transactions (the most common Web transactions) do not carry “state” from one Web page to another. They consist of a request from the client and then a response from the server. Once the response has been delivered the transaction is complete. The next transaction will have no relation to the prior transaction or the following transaction. Generally, user and session information is not captured by the application server.

• Stateful transactions do carry “state” from one transaction to another. They are similar to a database session. In a database session, a user may perform a number of inserts or updates before committing or rolling back the information. A stateful transaction operates in a similar manner.

In a stateless environment, each HTTP request from a client maps to a new database session. Application state is typically maintained in HTTP cookies or database tables. Transaction state cannot span across requests. If a PL/SQL procedure executes successfully, an implicit commit is performed. If it executes with an error, an implicit rollback is performed. Cookies will be covered in more detail in Chapter 15, “Maintaining State with Cookies and Tables.”

In a stateful environment, each HTTP request from a client maps to the same database session. Application state is preserved in PL/SQL package variables. A transaction can span across requests because no implicit commits or rollbacks are performed.

• Oracle 9iAS with mod_plsql supports running in stateless mode only. This is the recommended configuration for users who want to develop stateless PL/SQL-based Web applications. In stateless mode, mod_plsql has a connection that keeps the database sessions open between HTTP requests, preventing the need for the user to log in with each Web page.

• Oracle 9iAS with mod_ose supports running in both stateless and stateful mode. When using mod_ose, the stateful mode is preferable because a new database session does not have to be created and destroyed for every HTTP request.

Oracle HTTP Server Modules (MODS)

In addition to the compiled Apache modules (referred to here as simply mods) provided with the Oracle HTTP Server, which support current Internet application technologies to deliver dynamic Web pages, Oracle has enhanced several of the standard Apache mods and has added Oracle-specific mods. For more information, refer to http://www.apache.org/docs/mod/index.html. main mods to consider are:

MOD_PLSQL: This module is an HTTP Server plug-in that dispatches requests for PL/SQL and Java stored procedures to an Oracle database. Mod_PLSQL is the most efficient SQL interface for generating HTML. The HTTP Server identifies the request as belonging to this module, based on the URL from the client. HTTP requests that are identified are handed from the HTTP Server to mod_plsql. These requests are then mapped to database stored procedures. The module maintains database connections specified by database access descriptors (DAD). The application that is built in this book is designed to run using this module. This module is installed in all versions of the Oracle 9iAS.

MOD_OSE: This module delegates URLs to stateful Java and PL/SQL servlets in the Oracle Servlet Engine (OSE) contained in an Oracle database. It keeps session IDs in cookies, or redirected URLs, and routes requests to the appropriate OSE sessions over NS (Net8, referred to as Oracle Net in Oracle9i.)

The other mods that are commonly used are the mod_perl for Perl; mod_jserv, a servlet engine; and mod_ssl for secure socket layer connections. Oracle 9iAS has many other exciting features, but there are far too many to discuss them all in detail here. They range from Oracle Forms, Reports, and Discoverer Queries being deployed over the Web as well as innovations such as the Oracle Internet File System, which is a service that stores files in an Oracle database. The range also includes Oracle products such as Oracle Portal, an application that can quickly build a Web portal. Refer to the Oracle 9iAS installation guide for details on installation and configuration.

Important Oracle 9iAS Components

The Oracle 9iAS consists of numerous components. These are constantly evolving and more components are being added. The components that are addressed in this book are:

• Oracle PL/SQL Server Pages (Oracle PSP)—These are very similar to Oracle JSP. Oracle’s LoadPSP will translate a PSP file and create a database stored procedure. This stored procedure is then accessed by Web requests through mod_plsql. This will be addressed in detail in Chapter 12, “Working with PL/SQL Server Pages (PSPs).”

• PL/SQL Web Toolkit provides support for building and deploying PL/SQL-based applications on the Web. PL/SQL stored procedures can retrieve data from database tables and generate HTTP responses containing data and code to display in a Web browser. This will be discussed in more detail starting with Chapter 10, “Web Toolkit I: HTML and JavaScript with PL/SQL.”

• Servlets are often Java applications (though Oracle now offers PL/SQL servlets) that run in a server-side environment and service requests from the clients.

• Database and Web Cache stores frequently accessed data and applications on the middle tier. This setup routes queries transparently to the cache or back-end database.

• Load Balancing maximizes scalability and uses hardware efficiently through balancing the client load among various servers.

• iSQL*Plus is a Web-based SQL*Plus client tool. Figure 2.1 is a sample of the logon screen and Figure 2.2 is a sample of working within the SQL*Plus application.

  Figure 2.1. The iSQL*Plus Logon screen.

  

  Figure 2.2. The iSQL*Plus application.

  

If the Oracle 9iAS server had the name MyServer, then the iSQL*Plus application could be run by the URL http://MyServer/isqlplus. If the Oracle 9iAS server and the Database were installed on the same server and in the same Oracle Home, then a connect string would not be needed. In any other situation you will need to use the proper service name from the tnsnames.ora file in the network/admin directory of the Oracle 9iAS Oracle Home.

PL/SQL Web Toolkit Packages

The PL/SQL Web toolkit consists of a number of Oracle-supplied packages. You have worked with Oracle-supplied packages such as DBMS_OUTPUT when you were learning PL/SQL. In the former version of the application server the OAS installed the PL/SQL Web Toolkit packages in an OWA (Oracle Web Application) user such as OAS_PUBLIC. Starting with Oracle 8.1.7 and Oracle 9iAS, a number of new packages have been added to the Toolkit. These packages are installed in the SYS user’s schema. Oracle 9iAS installs the following packages: OWA_CUSTOM, OWA_GLOBAL, HTF, HTP, OWA_COOKIE, OWA_IMAGE, OWA_OPT_LOCK, OWA_PATTERN, OWA_SEC, OWA_TEXT, OWA_UTIL, OWA_INIT, OWA_CACHE, and WPG_DOCLOAD. Note that Oracle Portal 3.0 depends on the new PL/SQL Web Toolkit packages.

• In earlier versions of Oracle iAS, users of mod_plsql were required to manually install these packages into the SYS schema. These packages are located under the $IAS_HOME/Apache/modplsql/owa directory.

• In an 8.1.7 installation and above, the new PL/SQL Web Toolkit packages are located under the $ORACLE_HOME/rdbms/admin directory and are installed into the SYS schema.

The Process of Running a Web Page via MOD_PLSQL

When entering a URL that launches a Web page generated by an Oracle procedure, follow this format:

Http://Host_Name:Port_Number/pls/DAD_Name/Procedure_Name 

The default port for the Oracle HTTP server is 80, so if you are using this default port you do not need to specify the port number in the URL. Different versions of the Oracle iAS install on different default ports. It can be 80 and is also often Port 7778.

Each PC or server on a network has a unique IP address. This IP address has virtual divisions and these divisions are known as ports. Certain ports are set aside for certain processes. For example, Port 1521 is generally reserved for the Oracle Database listener. Port 80 is used for a Web server.

Communication Flow: The Path of HTTP Requests

Connecting to a Remote Database Server

A full discussion of Oracle networking is beyond the scope of this book; however, since you are learning to build Web applications that access an Oracle database, some discussion in how to get started in connecting your applications to an Oracle database is necessary.

Oracle’s networking solutions involve many different components, as well as many different implementations. This chapter focuses on the basic networking components that a Web developer would be concerned with. All other types of networking configurations are usually set up and maintained by a database administrator or systems administrator.

Oracle Net (a set of networking components, known as Net8 for Oracle8 and Oracle8i and SQL*Net prior to Oracle8) makes database communication with an Oracle database possible. These components can support connections from the same machine that the database is on, or from remote machines.

The Oracle listener is one of the important components of Oracle networking. It is the process responsible for receiving database connection requests and redirecting them to another process, which then becomes the main point of contact between the client and the database. The information needed to establish connections with an Oracle database is stored in several configuration files. Two such files are the listener.ora file and the tnsnames.ora file.

Your database administrator should maintain the listener.ora file. A typical Web developer is not responsible for maintaining this file since it resides only on the database server. Therefore, this discussion will focus on the one of these two files that a Web developer will most often be working with—tnsnames.ora, which resides on both the client and the server.

Both of these files can be found in a location referred to as the TNS_ADMIN directory. The TNS_ADMIN directory location depends on the version of the Oracle Server that is installed. For versions 7.x, 8.1.x, and beyond (for instance, in an NT environment), the TNS_ADMIN directory is usually <ORACLE_HOME> networkadmin; for version 8.0.x, it is usually found at ORACLE_HOME et80 admin. In UNIX, the default location for these files would be written as $ORACLE_HOME/network/admin.

The listener.ora file simply contains configuration information for the Oracle listener. The tnsnames.ora file is used in defining TNS net service names. “TNS” stands for Transparent Network Substrate, and it serves as a single, common interface to most industry-standard networking protocols. TNS service names are resolved in the tnsnames.ora file, which contains information on where to locate particular databases.

For example, you might define a TNS service name called WEB_DEV. In your tnsnames.ora file, the configuration information for WEB_DEV may indicate that the listener for this database is located at port 1521 (the default port location if you don’t specify otherwise) on IP address 111.222.333.444 (or the name of the machine at that address) and listens for connection requests to a database called “web_dev.” Oracle Net’s location transparency is largely made possible due to the tnsnames.ora file. If you move a database from one machine to another, you need only update the tnsnames.ora files on the clients that connect to this database to reflect the new address for the existing service name (which, as you read later, is often the same as the database or instance name).

If your environment uses TNSNames (as opposed to one of the other Oracle networking solutions, like the Oracle Names Server), a tnsnames.ora file is configured and maintained on both the database server and the client. Therefore, to effectively support connections to the database, service name listings in both files (the file residing on the server and the file residing on the client) must be identical.

FOR EXAMPLE

The following is a sample tnsnames.ora file (lines beginning with # are comments):

# TNSNAMES.ORA Network Configuration File: 
#C:ORACLEORA817
etworkadmin	nsnames.ora 
# Generated by Oracle configuration tools. 
WEB_DEV = 
 (DESCRIPTION = 
  (ADDRESS_LIST = 
   (ADDRESS = (PROTOCOL = TCP) 
              (HOST = web_development) 
              (PORT = 1521) 
   ) 
  ) 
  (CONNECT_DATA = 
   (SERVICE_NAME = web_dev) 
  ) 
 ) 

Most of this listing—from the keyword, DESCRIPTION, to the last parentheses— is known as a connect descriptor. It contains the definition of a protocol address and the service name to which to connect. The ADDRESS section specifies the protocol address of a listener. With the ADDRESS_LIST keyword present, multiple ADDRESS sections may be defined, with multiple protocols and protocol addresses, for a single net service name. Multiple addresses are simply listed after the ADDRESS_LIST parameter. The CONNECT_DATA keyword is always followed by the name of the service to which you’d like to connect. Typical types of services used with CONNECT_DATA are:

• SID, which identifies the database instance by the Oracle System Identifier (SID)

• SERVICE_NAME, which identifies the global database name, a name comprised of the database name and domain name, created during installation or database creation

• INSTANCE_NAME, which identifies the database instance to access

You can make changes to your tnsnames.ora file using the following steps:

SID is most commonly used with Oracle8. Oracle recommends that, with Oracle8i and 9i, you use SERVICE_NAME as opposed to SID.

Once you have entered configuration information for your TNS service name in your tnsnames.ora file, you can open SQL*Plus and attempt to connect to the database it represents using the following syntax:

CONNECT <username>/<password>@<TNSservicename> 

Oracle Net Manager

You can accomplish the task of creating your networking configuration files by using Oracle Net Manager. This GUI (graphical user interface) utility was previously named Net8 Assistant in Oracle8. As you can see from the example above, Oracle Net configuration files have a very specific syntax with multiple levels of nested brackets. You can avoid the errors sometimes common to hand-typed configuration files by using the Oracle Net Manager.

You can access the Oracle Net Manager by going to your Start menu, then going to Programs, your Oracle 9i program listing, Network Administration, then Oracle Net Manager. Once there, follow the wizard prompts to set up your net service names. If you need further reference on what each prompt is asking for, refer to the list of steps laid out earlier for those brave enough to hand-code their tnsnames.ora file.

If you’re having a problem with your network, back up the current configuration files and use the Oracle Net Manager to regenerate them.

tnsping

Oracle Net provides a utility, tnsping, which can be used to validate both the name resolution to, and the existence of, an Oracle Listener service. Oracle Net interfaces with a variety of Network and Transport layer protocols, one of which is TCP/IP (Transmission Control Protocol/Internet Protocol). If TCP is the protocol being used, then the utility tnsping uses TCP for its communication. TCP is an OSI (Open Systems Interconnection) Transport layer protocol that is connection-oriented. This connection-oriented protocol requires an exchange of sequencing numbers in the initial connection setup. This exchange is commonly called the “three-way handshake.” When tnsping is issued from the command line, a lookup on the Oracle Net Alias (or Service Name) is performed. This can occur using your local tnsnames.ora file. The purpose is to get the host name and port number the target Listener is listening on. Once this information is acquired, a TCP connection is opened to the target host and port the Oracle Listener is on. To open this TCP connection, the host name must be resolved to the IP address of the target host. TCP/IP then performs the three-way handshake to complete the connection. tnsping sends an Oracle TNS Connect packet (the “ping”) to the Oracle Listener. The Listener responds with a TNS Refuse packet (the “pong”). The TCP/IP connection between the two hosts is then terminated. The total time from Oracle Net Alias lookup to TCP/IP connection termination is then reported back to the command line. Here is an example of the output after invoking the tnsping utility:

C:>tnsping web_dev 
WEB_DEV 4 TNS Ping Utility for 32-bit Windows: Version 
8.1.7.0.0 – 
Production on 04-FEB-2002 21:25:57 c) Copyright 1997 Oracle 
Corporation. 
All rights reserved. 
Attempting to contact ADDRESS=(PROTOCOL=TCP) 
(HOST=web_development)(PORT=1521)) 
OK (15100 msec) 
OK (10 msec) 
OK (0 msec) 
OK (10 msec) 

This example shows a 15100-millisecond period for the first “ping.” This time period is comprised of the lookup of the alias WEB_DEV in a local tnsnames.ora file, a DNS resolution of the destination host web_development and port 1521, the TCP/IP three-way handshake, the actual transport of the TNS Connect and Refuse packets, and the tearing down of the TCP/IP connection. The second time only took 10 milliseconds because all the connection information, the alias WEB_DEV, and IP address had already been cached. Tnsping still does the connection setup and teardown for TCP/IP for each invocation of tnsping, however.

ping

TCP/IP uses its own utility called “ping,” named after the sound SONAR makes underwater. It is the command-line interface to the TCP/IP protocol ICMP (Internet Control Message Protocol). One of ping’s primary responsibilities is to gather information about general roundtrip times for a variety of IP packet sizes. This measurement can be used to estimate the overall performance and response time of an application on a network. Ping uses IP, which does not require the three-way handshake. When ping operates, it only sends one IP packet and receives only one. This is fewer packets, by quite a bit, than Oracle’s tnsping issues. It is typical for ping to show an initial response time being longer than the average. This is usually due to the time it takes to perform a host name to IP address lookup (or resolve). This lookup can be performed with either a local hosts file or by using a DNS server. An example output for a ping looks like the following:

Pinging web_development [111.22.333.444] with 32 bytes of 
data: 
Reply from 555.66.777.888: bytes=32 time<50ms TTL=315 
Reply from 555.66.777.888: bytes=32 time<10ms TTL=315 
Reply from 555.66.777.888: bytes=32 time<10ms TTL=315 
Reply from 555.66.777.888: bytes=32 time<10ms TTL=315 

This example shows a 50-millisecond ping time for the first attempt. This time included a DNS resolve for the target host.

Unit 2.1 Exercises

Unit 2.1 Exercise Answers