phichamhokouda.ga WebSphere Application. Server V7 Administration and Configuration Guide. Fabio Albertoni. Leonard Blunt. Michael. IBM® WebSphere® Application Server V7 – LAB EXERCISE. WebSphere Application Server Network Deployment V7. Installation guide. What this exercise is. Chapter 2. Installing WebSphere Application Server on distributed systems.. 31 WebSphere Application Server V Administration and Configuration Guide for the Full Profile. Repository . Federating nodes to a cell.
|Language:||English, German, Japanese|
|Genre:||Business & Career|
|ePub File Size:||15.49 MB|
|PDF File Size:||12.76 MB|
|Distribution:||Free* [*Sign up for free]|
administration-guide/book. WebSphere Application Server Administration Guide. As a J2EE (Enterprise Edition) administrator, you require a secure. How can I get started with WebSphere Application Server on Solaris 10? I. Prepare the Solaris 10 Environment for WebSphere Application Server V refer to Solaris System Administration Guide: Solaris Zones (see Whole Root Zone and .. phichamhokouda.ga Configuration Guide for IBM WebSphere Application Server. 11g Release 1 ( .1). E . Creating Clusters and Cloning Application Servers.
Environment settings WebSphere uses Java environment variables to control settings and properties related to the server environment. Resource definitions are a fundamental part of J2EE administration.
Application logic can vary depending on individual business requirements, and there are several resource types that can be used by an application. The following table shows a list of some of the most commonly used resource types: Resource types Description Used to define providers and data sources. URL providers Used to define end-points for external services, for example, web services.
Naming operations, such as lookups and binds, are performed on contexts. All naming operations begin with obtaining an initial context. You can view the initial context as a starting point in the namespace. Applications use JNDI lookups to find a resource using a known naming convention. You can override the resource the application is actually connecting to without requiring a reconfiguration or code change in the application.
The actual internal physical layout is much like a ZIP file. A JAR is generally used to distribute Java classes and associated metadata.
WebSphere supports both. All we have installed at this point is the base binaries into the location we specified. By looking at the files installed by the installer, you will see what makes up the base binaries. You will also notice that the folder permissions are rwxr-xr-x , which is a result of the umask that we set before we ran the installation wizard. The presence of the Uninstall folder contains an uninstaller, which we can use to uninstall WAS.
We will now do a quick check to see if the base binaries have installed correctly by running the WAS command script versionInfo.
We can generate a report that will identify the state of the installation. Since you may have chosen not to follow the default WAS convention during installation, you can substitute the base folder with the appropriate naming convention. Run the following command: If there is a problem with your installation, you can consult the logs.
The IIM logs files are located at the following location: For Windows non-administrator: For Windows administrator: In the root of the IIM log location will be a file called index. If you open this main index file in your favorite web browser, you can navigate through the logs as if they were web pages. Log files are the life blood of WAS.
They are used for problem solving and runtime status. Agent data location Previously in WAS 7 the installer stored application registry information in a file called vdp. IIM will store data in the agent data location, or appDataLocation, and it is this directory that IIM uses for data that is associated with an application. Associated data includes the state and history of operations that the Installation Manager completes.
Changing the content, files, or directories in the agent data location directory or subdirectories is not supported. Changes to the content might prevent IIM from working. There is a file called the cic. We must create a profile which is essentially an application server definition. The tool is Java-based. To manually run it, type the following command: Once the PMT has loaded, the option to Create a profile will be available. Click the Create button to start the actual profile-creation wizard: In the environment screen you will be asked to either create a Management profile or an Application server profile.
IBM WebSphere Application Server 8.0 Administration Guide
The two profile types are explained in the following table: Profile Option Description Management A management profile includes an administrative agent server and services for managing multiple application server environments. An administrative agent manages application servers that are on the same machine. We will cover the Administrative agent in Chapter 9, Administrative Features. Application server A standalone application server environment runs your enterprise applications.
The application server is managed from its own administrative console and functions independently of all other application servers.
Ensure the Application server option is selected and click Next to continue: In the Profile Creation options screen as shown in the following screenshot, select Advanced profile creation.
Choosing this option allows for greater choice, flexibility, and control of our profile creation as opposed to using a default configuration. On the next screen, we can see that the there are some optional choices.
The Deploy the administrative console recommend option will install a special web application allowing an administrator to configure WAS using a webbased UI. Please ensure the Deploy the administrative console recommend option is selected before continuing.
There is also an option to Deploy the default application. For now, uncheck this option. Click on Next to continue to the profile name and location screen: In the Profile name and location screen we determine the actual name for our first profile and the location within the filesystem where it will be created.
The profile will make up our application server definition. Using lowercase for all folder names prompted in a wizard makes it easier to remember especially when typing folder paths in Linux, as Linux is case-sensitive. Since we will be starting and stopping the server many times during the course of our learning, it is recommended that we turn this option ON to save time when waiting for server restarts.
The following table describes the three runtime-performance options: Option name Description Standard The Standard option invokes conservative settings optimized for general purpose usage. The performance monitoring infrastructure service is enabled to gather statistics so you can further tune the server.
We will learn more about tuning in Chapter 8, Monitoring and Tuning. Production The Production option sets settings to ensure WAS is optimized for performance when updates to applications are infrequent. Click Next to move on to the next screen. The next screen is the Node and Host Names screen. The Node name is an important part of the installation process. It is recommended to keep this name as short as possible. We will cover the administration of WAS nodes in later chapters.
The Server name is the actual name of the application server's JVM. This name will be referred to in logging and configuration, which again we will address in later chapters. The Host name will automatically be taken from the OS host's file and can be changed in the wizard at this point to suit your requirements.
If you decide to change the hostname in the wizard, ensure that the change is reflected in your host file or DNS as required. If you use an FQDN, first test that it is resolvable. In our examples, we will be using a manually-derived hostname for simplicity. Our hostname will be node01 and our domain name is waslocal. The FQDN will be node This is not a real Internet domain. We are running on a private network so we can call it whatever we like, as long as our OS host file is configured correctly.
Enter the values listed in the following table into the fields on the Nodes and Host Names screen: You can see the application of these values in the following screenshot. Click Next to move on to the Administrative Security screen. In the Administrative Security screen, we will disable administrative security for now and re-enable it in Chapter 4, Security.
It is recommended for production environments that you enable administrative security right from the start to secure against unwanted changes being made to your server configuration by non-administrators.
Leave the option Enable administrative security unchecked and click Next to move on to the security certificate screens. We will deal with more on security later in Chapter 4, Security. The next screen is the Security Certificate Part 1 screen. This is a new feature of the WAS installation wizard available since version 7. In previous versions of WAS, the security certificate screens were not available.
The options available are: For now, we will use the default keystore as generated by the installer. Certificates that are used for SSL are beyond the scope of this book. We will accept the default settings. Click Next to go to the Security Certificate Part 2 screen. The next screen is the Security Certificate Part 2 screen.
The reason for this is that SSL provides a secure connection. If you connect to a host and the actual hostname doesn't match the hostname associated with the SSL certificate presented by the server, then you need to be informed whether to trust the site or not.
The wizard will generate a self-signed certificate as part of the installation process. By updating the distinguished name of the self-signed certificate that WAS generates, we can stop browser exceptions. In the Issued to distinguished name field, type the following: Click Next to move on to the Port Value Assignment screen.
WAS requires the use of several ports during runtime. It is wise to ensure that no other application is already using the ports that you wish to use. Use the following steps to check for used ports: Since this is our first WAS profile, we will use the defaults recommended by the wizard. If you see different ports than the default ones, then it means you must have other processes running on these ports, or another version of WAS is already installed.
The administrative console port is very important. We will use this port to gain access to the administration console. Please take note of the Administrative console port Default , before you move on to the next step.
Click Next to go to the next step of the installation, where we choose whether we want WAS to automatically restart on reboot. If you wish to have WAS automatically start up again when a server is rebooted, then you can enable this option. In our examples, we don't require WAS to start on reboot, so we will leave the Run the application server process as a Linux service checkbox unchecked.
If enabled, the wizard will generate an automatic start and stop script in the init. We will not be discussing Linux run levels in this book; please consult your Linux distribution's documentation.
For those of you who have chosen to install WAS on Windows, the equivalent screen will provide an option to install Windows service. You will require administrative privileges to ensure that the service can start and stop WAS correctly. Automatic start and stop scripts are recommended for production environments.
However, Linux administrators may wish to craft their own start-up scripts. If you wish to learn how these startup scripts work, then enable the creation of the Linux Service Definition to view the resulting script and it is also recommended that you consult how Linux run levels work.
Click Next to enter the Web Server Definition screen. For now, we will skip this screen, leaving the Create a Web server definition checkbox unchecked. Click Next to move on to the Profile Creation Summary screen. The final step of the wizard is Profile Creation Summary. The wizard presents a summary of your configuration options. If you are not happy with your configuration, you can go back and change your settings. If your settings are correct, click Create, which will start the profile creation.
To verify your GUI-based installation, it is best to ensure that you run all the checks within, and ensure that your installation and profile creation was successful and get quick proof that WAS is actually functional. Launch the First steps console by selecting the on-screen option labeled Launch the First steps console, and click Finish which will trigger the console to load. You can see the console in the following screenshot: Click on the Installation verification option in the First steps console as shown in the previous screenshot.
If there were no problems with the installation, WAS will be started and a report similar to the following screenshot will be generated: Now that we have proven the application server was able to start, we can now stop the server by clicking on Stop the server. The First steps console should now report that server01 has stopped.
This is shown in the following screenshot: You can now close down the First steps console window. When you exit the First steps console and return back to the Profile Management Tool, you will see that the new profile is listed in the profile list, as shown in the following screenshot: You have now successfully installed the WebSphere Application Server.
You can close the PMT. Logs During the creation of a profile, the PMT logs to a file called pmt. This log file can be used to help diagnose causes of issues when a profile creation fails.
This file most probably will not need to be consulted very often. This file can be useful to determine basic information about the profile-like ports and general settings.
Also located in the logs folder is a file called ivtClient. Administrative console To test our application server is functioning correctly, we will log in to the administration console.
The administration console is a web application, which is used to configure the WebSphere Application Server. You can use it to perform tasks such as: Currently, the application server is in a stopped state. Before we can log in to the admin console, we must start the newly created application server. To start the application server, we can use a special command script.
Command scripts are found in the directory. Script Name Description startServer. Reading configuration for server: Server launched. Waiting for initialization status. Server server01 open for e-business; process id is Now that the application server has started, we can navigate to the admin console URL. We can craft the URL as follows: If you are able to browse from the local server machine where the application server is running, you can use http: When we navigate to the admin console URL, we see the following login screen: During the installation, we opted not to turn on global security, and so we can log in using any username and no password is required.
For the purpose of this book, we will log in using wasadmin for the User ID field. Looking at the LHS panel shown in the following screenshot, we can see a list of all the configuration items, that is features and resources that are available for WAS administration: There is also an interactive command-line interface called wsadmin. We will cover administrative scripting in Chapter 5, Administrative Scripting.
It is important to know how to uninstall WAS correctly because if you don't, residual folders and files can be left behind. So if you purposely want to re-install again into the same folder path, you need to ensure that WAS is removed correctly before you do so.
What we will do is remove the installation we created earlier and then re-create the same setup using a command-line based silent installation. To delete a profile, you can use the manageprofiles.
Load IIM and click on the Uninstall button, as shown in the following screenshot: The wizard will then provide a summary screen; click Uninstall to continue. The entire repository located in the folder will also be deleted.
Once the uninstall process is complete, a screen will be presented giving you the option to view the uninstall logs: Click Finish to return to the IIM workbench. You can now close the IIM. Delete the installation folder. You can work with response files and Installation Manager to uninstall the product silently in a variety of ways. You can use a response file by: We cover this later on in the chapter.
We will cover how to do this in the following paragraph. Running the uninstaller script with no parameters will automatically launch the IIM, and then you will be provided with the same process as mentioned previously.
However, if you need to run the install in headless mode with no GUI you can use the commands which follow. To uninstall via the command line using the default sample response. You cannot install WAS into the same location a second time if it is not empty. Once the uninstall process has completed, you can delete the folder and all its contents, allowing you to re-install into the same location at a later stage.
The IIM installation process can also be run silently in headless mode. By using special response files, we can preset installation settings which do not require any user input. Using response files is the technique used in automatic installations where servers are built to a known standard and naming convention. This ensures that each new WAS is installed exactly the same way each time. This is critical for production environments to ensure each server is configured the same way.
This lends to easier support and fewer errors are introduced into environments, which is a key factor in supporting production systems. Another vital reason to use silent installations is that some organizations do not install X11 on production servers for security reasons. Installing packages silently using Installation Manager To install product packages silently using the Installation Manager, you must first create a response file. A response file can contain many different settings and they can often change as product packages are updated, and so being able to get a list for all available settings along with the correct syntax can be difficult and time consuming.
To solve this problem, IBM has added a feature to the IIM to record installations, as such automatically creating a response file with the correct settings. You can then use a record response file with the silent command-line option and install WAS in an automated non-GUI fashion. Recording a response file You can use the IBM Installation Manager to record installation actions into a response file.
When you record a response file, the selections that you make in Installation Manager are stored in an XML file. When you use the recording option of IIM, you do not actually install WAS, you are just recording a set of instructions that will be used to generate a response file.
The resulting response file can be used in silent mode, instructing IIM to use the data in the XML response file to install packages without user intervention. To install both Installation Manager and an IBM product, you must modify a response file to add the commands to install IIM; however, it is beyond the scope of this book. Command-line options for recording There are three important command-line options which can be used to instruct IIM to record a response file: The response file is used in a silent installation.
The -skipInstall argument requires that the is a directory that you can write to. You can use the same in another subsequent recording session to record updates or modifications to the IBM product.
These changes are recorded in the directory. For more information about the -skipInstall argument, see Installation Manager help and look up command-line arguments.
On a command line, change to the eclipse subdirectory in the directory where you installed Installation Manager earlier in the chapter. Run the following command to record a response file for the IBM product installation. This command uses the -skipInstall argument, which records the installation commands without installing the IBM product.
Substitute your own filename and location for the response file. Verify that the file paths that you enter exist. Installation Manager does not create directories for the response file.
Using the -log option is not supported when recording a response file. Follow the on-screen instructions as required by the IIM wizard. You will need to set the repository location again.
You can set the location of the repository in the repository table. To access the repository table, click File Preferences The text Recording Click Finish, and then close Installation Manager to finish the recording of the response file. The result of running the command will be an XML response file, which is created and saved in the location that you specified in the command-line options outlined previously.
Before we do so, we need to cover the IIM command-line options available to the recording process. Command-line options for installing To run IIM in record mode, there are several command-line parameters which can be used to instruct IIM to silently install using a response file: Indicates that an install preferences ini-file is being used to set IIM settings. You can read the IIM help to learn more about ini-file settings.
The filename and file path to the install ini-file you have configured.
There is a sample file called silent-install. The input option is used when a response file is being used. The actual filename and file path of the XML response file to use in the silent install. The actual filename and file path of the log file that will be generated.
An unsuccessful operation returns a non-zero number. If you specified a log file and directory, the log file is empty when the operation is successful. The log file contains error elements if the operation was not completed successfully. Silent profile creation Now we have installed WAS silently, we need to cover how to create profiles using the profile management command-line script. Command-line option Description augment The augment parameter is used to make changes to an existing profile with an augmentation template.
The augment parameter causes the manageprofiles command to update or augment the profile identified in the -profileName parameter using the template in the -templatePath parameter. You can Specify manageprofiles -create -templatePath. Use -help for specific information about creating a profile. Available templates include: Management — Used in conjunction with the -serverType parameter to indicate the type of management profile; Default — A standard application server profile.
Deleting a profile does not delete the profile directory. You must specify the -profileName parameter with the -delete parameter. To unaugment a profile that has been augmented, you must specify the -unaugment parameter and the -profileName parameter.
You must specify the -profileName parameter with the -listAugments parameter. Any servers using the profile that you want to back up must first be stopped prior to invoking the manageprofiles command with the -backupProfile option. The -backupProfile parameter must be used with the -backupFile and -profileName parameters. Must be used with the -backupFile parameter.
Commonly used in automation scripting. Requires the -profileName parameter. Returns a list of missing profiles. Removes any missing profiles from the registry. Returns a list of the missing profiles that were deleted from the registry.
Must be used with the -profileName parameter. For example: Profile appsrv01 now exists. It may also be pertinent to read up on how to use the -response mode option, which allows a profile response file to be used instead of using such a lengthy command line.
Response files are very useful in automation when you want to have a master script to manage many different profile creation types. Each different profile type can be specified by different response files.
Summary In this chapter, we covered how to install an application server and learned that there are different optional installation scenarios. Depending on requirements, there are multiple ways to install WAS. The manual techniques shown previously have given a cross-section of possible install variations and demonstrated how flexible the installation process is. We also covered the ability to use a silent installation by using a response file that is used to direct IIM for silent installs.
Silent installs dramatically speed up an installation. When installations are frequent, a response file approach ensures less installation errors due to the fact that it requires no human intervention.
Once configured and tested, they can be run again and again without introducing errors that are often introduced when information needs to be typed into fields as required by a GUI-like IIM. We were also introduced to a few command-line scripts such as start, stop, and other commands to manage profiles.
We also had a brief look at the administration console. A reoccurring theme in this chapter was the use of evaluating logs to ensure our installations were successful and error-free. Ensuring we have a stable set of binaries and correctly configured profile s ensures an application server is less likely to contain errors related to the actual installation process. In the next chapter, we will cover the process of deploying and configuring applications, including how to configure Java Database Connectivity JDBC.
We will also introduce a new WAS 8 feature known as monitored deployments. Monitored deployments allow a dragand-drop approach to application deployments.
Applications can be installed both manually and in an automated fashion using scripts. In this chapter, we will cover how to manually deploy a JEE Java Enterprise Edition application, later covering automated deployments in Chapter 5, Administrative Scripting.
As we walk through this chapter, we will show you how to deploy two applications. One application does not require database connectivity, while the second is a database-aware application which requires some WebSphere Application Server WAS configuration to provide database connectivity to the application. We will also cover a new feature of WAS 8, where an application can be deployed simply by placing the application in a special monitored directory.
In this chapter, we will cover the following topics: These applications may be written in-house or delivered by a thirdparty vendor. Product Overview, where we created a profile and opted not to install an EAR file called the "default application". For the purpose of understanding a manual deployment, we are going to install the default application EAR file. The following steps will show how we deploy the EAR file. Open the Administration console and navigate to the Applications section and click on New Application, as shown in the following screenshot: You now see the option to create one of the following three types of applications: Business-level Application A business-level application is an administration model, similar to a server or cluster.
However, it lends itself to the configuration of applications as a single group of modules. More about this topic is covered at the end of this chapter. Asset An asset represents one or more application binary files that are stored in an asset repository, such as Java archives, library files, and other resource files.
Assets can be shared between applications. We cover managing assets as part of BLAs later on in this chapter. Click on New Enterprise Application. As seen in the following screenshot, you will be presented with the option to either browse locally on your machine for the file, or remotely on the Application Server's filesystem.
Since the EAR file we wish to install is on the server, we will choose the Remote file system option. It can sometimes be quicker to deploy large applications by first using Secure File Transfer Protocol SFTP to move the file to the application server's file system and then using the remote file system option.
Using the Local file system option is slower, as it will require an HTTP file transfer from your local machine to the server. The following image depicts the path to the new application. Click Browse: You will now see the name of the application server node. If there is more than one profile, select the appropriate instance.
You will then be able to navigate through a web-based version of the application server's filesystem, as shown in the following screenshot: Locate the DefaultApplication.
Click Next to begin installing the EAR file. On the Preparing for the application installation page, there are two options to choose from: Install option Description Fast Path The deployment wizard will skip advanced settings and only prompt for the absolute minimum settings required for the deployment.
Detailed The wizard will allow, at each stage of the installation, the user to override any of the J2EE properties and configurations available to an EAR file. The Choose to generate default bindings and mappings setting allows the user to accept the default settings for resource mappings or override with specific values. Resource mappings will exist depending on the complexity of the EAR. Bindings are JNDI to resource mappings, which have been preset in the application.
Not all applications will contain XML-based binding files. EAR files also contain pre-configured XML descriptors which specify the JNDI name that the application resource uses to map to matching application server provided resources. By choosing the Detailed option, you get prompted by the wizard to decide on how you want to map the resource bindings.
By choosing the Fast Path option, you are allowing the application to use its pre-configured default JNDI names, which can also be pre-set using the aforementioned binding files.
Websphere Application Server 6.1 Administration Guide Redbook Pdf
We will cover the details of resources in later chapters. For now, select Fast Path. Click on Next: In the Path to the new application screen, browse the remote filesystem and select DefaultApplication. Click Next: In the next screen, we are given the ability to fill out some specific deployment options.
Following is a list of options presented on this page: The default is not to precompile JSP files. You can change this if you want the application to be physically located outside of the WebSphere Application Server file structure. Distribute application The default is to enable application distribution. You can override this and choose not to distribute the application across multiple nodes. Use Binary Configuration Specifies whether the application server uses the binding, extensions, and deployment descriptors located within the application deployment document, the deployment.
Its default value is false. Application name A logical name for the application. The default name is the same as the EAR file. An application name must be unique within a cell. The default is to create MBeans. Override class reloading settings for Web and EJB modules Specifies whether the WebSphere Application Server runtime detects changes to application classes when the application is running. If this setting is enabled and if application classes are changed, then the application is stopped and restarted to reload updated classes.
The default is not to enable class reloading. Reload interval in seconds Specifies the number of seconds to scan the application's filesystem for updated files. Process embedded configuration Specifies whether the embedded configuration should be processed. An embedded configuration consists of files such as resource.
When selected or true, the embedded configuration is loaded to the application scope from the. File Permission Allows all files to be read but not written to. Allows executables to execute. Allows HTML and image files to be read by everyone.
Application Build ID A string that identifies the build version of the application. Once set, it cannot be edited.
Allow dispatching includes to remote resources Web modules included in this application are enabled as remote request dispatcher clients that can dispatch remote includes. Allow servicing includes from remote resources Web modules included in this application are enabled as remote request dispatcher servers that are resolved to service remote includes from another application.
Business level application name Specifies whether the product creates a new business-level application with the enterprise application that you are installing or makes the enterprise application a composition unit of an existing business-level application.
For most applications, you will not have to change these previous settings. However, in this deployment, we will override the EAR application name to be: Default Application as opposed to: This should give you an insight and understanding into what WebSphere 8 has to offer in the way of JEE 6 support for these containers. These containers form the guidelines of the services, which are to be provided by a JEE application server as implemented by a software vendor like IBM: A JEE application will use one or more of the previous four components, that is an application can simply be a web application running in the Web Container alone, or a JEE application can be more complex and contain both Web components and EJB components, and so more than one container can be used in serving an application.
An Applet is a Java program that can be embedded into a web page. The Applet container manages the execution of the applet, and contains the web browser. Web container The Web container, also known as a Servlet container, provides web-related services. In a nutshell, this is the component of a web-server which serves web content, web-services, facilitates web-security, application deployment, and other key services.
Enterprise JavaBeans are used in distributed applications, and facilitate transaction services and appropriate low-level implementations of transaction management and coordination, as required by key business processes. They are essentially the business components of an application. The EJB container also manages database connections and pooling, threads, and sockets on behalf of enterprise beans, as well as state and session management.
Application client's access enterprise beans running in the business tier—which we explained earlier—run in the EJB container.
WebSphere Application Server 7.0 Administration Guide
Now that we have seen the various APIs contained within the four component containers for the JEE 6 platform, we can now look at the internal architecture of WebSphere with some context established. The anatomy of WebSphere Application Server is quite detailed so, for now, let's briefly outline some of the more important parts, discovering more about the working constituent parts as we work through each of the remaining chapters.
JEE applications are deployed to an Application Server.Workload efficiency Run the same workload on fewer servers, creating savings of 30 percent due to updates in the performance for EJB and web services. Installation wizard fails Problem: Resource mappings will exist depending on the complexity of the EAR. Nodes A node is the term which can be given to the physical OS instance on which the WebSphere process will run.
Profile Option Description Management A management profile includes an administrative agent server and services for managing multiple application server environments. GUI Install Resolution: If there are no errors shown in the summary, you can click Save to persist the application deployment.
- A-PDF IMAGE TO PDF CRACK
- NEW YORK BODY PLAN PDF
- WHAT I LOVED SIRI HUSTVEDT EPUB
- CCNA SECURITY 210-260 PDF
- EDINGER EGO AND ARCHETYPE EBOOK
- RELUCTANT FUNDAMENTALIST BOOK
- 8TH STANDARD SOCIAL SCIENCE BOOK IN TAMIL PDF
- DOSTOIEVSKI LIVROS PDF
- HARRY POTTER AND CURSED CHILD PDF
- VASTU SHASTRA BOOK HINDI PDF
- HARDWARE AND NETWORKING INTERVIEW QUESTIONS WITH ANSWERS PDF