How-To Tutorials

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>.

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.

We have our entire source structures defined in the Warehouse Builder. But before we can do anything with them, we need to design what our target data warehouse structure is going to look like. When we have that figured out, we can start mapping data from the source to the target. So, let's design our target structure. First, we're going to take a look at some design topics related to a data warehouse that are different from what we would use if we were designing a regular relational database. Data Warehouse Design When it comes to the design of a data warehouse, there is basically one option that makes the most sense for how we will structure our database and that is the dimensional model. This is a way of looking at the data from a business perspective that makes the data simple, understandable, and easy to query for the business end user. It doesn't require a database administrator to be able to retrieve data from it. We know the normalized method of modelling a database. A normalized model removes redundancies in data by storing information in discrete tables, and then referencing those tables when needed. This has an advantage for a transactional system because information needs to be entered at only one place in the database, without duplicating any information already entered. For example, in the ACME Toys and Gizmos transactional database, each time a transaction is recorded for the sale of an item at a register, a record needs to be added only to the transactions table. In the table, all details regarding the information to identify the register, the item information, and the employee who processed the transaction do not need to be entered because that information is already stored in separate tables. The main transaction record just needs to be entered with references to all that other information. This works extremely well for a transactional type of system concerned with daily operational processing where the focus is on getting data into the system. However, it does not work well for a data warehouse whose focus is on getting data out of the system. Users do not want to navigate through the spider web of tables that compose a normalized database model to extract the information they need. Therefore, dimensional models were introduced to provide the end user with a flattened structure of easily queried tables that he or she can understand from a business perspective. Dimensional Design A dimensional model takes the business rules of our organization and represents them in the database in a more understandable way. A business manager looking at sales data is naturally going to think more along the lines of "how many gizmos did I sell last month in all stores in the south and how does that compare to how many I sold in the same month last year?" Managers just want to know what the result is, and don't want to worry about how many tables need to be joined in a complex query to get that result. A dimensional model removes the complexity and represents the data in a way that end users can relate to it more easily from a business perspective. Users can intuitively think of the data for the above question as a cube, and the edges (or dimensions) of the cube labeled as stores, products, and time frame. So let's take a look at this concept of a cube with dimensions, and how we can use that to represent our data. Cube and Dimensions The dimensions become the business characteristics about the sales, for example: A time dimension—users can look back in time and check various time periods A store dimension—information can be retrieved by store and location A product dimension—various products for sale can be broken out Think of the dimensions as the edges of a cube, and the intersection of the dimensions as the measure we are interested in for that particular combination of time, store, and product. A picture is worth a thousand words, so let's look at what we're talking about in the following image: Notice what this cube looks like. How about a Rubik's Cube? We're doing a data warehouse for a toy store company, so we ought to know what a Rubik's cube is! If you have one, maybe you should go get it now because that will exactly model what we're talking about. Think of the width of the cube, or a row going across, as the product dimension. Every piece of information or measure in the same row refers to the same product, so there are as many rows in the cube as there are products. Think of the height of the cube, or a column going up and down, as the store dimension. Every piece of information in a column represents one single store, so there are as many columns as there are stores. Finally, think of the depth of the cube as the time dimension, so any piece of information in the rows and columns at the same depth represent the same point in time. The intersection of each of these three dimensions locates a single individual cube in the big cube, and that represents the measure amount we're interested in. In this case, it's dollar sales for a single product in a single store at a single point in time. But one might wonder if we are restricted to just three dimensions with this model. After all, a cube has only three dimensions—length, width, and depth. Well, the answer is no. We can have many more dimensions than just three. In our ACME example, we might want to know the sales each employee has accomplished for the day. This would mean we would need a fourth dimension for employees. But what about our visualization above using a cube? How is this fourth dimension going to be modelled? And no, the answer is not that we're entering the Twilight Zone here with that "dimension not only of sight and sound but of mind..." We can think of additional dimensions as being cubes within a cube. If we think of an individual intersection of the three dimensions of the cube as being another cube, we can see that we've just opened up another three dimensions to use—the three for that inner cube. The Rubik's Cube example used above is good because it is literally a cube of cubes and illustrates exactly what we're talking about. We do not need to model additional cubes. The concept of cubes within cubes was just to provide a way to visualize further dimensions. We just model our main cube, add as many dimensions as we need to describe the measures, and leave it for the implementation to handle. This is a very intuitive way for users to look at the design of the data warehouse. When it's implemented in a database, it becomes easy for users to query the information from it.

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.

(For more resources on Solr, see here.) Faceting, after searching, is arguably the second-most valuable feature in Solr. It is perhaps even the most fun you'll have, because you will learn more about your data than with any other feature. Faceting enhances search results with aggregated information over all of the documents found in the search to answer questions such as the ones mentioned  below, given a search on MusicBrainz releases: How many are official, bootleg, or promotional? What were the top five most common countries in which the releases occurred? Over the past ten years, how many were released in each year? How many have names in these ranges: A-C, D-F, G-I, and so on? Given a track search, how many are < 2 minutes long, 2-3, 3-4, or more? Moreover, in addition, it can power term-suggest aka auto-complete functionality, which enables your search application to suggest a completed word that the user is typing, which is based on the most commonly occurring words starting with what they have already typed. So if a user started typing siamese dr, then Solr might suggest that dreams is the most likely word, along with other alternatives. Faceting, sometimes referred to as faceted navigation, is usually used to power user interfaces that display this summary information with clickable links that apply Solr filter queries to a subsequent search. If we revisit the comparison of search technology to databases, then faceting is more or less analogous to SQL's group by feature on a column with count(*). However, in Solr, facet processing is performed subsequent to an existing search as part of a single request-response with both the primary search results and the faceting results coming back together. In SQL, you would need to potentially perform a series of separate queries to get the same information. A quick example: Faceting release types Observe the following search results. echoParams is set to explicit (defined in solrconfig.xml) so that the search parameters are seen here. This example is using the standard handler (though perhaps dismax is more typical). The query parameter q is *:*, which matches all documents. In this case, the index I'm using only has releases. If there were non-releases in the index, then I would add a filter fq=type%3ARelease to the URL or put this in the handler configuration, as that is the data set we'll be using for most of this article. I wanted to keep this example brief so I set rows to 2. Sometimes when using faceting, you only want the facet information and not the main search, so you would set rows to 0, if that is the case. It's important to understand that the faceting numbers are computed over the entire search result, which is all of the releases in this example, and not just the two rows being returned. <?xml version="1.0" encoding="UTF-8"?> <response> <lst name="responseHeader"> <int name="status">0</int> <int name="QTime">160</int> <lst name="params"> <str name="wt">standard</str> <str name="rows">2</str> <str name="facet">true</str> <str name="q">*:*</str> <str name="fl">*,score</str> <str name="qt">standard</str> <str name="facet.field">r_official</str> <str name="f.r_official.facet.missing">true</str> <str name="f.r_official.facet.method">enum</str> <str name="indent">on</str> </lst> </lst> <result name="response" numFound="603090" start="0" maxScore="1.0"> <doc> <float name="score">1.0</float> <str name="id">Release:136192</str> <str name="r_a_id">3143</str> <str name="r_a_name">Janis Joplin</str> <arr name="r_attributes"><int>0</int><int>9</int> <int>100</int></arr> <str name="r_name">Texas International Pop Festival 11-30-69</str> <int name="r_tracks">7</int> <str name="type">Release</str> </doc> <doc> <float name="score">1.0</float> <str name="id">Release:133202</str> <str name="r_a_id">6774</str> <str name="r_a_name">The Dubliners</str> <arr name="r_attributes"><int>0</int></arr> <str name="r_lang">English</str> <str name="r_name">40 Jahre</str> <int name="r_tracks">20</int> <str name="type">Release</str> </doc> </result> <lst name="facet_counts"> <lst name="facet_queries"/> <lst name="facet_fields"> <lst name="r_official"> <int name="Official">519168</int> <int name="Bootleg">19559</int> <int name="Promotion">16562</int> <int name="Pseudo-Release">2819</int> <int>44982</int> </lst> </lst> <lst name="facet_dates"/> </lst> </response> The facet related search parameters are highlighted at the top. The facet.missing parameter was set using the field-specific syntax, which will be explained shortly. Notice that the facet results (highlighted) follow the main search result and are given a name facet_counts. In this example, we only faceted on one field, r_official, but you'll learn in a bit that you can facet on as many fields as you desire. The name attribute holds a facet value, which is simply an indexed term, and the integer following it is the number of documents in the search results containing that term, aka a facet count. The next section gives us an explanation of where r_official and r_type came from. MusicBrainz schema changes In order to get better self-explanatory faceting results out of the r_attributes field and to split its dual-meaning, I modified the schema and added some text analysis. r_attributes is an array of numeric constants, which signify various types of releases and it's official-ness, for lack of a better word. As it represents two different things, I created two new fields: r_type and r_official with copyField directives to copy r_attributes into them: <field name="r_attributes" type="integer" multiValued="true" indexed="false" /><!-- ex: 0, 1, 100 --> <field name="r_type" type="rType" multiValued="true" stored="false" /><!-- Album | Single | EP |... etc. --> <field name="r_official" type="rOfficial" multiValued="true" stored="false" /><!-- Official | Bootleg | Promotional --> And: <copyField source="r_attributes" dest="r_type" /> <copyField source="r_attributes" dest="r_official" /> In order to map the constants to human-readable definitions, I created two field types: rType and rOfficial that use a regular expression to pull out the desired numbers and a synonym list to map from the constant to the human readable definition. Conveniently, the constants for r_type are in the range 1-11, whereas r_official are 100-103. I removed the constant 0, as it seemed to be bogus. <fieldType name="rType" class="solr.TextField" sortMissingLast="true" omitNorms="true"> <analyzer> <tokenizer class="solr.KeywordTokenizerFactory"/> <filter class="solr.PatternReplaceFilterFactory" pattern="^(0|1dd)$" replacement="" replace="first" /> <filter class="solr.LengthFilterFactory" min="1" max="100" /> <filter class="solr.SynonymFilterFactory" synonyms="mb_attributes.txt" ignoreCase="false" expand="false"/> </analyzer> </fieldType> The definition of the type rOfficial is the same as rType, except it has this regular expression: ^(0|dd?)$. The presence of LengthFilterFactory is to ensure that no zero-length (empty-string) terms get indexed. Otherwise, this would happen because the previous regular expression reduces text fitting unwanted patterns to empty strings. The content of mb_attributes.txt is as follows: # from: http://bugs.musicbrainz.org/browser/mb_server/trunk/ # cgi-bin/MusicBrainz/Server/Release.pm#L48 #note: non-album track seems bogus; almost everything has it 0=>Non-Album Track 1=>Album 2=>Single 3=>EP 4=>Compilation 5=>Soundtrack 6=>Spokenword 7=>Interview 8=>Audiobook 9=>Live 10=>Remix 11=>Other 100=>Official 101=>Promotion 102=>Bootleg 103=>Pseudo-Release It does not matter if the user interface uses the name (for example: Official) or constant (for example: 100) when applying filter queries when implementing faceted navigation, as the text analysis will let the names through and will map the constants to the names. This is not necessarily true in a general case, but it is for the text analysis as I've configured it above. The approach I took was relatively simple, but it is not the only way to do it. Alternatively, I might have split the attributes and/or mapped them as part of the import process. This would allow me to remove the multiValued setting in r_official. Moreover, it wasn't truly necessary to map the numbers to their names, as a user interface, which is going to present the data, could very well map it on the fly. Field requirements The principal requirement of a field that will be faceted on is that it must be indexed. In addition to all but the prefix faceting use case, you will also want to use text analysis that does not tokenize the text. For example, the value Non-Album Track is indexed the way it is in r_type. We need to be careful to escape the space where this appeared in mb_attributes.txt. Otherwise, faceting on this field would show tallies for Non-Album and Track separately. Depending on the type of faceting you want to do and other needs you have like sorting, you will often find it necessary to have a copy of a field just for faceting. Remember that with faceting, the facet values returned in search results are the actual terms indexed, and not the stored value, which isn't even used.

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.

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.

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.

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.

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.

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.

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.

Synchronizing objects We created tables, dimensions, and a cube; and new tables were automatically created for each dimension and cube. We then created mappings to map data from tables to tables, dimensions, and a cube. What happens if, let's say for example, a table definition is updated after we've defined it and created a mapping or mappings that include it? What if a dimensional object is changed? In that case, what happens to the underlying table? This is what we are going to discuss in this section. One set of changes that we'll frequently find ourselves making is changes to the data we've defined for our data warehouse. We may get some new requirements that lead us to capture a new data element that we have not captured yet. We'll need to update our staging table to store it and our staging mapping to load it. Our dimension mapping(s) will need to be updated to store the new data element along with the underlying table. We could make manual edits to all the affected objects in our project, but the Warehouse Builder provides us some features to make that easier. Changes to tables Let's start the discussion by looking at table updates. If we have a new data element that needs to be captured, it will mean finding out where that data resides in our source system and updating the associated table definition in our module for that source system. Updating object definitions There are a couple of ways to update table definitions. Our choice will depend on how the table was defined in the Warehouse Builder in the first place. The two options are: It could be a table in a source database system, in which case the table was physically created in the source database and we just imported the table definition into the Warehouse Builder. It could be a table we defined in our project in the Warehouse Builder and then deployed to the target database to create it. Our staging table would be an example of this second option. In the first case, we can re-import the source table using the procedures generally used for importing source metadata. When re-importing tables, the Warehouse Builder will do a reconciliation process to update the already imported table with any changes it detects in the source table. For the second case, we can manually edit the table definition in our project to reflect the new data element. For the first case where the table is in a source database system, the action we choose also depends on whether that source table definition is in an Oracle database or a third-party database. If it is in a third-party database, we're going to encounter an error. Hence, we'll be forced to make manual edits to our metadata for that source until that bug is fixed. If the table is in an Oracle database, re-importing the table definition would not be a problem and it will do the reconciliation process, picking up any new data elements or changes to the existing ones. For a hands-on example here, let's turn to our new project that we created earlier while discussing snapshots. We copied our POS_TRANS_STAGE table over to this project, so let's use that table as an example of a changing table, as we defined the table structure manually in the Warehouse Builder Design Center and then deployed it to the target database to actually create it. For this example, we won't actually re-deploy it because we'll be using that second project we created. It doesn't have a valid location defined, but we can still edit the table definition and investigate how to reconcile that edit in the next section. So, let's edit the POS_TRANS_STAGE table in the ACME_PROJ_FOR_COPYING project in the Design Center by double-clicking on it to launch it in the Data Object Editor. We'll just add a column called STORE_AREA_SIZE to the table for storing the size of the store in square feet or square meters. We'll click on the Columns tab, scroll it all the way to the end, enter the name of the column, then select NUMBER for the data type, and leave the precision and scale to the default (that is 0) for this example. We can validate and generate the object without having a valid location defined, so we'll do that. The validation and generation should complete successfully; and if we look at the script, we'll see the new column included. We now need a mapping that uses that table, which we have back in our original project. Let's use the copy and paste technique we used earlier to copy the STAGE_MAP mapping over to this new project. We'll open the ACME_DW_PROJECT project, answering Save to the prompt to save or revert. Then on the STAGE_MAP mapping entry, we'll select Copy from the pop-up menu. We'll open the ACME_PROJ_FOR_COPYING project and then on the Mappings node, select Paste on the pop-up menu. We ordinarily won't copy an object and paste it into a whole new project just for making changes. We're only doing it here so that we can make changes without worrying about interfering with a working project.