How-To Tutorials

Editing load tests The load can contain one or more scenarios for testing. The scenarios can be edited any time during the design. To edit a scenario, select the scenario you want to edit and right-click to edit the test mix, browser mix, or network mix in the existing scenario or add a new scenario to the load test. The context menu has different options for editing as shown here: The Add Scenario... will open the same wizard, which we used before adding the scenario to the load test. We can keep adding the scenarios as much as we need. The scenario properties window also helps us modify some properties such as the Think Profile and the Think Time Between Test Iteration and the scenario Name. The Add Tests... option is used for adding more tests to the test mix from the tests list in the project. We can add as many tests as required to be part of the test mix. The Edit Test Mix... option is used for editing the test mix in the selected scenario. This option will open a dialog with the selected tests and distribution. Using this Edit Test Mix window we can: Change the test mix model listed in the drop–down. Add new tests to the list and modify the distribution percentage. Select an initial test that executes before other tests for each virtual server. The browse option next to it opens a dialog showing all the tests from the project from which we can select the initial test. Similar to the initial test, we can choose a test which is the final test to run during the test execution. The same option is used here to select the test from the list of available tests. The Edit Browser Mix... option opens the Edit Browser Mix dialog from where you can select the new browser to be included to the browser mix and delete or change the existing browsers selected in the mix. The Edit Network Mix... option opens the Edit Network Mix dialog from where you can add new browsers to the list and modify the distribution percentages. We can change or delete the existing network mix. For changing the existing load pattern, select the Load Pattern under the Scenarios and open the Properties window which shows the current patterns properties. You can change or choose any pattern from the available patterns in the list as shown in the following screenshots: The Run Settings can be multiple for the load tests, but at any time only one can be active. To make the run settings active, select Run Settings, right-click and select Set as Active. The properties of the run settings can be modified directly using the properties window. The properties that can be modified include results storage, SQL tracing, test iterations, timings, and the web test connections. Adding context parameters The web tests can have context parameters added to them. The context parameter is used in place of the common values of multiple requests in the web test. For example, every request has the same web server name, which can be replaced by the context parameters. So whenever the web server changes, we can just change the context parameter value, which replaces all the requests with the new server name. We know that the load test can have web tests and unit tests in the list. If there is a change in the web server for the load test other than what we used for web tests then we will end up modifying the context parameter values in all the web tests used in the load tests. Instead of this, we can include another context parameter in the load test with the same name used in the web tests. The context parameter added to the load test will override the same context parameter used in the web tests. To add new context parameter to the load test, select the Run Settings and right-click to choose the Add Context Parameter option, which adds a new context parameter. For example, the context parameter used in the web test has the web server value as this.Context.Add("WebServer1", "http://localhost:49459"); Now to overwrite this in load tests, add a new context parameter with the same name as shown below: Results store All information collected during the load test run is stored in the central result store. The load test results store contains the data collected by the performance counters and the violation information and errors that occurred during the load test. The result store is the SQL server database created using the script loadtestresultsrepository.sql, which contains all the SQL queries to create the objects required for the result store. If there are no controllers involved in the test and if it is the local test, we can create the results store sql database using SQL Express. Running the script creates the store using SQL Express. Running this script once on the local machine is enough for creating the result store. This is a global central store for all the load tests in the local machine. To create the store, open the visual studio command prompt and run the command with the actual drive where you have installed the visual studio. cd c:Program FilesMicrosoft Visual Studio 9.0Common7IDE In the same folder, run the following command which creates the database store SQLCMD /S localhostsqlexpress /i loadtestresultsrepository.sql If you have any other SQL Server and if you want to use that to have the result store then you can run the script on that server and use that server in connection parameters for the load test. For example, if you have the SQL Server name as SQLServer1 and if the result store has to be created in that store, then run the command as below: SQLCMD /S SQLServer1 -U <user name> -P <password> -iloadtestresultsrepository.sql All these commands create the result store database in the SQL Server. If you look at the tables created in the store, it would look like this: If you are using a controller for the load tests, the installation of the controller itself takes care of creating the results store on the controller machine. The controller can be installed using the Visual Studio 2008 Team Test Load agent Product. To connect to the SQL Server result store database, select the Test option from the Visual Studio IDE and then select the Administer Test Controller window. This option would be available only in the controller machine. If the result store is on a different machine or the controller machine, select the controller from the list or select <Local-No controller>, if it is in the local machine without any controller. Then select the Load Test Results store using the browse button and close the Administer test Controller window. The controllers are used for administering the agent computers and these controller and agents form the rig. Multiple agents are required to simulate a large number of loads from different locations. All the performance data collected from all these agents are saved at the central result store at the controller or any global store configured at the controller. Running the load test Load tests are run like any other test in Visual Studio. Visual Studio also provides multiple options for running the load test. One is through the Test View window where all the tests are listed. We can select the load test, right-click and choose the option Run Selection option, which starts the load tests to run. The second option is to use the Test List Editor. Select the load test from the test list in the test lists editor and choose the option to run the selected tests from the test list editor toolbar. The third option is the built-in run option in the load test editor toolbar. Select the load test from the project and open the load test. This opens the load test in the load test editor. The toolbar for this load test editor has the option to run the currently opened load test. The fourth option is through the command line command. MS Test command line utility is used for running the test. This utility is installed along with the Visual Studio Team System for Test. Open the Visual Studio command prompt. From the folder where the load test resides, run the following command to start the load test mstest /testcontainer:LoadTest1.loadtest In all the above cases, the load test editor will show the progress during the test run. But the other option does not show the progress instead stores the result to the result store repository. It can be loaded later to see the test result and analyze it. You can follow these steps to open the last run tests: Open the menu option Test | Windows | Test Runs. From the Connect drop-down, select the location for the test results store. On selecting this, you can see the trace files of the last run tests getting loaded in the window. Select the test run name from the list and double-click to open the test results for the selected run. Double-click the test result shown in the Results window that connects to the store repository, fetches the data for the selected test result, and presents in the load test window. The end result of the load test editor window will look like the one shown in the following screenshot with all the performance counter values and the violation points. More details about the graph are given under the Graphical View subsection.

A couple of days ago, a client asked me for an easy way to develop PHP applications. Naturally, I told him the best way would be to pay me for doing it! Just kidding… "Use the NetBeans IDE", I said to him, almost automatically. "But… isn’t NetBeans something related to Java?" he answered back, with a startled grin on his face. "My dear friend, you can use NetBeans to develop software on Java, PHP, C++, and almost any other programming language I’ve heard of! You could even use it to work on a WordPress live Web site!" I said to him triumphantly. And that’s when a small light bulb lit up inside my mind... I introduced him to VirtualBox and the world of virtual machines, the Turnkey Linux LAMP appliance, and how to make all these software applications collaborate between each other. And that’s how this article was born. So now, my dear readers, let’s get on with the action! Oh, and feel free to skip any section you don’t need, ok? Download and Install VirtualBox Go to the VirtualBox Web site and download the most recent version: http://download.virtualbox.org/virtualbox/3.0.4/VirtualBox-3.0.4-50677-Win.exe After downloading VirtualBox, install it with all the default options (remember to register with Sun!). Download the Turnkey LAMP appliance Go to the Turnkey Linux Web site and download the LAMP appliance: http://www.turnkeylinux.org/download?file=turnkey-lamp-2009.02-hardy-x86.iso . Download the NetBeans PHP IDE Go to the Sun Web site and download the NetBeans PHP IDE here. After downloading NetBeans, install it with the default options. Create a virtual machine Open VirtualBox and click on the New button to create a virtual machine (VM). In the following screenshot I used the VirtualPHPDev name for my VM, but you can use whatever you want; just don’t use strange characters or signs: Choose Linux and Ubuntu as the Operating System and Version, respectively. Click on Next to continue. Leave the default values for RAM and hard disk. When finished, click on the VirtualBox Settings button to open your virtual machine’s settings dialog, select the CD/DVD-ROM category, enable the Mount CD/DVD drive option, select the ISO Image File button and then click on the Invoke Virtual Media Manager button . Click on the Add button in the Virtual Media Manager to open up the Select a CD/DVD-ROM disk image file, go to the directory where you downloaded the Turnkey LAMP appliance and double-click on it to add it to the Virtual Media Manager: Click on Select to close the Virtual Media Manager, and then click on OK to exit the Settings dialog. Now you can click on the Start button to start your LAMP virtual machine: Select the Install to hard disk option in the Turnkey Linux menu screen and press Enter to start installing the LAMP appliance on your virtual machine. Eventually the following screen will show up: Select the Guided option and press Enter to continue. The installer will ask if you want to save changes to disk. Select Yes and press Enter. The installer will start the disk formatting process and then you’ll get to the root password screen. Type the password twice for the root user, and then do the same for the MySQL user. The installer will continue and, after a while, the following installation completion screen will show up: Select No, press Enter and then close the virtual machine typing shutdown -r now at the system prompt. You’ll return to the VirtualBox main screen. With your LAMP virtual machine selected, click on the Settings button to open the settings dialog box. Select the CD/DVD-ROM category and disable the Mount CD/DVD drive option. Then select the Network category, change the Attached to: option to Bridged Adapter and click on OK to continue: You can start your LAMP virtual machine now. When ready, the following screen will appear: The Bridged Adapter mode lets your virtual machine act as if it were another PC on the LAN, and consequently, it will have a different IP address. Write down the IP address shown in the Turnkey Linux Configuration Console screen, because you’ll need it to configure the NetBeans IDE later. You can minimize the LAMP virtual machine window now.

Isaac wants his web site to have the following features: An "About me" page—showing his personal profile and interests A page that will list all of his publications A Blog to tell the world what he is currently doing, with a list of the latest blog posts displayed on the front page A Contact form that site visitors can use to send an email to I.M. Smart Theme Smart has chosen the "AD The Morning After" theme (which is a contribution to the Drupal project) because he loves the design. The front page will feature a teaser for Smart's profile at the top of the content area, and a list of his most recent blog posts in a block at the bottom of the front page. The final layout of Smart's web site can be seen in the following screenshot: Build I.M. Smart's site Okay, this guy Smart doesn't appear particularly likeable does he, and isn't this quite typical of university professors? But let's put our prejudices aside for a couple of hours and get his work done for him. The major tasks in building the web site for Isaac Smart will be: To create a new Content type called "Publication", under which he can list all of his work To be able to allocate terms to describe each added work To be able to display a Page view of the list of publications To be able to create a Block view of the list of his daily blog posts To create a simple Contact form Modules In order to create the desired web site, we will be using some essential Drupal modules. Optional Core modules The following optional Core modules will be required: Blog—will enable him create his blog posts Taxonomy—will enable him to classify his blog posts Comment—will allow all visitors to his web site to comment on, and to discuss his blog posts and publications Contact—will allow site visitors to send him personal messages Upload—will allow the upload of files into content Contributed modules The following contributed modules will also be used: Taxonomy Menu—will allow taxonomy vocabularies to be transformed into menus easily IMCE—will give the ability to upload and manage files and images Image—will allow the inclusion of images in content Basic content Smart's site is quite basic. The About Me page can be safely created from the Story Content type, and that is what we are going to do. However, to add an element of danger to the project, we will be including a new Content type for his publications, and we will call it just that—"Publication". Create a new Content type By navigating to the Administer page of the site and then to the Content management section, we will find the Content types link. If we access this page, then we will see the various Content types listed there. Here, we need to create a new Content type for "Publication". To create the "Publication" Content type: Click on the Add content type link at the top of the page. You will then be presented with a form. Add the Content type description and the general rules for the adding and display of content for this new Content type, in the places where they need to be in the form. Here are some guidelines: In the Identification fields, add the Name and the Description of the Content type (in this case "Publication"). In the Submission form settings, you can choose the titles that you want to give the fields. By default, you are presented with Title (for the title of the submission), Body (for the main story), and also fields specifying the minimum length of the article before it can be accepted for submission, as well as another place where you can describe submission guidelines for this Content type. Leave this at the system default setting. In the Workflow setting we need to determine the default options: Do you want the article to be immediately published and available for use on the site, immediately after submission? If so, select the Published checkbox. Do you want to promote the article to the front page? If so, select the Promoted to front page checkbox. Do you want the article to remain at the top of the list of contents on the site? If so, select the Sticky at top of list checkbox. In the Comments settings panel, indicate whether you want to allow comments to be made on articles of this Content type or not, and if you do, how these comments will be handled. As previously mentioned, Smart wants to allow comments to be added to his publications by site visitors. Categorize content We first need to establish how the content is going to be organized for use on the site. This is quite easy because we have created only one new Content type, named Publication, that will have taxonomy terms—Books and Papers—attached to it. By doing this, we will have set the ground rules for how content will be created and displayed on the site. Categories or terms may be used to further classify items that, even though they fall under the same Content type, need to be grouped with others with which they bear a close similarity. In this case, Smart's Publication list includes Books and Papers, which, even though they are both publications, would do well if grouped separately. So we must now create the new categories and establish relationships between these new categories and the new Content type. Go to the Taxonomy link under the Content management section on the Administer page, and click on it to get to the Taxonomy page. If you have started a new site, then at the foot of this page, you will see a notice that there is no vocabulary available for your new categories. The vocabulary is a term by which a collection of categories (or terms) can be collectively described. In this case, let us create a vocabulary that we will call Publications Type. We will do this by clicking on the Add vocabulary link at the top of the page. This is what we will be entering into the form for this new vocabulary: In the Identification panel, let us enter the Vocabulary name, and a Description, as well as any Help text that will guide Smart when he comes across this vocabulary. For Publication, we have used Publications Type as the Vocabulary name. For the Description, we have entered The type of publication. Is it book or paper? For the Help text, we will be instructing Smart to Select appropriate publication. We need to associate this vocabulary with a Content type. We have created it specifically for Publication, so we will naturally select the Publication checkbox. For the Settings, we declare that the selection of a term from this vocabulary is Required, and that Smart must choose a term from the supplied list. Moreover, because a Publication can be either a Book or a Paper but never both, a posted content may not have more than one term associated with it. Therefore, leave all of the other checkboxes with the system default settings. The completed vocabulary page is shown in the following screenshot: On returning to the Taxonomy page, we can see the new vocabulary that we have just created is listed. Now we need to add the terms for the vocabulary. We do this by clicking on the add terms link and completing the form that we will be presented with. At this stage, forget about the Advanced Options link at the bottom, because we only have a single level of terms. If you click on the list terms link on the vocabulary, then you will be presented with a list of the terms that you have created, in the order that these terms will be presented to Smart. If you don't like this order, then just drag the ones you want to change to the location that you want. Test the submission form Now, let us test our content submission form and see how it works. In order to do this, you click on the Create content link (on the lefthand side of your page), and select Publication. You will then get a form, as shown in the following screenshot: Using this form, Smart will be able to post the details of his many publications to his web site. However, he doesn't know a thing about HTML (which proves that he isn't so great after all) and will definitely have problems while uploading images into his posts. So, we will give him an easy way to do this. Images Download the IMCE and Image modules. Install and enable them. It is also essential that you have the Upload module enabled. The TinyMCE editor (even though it is not essential) will permit Smart to edit his pages without knowing any HTML. Download the editor, if this feature is required. Having done this, return to Administer | Content management | Content types, and select the Publication Content type. At the bottom of the page, you will see a new panel for Image Attach settings. Enable Attach images, and now the Publication Content type will be ready to incorporate images. To confirm this, go to the Create content link for the Content type. Near the bottom of the page you will find the Attached images panel, as shown in the following screenshot, where you can upload images for your content. Do the same for the Blog entry, Story, and Page Content types. If you have configured your TinyMCE editor correctly, then you can similarly post images into the Body of your article by using the image upload function in TinyMCE. We will also ensure that the Attach images functionality has been enabled in all of the other Content types. Then, in the Workflow settings for each Content type, deselect the Promoted to front page checkbox, or else you will end up with a very unruly front page display. Create the About Me page The About Me page, as we have decided, should really be quite straightforward and will be created from the Story Content type, which is recommended for content that is static. From the admin menu, click on the Create content link, and then select Story. This will give you a form, which is similar to the following screenshot: The handy WYSIWYG (What You See Is What You Get) editor, which is an emulation of desktop software like MS Word or Open Doc (with which most people will probably be accustomed), will make it easy for Smart to create his personal information page, and format it to his satisfaction. Tips and trapsWe have used this approach because Smart is the only person having a personal profile on this web site. Otherwise, it will not be adequate, and we may have to call up some other modules, especially the CCK module, which will enable us to create new form fields to make submissions more intuitive (for example, to present defined fields for name, education, interests, and so on). Because Smart wants this to feature on the front page, we will just promote the About Me page to the front page before saving it. The Menu settings field is optional, and it is only used if you want to add the item to the menu system. We will add the About Me page to the <Primary links>.

At the end of this article, we will be able to: Identify the purpose of the several downloads that can be found at the JasperReports web site Set up our development and execution environment to successfully add reporting capabilities to our Java applications Identify the required libraries for adding reporting capabilities to Java applications Identify the optional libraries that can be used to enhance the reporting capabilities of our Java applications Downloading JasperReports JasperReports is distributed as a JAR file that needs to be added to the CLASSPATH of any application we wish to add reporting capabilities to. JasperReports can be downloaded from http://jasperforge.org/plugins/project/project_home.php?group_id=102. Clicking on the Download link around the center of the page will take us to the JasperReports download page on SourceForge.net. The specific version on your screen might be different; at the time of writing, the latest stable version of JasperReports is 3.5.2. It is not always clear what exactly is downloaded by clicking on these links; thus, we will provide a brief explanation of what each link is for. jasperreports-3.5.2-applet.jar: This first download link is for a JAR file containing a subset of the JasperReports functionality. Specifically, it contains classes that can be used to display JasperPrint files, which are reports in JasperReports' native format. This file is offered as a separate download as a convenience for developers; it can be used for applications or applets that don't need full reporting capabilities, yet need to display generated reports. Even though the filename has a suffix of "applet", there is nothing preventing us from using it with standalone applications, without the overhead that the missing JasperReports classes would add to the download. This file is approximately 346 KB in size. jasperreports-3.5.2.jar: This is the second download link, and it is the complete JasperReports class library. It contains all classes necessary to compile, fill, and export reports, but does not include any additional libraries that JasperReports depends on. This is the minimum file requirement for us to add full reporting capabilities to our Java applications. However, if we choose to download this file, we need to download the JasperReports dependencies separately. This file is approximately 2.2 MB in size. jasperreports-3.5.2-javaflow.jar: This is the third download link, and it is the javaflow version of JasperReports. This version of JasperReports should be used in environments where multithreading is discouraged. This file is approximately 2.2 MB in size. jasperreports-3.5.2-project.tar.gz: This is the fourth download link, and it contains the complete JasperReports class library plus all the required and optional libraries. In addition, it contains the entire file as a gzipped TAR file, which is common in Unix and Unix-like systems, such as Linux. This download also includes the JasperReports source code and a lot of source code providing examples of JasperReports' functionality. This gzipped TAR file is approximately 42 MB in size jasperreports-3.5.2-project.zip: The fifth download link, like the fourth link, contains the complete JasperReports class library plus all the required and optional libraries, along with the JasperReports source code. However, it contains the files in ZIP format, which is more commonly used under Microsoft Windows. This file is approximately 51 MB in size. Unless Internet connection speed is an issue, we recommend downloading one of the last two mentioned files, as they include everything we need to create reports with JasperReports. Another good reason to download one of these files is that the included examples are a great way to learn how to implement the different JasperReports features. All of the examples in the file come with an ANT build file containing targets to compile and execute them. We will refer to this file as the JasperReports project file, or more succinctly, as the project file. Once we have downloaded the appropriate file for our purposes, we need to set up our environment to be able to start creating reports. In the next section, we discuss how to do this, assuming that the project file was downloaded. Setting up our environment To set up our environment to get ready for creating reports, we need to extract the JasperReports project ZIP file to a location of our choice. Once we extract the project ZIP file, we should see a jasperreports-3.5.2 directory (The actual name of the directory may vary slightly depending on the version of JasperReports.) containing the following files and directories: build: This directory contains the compiled JasperReports class files. build.xml: This is an ANT build file, which builds the JasperReports source code. If we don't intend to modify JasperReports, we don't need to use this file as JasperReports is distributed in compiled form. changes.txt: This file explains the differences between the current and previous versions of the JasperReports' class library. demo: This directory contains various examples demonstrating several aspects of JasperReports functionality. dist: This directory contains a JAR file containing the standard, javaflow, and applet versions of the JasperReports library. We should add one of these JAR files to our CLASSPATH to take advantage of JasperReports functionality. docs: This directory contains a quick reference guide to most XML tags used in JasperReports templates. lib: This directory contains all the libraries needed to build JasperReports and to use it in our applications. license.txt: This file contains the full text of the LGPL license. pom.xml: This is a Maven 2 POM file used to build JasperReports with Maven, just like build.xml. We don't need this file because JasperReports is distributed in compiled form. readme.txt: This file contains instructions on how to build and execute the supplied examples. src: This directory contains the JasperReports source code. Getting up and running quicklyTo get up and run quickly, the files to add to the CLASSPATH are the JasperReports JAR files, and all the JAR files under the lib directory in the project ZIP file. By adding these files to the CLASSPATH, we don't have to worry about the CLASSPATH when implementing additional functionality, for example, when exporting to PDF or producing charts. JasperReports class library For all JasperReports-related tasks, we need to add the JasperReports library to our CLASSPATH. The JasperReports library can be found under the dist directory in the project file; it is named jasperreports-3.5.2.jar. Depending on the version of JasperReports, the filename will vary. Required libraries for report compilation The project file described earlier contains all of the required supporting libraries. Once that file is downloaded, all the required libraries can be found under the lib subdirectory of the directory created when extracting the ZIP file. JasperReports uses these required files for XML parsing. Therefore, they are needed when compiling JRXML files programmatically, not for filling or displaying reports. JRXML files can be compiled using a custom ANT task provided by JasperReports. If we choose to compile our JRXML files using this custom ANT target, these required libraries need to be added to the CLASSPATH variable of the ANT build file. There are example build files included in the project file and also at http://www.packtpub.com/files/code/8082_Code.zip. The following discussion about libraries highlights the fact that JasperReports makes extensive use of Apache Commons. Apache Commons Digester The Commons Digester library includes utility classes used to initialize Java objects from XML files. JasperReports takes advantage of the Digester component of the Apache Commons repository to implement its XML parsing functionality. Version 3.5.2 of the JasperReports project ZIP file includes version 1.7 of Commons Digester. The filename is commons-digester-1.7.jar, and it must be on your CLASSPATH for your JasperReports application to work correctly. If you downloaded the bare JasperReports class library, you will need to download Commons Digester separately from http://commons.apache.org/digester/. Apache Commons Collections Another component of the Apache Commons suite is the Collections component. This component provides functionality to complement and augment the Java Collections framework. JasperReports takes advantage of the Collections component of Apache Commons to implement some of its functionality. Like all required libraries included in the project ZIP file, the Commons Collections library can be found under the lib subdirectory of the directory created when extracting the project ZIP file. JasperReports project file version 3.5.2 includes version 2.1 of Commons Collections, distributed as a JAR file named commons-collections-2.1.jar. If you have downloaded the bare JasperReports class library, you will need to download Commons Collections separately from http://commons.apache.org/collections/. Apache Commons Logging Apache Commons Logging is a component of the Apache Commons that provides components to aid developers with sending data to log files. JasperReports takes advantage of this component, which can be found on the lib directory of the project ZIP file. The version included with JasperReports 3.5.2 is Commons Logging 1.0.2. The file to be added to your CLASSPATH is commons-logging-1.0.2.jar. If you have downloaded the bare JasperReports class library, you will need to download Commons Logging separately from http://commons.apache.org/logging/. Apache Commons BeanUtils The last library that JasperReports requires for compiling reports is Apache Commons BeanUtils. BeanUtils is a library that provides easy-to-use wrappers around the Java reflection and introspection APIs. Version 3.5.2 of the JasperReports project ZIP file includes BeanUtils 1.8; the file to add to your CLASSPATH is commons-beanutils-1.8.jar. If you have downloaded the bare JasperReports class library, you will need to download Commons BeanUtils separately from http://commons.apache.org/beanutils/. Optional libraries and tools There are a number of libraries that are required only if we wish to take advantage of some of JasperReports' features. These optional libraries and their uses are listed next. Apache ANT JasperReports comes bundled with some custom ANT targets for previewing report designs and for viewing reports serialized in JasperReports' native format. Although not strictly necessary, it is very helpful to have ANT available to take advantage of these custom targets. ANT can be downloaded from http://ant.apache.org/. JDT compiler JDT (Java Development Tools) compiler is the Java compiler included with the Eclipse IDE. The JDT compiler is needed only if the JasperReports application is running under a Java Runtime Environment (JRE) and not under a full JDK. When creating reports, JasperReports creates temporary Java files and compiles them. When using a JDK, JasperReports takes advantage of tools.jar for this functionality. As a JRE does not include tools.jar, the JDT compiler is needed. The JasperReports project file version 3.5.2 includes version 3.1.1 of the JDT compiler. It can be found under the lib directory of the directory created when extracting the project ZIP file. The file to add to your CLASSPATH is jdt-compiler-3.1.1.jar. This file cannot be downloaded separately; therefore, if we need to execute our code under a JRE. We need to download the JasperReports project ZIP file because it includes this file needed for report compilation. JDBC driver When using a JDBC datasource, which is the most common datasource for JasperReports generated reports, the appropriate JDBC driver for our specific RDBMS is needed. The following table lists popular relational database systems and the required JAR files to add to the CLASSPATH. The exact filenames may vary depending on the version, target JDK, and supported JDBC version. The filenames shown here reflect the latest stable versions targeted to the latest available JDK and the latest available version of JDBC at the time of writing. RDBMS Driver JAR Files Firebird jaybird-2.1.6.jar HSQLDB hsqldb.jar JavaDB/Derby (included with JDK 1.6+) derby.jar (embedded) derbyclient.jar (network) MySQL mysql-connector-java-5.1.7-bin.jar Oracle ojdbc6.jar PostgreSQL postgresql-8.3-604.jdbc4.jar SQL Server sqljdbc_1.2.2828.100_enu.exe (for Windows systems) sqljdbc_1.2.2828.100_enu.tar.gz (for Unix systems) Sybase Jconnect60.zip   The JasperReports project file includes the JDBC driver for HSQLDB. Consult your RDBMS documentation for information on where to download the appropriate JDBC driver for your RDBMS. iText iText is an open source library for creating and manipulating PDF files. It is needed in our CLASSPATH only if we want to export our reports to PDF or RTF format. Version 3.5.2 of the JasperReports project file includes iText version 2.1.0; the file to add to your CLASSPATH is iText-2.1.0.jar. The iText library can be downloaded separately from http://www.lowagie.com/iText/. JFreeChart JFreeChart is an open source library for creating professional looking charts, including 2D and 3D pie charts, 2D and 3D bar charts, and line charts. It is needed in our CLASSPATH only if we intend to add charts to our reports. JFreeChart 1.0.12 can be found on the lib directory inside the JasperReports project file version 3.5.2. The file to add to the CLASSPATH is jfreechart-1.0.12.jar. JFreeChart can be downloaded separately from http://www.jfree.org/jfreechart/. JExcelApi JExcelApi is a Java library that allows Java applications to read, write, and modify Microsoft Excel files. We need JExcelApi in our CLASSPATH only if we need to export our reports to XLS format. JasperReports 3.5.2 includes JExcelApi version 2.6. To add XLS exporting capabilities to our reports, the file we need to add to our CLASSPATH is jxl-2.6.jar. JExcelApi can be downloaded separately from http://jexcelapi.sourceforge.net/. Summary This article covered the required and optional libraries needed to add reporting capabilities to Java applications. All the libraries covered in this article are needed at both compile time and runtime. The article provided an explanation of the different files available for downloading on JasperReports' web site and in which conditions it is appropriate to use them. We also saw which libraries are required for report compilation under a JDK and the additional libraries required when compiling JRXML templates under a JRE. Besides, we also learned which libraries are required when using JDBC datasources for our reports, and finally the libraries required when exporting our reports to several formats.

Load testing an application helps the development and management team understand the application performance under various conditions. Load testing can have different parameter values and conditions to test the application and check the application performance. Each load test can simulate the number of users, network bandwidths, combinations of different web browsers, and different configurations. In the case of web applications, it is required to test the application with different sets of users and different sets of browsers to simulate multiple requests at the same time to the server. The following figure shows a sample of real-time situations for multiple users accessing the web site using different networks and different browsers from multiple locations. Load testing is meant not just for web applications. We can also test the unit tests under load tests to check the performance of the data access from the server. The load test helps identify application performance in various capacities, application performance under light loads for a short duration, performance with heavy loads, and different durations. Load testing uses a set of computers, which consists of a controller and agents. These are called rig. The agents are the computers at different locations used for simulating different user requests. The controller is the central computer which controls multiple agent computers. The Visual Studio 2008 Test Load agent in the agent computers generates the load. The Visual Studio 2008 Test Controller at the central computer controls these agents. This article explains the details of creating test scenarios and load testing the application. Creating load test The load tests are created using the Visual Studio Load Test wizard. You can first create the test project and then add the new load test which opens the wizard, and guides us to create the test. We can edit the test parameters and configuration later on, if required. Before we go on to create the test project and understand the parameters, we will consider a couple of web applications. Web applications or sites are the ones accessed by a large number of users from different locations at the same time. It is quite required to simulate this situation and check the application performance. Let’s take a couple of web applications. It is a simple web page, where the orders placed by the current user are displayed. The other application is the coded web test that retrieves the orders for the current user, similar to the first one. Using the above examples we will see the different features of load testing that is provided by Visual Studio. The following sections describe the creation of load testing, setting parameters, and load testing the application. Load test wizard The load test wizard helps us create the load test for the web tests and unit tests. There are different steps to provide the required parameters and configuration information for creating the load test. There are different ways of adding load tests to the test project: Select the test project and then select the option Add | Load Test... Select the test menu in Visual Studio 2008 and select New Test, which opens the Add | New Test... dialog. Select the load test type from the list. Provide a test name and select the test project to which the new load test should be added. Both the above options open the New Load Test Wizard shown as follows: The wizard contains four different sets with multiple pages, which collects the parameters and configuration information for the load test. The welcome page explains the different steps involved in creating a load test. On selecting a step like Scenario or Counter Sets or Run Settings, the wizard displays the section to collect the parameter information for the selected set option. We can click on the option directly or keep clicking Next and set the parameters. Once we click on Finish, the load test is created. To open the load test, expand the solution explorer and double-click on the load test, LoadTest1. We can also open the load test using the Test View window in the Test menu and double-click on the name of the load test from the list to open the Test Editor. For example, the following is a sample load test: The following detailed sections explain setting the parameters in each step: Specifying scenario Scenarios are used for simulating the actual user tests. For example, there are different end users to any web application. For a public web site, the end user could be anywhere and there could be any number of users. The bandwidth of the connection and the type of browsers used by the users also differ. Some users might be using a high-speed connection, and some a slow dial-up connection. But if the application is an Intranet application, the end users are limited within the LAN network. The speed at which the users connect will also be constant most of the time. The number of users and the browsers used are the two main things which differ in this case. The scenarios are created using these combinations which are required for the application under test. Enter the name for the scenario in the wizard page. We can add any number of scenarios to the test. For example, we might want to load test the WebTest3 with 40 per user per hour and another load test for WebTest11Coded with 20 per user per hour. Now, let us create a new load test and set the parameters for each scenario. Think time The think time is the time taken by the user to navigate to the next web page. This is useful for the load test to simulate the test accurately. We can set the load test to use the actual think time recorded by the web test or we can give a specific think time for each test. The other option is to set the normal distribution of the think time between the requests. The time varies slightly between the requests, but is mostly realistic. There is a third option, which is configured not to use the think times between the requests. The think times can also be modified for the scenario after creating the load test. Select the scenario and right-click and then open Properties to set the think time. Now once the properties are set for the scenario, click Next in the New Load Test Wizard to set parameters for Load Pattern. Load pattern Load pattern is used for controlling the user loads during the tests. The test pattern varies based on the type of test. If it is a simple Intranet web application test or a unit test, then we might want to have a minimum number of users for a constant period of time. But in case of a public web site, the amount of users would differ from time to time. In this case, we might want to increase the number of users from a very small number to a large number with a time interval. For example I might have a user load of 10 initially but during testing I may want the user load to be increased by 10 in every 10 seconds of testing until the maximum user count reaches 100. So at 90th second the user count will reach 100 and the increment stops and stays with 100 user load till the test completion. Constant load The load starts with the specified user count and ends with the same number. User Count: This is to specify the number of user counts for simulation. Step load The load test starts with the specified minimum number of users and the count increases constantly with the time duration specified until the user count reaches the maximum specified. Start user count: This specifies the number of users to start with Step duration: This specifies the time between the increases in user count Step user count: This specifies the number of users to add to the current user count Maximum user count: This specifies the maximum number of user count We have set the parameters for the Load Pattern. The next step in the wizard is to set the parameter values for Test Mix Model and Test Mix. Test mix model and test mix The test load model has to simulate the accuracy of the end-users count distribution. Before selecting the test mix, the wizard provides a configuration page to choose the test mix model from three different options. They are based on the total number of tests, on the virtual users, and on user pace. The next page in the wizard provides the option to select the tests and provide the distribution percentage, or the option to specify the tests per user per hour for each test for the selected model. The mix of tests is based on the percentages specified or the test per user specified for each test. Based on the total number of tests The next test to be run is based on the selected number of times. The number of times the tests is run should match the test distribution. For example, if the distribution is like the one shown in the image on the previous page, then the next test selected for the run is based on the percentage distributions. Based on the number of virtual users This model determines running particular tests based on the percentage of virtual users. Selecting the next test to be run depends on the percentage of virtual users and also on the percentage assigned to the tests. At any point, the number of users running a particular test matches the assigned distribution. Based on user pace This option determines running each test for the specified number of times per hour. This model is helpful when we want the virtual users to conduct the test at a regular pace. The test mix contains different web tests, each with different number of tests per user. The number of users is defined using load pattern. The next step in the wizard is to specify the Browser Mix, explained in the next section. Browse mix We have set the number of users and the number of tests, but there is always a possibility that all the users may not use the same browser. To mix the different browser types, we can go to the next step in the wizard and select the browsers listed and give a distribution percentage for each browser type. The test does not actually use the specified browser, but sets the header information in the request to simulate the same request through the specified browser. Like different browsers, the network speed also differs with user location, which is the next step in the wizard. Network mix Click on Next in the wizard to specify the Network Mix, to simulate the actual network speed of the users. The speed differs based on user location and the type of network they use. It could be a LAN network, or cable or wireless, or a dial-up. This step is useful in simulating the actual user scenario. The next step in the wizard is to set the Counter Sets parameters, which is explained in the next sections. Counter sets Load testing the application not contains the application-specific performance but also the environmental factors. This is to know the performance of the other services required for running the load test or accessing the application under test. For example, the web application makes use of IIS and ASP.NET process and SQL Server. VSTS provides an option to track the performance of these services using counter sets as part of the load test. The load test collects the counter set data during the test and represents it as a graph for a better understanding. The same data is also saved locally so that we can load it again and analyze the results. The counter set is for all the scenarios in the load test. The counter set data is collected for the controllers and agents by default. We can also add the other systems that are part of load testing. These counter set results help us to know how the services are used during the test. Most of the time the application performance is affected by the common services or the system services used. The load test creation wizard provides the option to add the performance counters. The wizard includes the current system by default and the common counter set for the controllers and the agents. The following screenshot shows the sample for adding systems to collect the counter sets during the load test: There are lists of counters listed for the system by default. We can select any of these for which we want to collect the details during the load test. For example, the above screenshot shows that we need the data to be collected for ASP.NET, .Net Application, and IIS from System1. Using the Add Computer... option, we can keep adding the computers on which we are running the tests and choose the counter sets for each system. Once we are done with selecting the counter sets, we are ready with all the parameters for the test. But for running the test some parameters are required, which is done in the next step in the wizard.

The one thing to keep in mind is that when designing your Active Directory, never go at it from a, present needs, point of view. Technology and systems are changing so fast nowadays that you have to design with the most open and future-proof concept that you can think of. It was only a few years back when Windows 95 revolutionized the personal computing platform by pushing 32-bit addressing to the mainstream. Before that it was 14 years where everyone ran 16-bit programs on 16- or 32-bit processors. In April 2003, Microsoft launched the 64-bit version of its Server Operating System and in April 2005, the 64-bit version of its Desktop Operating System, Windows XP. These are less then a decade after the big Windows 95 push. Active Directory was introduced with Windows 2000, which is only Five years after Windows NT 4's "enhanced omain structure". The trend is that new features and new technologies are constantly being invented and introduced. While there are quite a few companies that have a proper open and flexible design in their Active Directory structures, there are a lot more organizations that see Active Directory as the answer to all their prayers and just keep adding things to it and to the schema. To read more about the technical aspects of the AD schema, please refer to http://msdn2.microsoft.com/en-us/library/ms675085.aspx. Software companies nowadays are pushing "Active Directory compatible" features more and more, and problems can arise when these packages need complete domain administrator rights in order to function (or modify the Active Directories' inner workings), which they usually do not advertise up-front. The need for proper planning and design of the AD is extremely high in order to ensure that your DR strategies will work and are easy to implement. A properly designed AD is extremely resilient and still very flexible. Whenever you intend to add new services, make sure that you test and re-test the things that are necessary for the service to function properly. As the IT department, you are responsible to keep the systems going and ensure business continuity. Active Directory elements When designing an Active Directory, you need to be completely clear of what each element or part actually means and how it fits into the overall design. The old saying goes: You can't see the forest because of the trees, and you can apply this to Active Directory as well. It is all about trees and forests and leaves and branches. The Active Directory forest The forest, in terms of Active Directory, basically means every domain, organizational unit, and any other object stored within its database. The forest is the absolute top level of your Active Directory infrastructure. Of course, you can have more than one forest in a company, which actually represent security boundaries, and can therefore improve security between different business units or companies belonging to a single organization. The point behind the forest is that you have all your domains and domain tree within your organization contained within it. It is designed so that you can have transitive trust-links between all of the trees within one forest. To read more about the technical layout of AD, please read Domains and Forests Technical Reference at: http://technet2.microsoft.com/windowsserver/en/library/16a2bdb3-d0a3-4435-95fd-50116e300c571033.mspx. To visualize a forest with its parts, please see the following image. The Active Directory tree A tree in Active Directory refers to a domain and all of its objects that adhere to a single DNS name. For example, a tree of nailcorp.com would contain all other domains that end with "nailcorp.com". So, americas.nailcorp.com, europe.nailcorp.com, and asia.nailcorp.com all belong to the Active Directory tree of nailcorp.com. You cannot separate these unless you create a whole new forest for a sub-domain. Organizational Units and Leaf Objects In Active Directory, Organizational Units (OU), which are also called Containers, and Leaf Objects, which are non-containing objects such as computer accounts and user accounts, are directly related and even though you could have objects that do not belong to an OU, it isn't recommended and isn't really feasible. Organizational Units are comparable to folders in a filing cabinet, and objects are the files. You can move files between different folders, and classifications or properties are applied to the files within a folder. For example, if you move a file into a folder classified "Top Secret", the file will automatically fall under that classification. The same applies to objects within an OU, all properties or rules that apply to the OU apply to the objects within it. OUs, however, are mostly useful from an administrative point of view, not from an user's point of view. If you think of how your files are organized, for example, on your computer, they are most likely to be organized into different folders. You can go ahead and set different folder settings, such as permissions, and it will affect all of the files within that folder, but anything outside that folder won't have its permission affected. It is exactly the same principle with OUs. Any OU that will be created within an OU will contain all of the policy settings of the parent unless you change them. An object can also only belong to a single OU, just as a single file can only be contained within a single folder. Leaf objects in Active Directory can be users, contacts, and computers. Or in short, any object that cannot contain other objects. They are called leaf objects because they are like leaves on a tree. And, as you can guess, they are the "lowest" class of objects within Active Directory. But if you now look at the forest-tree-branch-leaf concept, it is starting to make sense. You can access the OUs and other objects through the Microsoft Management Console (MMC) or through the Users and Computers tool in the Administrative Tools. This second option actually just invokes the MMC with the correct view and is a lot quicker, as seen in the following screenshot: Active Directory Sites The Sites and Services MMC snap-in is a utility that a lot of Windows administrators, particularly in smaller organizations, completely overlook. This part of Active Directory, however, is one of the most crucial parts to understand and implement correctly. If you have several locations in your organization, you need to know about Active Directory Sites. Sites give you a very unique and well-designed approach to separate specific locations within your Active Directory. As the principle of an Active Directory domain is global-meaning that it is meant to be the same anywhere-it could present a problem for users who move from office to office, or for offices with network connections that are slow. Active Directory sites allow you to specify the IP address spaces or subnets used within your organization and, therefore, bring the structure of your network into Active Directory. The usefulness of having properly organized and maintained Sites becomes more evident when you consider that any machine within an address space will use that Sites' DC to authenticate. This is a great feature of AD and reduces unnecessary traffic. However, it requires having Sites and subnets properly updated and maintained. This is also particularly useful for defining different replication schedules for different locations within the same domain, and also to support users who travel. Once they log on through the other location, they are assigned an IP address from that network. The Windows locator service will then look up which DC is the nearest one, and the user won't log on all the way to their usual DC (to read more about how the locator service works please refer to http://support.microsoft.com/kb/314861). This saves bandwidth and speeds up the authentication process. Bandwidth nowadays is cheap, especially in developed countries such as the USA or most parts of Western Europe. But just because it is cheap in some parts, does not mean it is cheap in other parts of your organization. If you are primarily located within developed countries, but your then company decides to open 10 or 20 small sales offices within not-so-developed countries, where bandwidth is expensive, then you really need to start using AD sites. Of course, the problem then is that because you haven't used AD sites before, you need to make the appropriate changes to your infrastructure to accommodate them, and train staff appropriately in order to be able to implement, support, and manage them. In this example, the argument might be brought up that each of these small branch offices has a local DC that also functions as a File and Print server where the local employees collaborate. This is great, but what about replication to and from your Hub site? Which is the data centre that hosts a critical part of your Active Directory backend? If changes to your AD are fairly frequent, for example, adding and removing users on a regular basis, then the Active Directory will replicate—if the Site links are properly configured—without compression every 15 minutes. Of course, depending on the size of your organization, this can be quite a strain on the link you have from that office. If the people at that office receive email and browse the Web over the same link, network performance will degrade significantly for users and cause unnecessary inconvenience. To see what Sites look like in the Active Directory Sites and Services console, see the following screenshot: Group Policy Objects Group Policy Objects in Active Directory are a set of defined rules for settings about the user environment or the operating environment for a particular PC. They are treated as standalone objects because they can be linked to different OUs. This gives you the flexibility of creating one set of rules and applying it to different OUs in different OU structures, making settings deployment much easier and administratively quick. The policy settings are quite extensive and if you want to get your hands dirty, you can create your own policy templates, giving you even more control over the machines and application settings located in your domain. There are templates available for many settings, ready to use. The templates for these settings are called ADM templates and there are quite a few already included in the Windows 2003 installation. Some applications, such as Microsoft Office 2007, also provide ADM templates that can be loaded and modified (see http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=92d8519a-e143-4aee-8f7a-e4bbaeba13e7 for Office 2007 ADM templates). Using ADM templates, you do not need to write anything by yourself, and so it is a quicker way apply to GPO settings. The following screenshot shows Office 2007 ADM templates loaded in the Group Policy Editor.

Tones Let's work from the inside out. The types of call progress tones played to the callers once they are within Asterisk are set in indications.conf, which is, of course, one of the many .conf files to be found in the /etc/asterisk directory. On opening indications.conf, you will find that the default set of tones to be used (by the pbx_indications module) is specified in the [general] section with a two letter country code. The next example, shows the way the first few lines of the file look on a fresh installation, prior to any changes: ; indications.conf; Configuration file for location specific tone indications; used by the pbx_indications module.;; NOTE:; When adding countries to this file, please keep them inalphabetical; order according to the 2-character country codes!;; The [general] category is for certain global variables.; All other categories are interpreted as location specificindications;;[general]country=us ; default location The highlighted code shows the country specified by the two letter country code. If indications.conf is missing, Asterisk will assume that you want to use the US tone set. There are a number of separate sections in the files, each headed with a two letter country code in square brackets, which describe the actual tones for that country in terms of frequencies and cadences, along with the odd explanation or cryptic note left there by the compiler of the tones for a given country. Here we see the entry for the UK: [uk]description = United Kingdomringcadence = 400,200,400,2000; These are the official tones taken from BT SIN350. The actual tones; used by BT include some volume differences so sound slightly; different from Asterisk-generated ones.dial = 350+440; Special dial is the intermittent dial tone heard when, for example,; you have a divert active on the linespecialdial = 350+440/750,440/750; Busy is also called "Engaged"busy = 400/375,0/375; "Congestion" is the Beep-bip engaged tonecongestion = 400/400,0/350,400/225,0/525; "Special Congestion" is not used by BT very often if at allspecialcongestion = 400/200,1004/300unobtainable = 400ring = 400+450/400,0/200,400+450/400,0/2000callwaiting = 400/100,0/4000; BT seem to use "Special Call Waiting" rather than just "CallWaiting" tonesspecialcallwaiting = 400/250,0/250,400/250,0/250,400/250,0/5000; "Pips" used by BT on payphones. (Sounds wrong, but this is what BT; claim it; is and I've not used a payphone for years)creditexpired = 400/125,0/125; These two are used to confirm/reject service requests on exchanges; that don't do voice announcements.confirm = 1400switching = 400/200,0/400,400/2000,0/400; This is the three rising tones Doo-dah-dee "Special Information; Tone",; usually followed by the BT woman saying an appropriate message.info = 950/330,0/15,1400/330,0/15,1800/330,0/1000; Not listed in SIN350record = 1400/500,0/60000stutter = 350+440/750,440/750 So, once you have chosen your country by changing (if necessary) the two letter country code, you just need to save the file and reload. You will now hear those tones when a call is being handled inside Asterisk. The word "inside" has been stressed as all calls are initiated outside of Asterisk, and will come in from SIP, IAX2, or analog phones, or trunks of one description or another. The nature of the tones you hear through these devices is not the responsibility of Asterisk, although Asterisk will dictate the type (busy, ringing, and so on) that you hear. Therefore, now we need to step outside of Asterisk and deal with those tones. SIP and IAX phones are easy to deal with, as these devices generate the tones themselves. So, when you lift the handset on say, an SIP phone, you will hear a dial tone whether the device is connected to an IP telephony network or not. Contrast this scenario to the original reason for the dial tone. The clue is in the name "dial tone". It was originally a "confidence tone" to signal to the users that they were indeed connected to a telephone exchange, and that they could now dial a number. Of course, this is still the case with traditional telephony connections. How things changed in the world of IP—all a dial tone in the earpiece of an IP phone will tell you is that your IP phone is alive, and the curly cord to the handset works. In order to change the nature of the tones you hear from your SIP or IAX phones, you will need to change parameters on the phones themselves, usually, via their web interfaces. Asterisk only tells these telephones which tones to play (through the protocol being used for call control). It is on the phones themselves that you will need to change the tones. We have now seen how to change the tones that Asterisk provides to calls which it is terminating, and we have seen that the tones heard through SIP and IAX phones (prior to the call being terminated by Asterisk) must be changed on the devices themselves. Let us now consider the tones that will be used (both recognized and generated) for analog telephony. If analog devices are connected through ATAs (Analog Telephony Adaptor), then the tones will again be changed on the ATA devices themselves, as tone generation and recognition is part of their job. However, if we connect our analog devices to Asterisk through a Digium card, we will need to configure these tones as part of the DAHDI (formerly Zaptel) setup. In the /etc/dahdi/ directory a file called system.conf (formerly etc/zaptel.conf) will be found with the code: loadzone=usloadzone=ukloadzone=nldefaultzone=us We are interested in two parts of the configuration in this file—loadzone that loads a set of tones to be used with the analog card(s), you can load as many sets as you want (details of the actual tones are found in zonedata.c), and, defaultzone that defines the tone set you will use as standard when handling calls. Remember, we are only talking about the tones that will be recognized or generated on analog channels here. If you want to employ some tones which are loaded, but not default, this is easily done within the dialplan using the Playtones() application. That was about the tones. Here is a quick list and a picture to help you remember: Tones that will be heard once a call is inside Asterisk are chosen and specified in indications.conf Tones heard on SIP or IAX phones (prior to the call being answered by Asterisk) are set on the devices themselves Take a look at the next figure to reinforce this: Time and date and localization Although the actual system time and date for your Asterisk machine will only be affected by the setting in Linux, it is quite possible to make Asterisk aware of as many time zones as necessary, and to alter the way time and date are set out and spoken within Asterisk. When you think about the need to manifest different time zones and spoken localization (other than the language itself—we'll come to that), it really occurs only in voicemail transactions. When you are being told at what time and on which date a message was left, you will want to hear it in your local time zone, regardless of where the Asterisk server is located. Moreover, you will want to hear the time and date spoken in a way that you naturally understand, rather than having to struggle to interpret the information while it is given to you in some alien form. Fortunately, Asterisk recognizes this fact and allows different "voicemail zones" to be set, which dictate the time zone and the way in which the time and date are announced. These settings are created in the [zonemessages] section of voicemail.conf, and further down the file, the voicemail zone for each voicemail box can be specified as an option (if required) where voicemail boxes are specified.

Theming custom components So far our theme file has specified attributes for the standard components supported by the library. It is possible to use theming for custom components too. To try this out, we shall use the TimeTeller component. The two interfaces and the two classes that together make up that component have been put into a package named book.newcomp to make the code better organized. A timeteller is added to the form by uncommenting the relevant statements shown in the MIDlet code snippet listed earlier in this article. However, note that we have not set any style for the timeteller instance. Without any entry for TimeTeller in the theme file, the screen looks similar to the following screenshot: We can see that the two labels of the timeteller are properly styled, while the overall component background has the default color. This happens because the labels have been explicitly styled through code while creating the timeteller. If you experiment with the theme file, then you will see that it is not possible to affect the styles of the TimeViewer part of the component through the file. This can be explained when we consider how theming works. When the setThemeProps method is executed, the UIManager instance transfers values from the theme file into respective style objects by using the UIID of a component as the key. Obviously, if a component does not have its own UIID, its style cannot be set through the theme. The TimeViewer class has not been allocated a UIID and that is why it will not be affected by any entry in the theme file. TimeTeller, on the other hand, does have a UIID, and we can therefore set its attributes through the theme file. In order to do that, we click on the Add button to get the Add dialog. In the Component field, we type in TimeTeller and set bgColor following the usual procedure. A click on the OK button enters the value in the theme. The following screenshot shows three entries for TimeTeller: The result of setting these attributes can be seen in the following screenshot: Manual styling versus theming We know that an attribute can be set for a specific widget by using a settermethod of theStyleclass. Let's take a concrete example. In our demo MIDlet, we have manually set background colors for the two labels of the timeteller. We have also defined a different set of background colors for labels in general through the theme. We need to understand which setting takes precedence when conflicting attributes are set in this way. The API documentation tells us that there are two types of methods for setting attributes. For setting background colors, the methods are setBgColor(int bgColor) and setBgColor(int bgColor, boolean override). If the first method is used to manually set the background color of a widget, then a theme file entry will not be effective for that particular component instance. However, all other instances of the same component will be styled as per the theme file, provided manual styling using the same method has not been done. In this case, we have used the setBgColor(int bgColor) method to set background colors for the two labels within the timeteller. Therefore, the theme file has no effect on these two labels, although it does determine the corresponding color for the other label on the form. On the other hand, when the setBgColor(int bgColor, boolean override) method is used and the Boolean parameter is true, theme settings will override any manual styling. There is another way to allow a theme to override manually set style attributes. If we create a new style object and pass all the options in the constructor, then setting a theme file will change the attributes of such a style object. Theming on the fly One feature of theming that we have not talked about so far is that it is possible to change themes at runtime by using the setThemeProps method of UIManager. But when a theme is set on the fly there will be, in general, components that are not visible, and the effect of setting a theme on these components is not predictable. In order to make sure that even the components that are not visible have their styles properly updated, you should call the refreshTheme method using code like this: Display.getInstance().getCurrent().refreshTheme(); When a theme is installed at runtime, there may be form instances that have been created earlier and are to be displayed later. In order that the newly installed theme may take effect on these forms too, it is necessary to call refreshTheme on all such forms before they are shown on screen. For forms that are created after the theme is set, no such action is required, as the respective style objects will be initialized to the theme settings. In the current example, demoForm was instantiated after the theme was installed, and accordingly, refreshTheme was not invoked.

Design your Active Directory In most corporations and large organizations, there are people with job titles such as "Network Architect", "Windows Server Configuration Owner" or "Network Designer". These people do not have these titles just for fun. In large organizations, there is an actual need for people whose sole purpose is to design or optimize the networking topology according to how technology progresses. This is also valid for people who work in the Security and the actual Business Solutions sections of large corporations. There are always new ways of doing things and new designs surfacing in the IT world, and those people need to stay on top of their respective fields. If you are a medium to small-sized company, you can probably combine all of those roles into one person or have several roles distributed over few people. This is especially true for Windows Server architecture and Active Directory. When designing your Active Directory, you need to really open your mind and focus on the future. A bit of clairvoyance doesn't hurt here. The problem with an Active Directory design for a medium to large-sized company is actually two-fold. One, you need to be able to make your design scalable in the future and two, you need to be able to migrate to your new architecture with the least user impact. In order to make this a bit easier, here are two small checklists. The first one contains things to consider when designing a global AD, and the second one is a checklist of things to consider when finalizing the design, or when migrating. These points are not in any particular order as they should all be considered. Checklist When Designing a New AD Is the name future-proof (DNS)? Do you own the DNS name? How many users are in each office? What's the bandwidth available between offices? Is it enough for smaller offices to authenticate in a central location? Who will administer the AD? Who will perform day-to-day tasks (password resets, user and computer account creation)? Are there plans to build on the AD with additional services, such as Exchange, SharePoint etc.? Which DCs will be Global Catalog Servers? Where will the FSMO roles be located? Will the new design support all the current business functions? If not at the beginning, will there be a transition period and if so how long? Have you cleared this with business? Will all the third-party applications still work with this design? Checklist When Finalizing the Design or When Migrating to an AD Have you chosen a design? If yes, have you considered the model carefully, taking into account future growth? Is the DNS name available and is it future-proof? Have you calculated the appropriate number of DCs? Have you considered DC failover and the network strain? Is the number of administrators and their roles clearly defined? Do you have processes for change mangement in place? If no, should you? Do you have back-up designs and solutions in place where it matters (hub sites and data centers)? Is your staff trained or will there be training to bring them up-to-date with the new methodologies? How significant will the user impact be? Are mechanisms in place to inform the users of the coming changes? Are all networked applications accounted for? Have service accounts been assigned and possibly consolidated across the enterprise? Is a realistic implementation schedule in place? Has it been approved and discussed? Naming standards Before you begin to design anything, you need to make sure that you have a naming standard for everything across your entire organization. If this is missing, and everyone just decides what to name the GPO and computers, how usernames are formatted, how service accounts are named, etc., then you will never have a proper structure. Username and service account naming There are endless ways of naming your user accounts and you probably already have one or another in place. If, however, you have a multitude of different ways because of acquisition, or autonomy of certain offices in the past, defining a universal way of naming user accounts is crucial. This will not only help you with administration, but also with deploying services across your organization. If you name the service accounts using a standard, every administrator knows exactly what the account is for. When you name the users in a standard way, processes regarding user administration can be very streamlined. You should also consider the lockdown of service accounts, for example by defining what machine they can authenticate from and what they can access. The same goes for user accounts. Group policy naming A common thing for administrators to do is name group policies after what they see as the most logical thing at that moment. You should have clear guidelines of how to name GPO's so that they make sense even to a new person. "Internet Explorer Test 3" as a GPO name is not anything that you could guess what it includes, or to whom it applies. Naming conventions are overlooked a lot of the time, not only for GPOs but for many administrative things that do not seem to matter at the time. In short, the naming of the GPO is important so that you can immediately know what the policy does and who it applies to. This makes troubleshooting much easier. The following figure shows GPOs named with a little bit more sense, as it shows that the policy is global and that the settings that these policies set are for users and computers. Design with scalability in mind Whenever you read books or white papers about Active Directory, they mention the amazing scalability of Active Directory, its security features, and the redundancy. Active Directory was coded from the ground up with mechanisms that make it easy to add or remove domain controllers. With this ability, features are built in to failover to the next domain controller in case of a failure in one of them. The client never really knows about this. On paper, this is a great thing and reduces the administrative overhead. In practice, it is just as good. Large corporations can have Active Directory structures that work so perfectly that the administrators really do not have to worry about anything regarding stability. This applies even when there are more then 30,000 users over several countries and almost twice as many computer accounts. As the saying goes: "Behind every strong man stands a strong woman". The same goes for Active Directory: "Behind every perfectly working Active Directory, there is a good architect". Microsoft's recommendation is to have 150 users per domain controller. This is a good recommendation yet you do not need to take it 100% verbatim. In any site with 150-200 users, you should have at least two domain controllers. This is not meant as an issue of scalability but more of a failover issue. In a case of 400 users for example, Microsoft recommends, according to their white paper, three domain controllers. For 400 users in a single site that is a lot. Considering that the heavy load on the domain controllers will be in the morning when people arrive and log in, and after lunch when people log in again, most of the time the domain controllers will sit idle. In this case, the recommendation is rather to spend a bit extra on more RAM and more CPU power than on an extra machine. If your network is well-designed and your domain controllers have a little more power, you can load a relatively large number of users onto them. It is not unheard of to have over 600 users per domain controller in a large organization and the average load during the day is around 40%. It rises during peak hours of logon and logoff, as is expected, but quite a lot of time they are almost idle. The key factor here is memory and CPU. If the amount of RAM you have is twice the size of your Active Directory database, the database will be loaded completely into memory by the domain controller. This, combined with a server-class CPU such as XEON or Opteron, will reduce the processing time during authentication per user to fractions of a second. If you could only authenticate five people per second on a domain controller, it would take you two minutes to authenticate 600 users. And 600 users do not all arrive at work at the same time and log in at the exact same time. Scalability in Active Directory is achieved through the distributed model that it builds on. Every domain controller is writable in the AD and holds more-or-less a complete copy of the directory. When changes occur in one site on one DC, these changes are then replicated out to all the others. This architecture is radically different from Windows NT 4, where there was a primary domain controller and many backup domain controllers. There is only one problem with this set-up, and this becomes apparent when you have a lot of distributed domain controllers and a lot of sites. If you do not invest time into the design of the sites and site links, you can cause a lot of damage and a lot of unnecessary traffic in a very short time. Site links are there to provide ways of controlling when and how the Active Directory is replicated to other domain controllers. You do not want to end up replicating a 2GB database during business hours over a 2 Mbit link. However, if you do not properly document and implement a good replication design, unnecessary delays will happen. You will then have the nice job of finding out where the replication went wrong, and depending on the number of sites you have, this can be a non-trivial task. The following figure shows different replication schedules and site links that make it quite normal for one site to have a six to eight hour delayed version of the Active Directory. Replication schedules are not difficult to design and implement, but do require a bit of time and input from other sources. Remember, because Active Directory is so distributed, the site with the slowest site link and the slowest replication will have the most outdated version of Active Directory. It is recommended that in case something unexpected happens, such as dismissing an employee in a remote office, you force-replicate between the main site and that site-as soon as the changes are made. If the person is leaving in two week's time, set his or her account on the date they are scheduled to leave and then verify that the data has been replicated after this date. Flexible Single Master Operation Roles (FSMO) When you design your topology, you have to be aware of the Flexible Single Master Operation Roles (FSMO) and place them accordingly. FSMO roles are roles that only one server in an Active Directory can have. These roles, while not apparent immediately and not needed all the time, are very important, and some of them are very crucial. There are five FSMO roles and they must be present in an Active Directory. Three of these roles are domain-specific, which means that in every domain in an AD forest, they have to be present. The other two are forest-specific and therefore one of each needs to be present in each of your AD forests. See the table below for a few summary of roles and where they belong: Name of the role Where is it needed RID Master (Relative ID Master) In each domain Infrastructure Master In each domain PDC Emulater In each domain Schema Master In each forest Domain name Master In each forest Each role does different things and in order to understand the importance of the roles, a full description of each role, and the steps you need to take to see which server has what role, is given below: Relative ID Master (RID Master) This role allocates security RIDs to DCs within a domain. The DCs use the allocated RIDs and in turn allocate them to security principals, such as users and computers, as they are added. The server that has this role also manages the movement of objects between domains. It monitors all of the pools allocated to all of the DCs within a domain and in doing so allocates more RIDs where needed, to prevent these pools from becoming exhausted, which would result in the inability to create new user or computer accounts. Infrastructure Manager The server having this role maintains security Globally Unique Identifiers (GUIDs) and Distinguished Names (DNs) for all objects that are referenced across different domains. However, its most common task is to update user and group links. PDC Emulator This is a crucial role, not only because it emulates a Primary Domain Controller for Windows NT, but because other DCs look at the PDC as the primary source for confirmation of authentication, and it is the most trusted source for time within a domain. To change any of the three domain-specific roles, open Active Directory Users and Computers, right-click on the domain name and click on Operations Masters. You will then get the following screen where you can assign the roles in your domain. Schema Master The server having this role maintains all schema information and all modifications to the schema. The schema in a forest determines what types of objects are permitted and what types of attributes an object can have. A typical scenario for this role would be an installation or deployment of Exchange, or an upgrade from Windows 2000 to 2003, because these operations contain schema modifications.

Local telephony interfaces Having set the tones, announcements, and language so that your users feel at home, the next task is to physically connect our Asterisk to the outside (telephony) world. Fortunately, the RJ-45 is ubiquitous as far as Ethernet connectivity is concerned, so attention can be focused on traditional telephony connections. Analog It is a fairly safe bet that whatever equipment you choose to connect your analog lines and phones to Asterisk, whether you have gone with an ATA or a Digium card, the termination will be with an RJ-11 socket (with the middle two pins used for the pair). This means that the lead that plugs into that RJ-11 socket becomes a mission-critical accessory, which, in a number of cases, is not shipped with your equipment. You need to be absolutely sure that the lead you use has the right pin to pin connections as well as the right connectors at each end. This may seem like stating the obvious, but it is included as a result of a Digium support case where a customer in the UK reported that the analog card they were using was faulty. The case got to the stage where the support team remotely accessed the machine in the UK and established that there appeared to be an unexpected voltage on one of the legs of the telephone line. When someone questioned the patch lead connecting the card to the PSTN, only then was it established that the customer had just picked up a lead that had the right ends and plugged it in, without worrying about whether the electrical connections were right. It turned out that the lead was probably for some old modem and it cross-connected some of the pins. Of course, physical connectivity is essential, so is ensuring that the pinouts are correct. In the left part of the following picture, we can see the type of lead in question. It has an RJ-11 at one end, and a BT (British Telecom, the main telco in the UK) plug at the other. To the right is a picture of the two ends of the lead that would be required to connect to an analog telephone line in Korea. This has been included to give an idea about the diversity of connectors that are used around the world. From a regulatory standpoint, it should be pointed out that only analog telephony cards and ATAs with the appropriate approvals should be connected to the telephone network in a given country. The main learning point here is to ensure that you consider physical connectivity as part of your localization planning. Digital Digital telephony interfaces will be in two groups—basic rate access (otherwise known as BRI or ISDN2), and primary rate access (otherwise known as PRI, E1, T1, or ISDN, and sometimes ISDN30 in countries where 30 voice channels are used). BRI is almost universally connected using an RJ-45 patch lead, which will look like a standard Ethernet patch, but if more closely inspected, it becomes apparent that only four wires are connected. PRI connectivity started being implemented using two BNC connectors (one for transmit and one for receive), but is more commonly connected using RJ-45s these days. Note that a PRI patch lead with RJ-45s at each end will be different from a BRI patch cable, which as mentioned, is different from an Ethernet patch. So, label your cables! In countries such as the UK, you would not expect to find signaling systems with telco presentation on co-axial connections, but many countries (for example, those found in South America) still utilize R2 signaling, which may well be presented using co-ax. Most PRI apparatus (including telephony cards) will use RJ-45 sockets these days. Therefore, it may be possible that in some countries you are presented with a situation where the telco is giving you two BNC connectors, but your equipment wants an RJ-45 plug. This is simply remedied by using a balun (so named because it is connecting a balanced interface, the RJ-45 end, to an unbalanced interface, the BNC end). Here is a picture: When I say "simply remedied", that is as long as you have thought of it in advance, and ordered these inexpensive, yet very useful adapters. If you have not thought of it prior to implementation and find yourself in need of a balun, be prepared to wait to get them shipped. These are not items you will find at the corner store. Localizing caller ID signaling on Digium analog interfaces Given the work we have already identified how to localize your Asterisk telephony solution in the previous article, it will not come as a complete surprise to learn that the method used to send caller ID information over analog lines varies from country to country. Fortunately, Asterisk is capable of recognizing many different types of caller ID signaling. This should not be a problem as long as you remember to set up the correct type for the country where the system will be connected. All caller ID settings are made in chan_dahdi.conf (formerly zapata.conf), which is found in the /etc/asterisk/ directory. When you look into this file, the only lines you see concerning caller ID are: usecallerid=yeshidecallerid=no Asterisk will be using its default type of caller ID signaling, which is North American. You may not even see these lines, as this is the default position. In order to change things, you will need to add some extra lines to the file. The number of lines you add will depend on the type of signaling you want to work with, and whether you are connecting to analog phones, or lines, or both. Shown next, is the kind of entry you would expect to see for a connection to an analog telephone line, with the entries that change the caller ID signaling highlighted: context=from_outsidesignalling=fxs_ksusecallerid=yeshidecallerid=nocidsignalling=v23 ;BT CallerID presentation signalling methodcidstart=polarity ;Indication of CallerID data startingcallerid=asreceivedcallwaiting=nochannel => 4 The two highlighted lines are equipping Asterisk to recognize the caller ID as it is sent in the UK over BT (British Telecom) analog lines. The callerid=asreceived line is not part of the change and serves to propagate the caller ID information through Asterisk. Therefore, it will show up on connected extensions when they are called. What we saw just now covers the case where we want to interpret incoming caller ID data. However, we also need to look at the sending of caller ID to any analog phone that we have connected to our Asterisk. If the analog phones are connected using ATAs, it is those devices that will handle the caller ID. If the phones are connected to a Digium card, then we are back in chan_dahdi.conf. context=userssignalling=fxo_kscallerid="David Duffett" <5001>cidsignalling=v23 ;BT CallerID presentation signalling methodcidstart=polarity ;Indication of CallerID data startingsendcalleridafter=2;The number of rings before sending datamailbox="5001"callwaiting=yesthreewaycalling=yestransfer=yeschannel => 1 In the code that we saw just now, the third highlighted line is particular to only a few caller ID signaling systems, and instructs Asterisk to send the caller ID data after (in this case) two rings. This is for systems where the data is sent between rings. It is the kind of system used in the UK. A final note on caller ID:Do make sure that your customer actually has caller ID enabled on their telephone line before you run around worrying that Asterisk is not recognizing it. There was a guy who spent a good amount of time analyzing why the caller ID was not showing up in Asterisk by changing settings, changing them back, and so on before asking the customers if they actually had caller ID on their line. The response: "No, we never use it". Needless to say, it's the kind of mistake you make only once or twice.

What is agility Agility includes effective, that is, rapid and adaptive, response to change. This requires effective communication among all of the stakeholders. Stakeholders are those who are going to benefit from the project in some form or another. The key stakeholders of the project include the developers and the users. Leaders of the customer organization, as well as the leaders of the software development organizations, are also among the stakeholders. Rather than keeping the customer away, drawing the customer into the team helps the team to be more effective. There can be various types of customers, some are annoying, and some who tend to forget what they once said. There are also those who will help steer the project in the right direction. The idea of drawing the customer into the team is not to let them micromanage the team. Rather, it is for them to help the team to understand the user requirements better. This needs to be explained to the customers up front, if they seem to hinder the project, rather than trying to help in it. After all, it is the team that consists of the technical experts, so the customer should understand this. Organizing a team, in such a manner so that it is in control of the work performed, is also an important part of being able to adapt to change effectively. The team dynamics will help us to respond to changes in a short period of time without any major frictions. Agile processes are based on three key assumptions. These assumptions are as follows: It is difficult to predict in advance, which requirements or customer priorities will change and which will not. For many types of software, design and construction activities are interweaved. We can use construction to prove the design. Analysis, design, and testing are not as predictable from the planning's perspective as we software developers like them to be. To manage unpredictability, the agile process must be adapted incrementally by the project's team. Incremental adaptation requires customer's feedback. Based on the evaluation of delivered software, it increments or executes prototypes over short time periods. The length of the time periods should be selected based on the nature of the user requirements. It is ideal to restrict the length of a delivery to get incremented by two or three weeks. Agility yields rapid, incremental delivery of software. This makes sure that the client will get to see the real up-and-running software in quick time. Characteristics of an agile process An agile process is driven by the customer's demand. In other words, the process that is delivered is based on the users' descriptions of what is required. What the project's team builds is based on the user-given scenarios. The agile process also recognizes that plans are short lived. What is more important is to meet the users' requirements. Because the real world keeps on changing, plans have little meaning. Still, we cannot eliminate the need for planning. Constant planning will make sure that we will always be sensitive to where we're going, compared to where we are. Developing software iteratively, with a greater emphasis on construction activities, is another characteristic of the agile process. Construction activities make sure that we have something working all of the time. Activities such as requirements gathering for system modeling are not construction activities. Those activities, even though they're useful, do not deliver something tangible to the users. On the other hand, activities such as design, design prototyping, implementation, unit testing, and system testing are activities that deliver useful working software to the users. When our focus is on construction activities, it is a good practice that we deliver the software in multiple software increments. This gives us more time to incorporate user feedback, as we go deeper into implementing the product. This ensures that the team will deliver a high quality product at the end of the project's life cycle because the latter increments of software are based on clearly-understood requirements. This is as opposed to those, which would have been delivered with partially understood requirements in the earlier increments. As we go deep into the project's life cycle, we can adopt the project's team as well as the designs and the PHP code that we implement as changes occur. Principles of agility Our highest priority is to satisfy the customer through early and continuous delivery of useful and valuable software. To meet this requirement, we need to be able to embrace changes. We welcome changing requirements, even late in development life cycle. Agile processes leverage changes for the customer's competitive advantage. In order to attain and sustain competitive advantage over the competitors, the customer needs to be able to change the software system that he or she uses for the business at the customer's will. If the software is too rigid, there is no way that we can accommodate agility in the software that we develop. Therefore, not only the process, but also the product, needs to be equipped with agile characteristics. In addition, the customer will need to have new features of the software within a short period of time. This is required to beat the competitors with state of the art software system that facilitate latest business trends. Therefore, deliver the working software as soon as possible. A couple of weeks to a couple of months are always welcome. For example, the customer might want to improve the reports that are generated at the presentation layer based on the business data. Moreover, some of this business data will not have been captured in the data model in the initial design. Still, as the software development team, we need to be able to upgrade the design and implement the new set of reports using PHP in a very short period of time. We cannot afford to take months to improve the reports. Also, our process should be such that we will be able to accommodate this change and deliver it within a short period of time. In order to make sure that we can understand these types of changes, we need to make the business people and the developers daily work together throughout the project. When these two parties work together, it becomes very easy for them to understand each other. The team members are the most important resource in a software project. The motivation and attitude of these team members can be considered the most important aspect that will determine the success of the project. If we build the project around motivated individuals, give them the environment and support they need, trust them to get the job done, the project will be a definite success. Obviously, the individual team members need to work with each other in order to make the project a success. The most efficient and effective method of conveying information to and within a development team is a face-to-face conversation. Even though various electronic forms of communication, such as instant messaging, emails, and forums makes effective communication possible, there is nothing comparable to face-to-face communication. When it comes to evaluating progress, working software should be the primary measure of progress. We need to make sure that we clearly communicate this to all of the team members. They should always focus on making sure that the software they develop is in a working state at all times. It is not a bad idea to tie their performance reviews and evaluations based on how much effort they have put in. This is in order to make sure that whatever they deliver (software) is working all of the time. An agile process promotes sustainable development. This means that people are not overworked, and they are not under stress in any condition. The sponsors, managers, developers, and users should be able to maintain a constant pace of development, testing, evaluation, and evolution, indefinitely. The team should pay continuous attention to technical excellence. This is because good design enhances agility. Technical reviews with peers and non-technical reviews with users will allow corrective action to any deviations from the expected result. Aggressively seeking technical excellence will make sure that the team will be open minded and ready to adopt corrective action based on feedback. With PHP, simplicity is paramount. Simplicity should be used as the art of maximizing the amount of work that is not done. In other words, it is essential that we prevent unwanted wasteful work, as well as rework, at all costs. PHP is a very good vehicle to achieve this. The team members that we have should be smart and capable. If we can get those members to reflect on how to become more effective, at regular intervals, we can get the team to tune and adjust its behavior to enhance the process over time. The best architectures, requirements, and designs emerge from self-organizing teams. Therefore, for a high quality product, the formation of the team can have a direct impact.

Working with theme files A theme file is conceptually similar to CSS while its implementation is like that of a Java properties file. Essentially a theme is a list of key-value pairs with an attribute being a key and its value being the second part of the key-value pair An entry in the list may be Form.bgColor= 555555. This entry specifies that the background color of all forms in the application will be (hex) 555555 in the RGB format. The list is implemented as a hashtable. Viewing a theme file A theme is packaged into a resource file that can also hold, as we have already seen, other items like images, animations, bitmap fonts, and so on. The fact that a theme is an element in a resource bundle means it can be created, viewed, and edited using the LWUIT Designer. The following screenshot shows a theme file viewed through the LWUIT Designer: The first point to note is that there are five entries at the bottom, which appear in bold letters. All such entries are the defaults. To take an example, the only component-specific font setting in the theme shown above is for the soft button. The font for the form title, as well as that for the strings in other components is not defined. These strings will be rendered with the default font. A theme file can contain images, animations, and fonts—both bitmap and system—as values. Depending on the type of key, values can be numbers, filenames or descriptions along with thumbnails where applicable. Editing a theme file In order to modify an entry in the theme file, select the row, and click on the Edit button. The dialog for edit will open, as shown in the following screenshot: Clicking Clicking on the browse button (the button with three dots and marked by the arrow) will open a color chooser from which the value of the selected color will be directly entered into the edit dialog. The edit dialog has fields corresponding to various keys, and depending on the one selected for editing, the relevant field will be enabled. Once a value is edited, click on the OK button to enter the new value into the theme file. In order to abort editing, click on the Cancel button. Populating a theme We shall now proceed to build a new theme file and see how it affects the appearance of a screen. The application used here is DemoTheme, and the code snippet below shows that we have set up a form with a label, a button, and a radio button. //create a new formForm demoForm = new Form("Theme Demo");//demoForm.setLayout(new BorderLayout());demoForm.setLayout(new BoxLayout(BoxLayout.Y_AXIS));//create and add 'Exit' command to the form//the command id is 0demoForm.addCommand(new Command("Exit", 1));//this MIDlet is the listener for the form's commanddemoForm.setCommandListener(this);//labelLabel label = new Label("This is a Label");//buttonButton button = new Button("An ordinary Button");//radiobuttonRadioButton rButton = new RadioButton("Just a RadioButton");//timeteller -- a custom component//TimeTeller timeTeller = new TimeTeller();//set style for timeLabel and titleLabel(in TimeViewer)//these parts of TimeTeller cannot be themed//because they belong to TimeViewer which does not//have any UIID/*Style tStyle = new Style();tStyle.setBgColor(0x556b3f);tStyle.setFgColor(0xe8dd21);tStyle.setBorder(Border.createRoundBorder(5, 5));timeTeller.setTitleStyle(tStyle);Style tmStyle = timeTeller.getTimeStyle();tmStyle.setBgColor(0xff0000);tmStyle.setFgColor(0xe8dd21);tmStyle.setBgTransparency(80);tmStyle.setBorder(Border.createRoundBorder(5, 5));*///add the widgets to demoFormdemoForm.addComponent(label);demoForm.addComponent(button);demoForm.addComponent(rButton);//demoForm.addComponent(timeTeller);//show the formdemoForm.show(); The statements for TimeTeller have been commented out. They will have to be uncommented to produce the screenshots in the section dealing with setting a theme for a custom component. The basic structure of the code is the same as that in the examples that we have come across so far, but with one difference—we do not have any statement for style setting this time around. That is because we intend to use theming to control the look of the form and the components on it. If we compile and run the code in its present form, then we get the following (expected) look. All the components have now been rendered with default attributes. In order to change the way the form looks, we are going to build a theme file—SampleTheme—that will contain the attributes required. We start by opening the LWUIT Designer through the SWTK. Had a resource file been present in the res folder of the project, we could have opened it in the LWUIT Designer by double-clicking on that file in the SWTK screen. In this case, as there is no such file, we launch the LWUIT Designer through the SWTK menu. The following screenshot shows the result of selecting Themes, and then clicking on the Add button: The name of the theme is typed in, as shown in the previous screenshot. Clicking on the OK button now creates an empty theme file, which is shown under Themes. Our first target for styling will be the form including the title and menu bars. If we click on the Add button in the right panel, the Add dialog will open. We can see this dialog below with the drop-down list for the Component field. Form is selected from this list. Similarly, the drop-down list for Attribute shows all the attributes that can be set. From this list we select bgImage, and we are prompted to enter the name for the image, which is bgImage in our case. The next step is to close the Add Image dialog by clicking on the OK button. As we have not added any image to this resource file as yet, the Image field above is blank. In order to select an image, we have to click on the browse button on the right of the Image field to display the following dialog. Again, the browse button has to be used to locate the desired image file. We confirm our selection through the successive dialogs to add the image as the one to be shown on the background of the form.

Inside the Application Server Before we look at deploying an application, we will quickly run over the internals of WebSphere Application Server (WAS). The anatomy of WebSphere Application Server is quite detailed, so for now, we will briefly explain the important parts of WebSphere Application Server. The figure below shows the basic architecture model for a WebSphere Application Server JVM. An important thing to remember is that the WebSphere product code base is the same for all operating-systems (platforms). The Java applications that are deployed are written once and can be deployed to all versions of a given WebSphere release without any code changes. JVM All WebSphere Application Servers are essentially Java Virtual Machines (JVMs). IBM has implemented the J2EE application server model in a way which maximizes the J2EE specification and also provides many enhancements creating specific features for WAS. J2EE applications are deployed to an Application Server. Web container A common type of business application is a web application. The WAS web container is essentially a Java-based web server contained within an application server's JVM, which serves the web component of an application to the client browser. Virtual hosts A virtual host is a configuration element which is required for the web container to receive HTTP requests. As in most web server technologies, a single machine may be required to host multiple applications and appear to the outside world as multiple machines. Resources that are associated with a particular virtual host are designed to not share data with resources belonging to another virtual host, even if the virtual hosts share the same physical machine. Each virtual host is given a logical name and assigned one or more DNS aliases by which it is known. A DNS alias is the TCP/ host name and port number that are used to request a web resource, for example: <hostname>:9080/<servlet>. By default, two virtual host aliases are created during installation. One for the administration console called admin_host and another called default_host which is assigned as the default virtual host alias for all application deployments unless overridden during the deployment phase. All web applications must be mapped to a virtual host, otherwise web browser clients cannot access the application that is being served by the web container. Environment settings WebSphere uses Java environment variables to control settings and properties relating to the server environment. WebSphere variables are used to configure product path names, such as the location of a database driver, for example, ORACLE_JDBC_DRIVER_PATH, and environmental values required by internal WebSphere services and/or applications. Resources Configuration data is stored in XML files in the underlying configuration repository of the WebSphere Application Server. Resource definitions are a fundamental part of J2EE administration. Application logic can vary depending on the business requirement and there are several types of resource types that can be used by an application. Below is a list of some of the most commonly used resource types. Resource Types Description JDBC (Java database connectivity) Used to define providers and data sources URL Providers Used to define end-points for external services for example web services... JMS Providers Used to defined messaging configurations for Java Message Service, MQ connection factories and queue destinations etc. Mail Providers Enable applications to send and receive mail, typically use the SMTP protocol. JNDI The Java Naming and Directory Interface (JNDI) is employed to make applications more portable. JNDI is essentially an API for a directory service which allows Java applications to look up data and objects via a name. JNDI is a lookup service where each resource can be given a unique name. 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. Administrators can override the resource the application is actually connecting to without requiring a reconfiguration or code change in the application. This level of abstraction using JNDI is fundamental and required for the proper use of WebSphere by applications. Application file types There are three file types we work with in Java applications. Two can be installed via the WebSphere deployment process. One is known as an EAR file, and the other is a WAR file. The third is a JAR file (often re-usable common code) which is contained in either the WAR or EAR format. The explanation of these file types is shown in the following table: File Type Description JAR file A JAR file (or Java ARchive) is used for organising many files into one. The actual internal physical layout is much like a ZIP file. A JAR is  generally used to distribute Java classes and associated metadata. In J2EE applications the JAR file often contains utility code, shared libraries and  EJBS. An EJB is a server-side model that encapsulates the business logic of an application and is one of several Java APIs in the Java Platform, Enterprise Edition with its own specification. You can visit http://java.sun.com/products/ejb/ for information on EJBs. EAR file An Enterprise Archive file represents a J2EE application that can be deployed in a WebSphere application server. EAR files are standard Java archive files (JAR) and have the file extension .ear. An EAR file can consist of the following: One or more Web modules packaged in WAR files. One or more EJB modules packaged in JAR files One or more application client modules Additional JAR files required by the application Any combination of the above The modules that make up the EAR file are themselves packaged in archive files specific to their types. For example, a Web module contains Web archive files and an EJB module contains Java archive files. EAR files also contain a deployment descriptor (an XML file called application.xml) that describes the contents of the application and contains instructions for the entire application, such as security settings to be used in the run-time environment... WAR file A WAR file (Web Application) is essentially a JAR file used to encapsulate a collection of JavaServer Pages (JSP), servlets, Java classes, HTML and other related files which may include XML and other file types depending on the web technology used. For information on JSP and Servlets, you can visit http://java.sun.com/products/jsp/. Servlets can support dynamic Web page content; they provide dynamic server-side processing and can connect to databases. Java ServerPages (JSP) files can be used to separate HTML code from the business logic in Web pages. Essentially they too can generate dynamic pages; however, they employ Java beans (classes) which contain specific detailed server-side logic. A WAR file also has its own deployment descriptor called "web.xml" which is used to configure the WAR file and can contain instruction for resource mapping and security. When an EJB module or web module is installed as a standalone application, it is automatically wrapped in an Enterprise Archive (EAR) file by the WebSphere deployment process and is managed on disk by WebSphere as an EAR file structure. So, if a WAR file is deployed, WebSphere will convert it into an EAR file. Deploying an application As WebSphere administrators, we are asked to deploy applications. These applications may be written in-house or delivered by a third-party vendor. Either way, they will most often be provided as an EAR file for deployment into WebSphere. For the purpose of understanding a manual deployment, we are now going to install a default application. The default application can be located in the <was_root>/installableApps folder. 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 below: You now see the option to create one of the following three types of applications: Application Type Description Enterprise Application EAR file on a server configured to hold installable Web Applications, (WAR), Java archives, library files, and other resource files. 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 grouping of modules. 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. 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 file system. 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 remote, as opposed to transferring via local browse, which will do an HTTP file transfer which takes more resources and can be slower. The following screenshot depicts the path to the new application: Click Browse.... You will 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 Linux file system as seen in the following screenshot: Locate the DefaultApplication.ear file. It will be in a folder called installableApps located in the root WebSphere install folder, for example, <was_root>/installableApps as shown in the previous screenshot. Click Next to begin installing the EAR file. On the Preparing for the application installation page, choose the Fast Path option. There are two options to choose. 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, for 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. Each EAR file has pre-configured XML descriptors which specify the JNDI name that the application resource uses to map to a matching (application server) provided resource. An example would be a JDBC data source name which is referred to as jdbc/mydatasource, whereas the actual data source created in the application server might be called jdbc/datasource1. 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. We will select Fast Path as demonstrated in the following screenshot: Click on Next. In the next screen, we are given the ability to fill out some specific deployment options. Below is a list of the options presented in this page.

Auto Attendant The multi-level auto attendant service provides system-wide answering of incoming calls, dial-by-name abilities, automated transfer to local extensions, access to remote voicemail retrieval, and transfer to other auto attendants. The auto attendant is often the first impression your callers will have of your organization, so designing a menu structure that is clear and concise is critically important. For good auto attendant design, try not to have more than two auto attendants deep. Callers quickly become annoyed if they have to go through too many menu layers. The auto attendant configuration is accessed through the system administration screen by clicking on the Features menu and then selecting the Auto Attendants menu item. The Auto Attendants page will be displayed as follows: By default there are two auto attendants defined, but only the Operator auto attendant (AA) is in use. The administrator is free to create as many auto attendants as he or she would like. Auto attendants can be cascaded to create multiple levels. Which auto attendant answers initially for the system is specified in the Dial Plan settings . Default Auto Attendant, Working Hours Auto Attendant, and Holiday Auto Attendant can all be specified as part of the Dial Plan configuration. On the Auto Attendants page a Special Auto Attendant may be selected with the select drop-down menu. This feature is useful if the organization is unexpectedly closed. In addition to activating the Special Auto Attendant on this page, it can also be activated remotely through the voicemail system by a system administrator or a user with the Record System Prompts permission To edit an existing attendant, click on its name. To add a new auto attendant, click on the Add Attendant hyperlink. The default Operator auto attendant has been selected for editing in the following screenshot: The name of the auto attendant can be changed and a more detailed description added if desired. To listen to the existing prompt, click on the Listen hyperlink. To upload a new prompt to play click on the Browse button and locate the file on your local computer. Auto attendant prompt sound files must be 8khz / 16 bit PCM samples, signed, little-endian, 1 channel (mono), .wavheader (implied 128kbps). There are many products available for manipulating audio files. MediaCoder (mediacoderhq.com) works very well for exchanging between different audio formats. Audacity (https://sourceforge.net/projects/audacity/) is a sound mixer that allows mixing in music along with recorded voice. The following actions may be assigned to the phone dial pad keys (0 through 9,asterisk—* and pound—#): Operator: Routes the call to extension zero (0). Dial by Name: Connects the caller to the dial-by-name directory. Repeat Prompt: Replay the greeting that was just heard. Voicemail Login: The caller will be directed to the voicemail system and prompted to log in. Disconnect: Plays a good-bye message and ends the call. Auto Attendant: Routes the caller to another auto attendant. Transfer to Extension or Other Destination: Routes the call to an extension. This can be a user on the system, hunt group, ACD queue, or an external phone number. Deposit Voicemail: Directs the caller directly to a voicemail box, plays the voicemail box greeting, and the user can leave a message. To add an action, click on the Dialpad drop-down box at the bottom of the table to select the digit desired, select the Action with the drop-down box, and click on the Add button. If a parameter is required a dialog or drop-down box will appear in the Parameter column shown as follows: Click on the OK or Apply button to make the changes take effect. The changes will become live after a short delay for the system to generate the new VXML (Voice XML) code in the background. To remove an action, place a check mark next to the action and click on the Remove button. Likewise, to reset the menu back to its default settings click on the Reset to Defaults button. Clicking on the Options link on the left side of the page allows the administrator to customize DTMF (Dial Tone Multi Frequency) handling and Auto Attendant Invalid Response handling. The Auto Attendant Options page is shown as follows: The following DTMF handling settings are available: Inter-DTMF Timeout: The time to wait between each dial pad key press before interpreting the caller's request. This value cannot be greater than Overall DTMF Timeout. (Default: 3 seconds.) Overall DTMF Timeout: The total time to wait before interpreting the caller's request. (Default: 7 seconds.) Maximum Number of DTMF tones: The maximum number of dial pad key presses to accept before interpreting caller's request. (Default: 10 key presses.) The Invalid Response settings allow the administrator to configure the auto attendant's behavior when callers enter an invalid response or no response is received. Replay Count: The number of times the auto attendant prompt will be repeated after the initial announcement due to no input being received. (Default: 2 times.) Invalid Response Count: The number of times the caller can input an invalid response before the auto attendant transfers or disconnects the call. (Default: 2 times.) Transfer on Failures: If this setting is enabled, the auto attendant will transfer the call to a designated extension if no valid response is received. If disabled, the call will be disconnected. (Default: unchecked.) Transfer Extension: The extension to be used when transfer on failure is enabled. Prompt to play when transferring call after failure : The administrator can specify a WAV fi le to play before transferring the call after a user input error. After the desired settings are modified click OK or Apply to make them active.

User requirements The initial activity of the process model is to analyze the user requirements. It is obvious that in any software project, the first and foremost activity is to have an understanding of what the users require. There are various tools and techniques to analyze user requirements. However, it is important to note that, while it is important to understand the user requirement in full, the idea here is not to write loads of documents, especially when it comes to PHP projects. What is more important is to make sure that we model what the users require and, based on the models, get the users to provide feedback, and then improve the model based on the user feedback. Some simple techniques that can be used to capture requirements include: Studying the existing system Observation of the users in action in a real environment Interviews with potential users and stakeholders of the system Some tools that can be used to capture requirements include: Data flow diagrams showing how data flows and processing happens in the system Use case diagrams that portray how potential users of the system would be using the system. When using use case diagrams, it is critical to capture all of the major use cases of the system at a high level. It does not need to be too detailed, but we need to ensure that we have not missed any key use case scenario in the implementation. We can always seek the help of the users to help us validate the use cases and fill in the gaps, in case we have missed any key user requirements. When documenting user requirements, we need to be comprehensive, concise, and clear. This is because the team members need to be able to refer to those, whenever they want. If the requirement specifications are too bulky and take time to read, it might not help the team. Therefore, it is always a good idea to use diagrams and tables to summarize information, whenever possible, to make sure that the captured information can be grasped by the team members at a glance. We need to make sure that the team members really refer to the requirements to during the project life cycle. Therefore, anything that encourages them to use those requirement specifications is welcome and would make the project's success more probable. Modeling what the users want The purpose of the requirements gathering activity is to help us understand what the users want. The next step is to come up with a model that bridges the gap between the real world and the software world. For example, we need to be able to map the user requirements to the data model, and the business logic model, that we can implement with the software technology that we know. Data modeling Data modeling activities are supposed to produce the data model that represents the data involved with the system under consideration. Entity relationship diagrams are the most well known tool to help model data in a system. Note that modeling data is the first activity following the user requirement gathering. This depicts the importance of the data modeling activity with respect to the design and implementation of the rest of the system. Most of the systems are all about effective data storage processing and presenting. The outcome of the data modeling activity is a set of diagrams that represent the entities within the system and their relationship to each other: It is important to note that a data model is not the same as a database design. The model is the reference that can be used as the input to the database design activity, and the data model is also the input for the business modeling activity of the process. Data design will be explained later in this article. Business modeling Once we understand the data involved with the system, the next step is to understand the business activities carried out with those data. Business logic modeling can be done with tools such as data flow diagrams or use case diagrams. The objective is to understand what sort of business activities the users carry out with the software system being developed. The inputs and outputs of the business logic processing and the various data stores, where the data is pulled from, are modeled in this phase of the process. Like in the case of data modeling, we can validate the business model with the user and incorporate user feedback back into the model. It is also noteworthy that the business modeling activity is different from the business logic design activity. Business logic design is based on the business model that we develop in this phase of the process. The output of the business modeling activity is the business model. Simply speaking, it is a set of diagrams that represent the use cases or the data flow. Like in the case of data model, the business model should also be simple to refer back, if team members require to do so. Once we have both the data model and the business model, we can move on to the user activity analysis. User activity analysis While executing business functions with the software application, users engage in various activities using the system. Analyzing those activities becomes the next important activity in the process, and it also opens up the doors to understanding and designing the user interface. Based on the business model and the data model, we can analyze the various activities that the users would want to carry out with the system. We can make use of the data processing functions of data flow diagrams, or use case diagrams, and come up with a list of user activities for each business use case of the system. The list of user activities becomes the input for the storyboard design activity. Before looking into the details of the presentation layer design, let us step back for a moment and look into data layer design. Designs and implementing the data layer The process model proposed in this article is intended to be used for PHP projects, and therefore, is based on the MVC pattern. The data layer represents the model in MVC. In the design of the PHP application, we need to first attend the data layer. Using the data model as the input, we can perform data design. The data design can be independent from a specific database management system. However, the information, such as data types, needs to be taken into account. The number of tables, their relationships, the volume of data involved, and related performance implications need to be taken into account. The next activity is the implementation, keeping open the option of switching the database management systems or supporting multiple database management systems open. In this activity, we might either use the database management systems directly or use SQL and try to be database agnostic. In addition to creating the database, the team members involved with the data layer implementation also devise plans for testing and also for carrying out unit testing. In addition to SQL based unit testing, they need to implement the database access logic, which is also a part of the database layer, using PHP. The team members can then implement unit tests with PHP to verify the implementation. Executing the unit tests can be automated using PHP frameworks, upon each source code change. Once the implementation is complete, it can be tested and verified completely using system testing by a quality assurance team. Database implementation is a prerequisite for business logic implementation. However, business logic design need not wait until the database implementation is complete. As soon as data model is available, business modeling can be done and followed by business logic design. It is the business logic implementation that requires database implementation. The business layer sub-team can start its design work in parallel with the data layer sub-team and work side by side on their designs.