How-To Tutorials

I will build a prototype for a hotel reservation system outlining the way Software Configuration Management makes the job easier. Don't worry if you are not fully familiar with the technologies used. The purpose of this application is purely for reference, so you can sit back and relax. At this point I will use my time machine and get a screenshot for the final application so you can see how it will look like. Or, I can insert the screenshot after it finished. I think the first way seems more reasonable. This is what the public reservation site looks like: If you like it, you can download the application from the book's website: http://orbitalhotel.alexandruserban.com. Now let's get back to our time and start the development lifecycle on the Orbital Hotel product. The first phase is the specifications phase. Specifications—Project Architecture In order to build a software system, we need a list of requirements. What is the purpose of the system? What are the actions performed by the system and against the system? Who will use the system and how? The answers to these questions will let us identify the main parts of the system and the way these parts work together. System Requirements Let's take a look at the Orbital Hotel's reservation system's requirements. The purpose of the reservation system is to allow guests to make room reservations. There are several room types each having a number, occupancy, price, availability, description, and image. The reservations can be made by using the hotel's internet website, through the websites of travel agencies (third parties), or by making phone calls to the hotel's client service. Reservations can be also made by internal client service staff who receive phone calls from guests. When guests use the hotel's website, they will create a user with a username and password and input their personal details such as first name, last name, address, city, zip code, state, country, phone, email address, and card number. Then they will choose a room and complete the reservation details such as arrival date, the number of nights they will be staying and the number of adults, teenagers, children, and pets. They will also be able to cancel their reservation. When making a reservation over the phone, a guest will provide the same personal information and reservation details to the hotel's client-service staff. The staff will create a reservation for the guest using an internal application. The staff members will also authenticate using a username and password. Travel agencies and other third parties must also be able to make hotel reservations. Taking a big picture about the type of system we are going to build, what we need is an application design that will be as flexible as possible. It should provide us with a variety of options like reservations through phone calls, personal or third-party websites, smart devices like PDAs or cell phones, and so on. This is where we gather the specifications and plan the system architecture. In this phase we have to consider as many aspects as we can, based on our requirements and specifications. So, let's see what the main existing application architectures are, and see what application architecture fits our requirements. Application Architectures The computer and computer programming history is a very short one in comparison with that of other industries. Although it is short, it has evolved and continues to evolve very rapidly, changing the way we live. Taking into account the architectures used at the beginning of computer programming, we can see an evolution from the single, powerful, fault-tolerant, expensive super mainframe computer applications, towards multiple, distributed, less expensive smaller machine applications, the personal computers. During this evolution, three main application architectures can be identified: Compact application architecture Component application architecture Service-Oriented Architecture (SOA) We are going to take a brief look at these application architectures and outline their characteristics. Compact Application Architecture During application development for the single mainframe, there was no clear separation between application layers and no reusable components were used. All the data access, business logic, and user interface-specific code were contained in a single executable program. This traditional compact architecture was used because the mainframe computers had specific proprietary programming languages and formats for accessing and manipulating the data. All the data access-specific procedures as well as the business logic and business rules code are written in this programming language. At the surface, a user interface is presented to the user for data visualisation and manipulation. This application architecture works for applications that do not need data input from multiple sources and can be easily developed by a single programmer. However, this approach has several major disadvantages when it comes to building large-scale systems: Application components cannot be reused in other applications because they are tightly coupled and dependent on one another. Tight coupling means that in order for a piece of code to use another piece of code, it must have intimate knowledge about its implementation details. Being tightly coupled, a change to one component can affect the functionality of another, making debugging and maintenance a difficult task. The application is actually a black box; no one, except the main developer, knows what it is in there. Applying security is another problem because the user interface cannot be separated from the business logic components using security-specific mechanisms like authentication and authorization. Application integration is affected because the code is platform dependent. Integration between two such applications requires special and specific coding and can be difficult to maintain. Scalability issues are considered when the system grows and need to be scaled across several machines. Using this application architecture, scalability is not possible as you can't separate different application parts across different physical boundaries because of the tight coupling. To address the issues with the compact application architecture, the component-based application architecture was developed. Component Application Architecture In the component application architecture, the application's functionality is defined using components. A component is like a black box, a software unit that encapsulates data and code and provides at the surface a set of well-defined interfaces used by other components. Since a component only needs to support a well-defined set of interfaces, it can change the inner implementation details without affecting other components that use its external interfaces. Components that export the same interfaces can be interchanged, allowing them to be reused and tight coupling to be eliminated. This makes them loosely coupled because they don't need to know internal implementation details of one another. This separation of application functionality using components allows the distribution of development tasks across several developers and makes the overall application more maintainable and scaleable. In the Windows environment, the most used component application architecture is the Component Object Model (COM). Typically, components are grouped into logical layers. For example, an application uses the data access layer to access the different data sources, the business logic layer to process the data according to the business rules, and the presentation layer also known as the user interface layer to present the data to end users. Using well-defined application layers allows for a modular design, component decoupling, and therefore the possibility for component reuse. Data Access Layer This architecture forms a chain of layers that communicate with one another. The base is the data access layer, which is responsible for querying, retrieving, and updating the data from and to different data sources while providing a uniform data view to the layers above. Business Layer Above the data access layer is the business logic layer. The business logic layer uses the uniform data provided by the data access layer and processes it according to the business rules it contains. The business logic layer doesn't need to know from what source and how the data was obtained. Its purpose is only data manipulation and processing. Presentation Layer At the top of the chain is the presentation layer or the user interface layer. Its purpose is to present the data processed by the business logic layer to end users and to receive input and commands from these end users. The presentation layer will propagate these commands down the chain to the business layer for processing. Characteristics The component application architecture solves many software problems and it has been used extensively in the past. But because software evolves continuously, new requirements introduce new challenges. Let's suppose we have several applications on different platforms, each incorporating its presentation layer, business logic layer, and data access layer. We want to integrate them into a bigger distributed system, a system that spans across several heterogeneous environments. At some point, one application will need to access the data existing in another application. While components can work well in a homogenous environment on the same platform, for example COM in the Windows environment, problems appear in components working across several platforms. For example, it is very difficult for a COM component to be used from a Java application or vice-versa, mainly because they don't speak the same language. Integration between two or more applications running on different platforms would require a middle component-dependent intercommunication layer that is expensive, difficult to build, and reintroduces tight coupling between systems, which is what we tried to avoid in the first place. Avoiding building this intercommunication layer would require that the data exchange between these applications be done by a person who will read the necessary data from the source application and write it into the target application. We need to integrate these systems, and maintain the loose coupling between them. What we need to do, is make these components understand each other, making them to speak the same language. This is where the concept of services and Service-Oriented Architecture (SOA) comes into play. Service-Oriented Architecture SOA describes an information technology architecture that enables distributed computing environments with many different types of computing platforms and applications. To enable distributed computing environments, SOA defines the concept of services. A service is a well-defined, self-contained unit of functionality, independent of the state of other services. Let's see how services can be used to create distributed applications, integrate component-based applications, and make them communicate with each other. We keep our data access layer and business logic layer as they are, but we completely decouple the presentation layer so we can change it later without affecting the other layers. In order to expose the functionality of the business logic layer, we wrap it in a service interface. The service interface wraps the business logic layer components offering a point of access for any process that needs to access the business logic, whose functionality has now become a service. Service-oriented architecture is basically a collection of services that communicate with each other. The communication can involve either simple data passing or it can involve two or more services coordinating some activity. Whatever the required functionality may be, we have now separated the functionality of applications into specific units, the services that we use to construct flexible, distributed applications. Typically services reside on different machines. They are exposed to the outside world by service interfaces. A service provider provides its functionality using the service interfaces that are used or consumed by the service consumers. A service consumer sends a service request to a service interface and receives a service response. The following figure represents a typical service consumer-service provider request. A service can be a service provider and a service consumer at the same time as it can consume other services. They communicate using a communication medium like a local area network for internal services or the Internet for external services. This communication medium is called a service bus. We saw that services don't have a presentation layer as we've decoupled the presentation layer from the rest. This presents an advantage because we can now use any platform able to understand and consume the service to build a presentation layer. The service interface has to provide a standard and open way of communication, a common language that both service providers and service consumers can understand, regardless of the machine type they are deployed on, their physical location, and the language in which they are written. XML Web Services In today's world, the communication standard used to connect services is achieved using web services. Web services are small, reusable applications that help computers with many different operating system platforms work together by exchanging messages. Web services are based on industry protocols that include XML (Extensible Markup Language), SOAP (Simple Object Access Protocol), and WSDL (Web Services Description Language). These protocols help computers work together across platforms and programming languages enabling data exchange between otherwise unconnected sources: Client-to-Client: Devices, also called smart clients, can host and consume XML web services, allowing data sharing anywhere, anytime. Client-to-Server: A server application can share data with desktop or mobile devices using XML web services over the Internet. Server-to-Server: Independent server applications can use XML web services as a common interface to share and exchange data. Service-to-Service: Systems that work together to deliver complex data processing can be created using XML web services. The following figure shows an example of services exposed using web services, which deliver their functionality to a wide variety of platforms and applications. Service-oriented architecture provides us with the maximum flexibility in building applications. Individual services define specific application functions and interact with one another to provide the entire business process functionality. Encapsulation: Just as an object encapsulates its internal implementation details inside while providing public methods to external objects, services encapsulate their internal complexity and implementation from the service consumers who don't have to know the internal details. Mobility: As services are independent and encapsulated, they can be deployed in any location. Since they are using the same standard communication language, they are accessed in the same way irrespective of their physical location or implementation details. Parallel development: A service-oriented application is built using several service layers and clients. These application components can be built in parallel by developers specialized in specific layer functionality, speeding up the development process. Platform independence: Service providers and service consumers can be written in any language and deployed on any platform, as long as they can speak the standard communication language. Security: More security can be added to a service-oriented application at the service interface layer. Different application components require different security levels. The security can be enforced by using firewalls configured to allow access only to the required service providers only by the required service consumers. In addition, by using Web Service Enhancements (WSE), authentication, authorization, and encryption can be easily added. Reusability: Once a service is constructed and deployed, it can be used by any other service consumer without problems related to platform integration and interoperability. Choosing an Application Architecture Now that we have seen the existing application architectures, we must choose one that meets our project requirements. As you may have guessed by this point, the best application architecture we can use for our project is a Service-Oriented Architecture (SOA). The SOA allows us to build a distributed system, a system that has great flexibility and interoperability with other systems on other platforms. This will allow us to build the business logic functions and expose them as services that will be used by higher functionality layers. Choosing an Application Platform After choosing our application architecture, we must choose a platform capable of building and supporting it. For the purpose of our system we will choose the Microsoft .NET Framework platform and build the system using Microsoft Visual Studio.NET 2005 and Microsoft SQL Server as the back-end database for storing the data. Microsoft .NET Framework From a Service-Oriented Architecture point of view, the .NET Framework is the Microsoft strategy for connecting systems, information, and devices through software such as web services. .NET technology provides the capability to quickly build, deploy, manage, and use connected, security-enhanced solutions through the use of web services. Intrinsically, the .NET Framework is an environment for development and execution that allows different programming languages and libraries to work together to create Windows-based applications that are easier to build, manage, deploy, and integrate with other networked systems. The .NET core components are: The Common Language Runtime (CLR): A language-neutral development and execution environment that provides a consistent model and services to manage application execution that includes: Support for different programming languages: A variety of over 20 programming languages that target the CLR, such as C#, VB.NET, and J#, can be used to develop applications. Support for libraries developed in different languages: Libraries developed in different languages integrate seamlessly, making application development faster and easier. Support for different platforms: .NET applications are not tied to a single platform and can be executed on any platform that supports the CLR. Enhanced security: The .NET Code Access Security model provides a managed environment for application execution and security. Automatic resource management: The CLR automatically handles process, memory, and thread management, enabling developers to focus on the core business logic code.   The Framework Class Libraries (FCL): An object-oriented library of classes that extends a wide range of functionality including: Support for basic operations: Input/output and string management, standard network protocols, and network standards such as TCP/IP, XML, SOAP, and HTTP are supported natively to allow basic operations and system connections. Support for data access and data manipulation: The FCL includes a range of data access and data manipulation classes forming the ADO.NET technology that natively supports XML and data environments such as SQL Server and Oracle. Support for desktop applications: Rich desktop and mobile client applications can be easily created using the Windows Forms technology. Support for web applications: Thin web clients, websites, and web services can be created using web forms and XML web services technologies that form ASP.NET.   In the planning phase we've gathered the project requirements and specifications and we've also chosen an application architecture. The next phase is the design phase. Designing the System In the design phase, we will create an application design based on the application architecture, project requirements, and specifications. Gathering all the information needed to design the system is a difficult task, but the most important step is to start writing down the first idea. System Structure The system will be composed from the following main component categories: Core components (Data Access Layer, Business Logic Layer) forming the middle-tier component layers. Web service components (XML Web service) forming the Service Interface layer. Website components (ASP.NET website) forming the front-end WebReservation application, a web presentation layer. Windows Application components (Windows Forms Application) forming the WinReservation application, a Windows presentation layer. The following figure illustrates the overall system structure, outlining each system component: As we saw earlier, one major advantage of a service-oriented application is the decoupling of the presentation layer from the business logic layer. This allows for the business logic layer being exposed as a web service to be used by other third parties to integrate its functionality into their business process. Database Structure The back-end database is hosted by a Microsoft SQL Server system. According to the project specifications the internal database structure will be composed of the following database tables: User (Contains the user accounts) Guest (Contains the personal details of the guests) Room (Contains the details of each of the hotel's rooms) Reservation (Contains the details of the reservation made by each user) The following figure illustrates these tables and the relations between them. The bold fields are mandatory (not NULL). The User table contains the following rows:    

The ResultSet interface requires a persistent connection with a database to invoke the insert, update, and delete row operations on the database table data. The RowSet interface extends the ResultSet interface and is a container for tabular data that may operate without being connected to the data source. Thus, the RowSet interface reduces the overhead of a persistent connection with the database. In J2SE 5.0, five new implementations of RowSet—JdbcRowSet, CachedRowSet, WebRowSet, FilteredRowSet, and JoinRowSet—were introduced. The WebRowSet interface extends the RowSet interface and is the XML document representation of a RowSet object. A WebRowSet object represents a set of fetched database table rows, which may be modified without being connected to the database. Support for Oracle Web RowSet is a new feature in Oracle Database 10g driver. Oracle Web RowSet precludes the requirement for a persistent connection with the database. A connection is required only for retrieving data from the database with a SELECT query and for updating data in the database after all the required row operations on the retrieved data has been performed. Oracle Web RowSet is used for queries and modifications on the data retrieved from the database. Oracle Web RowSet, as an XML document representation of a RowSet facilitates the transfer of data. In Oracle Database 10g and 11g JDBC drivers, Oracle Web RowSet is implemented in the oracle.jdbc.rowset package. The OracleWebRowSet class represents a Oracle Web RowSet. The data in the Web RowSet may be modified without connecting to the database. The database table may be updated with the OracleWebRowSet class after the modifications to the Web RowSet have been made. A database JDBC connection is required only for retrieving data from the database and for updating the database. An XML document representation of the data in a Web RowSet may be obtained for data exchange. In this article, the Web RowSet feature in Oracle 10g database JDBC driver is implemented in JDeveloper 10g. An example Web RowSet will be created from a database. The Web RowSet will be modified and stored in the database table. In this article, we will learn the following: Creating a Oracle Web RowSet object Adding a row to Oracle Web RowSet Modifying the database table with Web RowSet In the second half of the article, we will cover the following : Reading a row from Oracle Web RowSet Updating a row in Oracle Web RowSet Deleting a row from Oracle Web RowSet Updating Database Table with modified Oracle Web RowSet Setting the Environment We will use Oracle database to generate an updatable OracleWebRowSet object. Therefore, install Oracle database 10g including the sample schemas. Connect to the database with the OE schema: SQL> CONNECT OE/<password> Create an example database table, Catalog, with the following SQL script: CREATE TABLE OE.Catalog(Journal VARCHAR(25), Publisher Varchar(25),Edition VARCHAR(25), Title Varchar(45), Author Varchar(25));INSERT INTO OE.Catalog VALUES('Oracle Magazine', 'OraclePublishing', 'July-August 2005', 'Tuning Undo Tablespace','Kimberly Floss');INSERT INTO OE.Catalog VALUES('Oracle Magazine', 'OraclePublishing', 'March-April 2005', 'Starting with Oracle ADF', 'SteveMuench'); Configure JDeveloper 10g for Web RowSet implementation. Create a project in JDeveloper. Select File | New | General | Application. In the Create Application window specify an Application Name and click on Next. In the Create Project window, specify a Project Name and click on Next. A project is added in the Applications Navigator. Next, we will set the project libraries. Select Tools | ProjectProperties and in the Project Properties window, select Libraries | Add Library to add a library. Add the Oracle JDBC library to project libraries. If the Oracle JDBC drivers version prior to the Oracle database 10g (R2) JDBC drivers version is used, create a library from the Oracle Web RowSet implementation classes JAR file: C:JDeveloper10.1.3jdbclibocrs12.jar. The ocrs12.jar is required only for JDBC drivers prior to Oracle database 10g (R2) JDBC drivers. In Oracle database 10g (R2) JDBC drivers OracleRowSet implementation classes are packaged in the ojdbc14.jar. In Oracle database 11g JDBC drivers Oracle RowSet implementation classes are packaged in ojdbc5.jar and ojdbc6.jar. In the Add Library window select the User node and click on New. In the Create Library window specify a Library Name, select the Class Path node and click on Add Entry. Add an entry for ocrs12.jar. As Web RowSet was introduced in J2SE 5.0, if J2SE 1.4 is being used we also need to add an entry for the RowSet implementations JAR file, rowset.jar. Download the JDBC RowSet Implementations 1.0.1 zip file, jdbc_rowset_tiger-1_0_1-mrel-ri.zip, from http://java.sun.com/products/jdbc/download.html#rowset1_0_1 and extract the JDBC RowSet zip file to a directory. Click on OK in the Create Library window. Click on OK in the Add Library window. A library for the Web RowSet application is added. Now configure an OC4J data source. Select Tools | Embedded OC4J Server Preferences. A data source may be configured globally or for the current workspace. If a global data source is created using Global | Data Sources, the data source is configured in the C:JDeveloper10.1.3jdevsystemoracle.j2ee.10.1.3.36.73embedded-oc4jconfig data-sources.xml file. If a data source is configured for the current workspace using Current Workspace | Data Sources, the data source is configured in the data-sources.xml file. For example, the data source file for the WebRowSetApp application is WebRowSetApp-data-sources.xml. In the Embedded OC4J Server Preferences window configure either a global data source or a data source in the current workspace. A global data source definition is available to all applications deployed in the OC4J server instance. A managed-data-source element is added to the data-sources.xml file. <managed-data-source name='OracleDataSource' connection-pool-name='Oracle Connection Pool' jndi-name='jdbc/OracleDataSource'/><connection-pool name='Oracle Connection Pool'><connection-factory factory-class='oracle.jdbc.pool.OracleDataSource' user='OE' password='pw'url="jdbc:oracle:thin:@localhost:1521:ORCL"></connection-factory></connection-pool> Add a JSP, GenerateWebRowSet.jsp, to the WebRowSet project. Select File | New | Web Tier | JSP | JSP. Click on OK. Select J2EE 1.3 or J2EE 1.4 in the Web Application window and click on Next. In the JSP File window specify a File Name and click on Next. Select the default settings in the Error Page Options page and click on Next. Select the default settings in the Tag Librarieswindow and click on Next. Select the default options in the HTML Options window and click on Next. Click on Finish in the Finish window. Next, configure the web.xml deployment descriptor to include a reference to the data source resource configured in the data-sources.xml file as shown in following listing: <resource-ref><res-ref-name>jdbc/OracleDataSource</res-ref-name><res-type>javax.sql.DataSource</res-type><res-auth>Container</res-auth></resource-ref>

<cfscript> Enhancements Poor <cfscript>! It can't be easy being the younger sibling to CFML tags. Natively, you can just do more with tags. Tags are arguably easier to learn and read, especially for beginners. Yet, since its introduction in ColdFusion 4.0, <cfscript> has dutifully done its job while getting none, or little, of the love. Given that ColdFusion was marketed as an easy-to-learn tag-based language that could be adopted by non-programmers who were only familiar with HTML, why did Allaire make the effort to introduce <cfscript>? Perhaps it was an effort to add a sense of legitimacy for those who didn't view a tag-based language as a true language. Perhaps it was a matter of trying to appeal to more seasoned developers as well as beginners. In either case, <cfscript> <cfscript> wasn't without some serious limitations that prevented it from gaining widespread acceptance.<cfscript> For example, while it boasted an ECMAScript-like syntax, which perhaps would have made it attractive to JavaScript developers, it was tied tightly enough to CFML that it used CFML operators. If you were used to writing the following to loop over an array in JavaScript: for (var i=0; i<myArray.length; i++) { … it wasn't quite a natural progression to write the same loop in cfscript<cfscript>: <cfscript>for (i=1; i lt arrayLen(myArray); i=i+1) {<cfscript> On the surface, it may look similar enough. But there are a few significant differences. First, the use of "lt" to represent the traditional "<" ('less than' operator). Second, the lack of a built-in increment operator. While ColdFusion does have a built-in incrementValue() function, that doesn't really do much to bridge the gap between <cfscript> and ECMAScript. When you're used to using traditional comparison operators in a scripting language (<, =, >, etc), as well as using increment operators (++), you would likely end up losing more time than you'd save in <cfscript>. Why? Because chances are that you'd type out the loop using the traditional comparison operators, run your code, see the error, smack your forehead, modify the code, and repeat. Well, your forehead is going to love this. As of ColdFusion 8, cfscript supports all of the traditional comparison operators (<, <=, ==, !=, =>, >). In addition, both <cfscript> and CFML support the following operators as of ColdFusion 8: Operator Name ColdFusion Pre CF 8 ColdFusion 8 ++ Increment i=i+1 i++ -- Decrement i=i-1 i-- % Modulus x = a mod b x = a%b += Compound Addition x = x + y x += y -= Compound Subtraction x = x - y x -= y *= Compound Multiplication x = x * y x *= y /= Compound Division x = x / y x /= y %= Compound Modulus x = x mod y x %= y &= Compound Concatenation (Strings) str = "abc"; str = str & "def"; str = "abc"; str &= "def"; && Logical And if (x eq 1) and (y eq 2) if (x == 1) && (y == 2) || Logical Or if (x eq 1) or (y eq 2) if (x == 1) || (y == 2) ! Logical Complement if (x neq y) if (! x == y)   For people who bounce back and forth between ColdFusion and languages like JavaScript or ActionScript, this should make the transitions significantly less jarring. Array and Structure Enhancements Arrays and structures are powerful constructs within the world of programming. While the naming conventions may be different, they exist in virtually every language. Creating even a moderately complex application without them would be an unpleasant experience to say the least. Hopefully you're already putting them to use. If you are, your life just got a little bit easier. Creating Arrays One of the perceived drawbacks to a tag-based language like CFML is that it can be a bit verbose. Consider the relatively straightforward task of creating an array and populating it with a small amount of data: <cfset myArray  = arrayNew(1) /><cfset myArray[1] = "Moe" /><cfset myArray[2] = "Larry" /><cfset myArray[3] = "Curly" /> In <cfscript> it gets a little bit better by cutting out some of the redundancy of the <cfset> <cfset> tags: <cfset&gt<cfscript> myArray  = arrayNew(1); myArray[1] = "Moe"; myArray[2] = "Larry"; myArray[3] = "Curly";</cfscript></cfset&gt A little bit better. But if you're familiar with languages like JavaScript, ActionScript, Java, or others, you know that this can still be improved upon. That's exactly what Adobe's done with ColdFusion 8. ColdFusion 8 introduces shorthand notation for the creation of arrays. <cfset myArray = [] /> The code above will create an empty array. In and of itself, this doesn't seem like a tremendous time saver. But, what if you could create the array and populate it at the same time? <cfset myArray = ["Larry", "Moe", "Curly"] /> The square brackets tell ColdFusion that you're creating an array. Inside the square brackets, a comma-delimited list populates the array. One caveat to be aware of is that ColdFusion has never taken much of a liking to empty list elements. The following will throw an error: <cfset myArray = ["Larry", , "Curly"] /> <!-- don't do this --> If you're populating your array dynamically, take steps to ensure that there are no empty elements in the list.      

BlackBerry Enterprise Server Components BlackBerry Enterprise Server is not a single service. Like many complex application servers, BES is comprised of a number of services and components that are integrated to deliver the full feature set. Below is a list of the components and a description of their function. Component Name Component Function BlackBerry Attachment Service The BlackBerry Attachment Service converts email attachments into a format that can be viewed on BlackBerry devices. BlackBerry Collaboration Service The BlackBerry Collaboration Service encrypts the communications between instant messaging servers and the instant messenger client on client on BlackBerry devices. BlackBerry Configuration Database The BlackBerry Configuration Database is a relational database that stores the configuration information for the BES components, using either Microsoft SQL Developer Edition (MSDE) or Microsoft SQL Server. BlackBerry Controller The BlackBerry Controller monitors BES components and restarts any stopped services. BlackBerry Dispatcher The BlackBerry Dispatcher handles compression and encryption for BlackBerry data. BlackBerry Manager The BlackBerry Manager is used for administration of the BES. BlackBerry MDS Connection Service The BlackBerry MDS Connection Service is used to connect BlackBerry devices to online content and applications. BlackBerry MDS Services The BlackBerry MDS Services provide connectivity between BlackBerry MDS Studio Applications on BlackBerry devices and enterprise applications. BlackBerry MDS Studio Application Repository The BlackBerry MDS Studio Application Repository stores and manages BlackBerry MDS Studio Applications. BlackBerry Messaging Agent The BlackBerry Messaging Agent serves as the connection between the email server and the other BES components. BlackBerry Policy Service The BlackBerry Policy Service manages the IT policies for the BlackBerry devices. BlackBerry Router The BlackBerry Router connects to the BlackBerry Infrastructure and communicates with the BlackBerry devices. BlackBerry Synchronization Service The BlackBerry Synchronization Service syncs organizer data (tasks, calendar, etc.) between the email server and the BlackBerry devices. The component-based design of BES provides flexibility and scalability as you plan your implementation. This is due to the fact that the components can be installed on a single server or distributed among several servers based on your needs. The BlackBerry Enterprise Server components are integrated to deliver the desired services to your handheld clients. BlackBerry Enterprise Server Requirements and Prerequisites The BlackBerry Enterprise Server system requirements vary based on the number of users supported. Below are the recommended minimum requirements for a BlackBerry Enterprise Server v4.1 for Microsoft Exchange that supports 500 users. Refer to the BlackBerry Enterprise Server Version 4.1 for Microsoft Exchange Server Capacity Calculator at the BlackBerry Technical Solution Center (http://www.blackberry.com/btsc/) to calculate the system requirements for your environment. Intel® Pentium® IV, 2 GHz or better. 1.5GB RAM. BES supports specific Microsoft Windows and Exchange environments. Following are the basic software requirements. Microsoft Windows 2000 Server or Windows Server 2003. Microsoft Exchange 5.5 (SP4 or better), Microsoft Exchange 2000 (SP2 or better), Microsoft Exchange 2003, Microsoft Exchange 2007. Microsoft Internet Explorer 6.0 or better. In addition to the basic hardware and software requirements, there are a number of prerequisites for BES. Some of the prerequisites are installed as a part of the BES setup program, but others must be installed prior to starting the BES installation. Below is the list of prerequisites. Prerequisite Required/ Optional Notes Microsoft Messaging Queue (MSMQ) Version 3.0 Optional This is required for installations that will use Microsoft Windows Messenger. Microsoft .NET Framework Version 1.1 Required This may be installed during BES installation. SP1 is required to use Microsoft Windows Messenger. Microsoft Data Access Components (MDAC) Version 2.8 Required This requires either Security Patch MS04-003 (Version 2000.85.1025.00) or SP2 (Version 2000.86.1830.00) for Microsoft Windows Server 2003 SP1. Java® 2 Platform, Standard Edition (J2SETM) Runtime Environment Version 5.0 update 9 Required This may be installed during BES installation. Internet Service Manager for Internet Information Services Optional This is required for Microsoft Exchange 2007 support. Microsoft Exchange administration tools Required The appropriate tools for your Exchange version should be installed. Microsoft Exchange Version 5.5 Administrator Microsoft Exchange 2000 System Manager Microsoft Exchange  003 System Manager Microsoft Exchange Server MAPI Client and Collaboration Data Objects 1.2.1 For Exchange 2007, Microsoft Exchange Server MAPI Client and Collaboration Data Objects 1.2.1, or Microsoft Exchange Server 2003 System Manager with SP2 Refer to the BlackBerry Enterprise Server for Microsoft Exchange Installation Guide for your version of BES for an up-to-date list of system requirements, especially if you are planning to implement additional services above and beyond the basic messaging and collaboration.  

Categories, Products, and Attributes Products are the items that are sold. In Magento, Categories organize your Products, and Attributes describe them. Think of a Category as the place where a Product lives, and an Attribute is anything that describes a Product. Each one of your Products can belong to one or more Categories. Also, each Product can be described by any number of Attributes. Is it a Category or an Attribute? Some things are clearly Categories. For example, if you have an electronics store, MP3 players would make a good Category. If you're selling jewellery, earrings would make a good Category. Other things are clearly Attributes. Color, description, picture, and SKU number are almost always Attributes. Sometimes, the same thing can be used for a Category or an Attribute. For example, suppose your site sells shoes. If you made size an Attribute, then after your shoppers have located a specific shoe, they can select the size they want. However, if you also made size a Category, the shoppers could begin their shopping by selecting their size. Then they could browse through the styles available in their size. So should size be an Attribute, a Category, or both? The answer depends upon what kind of shopping experience you want to create for your customers. Examples The hierarchy of Categories, Products, and Attributes looks like this: Category 1 Product 1 Attribute 1 Attribute 2 Product 2 Attribute 1 Attribute 2 Category 2 Product 3 Attribute 1 Attribute 3 Product 4 Attribute 1 Attribute 3 We are building a site that sells gourmet coffee, so we might organize our store like this: Single Origin Hawaiian Kona Grind (whole bean, drip, French press) Roast (light, medium, dark) Blue Mountain Grind Roast Blends Breakfast Blend Grind Caffeine (regular, decaffeinated) Afternoon Cruise Grind Caffeine In Magento, you can give your shoppers the ability to search your store. So if the shoppers know that they want Blue Mountain coffee, they can use the Search function to find it in our store. However, customers who don't know exactly what they want will browse the store. They will often begin browsing by selecting a category. With the organization that we just saw, when customers browse our store, they will start by selecting Single Origin or Blends. Then the shoppers will select the product they want: Hawaiian Kona, Blue Mountain, Breakfast Blend, or Afternoon Cruise. After our shoppers decide upon a Product, they select Attributes for that product. In our store, shoppers can select Grind for any of the products. For Single Origin, they can also select Roast. For blends, they can select Caffeine. This gives you a clue about how Magento handles attributes. To each Product, you can apply as many, or as few, attributes as you want. Now that we have definitions for Category, Product, and Attribute, let's look at each of them in detail. Then, we can start adding products. Categories Product Categories are important because they are the primary tool that your shoppers use to navigate your store. Product Categories organize your store for your shoppers. Categories can be organized into Parent Categories and Subcategories. To get to a Subcategory, you drill down through its Parent Category. Categories and the Navigation Menu If a Category is an Anchor Category, then it appears on the Navigation Menu. The term "Anchor" makes the category sound as if it must be a top-level category. This is not true. You can designate any category as an Anchor Category. Doing so puts that category into the Navigation Menu. When a shopper selects a normal Category from the Navigation Menu, its landing page and any subcategories are displayed. When a shopper selects an Anchor Category from the menu, Magento does not display the normal list of subcategories. Instead, it displays the Attributes of all the Products in that category and its subcategories. Instead of moving down into subcategories, the shopper uses the Attributes to filter all the Products in that Anchor Category and the Categories below it. The Navigation Menu will not display if: You don't create any Categories, or You create Categories, but you don't make any of them Anchors, or Your Anchor Categories are not subcategories under the Default Category. The Navigation Menu will display only if: You have created at least one Category You have made at least one Category an Anchor You have made the Anchor Category a Subcategory under Default. When you first create your Magento site and add Products, you won't see those Products on your site until you've met all of the previous conditions. For this reason I recommend that you create at least one Anchor Category before you start adding Products to your store. As you add each Product, add it to an Anchor Category. Then, the Product will display in your store, and you can preview it. If the Anchor Category is not the one that you want for that Product, you can change the Product's Category later Before we add Products to our coffee store, we will create two Anchor Categories: Single Origin and Blends. As we add Products, we will assign them to a Category so that we can preview them in our storefront. Making best use of Categories There are three things that Categories can accomplish. They can: Help the shoppers, who know exactly what they want, to find the product that they are looking for. Help the shoppers, who almost know what they want, to find a product that matches their desires. Entice the shoppers, who have almost no idea of what they want, to explore your store. We would like to organize our store so that our Categories accomplish all these goals. However, these goals are often mutually exclusive. For example, suppose you create an electronics store. In addition to many other products, your store sells MP3 players, including Apple iPods. A Category called iPods would help the shoppers who know that they want an iPod, as they can quickly find one. However, the iPods Category doesn't do much to help shoppers who know that they want an MP3 player, but don't know what kind. On the Web, you usually search something when you know what you want. But when you're not sure about what you want, you usually browse. In an online store, you usually begin browsing by selecting a Category. When you are creating Categories for your online store, try to make them helpful for shoppers who almost know what they want. However, what if a high percentage of your shoppers are looking for a narrow category of products? Consider creating a top-level Category to make those products easily accessible. Again, suppose you have an electronics store that sells a wide variety of items. If a high percentage of your customers want iPods, it might be worthwhile to create a Category just for those few products. The logs from the Search function on your site are one way you can determine whether your shoppers are interested in a narrow Category of a Product. Are 30 percent of the searches on your site for left-handed fishing reels? If so, you might want to create a top-level Category just for those Products. Attributes An Attribute is a characteristic of a Product. Name, price, SKU, size, color, and manufacturer are all examples of Attributes. System versus Simple Attributes Notice that the first few examples (name, price, and SKU) are all required for a Product to function in Magento. Magento adds these Attributes to every product, and requires you to assign a value for each of them. These are called System Attributes. The other three examples (size, color, and manufacturer) are optional Attributes. They are created by the store owner. They are called Simple Attributes. When we discuss creating and assigning Attributes, we are almost always discussing Simple Attributes. Attribute Sets Notice that the Single Origin coffees have two Attributes: Grind and Roast. Also notice that the blends have the Attributes of Grind and Caffeine. Single Origin Hawaiian Kona Grind (whole bean, drip, French press) Roast (light, medium, dark) Blue Mountain Grind Roast Blends Breakfast Blend Grind Caffeine (regular, decaffeinated) Afternoon Cruise Grind Caffeine In this example, the store owner created three Attributes: Grind, Roast, and Caffeine. Next, the store owner grouped the Attributes into two Attribute Sets: one set contains Grind and Roast, and the other set contains Grind and Caffeine. Then, an Attribute set was applied to each Product. Attributes are not applied directly to Products. They are first grouped into Attribute Sets, and then a set can be applied to a Product. This means that you will need to create a set for each different combination of Attributes in your store. You can name these Sets after the Attributes they contain, such as Grind-Roast. Or, you can name them after the type of Product which will use those Attributes, such as Single Origin Attributes. If each Product in a group will use the same Attribute as every other Product in that group, then you can name the set after that group. For example, at this time, all Single Origin coffees have the same Attributes: Grind and Roast. If they will all have these two Attributes and you will always add and remove Attributes to them as a group, then you could name the set Single Origin Attributes. If the Products in a group will likely use different Attributes, then name the set after the Attributes. For example, if you expect that some Single Origin coffees will use the Attributes Grind and Roast, while others will use just Roast, then it would not make sense to create a set called Single Origin Attributes. Instead, create a set called Grind-Roast, and another called Roast. Three types of Products In Magento, you can create three different types of Products: Simple, Configurable, and Grouped. The following is a very brief definition for each type of Product. Simple Product A Simple Product is a single Product, with Attributes that the store owner chooses. As the saying goes, "What you see is what you get." The customer does not get to choose anything about the Product. In our coffee store, a good example for a Simple Product might be a drip coffee maker. It comes in only one color. And while the customer can buy drip coffee makers of various sizes (4 cups, 8 cups, 12 cups, and so on), each of those is a separate Product. A bad example of a Simple Product would be a type of coffee. For example, we might want to allow the customer to choose the type of roast for our Hawaiian Kona coffee: light, medium, or dark. Because we want the customer to choose a value for an Attribute, that would not be a good Simple Product. Configurable Product A Configurable Product is a single Product, with at least one Attribute that the customer gets to choose. There is a saying that goes, "Have it your way." The customer gets to choose something about the Product. A good example of a Configurable Product would be a type of coffee that comes in several different roasts: light, medium, and dark. Because we want the customer to choose the roast(s) he wants, that would be a good Configurable Product. Grouped Product A Grouped Product is several Simple Products that are displayed on the same page. You can force the customer to buy the group, or allow the customer to buy each Product separately. The previous definitions are adequate for now. However, when you start creating Products, you will need to know more about each type of Product.

Introducing Microsoft Windows Mobile There exist several types of smart devices in the market including Smart Phones, Pocket PCs, Pocket PC Phones, Tablet PCs, etc. Every smart device is installed with a mobile‑based operating system with respect to the features of the device. One of such operating systems is Microsoft Windows CE. Microsoft Windows CE is a small, embedded operating system (runs from ROM) that has a look and feel similar to Microsoft Windows 95/98. It includes scaled down versions of Microsoft Excel, Microsoft Word, Microsoft Internet Explorer, etc. Microsoft Windows Mobile (Windows Mobile in short) is a complete software platform built on Windows CE. Unlike Windows CE, the Windows Mobile for Smart Phone or Pocket PC operating systems is specifically designed for devices that require a specialized hardware configuration. The software includes standardized interfaces and applications that ensure compatibility across hardware designs. The Pocket PC is the best example device that gets equipped with Microsoft Windows Mobile operating system. The Pocket PC runs Windows CE as its core operating system. Pocket PCs come with mobile versions of Microsoft Office applications in addition to Microsoft Outlook Mobile. Though there are different Pocket PCs, many come with Wi-Fi to enable you to connect to the Internet when you are near to a wireless hotspot. You can compose email messages and send them wirelessly or by synchronizing with your desktop computer. A Pocket PC Phone is a bit different from an ordinary Pocket PC. You can do everything with a Pocket PC Phone that you can do with a Pocket PC, but with the addition of cellular phone capabilities. If you have a Pocket PC Phone, you can access the Internet through the GPRS service. A Smart Phone has phone capabilities and comes with a smaller set of applications. Though you can add third-party software titles to your Smart Phone, the smaller keypad and screen are designed to give you quick one-handed access to important data. A Smart Phone is a good choice for business users who need to check email, keep track of their calendars, and take voice notes. Microsoft.NET enables us to develop and deploy .NET applications on Microsoft Windows Mobile-enabled smart devices like Smart Phones, Pocket PCs, Tablet PCs, etc. To develop for either Smart Phones or Pocket PCs, we need not really buy those devices. We simply need to have smart device client extensions installed as a part of Visual Studio 2005 (which automatically installs .NET Compact Edition). When the extensions are installed, we are provided with few device emulators for developing and testing .NET-based mobile applications. However, for testing and production, it is recommended to have physical smart devices. The next section focuses on developing a simple Pocket PC application, which consumes the web service developed previously. Consuming a Web Service from Pocket PC Now, let us make use a web service for the Pocket PC. You need not have a physical Pocket PC in your hands to test it. We can simply use existing emulators available as part of Visual Studio 2005. The following are the steps: Open Visual Studio 2005 Environment    Go to File | New | Project.    Select and provide information as shown in the following figure:      Add a Web Reference for the web service you created.    Drag and drop a DataGrid on to the Pocket PC emulator as shown below:      Modify the existing code as follows: Public Class Form1 Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load Me.DataGrid1.DataSource = (New EmpService.Service).getList.Tables(0) End SubEnd Class     Press F5, and select any Emulator for deployment. The output should look like the following: Conclusion We have seen the deployment of .NET-based application on to smart devices enabled with Microsoft Windows Mobile operating system.

The following screenshot describes a simple web application, which has a page for the new user registration. The user has to provide the necessary field details. After entering the details, the user will click on the Register button provided in the web page to submit all the details so that it gets registered to the site. To confirm this to the user, the system will send a notification with a welcoming email to the registered user. The mail is sent to the email address provided by the user. In the application shown in the above screenshot, the entire registration process cannot be automated for testing. For example, the email verification and checking the confirmation email sent by the system will not be automated as the user has to go manually and check the email. This part of the manual testing process will be explained in detail in this article. Manual tests Manual testing, as described earlier, is the simplest type of testing carried out by the testers without any automation tool. This test may contain a single or multiple tests inside. Manual test type is the best choice to be selected when the test is too difficult or complex to automate, or if the budget allotted for the application is not sufficient for automation. Visual Studio 2008 supports two types of manual tests file types. One as text file and the other as Microsoft Word. Manual test using text format This format helps us to create the test in the text format within Visual Studio IDE. The predefined template is available in Visual Studio for authoring this test. This template provides the structure for creating the tests. This format has the extension of .mtx. Visual Studio servers act as an editor for this test format. For creating this test in Visual Studio, either create a new test project and then add the test or select the menu option Test | New Test... and then choose the option to add the test to a new project. Now create the test using the menu option and select Manual Test (Text Format) from the available list as shown in the screenshot below. You can see the list Add to Test Project drop–down, which lists the different options to add the test to a test project. If you have not yet created the test project and selected the option to create the test, the drop-down option selected will create a new test project for the test to be added. If you have a test project already created, then we can also see that project in the list to get this new test added to the project. We can choose any option as per our need. For this sample, let us create a new test project in C#. So the first option from the drop-down of Add to Test Project would be selected in this case. After selecting the option, provide the name for the new test project the system will ask for. Let us name it TestingAppTest project. Now you can see the project getting created under the solution and the test template is also added to the test project as shown next. The template contains the detailed information for each section. This will help the tester or whoever is writing the test case to write the steps required for this test. Now update the test case template created above with the test steps required for checking the email confirmation message after the registration process. The test document also contains the title for the test, description, and the revision history for the changes made to the test case. Before executing the test and looking into the details of the run and the properties of the test, we will create the same test using Microsoft Word format as described in the next section. Manual test using Microsoft Word format This is similar to the manual test that was created using text format, except that the file type is Microsoft Word with extension .mht. While creating the manual test choose the template Manual Test (Word format) instead of the Manual Test (Text Format) as explained in the previous section. This option is available only if Microsoft Word is installed in the system. This will launch the Word template using the MS Word installed (version 2003 or later) in the system for writing the test details as shown in the following screenshot. The Word format helps us to have richer formatting capabilities with different fonts, colors, and styles for the text with graphic images and tables embedded for the test. This document not only provides the template but also the help information for each and every section so that the tester can easily understand the sections and write the test cases. This help information is provided in both the Word and Text format of the manual tests. In the test document seen in previous screenshot, we can fill the Test Details, Test Target, Test Steps, and Revision History similar to the one we did for the text format. The completed test case test document will look like this: Save the test details and close the document. Now we have both formats of manual tests in the project. Open the Test View window or the Test List Editor window to see the list of tests we have in the project. It should list two manual tests with their names and the project to which the tests are associated with. The tests shown in the Test View window looks like the one shown here: The same tests list shown by the Test List Editor would look like the one shown below. The additional properties like test list name, the project name the test belongs to, is also shown in the list editor. There are options for each test either to run or get added to any particular list. Manual tests also have other properties, which we can make use of during testing. These properties can be seen in the Properties window, which can be opened by choosing the manual test either in the Test View or in the Test List Editor windows by right-clicking the test and selecting the Properties option. The same window can also be opened by choosing the menu option View | Properties window. Both formats of manual testing have the same set of properties. Some of these properties are editable while some are read-only, which will be set by the application based on the test type. Some properties are directly related to TFS. The VSTFS is the integrated collaboration server, which combines team portal, work item tracking, build management, process guidance, and version control into a unified server.

  "Linux4afrika has the objective of bridging the digital divide between developed and disadvantaged countries, especially in Africa, by supporting  access to information technology. This is done through the collection of used computers in Germany, the terminal server project and Ubuntu software which is open source, and by providing support to the involved schools and institutions." In this interview with the founder Hans-Peter Merkel, Packt's Kushal Sharma explores the idea, support, and the future of this movement. Kushal Sharma: Who are the chief promoters of this movement? Hans-Peter Merkel: FreiOSS (established in 2004) with currently about 300 members started the Linux4afrika project in 2006. The input was provided by some African trainees doing their internship at St. Ursula High school in Freiburg where we currently have 2 Terminal servers running. The asked FreiOSS to run similar projects in Africa. KS: What initiated this vision to bridge the IT gap between the developed and the under developed nations? During 2002 to 2005 we conducted IT trainings on Open Source products during 3 InWEnt trainings “Information Technology in African business” (see http://www.it-ab.org) with 60 African trainees (20 each year). This made FreiOSS to move OSS out of the local area and include other countries, especially those countries we had participants from. KS: Can you briefly recount the history of this movement, from the time it started to its popularity today? HPM: As mentioned before, the Linux4afrika project has its roots with FreiOSS and St. Ursula High school. There itself the idea was born. I conduct Open Source trainings and security trainings in several African countries (see http://www.hpmerkel.com/events). During a training in Dar es Salaam I demonstrated the Terminal Server solution to participants in a security training. One of the participants informed a Minister of Tanzanian Parliament who immediately came to get more information on this idea. He asked whether Linux4afrika could collect about 100 Computers and ship them to Tanzania. Tanzania would cover the shipping costs. After retuning to Germany I informed FreiOSS regarding this, and the collection activity started. We found out more information about the container costs and found that a container would fit about 200 computers for the same price. Therefore we decided to change the number from 100 to 200. One Terminalserver (AMD 64 Dual Core with 2 GB Memory) can run about 20 Thin Clients. This would serve about 10 schools in Tanzania. The Ubuntu Community Germany heard about our project and invited us to Linuxtag in Berlin (2007). This was a breakthrough for us; many organizations donated hardware. 3SAT TV also added greatly to our popularity by sending a 5 minute broadcast about our project (see http://www.linux4afrika.de). In June we met Markus Feilner from German Linux Magazin who contacted us and also published serveral online reports. In September Linux4afrika was invited to the German Parliament to join a meeting about education strategies for the under developed countries. In October Linux4afrika will start collection for a second container which will be shipped end of the year. In early 2008 about 5 members of FreiOSS will fly to Dar es Salaam on their own costs to conduct a one week training where teachers will be trained. This will be an addon to the service from Agumba Computers Ltd. (see http://www.agumba.biz). Agumba offers support in Tanzania to keep the network running. During the InWEnt trainings from 2002-2005, three employees from Agumba were in that training. Currently, 2 other people from Agumba are here for a three month internship to become familiar with our solution and make the project sustainable. KS: Who are the major contributors? HPM: Currently FreiOSS in Germany and Agumba Computers in Tanzania are the major contributors. KS: Do you get any internal support in Tanzania and Mozambique? Do their Governments support open source? HPM: Yes, we do. In Tanzania, it's Augumba Computers and in Mozambique we have some support from CENFOSS. All trainings conducted by me on Security and Forensics had a 70 percent part on Open Source in Tanzania. Currently, the Governmental agencies are implementing those technologies mainly on servers. KS: Do you have any individuals working full-time for this project? If so, how do the full-time individuals support themselves financially? HPM: All supporters are helping us without any financial support. They all come after work to our meetings which take place about once a month. After some starting problems the group is now able to configure and test about 50 Thin clients per evening meetings. KS: Tell us something more about the training program: what topics do you cover, how many participants do you have so far, etc.? HPM: Tanzania shows a big interest in Security trainings. Agumba computers offers those trainings for about 4-6 weeks a year. Participants come from Tanzania Revenue Authority, Police, Presidents office, banks, water/electricity companies and others. Currently Tanzania Revenue Authority has sent 5 participants to conduct a 3 month Forensic training in Germany. In Tanzania about 120 participants joined the trainings so far. Sessions for next year will start in January 2007. KS: Packt supported the project by sending some copies of our OpenVPN book. How will these be used and what do you hope to gain from them? HPM: Markus Feilner (the author of the OpenVPN book) is currently in Tanzania. He will conduct a one and a half day training on OpenVPN in Dar es Salaam. The participants in Germany who received the books will receive practical training on IPCop and OpenVPN for Microsoft and Linux clients. This will help them establish secure Wireless in their country. KS: What does the future hold for Linux4afrika? Our current plans include the second container, the visit to Dar early 2008, and Linuxtag 2008. Further actions will be discussed therafter. We already have a few requests to expand the Terminalserver Solution to other under developed countries. Also, currently we have a request to support Martinique after the hurricane has destroyed huge parts of the island. KS:Thanks very much Hans-Peter for taking out time for us, and all the very best for your plans.

Readers familiar with previous versions of J2EE will notice that Entity Beans were not mentioned in the above paragraph. In Java EE 5, Entity Beans have been deprecated in favor of the Java Persistence API (JPA). Entity Beans are still supported for backwards compatibility; however, the preferred way of doing Object Relational Mapping with Java EE 5 is through JPA. Refer to Chapter 4 in the book Java EE 5 Development using GlassFish Application Server for a detailed discussion on JPA. Session Beans As we previously mentioned, session beans typically encapsulate business logic. In Java EE 5, only two artifacts need to be created in order to create a session bean: the bean itself, and a business interface. These artifacts need to be decorated with the proper annotations to let the EJB container know they are session beans. Previous versions of J2EE required application developers to create several artifacts in order to create a session bean. These artifacts included the bean itself, a local or remote interface (or both), a local home or a remote home interface (or both) and a deployment descriptor. As we shall see in this article, EJB development has been greatly simplified in Java EE 5. Simple Session Bean The following example illustrates a very simple session bean: package net.ensode.glassfishbook; import javax.ejb.Stateless; @Stateless public class SimpleSessionBean implements SimpleSession { private String message = "If you don't see this, it didn't work!"; public String getMessage() { return message; } } The @Stateless annotation lets the EJB container know that this class is a stateless session bean. There are two types of session beans, stateless and stateful. Before we explain the difference between these two types of session beans, we need to clarify how an instance of an EJB is provided to an EJB client application. When EJBs (both session beans and message-driven beans) are deployed, the EJB container creates a series of instances of each EJB. This is what is typically referred to as the EJB pool. When an EJB client application obtains an instance of an EJB, one of the instances in the pool is provided to this client application. The difference between stateful and stateless session beans is that stateful session beans maintain conversational state with the client, where stateless session beans do not. In simple terms, what this means is that when an EJB client application obtains an instance of a stateful session bean, the same instance of the EJB is provided for each method invocation, therefore, it is safe to modify any instance variables on a stateful session bean, as they will retain their value for the next method call. The EJB container may provide any instance of an EJB in the pool when an EJB client application requests an instance of a stateless session bean. As we are not guaranteed the same instance for every method call, values set to any instance variables in a stateless session bean may be "lost" (they are not really lost; the modification is in another instance of the EJB in the pool). Other than being decorated with the @Stateless annotation, there is nothing special about this class. Notice that it implements an interface called SimpleSession. This interface is the bean's business interface. The SimpleSession interface is shown next: package net.ensode.glassfishbook; import javax.ejb.Remote; @Remote public interface SimpleSession { public String getMessage(); } The only peculiar thing about this interface is that it is decorated with the @Remoteannotation. This annotation indicates that this is a remote business interface . What this means is that the interface may be in a different JVM than the client application invoking it. Remote business interfaces may even be invoked across the network. Business interfaces may also be decorated with the @Local interface. This annotation indicates that the business interface is a local business interface. Local business interface implementations must be in the same JVM as the client application invoking their methods. As remote business interfaces can be invoked either from the same JVM or from a different JVM than the client application, at first glance, we might be tempted to make all of our business interfaces remote. Before doing so, we must be aware of the fact that the flexibility provided by remote business interfaces comes with a performance penalty, because method invocations are made under the assumption that they will be made across the network. As a matter of fact, most typical Java EE application consist of web applications acting as client applications for EJBs; in this case, the client application and the EJB are running on the same JVM, therefore, local interfaces are used a lot more frequently than remote business interfaces. Once we have compiled the session bean and its corresponding business interface,we need to place them in a JAR file and deploy them. Just as with WAR files, the easiest way to deploy an EJB JAR file is to copy it to [glassfish installationdirectory]/glassfish/domains/domain1/autodeploy. Now that we have seen the session bean and its corresponding business interface, let's take a look at a client sample application: package net.ensode.glassfishbook; import javax.ejb.EJB; public class SessionBeanClient { @EJB private static SimpleSession simpleSession; private void invokeSessionBeanMethods() { System.out.println(simpleSession.getMessage()); System.out.println("nSimpleSession is of type: " + simpleSession.getClass().getName()); } public static void main(String[] args) { new SessionBeanClient().invokeSessionBeanMethods(); } } The above code simply declares an instance variable of type net.ensode.SimpleSession, which is the business interface for our session bean. The instance variable is decorated with the @EJB annotation; this annotation lets the EJB container know that this variable is a business interface for a session bean. The EJB container then injects an implementation of the business interface for the client code to use. As our client is a stand-alone application (as opposed to a Java EE artifact such as a WAR file) in order for it to be able to access code deployed in the server, it must be placed in a JAR file and executed through the appclient utility. This utility can be found at [glassfish installation directory]/glassfish/bin/. Assuming this path is in the PATH environment variable, and assuming we placed our client code in a JAR file called simplesessionbeanclient.jar, we would execute the above client code by typing the following command in the command line: appclient -client simplesessionbeanclient.jar Executing the above command results in the following console output: If you don't see this, it didn't work! SimpleSession is of type: net.ensode.glassfishbook._SimpleSession_Wrapper which is the output of the SessionBeanClient class. The first line of output is simply the return value of the getMessage() method we implemented in the session bean. The second line of output displays the fully qualified class name of the class implementing the business interface. Notice that the class name is not the fully qualified name of the session bean we wrote; instead, what is actually provided is an implementation of the business interface created behind the scenes by the EJB container. A More Realistic Example In the previous section, we saw a very simple, "Hello world" type of example. In this section, we will show a more realistic example. Session beans are frequently used as Data Access Objects (DAOs). Sometimes, they are used as a wrapper for JDBC calls, other times they are used to wrap calls to obtain or modify JPA entities. In this section, we will take the latter approach. The following example illustrates how to implement the DAO design pattern in asession bean. Before looking at the bean implementation, let's look at the business interface corresponding to it: package net.ensode.glassfishbook; import javax.ejb.Remote; @Remote public interface CustomerDao { public void saveCustomer(Customer customer); public Customer getCustomer(Long customerId); public void deleteCustomer(Customer customer); } As we can see, the above is a remote interface implementing three methods; thesaveCustomer() method saves customer data to the database, the getCustomer()method obtains data for a customer from the database, and the deleteCustomer() method deletes customer data from the database. Let's now take a look at the session bean implementing the above business interface. As we are about to see, there are some differences between the way JPA code is implemented in a session bean versus in a plain old Java object. package net.ensode.glassfishbook; import java.sql.Connection; import java.sql.PreparedStatement; import java.sql.ResultSet; import java.sql.SQLException; import javax.annotation.Resource; import javax.ejb.Stateless; import javax.persistence.EntityManager; import javax.persistence.PersistenceContext; import javax.sql.DataSource; @Stateless public class CustomerDaoBean implements CustomerDao { @PersistenceContext private EntityManager entityManager; @Resource(name = "jdbc/__CustomerDBPool") private DataSource dataSource; public void saveCustomer(Customer customer) { if (customer.getCustomerId() == null) { saveNewCustomer(customer); } else { updateCustomer(customer); } } private void saveNewCustomer(Customer customer) { customer.setCustomerId(getNewCustomerId()); entityManager.persist(customer); } private void updateCustomer(Customer customer) { entityManager.merge(customer); } public Customer getCustomer(Long customerId) { Customer customer; customer = entityManager.find(Customer.class, customerId); return customer; } public void deleteCustomer(Customer customer) { entityManager.remove(customer); } private Long getNewCustomerId() { Connection connection; Long newCustomerId = null; try { connection = dataSource.getConnection(); PreparedStatement preparedStatement = connection .prepareStatement( "select max(customer_id)+1 as new_customer_id " + "from customers"); ResultSet resultSet = preparedStatement.executeQuery(); if (resultSet != null && resultSet.next()) { newCustomerId = resultSet.getLong("new_customer_id"); } connection.close(); } catch (SQLException e) { e.printStackTrace(); } return newCustomerId; } } The first difference we should notice is that an instance of javax.persistence. EntityManager is directly injected into the session bean. In previous JPA examples,we had to inject an instance of javax.persistence.EntityManagerFactory, then use the injected EntityManagerFactory instance to obtain an instance of EntityManager. The reason we had to do this was that our previous examples were not thread safe. What this means is that potentially the same code could be executed concurrently by more than one user. As EntityManager is not designed to be used concurrently by more than one thread, we used an EntityManagerFactory instance to provide each thread with its own instance of EntityManager. Since the EJB container assigns a session bean to a single client at time, session beans are inherently thread safe, therefore, we can inject an instance of EntityManager directly into a session bean. The next difference between this session bean and previous JPA examples is that in previous examples, JPA calls were wrapped between calls to UserTransaction.begin() and UserTransaction.commit(). The reason we had to do this is because JPA calls are required to be in wrapped in a transaction, if they are not in a transaction, most JPA calls will throw a TransactionRequiredException. The reason we don't have to explicitly wrap JPA calls in a transaction as in previous examples is because session bean methods are implicitly transactional; there is nothing we need to do to make them that way. This default behavior is what is known as Container-Managed Transactions. Container-Managed Transactions are discussed in detail later in this article. When a JPA entity is retrieved in one transaction and updated in a different transaction, the EntityManager.merge() method needs to be invoked to update the data in the database. Invoking EntityManager.persist() in this case will result in a "Cannot persist detached object" exception.

Joomla!'s Component Structure Joomla! employs a specific naming scheme, which is used by all components. Each component in the system has a unique name with no spaces. The code is split into two folders, each bearing the component name prefixed by com_. The component used here will be called reviews. Therefore, you will have to create two folders named com_reviews: Create one in the folder named components for the front end. Create one in the folder named components within the administrator folder for the back end. When the component is loaded from the front end, Joomla! will look for a file with the component's unique name ending in a .php extension. Within the components/com_reviews folder, create the reviews.php file. Similarly, running it in the back end assumes the presence of a file prefaced with admin. followed by the component name and ending in .php. Add the file admin.reviews.php in administrator/components/com_reviews. Leave both the files empty for the moment. Executing the Component All front-end requests in Joomla! go through index.php in the root directory. Different components can be loaded by setting the option variable in the URL GET string. If you install Joomla! on a local web server in a directory titled joomla, the URL for accessing the site will be http://localhost/joomla/index.php or something similar. Assuming this is the case, you can load the component's front end by opening http://localhost/joomla/index.php?option=com_reviews in your browser. At this point, the screen should be essentially blank, apart from the common template elements and modules. To make this component slightly more useful, open reviews.php and add the following code, then refresh the browser: <?php defined( '_JEXEC' ) or die( 'Restricted access' ); echo '<div class="componentheading">Restaurant Reviews</div>'; ?> Your screen will look similar to the following: You may be wondering why we called defined() at the beginning of the file. This is a check to ensure that the code is called through Joomla! instead of being accessed directly at components/com_reviews/reviews.php. Joomla! automaticallyconfigures the environment with some security safeguards that can be defeated ifsomeone is able to directly execute the code for your component. For the back end, drop this code into administrator/components/com_reviews/admin.reviews.php: <?php defined( '_JEXEC' ) or die( 'Restricted access' ); echo 'Restaurant Reviews'; ?> Go to http://localhost/joomla/administrator/index.php?option=com_reviews and compare your result to this:   Joomla!'s Division between Front End and Back End For all Joomla! components, code empowering the back-end portion is kept away from the front-end code. In some instances, such as the database table class, the back end will use certain files from the front end, but otherwise the two are separate. Security is enhanced as you are less likely to slip the administrative functions into the front-end code. This is an important distinction as the front end and back end are similar in structure. The following folder diagram shows the Joomla! root with the administrator folder expanded: Notice that the administrator folder has a structure similar to the root folder. It is important to differentiate between the two, else you may place your code in the wrong folder and it will fail to execute until youmove it.

Primary Network Your first thought might be that your current network will work fine with thin clients and that is entirely possible. But your network might be something that has grown through the years and is not that well designed. Your implementation of thin clients then might be a good time to review the design and make upgrades as needed. Personal Computers versus Thin Clients Based on conversations with some hardware vendors, it's clear that most of the testing is done with the expectation that personal computers willbe deployed. The biggest difference is in how the two platforms use the network. When running a personal computer, often software applications are stored on network servers. When you activate an icon, the network pushes the executable down to your PC. Once downloaded into memory, the application runs and then very little interaction takes place until you save a file. Or in other cases, the executables are on the local PC, and network activity is not used until files are saved. If an executable takes a few seconds longer to download, you won't      really notice it when using a personal computer. Some networking devices seem better designed for efficiency of download instead of being designed for the smaller and more plentiful packets of network computing. When you activate a software application on a thin client, the presentation of the user interface is pushed to you from the server, and then all keystrokes and mouse activity are transmitted back and forth to the server in real time. The network needs to be very fast, have low latency, and be configured to pass packets immediately to the servers. Network Design For implementing your network, the network backbone should be Gigabit if possible. Obviously if your solution is for only a small number of users, this might not be required. Ideally fibre optic lines are then run to each of the wiring closets, and each switch should have it's own line. It is advisable to avoid daisy-chaining the switches together in order to avoid any kind of contention between them. The servers are all plugged into the backbone at Gigabit as well. If a server is required away from a centralized computer room, then it is better to run a separate line instead of plugging it into a switch that will be shared with thin clients. It's important to keep the data paths solidly designed so that all of your real-time interaction will not be delayed. X windows, RDP, or Citrix are used to display the user presentation. This means that the software is running on the server, but the image of that software is transmitted over the network. It's important that a strong network exists or repaints of windows will be slower and feel sluggish. This issue will cause people problems, with perceptions that a personal computer can run software faster than a network. A correctly designed network will provide excellent response time and the user community should not even see a difference. Font servers are used to distribute fonts to users. A font server is just a process or application that runs on the server. When a user requests a font, it's sent over the network to the thin client and made available to them immediately. The strength of this design is that all your employees will have the same fonts and while sharing documents, they will render exactly the same way no matter from where you log into the network. Anyone that has shipped documents between personal computers with different fonts, will greatly appreciate this design. When the network is configured correctly, font download and interaction is immediate and undetected by the user community. NFS mounts are used to connect disk drives between Linux servers. This allows applications to share data between the various servers on your network. Response time needs to be excellent to provide very fast file saves and retrievals, at the same time avoiding applications that lock or timeout while trying to interact with files. A review of the possible network problems is provided in the following table: Networking Issue Symptom(s) X windows RDP Citrix Slow repaints of user interfaces Lockups Disconnections Font Servers Slow repaints Wrong fonts in applications Thin Client Slow keyboard response Disconnections Slow repaints NFS Mounts Lockups Slow response in saving files  

Confidentiality and integrity are two critical components of web services. While confidentiality can be ensured by means of encryption, the encrypted data can still be overwritten and the integrity of the message can be compromised. So it becomes is equally important to protect the integrity of the message; digital signatures helps us in doing just that. Overview of Digital Signatures In the web services scenario, XML messages are exchanged between the client application and the web services. Certain messages contain critical business information, and therefore the integrity of the message should be ensured. Ensuring the integrity of the message is not a new concept, it has been there for a long time. The concept is to make sure that the data was not tampered while in transit between the sender and the receiver. Consider, for example, that Alice and Bob are exchanging emails that are critical to business. Alice wants to make sure that Bob receives the correct email that she sent and no one else tampered with or modified the email in between. In order to ensure the integrity of the message, Alice digitally signs the message using her private key, and when Bob receives the message, he will check to make sure that the signature is still valid before he can trust or read the email. What is this digital signature? And how does it prove that no one else tampered with the data? When a message is digitally signed, it basically follows these steps: Create a digest value of the message(a unique string value for the message using a SHA1 or MD5 algorithm). Encrypt the digest value using the private key—known only to the sender. Exchange the message along with the encrypted digest value. MD5 and SHA1 are message digest algorithms to calculate the digest value. The digest or hash value is nothing but a non-reversible unique string for any given data, i.e. the digest value will change even if a space is added or removed. SHA1 produces a 160 bit digest value, while MD5 produces a 128 bit value. When Bob receives the message, his first task is to validate the signature. Validation of signature goes through a sequence of steps: Create a digest value of the message again using the same algorithm. Encrypt the digest value using the public key of Alice(obtained out of band or part of message, etc.) Validate to make sure that the digest value encrypted using the public key matches the one that was sent by Alice. Since the public key is known or exchanged along with the message, Bob can check the validity of the certificate itself. Digital certificates are issued by a trusted party such as Verisign. When a certificate is compromised, you can cancel the certificate, which will invalidate the public key. Once the signature is verified, Bob can trust that the message was not tampered with by anyone else. He can also validate the certificate to make sure that it is not expired or revoked, and also to ensure that no one actually tampered with the private key  of Alice. Digital Signatures in Web Services In the last section, we learnt about digital signatures. Since web services are all about interoperability, digital-signature-related information is represented in an industry standard format called XML Signature (standardized by W3C). The following are the key data elements that are represented in an interoperable manner by XML Signature: What data (what part of SOAP message) is digitally signed? What hash algorithm (MD5 or SHA1) is used to create the digest value? What signature algorithm is used? Information about the certificate or key. In the next section, we will describe how the Oracle Web Services Manager can help generate and verify signatures in web services. Signature Generation Using Oracle WSM Oracle Web Services Manager can centrally manage the security policy, including digital signature generation. One of the greatest advantages in using Oracle WSM to digitally sign messages is that the policy information and the digital certificate information are centrally stored and managed. An organization can have many web services, and some of them might exchange certain business critical information and require that the messages be digitally signed. Oracle WSM will play a key role when different web services have different requirements to sign the message, or when it is required to take certain actions before or after signing the message. Oracle WSM can be used to configure the signature at each web service level and that reduces the burden of deploying certificates across multiple systems. In this section, we will discuss more about how to digitally sign the response message of the web service using Oracle WSM. Sign Message Policy Step As a quick refresher, in Oracle WSM, each web service is registered within a gateway or an agent and a policy is attached to each web service. The policy steps are divided mainly into request pipeline template and response pipeline template, where different policies can be applied for request or response message processing. In this section, I will describe how to configure the policy for a response pipeline template to digitally sign the response message. It is assumed that the web service is registered within a gateway and a detailed example will be described later in this article . In the response pipeline, we can add a policy step called Sign Message to digitally sign the message. In order to digitally sign a message, the key components that are required are: Private key store Private key password The part of SOAP message that is being signed The signature algorithm being used The following screenshot describes the Sign Message policy step with certain values populated.   In the previous screenshot, the values that are populated are: Keystore location—The location where the private key file is located. Keystore type—Whether or not it is PKCS12 or JKS. Keystore password—The password to the keystore. Signer's private-key alias—The alias to gain access to the private key from the keystore. Signer's private-key password—The password to access the private key. Signed Content—Whether the BODY or envelope of the SOAP message should be signed. The above information is a part of a policy that is attached to the time service which will sign the response message. As per the information that is shown in the screenshot, the BODY of the SOAP message response will be digitally signed us in the SHA1 as the digest algorithm, and PKCS12 key store. Once the message is signed, the SOAP message will look like: <?xml version="1.0" encoding="UTF-8"?><soap:Envelope soap_encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" > <soap:Header> <wsse:Security soap_mustUnderstand="1"> <wsse:BinarySecurityToken ValueType="http://docs. oasis-open.org/wss/2004/01/oasis-200401-wss- x509-token-profile-1.0#X509v3" EncodingType="http://docs.oasis-open. org/wss/2004/01/oasis-200401-wss-soap-message- security-1.0#Base64Binary" wsu_Id="_ VLL9yEsi09I9f5ihwae2lQ22" >SecurityTOkenoKE2ZA==< /wsse:BinarySecurityToken> <dsig:Signature > <dsig:SignedInfo> <dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/ xml-exc-c14n#"/> <dsig:SignatureMethod Algorithm="http://www.w3.org/2000/09/ xmldsig#rsa-sha1"/> <dsig:Reference URI="#ishUwYWW2AAthrx hlpv1CA22"> <dsig:Transforms> <dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> </dsig:Transforms> <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <dsig:DigestValue>ynuqANuYM3qzdTnGOLT7SMxWHY=</dsig:DigestValue> </dsig:Reference> <dsig:Reference URI="#UljvWiL8yjedImz 6zy0pHQ22"> <dsig:Transforms> <dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> </dsig:Transforms> <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <dsig:DigestValue>9ZebvrbVYLiPv1BaVLDaLJVhwo=</dsig:DigestValue> </dsig:Reference> </dsig:SignedInfo> <dsig:SignatureValue>QqmUUZDLNeLpAEFXndiBLk</dsig:SignatureValue> <dsig:KeyInfo> <wsse:SecurityTokenReference wsu_Id="_7vjdWs1ABULkiLeE7Y4lAg22" > <wsse:Reference URI="#_VLL9yEsi09I9f5ihwae2lQ22"/> </wsse:SecurityTokenReference> </dsig:KeyInfo> </dsig:Signature> <wsu:Timestamp wsu_Id="UljvWiL8yjedImz6zy0pHQ22"> <wsu:Created>2007-11-16T15:13:48Z</wsu:Created> </wsu:Timestamp> </wsse:Security> </soap:Header> <soap:Body wsu_Id="ishUwYWW2AAthrxhlpv1CA22" > <n:getTimeResponse > <Result xsi_type="xsd:string">10:13 AM</Result> </n:getTimeResponse> </soap:Body></soap:Envelope>

If you've ever wondered how people find your website or how to generate more traffic, then this article tells you more about your visitors. Knowing where they come from, what posts they like, how long they stay, and other site metrics are all valuable information to have as a blogger. You would expect to pay for such a deep look into the underbelly of your blog, but Google wants to give it to you for free. Why for free? The better your site does, the more likely you are to pay for AdWords or use other Google tools. The Google Analytics online statistics application is a delicious carrot to encourage content rich sites and better ad revenue for everyone involved. You also want people to find your blog when they perform a search about your topic. The painful truth is that search engines have to find your blog first before it will show up in their results. There are thousands of new blogs being created everyday. If you want people to be able to find your blog in the increasingly crowded blogosphere, optimizing your blog for search engines will improve the odds. Improving Your Blog with Google Analytics Analytics gives you an overwhelming amount of data to use for measuring the success of your sites, and ads. Once you've had time to analyze that data, you will want to take action to improve the performance of your blog, and ads. We'll now look at how Analytics can help you make decisions about the design, and content of your site. Analyzing Navigation The Navigation section of the Content Overview report reveals how your visitors actually navigate your blog. Visitors move around a site in ways we can't predict. Seeing how they actually navigate a site and where they entered the site are powerful tools we can use to diagnose where we need to improve our blog. Exploring the Navigation Summary The Navigation Summary shows you the path people take through your site, including how they get there and where they go. We can see from the following graphical representation that our visitors entered the site through the main page of the blog most of the time. After reaching that page, over half the time, they went to other pages within the site. Entrance Paths We can see the path, the visitors take to enter our blog using the Entrance Paths report. It will show us from where they entered our site, which pages they looked at, and the last page they viewed before exiting. Visitors don't always enter by the main page of a site, especially if they find the site using search engines or trackbacks. The following screenshot displays a typical entrance path. The visitor comes to the site home page, and then goes to the full page of one of the posts. It looks like our visitors are highly attracted to the recipe posts. Georgia may want to feature more posts about recipes that tie in with her available inventory. Optimizing your Landing Page The Landing Page reports tell you where your visitors are coming from, and if they have used keywords to find you. You have a choice between viewing the source visitors used to get to your blog, or the keywords. Knowing the sources will give you guidance on the areas you should focus your marketing or advertising efforts on. Examining Entrance Sources You can quickly see how visitors are finding your site, whether through a direct link, or a search engine, locally from Blogger, or from social networking applications such as Twitter.com. In the Entrance Sources graph shown in the following screenshot, we can see that the largest among the number of people are coming to the blog using a direct link. Blogger is also responsible for a large share of our visitors, which is over 37%. There is even a visitor drawn to the blog from Twitter.com, where Georgia has an account. Discovering Entrance Keywords When visitors arrive at your site using keywords, the words they use will show up on the report. If they are using words in a pattern that do not match your site content, you may see a high bounce rate. You can use this report to redesign your landing page to better represent the purpose of your site by the words, and phrases that you use. Interpreting Click Patterns When visitors visit your site they show their attraction to links, and interactive content by clicking on them. Click Patterns are the representation of all those mouse clicks over a set time period. Using the Site Overlay reporting feature, you can visually see the mouse clicks represented in a graphical pattern. Much like collared pins stuck on a wall chart they will quickly reveal to you, which areas of your site visitors clicked on the most, and which links they avoided. Understanding Site Overlay Site Overlay shows the number of clicks for your site by laying them transparently in a graphical format on top of your site. Details with the number of clicks, and goal tracking information pop up in a little box when you hover over a click graphic with your mouse. At the top of the screen are options that control the display of the Site Overlay. Clicking the Hide Overlay link will hide the overlay from view. The Displaying drop-down list lets you choose how to view mouse Clicks on the page, or goals. The date range is the last item displayed. The graphical bars shown on top of the page content indicate where visitors clicked, and how many of them did so. You can quickly see what areas of the page interest your visitors the most. Based on the page clicks you see, you will have an idea of the content, and advertising that is most interesting to your visitors. Yes, Site Overlay will show the content areas of the page the visitors clicked on, and the advertisement areas. It will also help you see which links are tied to goals, and whether they are enticing your visitors to click. Optimizing Your Blog for Search Engines We are going to take our earlier checklists and use them as guides on where to make changes to our blog. When the changes are complete, the blog will be more attractive to search engines and visitors. We will start with changes we can make "On-site", and then progress to ways we can improve search engine results with "Off-site" improvements. Optimizing On-site The most crucial improvements we identified earlier were around the blog settings, template, and content. We will start with the easiest fixes, then dive into the template to correct validation issues. Let's begin with the settings in our Blogger blog. Seeding the Blog Title and Description with Keywords When you created your blog, did you take a moment to think about what words potential visitors were likely to type in when searching for your blog? Using keywords in the title and description of your blog gives potential visitors a preview and explanation of the topics they can expect to encounter in your blog. This information is what will also display in search results when potential visitors perform a search. Updating the Blog Title and Description It's never too late to seed your blog title and description with keywords. We will edit the blog title and description to optimize them for search engines. Login to your blog and navigate to Settings | Basic. We are going to replace the current title text with a phrase that more closely fits the blog. Type Organic Fruit for All into the Title field. Now, we are going to change the description of the blog. Type Organic Fruit Recipes, seasonal tips, and guides to healthy living into the description field. Scroll down to the bottom of the screen and click the Save Settings button. Y ou can enter up to 500 characters of descriptive text. What Just Happened? When we changed the title and description of our blog in the Basic Settings section, Blogger saved the changes and updated the template information as well. Now, when search engines crawl our blog, they will see richer descriptions of our blog in the blog title and blog description. The next optimization task is to verify that search engines can index our blog.

Custom Types Documentum provides a large number of built-in object types that support the functionality of the platform. Some object types are general purpose and can be used for business purposes as well. However, all possible business needs can neither be anticipated nor supported by default. Therefore, Documentum allows creation of new object types, which are called custom types. This article addresses creation and management of custom types. Before reading this article, it would be helpful to know about Objects and Types, since the majority of the concepts pertaining to object types apply here as well. Some concepts are explained here. Managing Custom Types A user-defined object type is called a custom type and the user-defined properties are called custom properties. Properties are also known as attributes. Custom types can be created, modified, and removed as long as certain rules are followed. This section describes the detail around managing custom types. Creating a Custom Type A custom type can be created using Documentum Application Builder (DAB), using Documentum Administrator (DA), or using DQL/API scripts. DAB is the most commonly used application for creating custom types since it fully supports the data dictionary (see Data Dictionary later in this article) and it has a Graphical User Interface (GUI) specifically designed for creating and managing custom types. Further, DAB can also be used for packaging the types into a DocApp. The following screenshot shows the DAB screen for creating and updating a custom type: DA provides basic support for managing custom types. For example, DA does not provide an interface for defining value assistance for a property. The following screenshot shows the screen for creating and updating custom types in DA: Creating a custom type is a privileged operation and only the users with following privileges can do so: Create Type Sysadmin Superuser        The user creating the type becomes the owner of the type. A custom type can extend an existing type through inheritance (see Type Hierarchy in Documentum). A new custom type can have an existing custom type or one of the sets of Documentum object types as its supertype. The most common supertype for a new custom type for representing documents is dm_document. It is also possible to create a custom type without a supertype. Such a type is called a NULL type. Only a user with Superuser privilege can create a NULL type. A NULL type is useful for storing data that does not need the usual object management features such as versioning. There are several built-in types that are NULL types such as dm_user, dm_session, and dm_alias_set. If a custom type is intended to only store non-versionable data, a NULL type may be appropriate for this purpose. Recall that any given type uses up to two tables (one for single-valued properties and one for repeating) of its own for storing non-inherited properties of its objects. There are additional views for retrieving all the properties together. The following key information is needed or captured in DAB when creating a new custom type:   Info Description Name Name of the type. A type name must be unique (caseinsensitive) in the repository and can be up to 27 characterslong. The additional constraints on the type name are that itcannot contain a space or punctuation nor can it be same asany DQL reserved word, such as SELECT or WHERE. Further, it cannot start with dm_, dmi, dmr_, a number, space, or a single quote. It is recommended that a custom prefix be used for custom type names to distinguish them from the other types. Creator The user creating the type. Supertype The supertype of the new type. This can be NULL. Label User-friendly version of the name, for display purposes in Documentum client applications. Default Lifecycle A lifecycle that can be attached to a document of this type, without identifying the lifecycle explicitly. Default Storage Area A storage area identifies where the content files are stored for objects. The default storage area identifies where the content files for objects of this type will be stored by default. Default Permission Set The default permission set is used when the default ACL mode for the Content Server is set to Type. In this case, a new object of this type gets this permission set. Template Document One or more template documents can be created for the type, which are available to users when they are creating a new object of this type. The template documents are stored in the Templates cabinet in Documentum repository.

In principle the simplest approach that actually always works is the following: Load the Joomla! 1.5 beta.zip file onto your local PC and unpack it in a temporary directory. Load the just unpacked files by means of FTP onto your rented server. The files must be installed in the publicly accessible directory. These directories are usually named htdocs, public_html, or simply html. You can specify a subdirectory within the directory into which you install your Joomla!. Many web hosts allow you to link your rented domain name to a directory. This name is necessary to call your website from a browser. You have to find out what your database is called. Usually one or several databases are included in your web-hosting package. Sometimes the user name, database name, and password are fixed; sometimes you have to set them up. There is usually a browser-based configuration interface at your disposal. You can see an example of such an interface in the following figure. You will need these access data for Joomla!'s web installer. You can get going after you have loaded these data onto your server and are in possession of your access data. Joomla! Installation To install Joomla!, you need the source code. Download the Joomla_1.5.0-Beta-Full_Package.zip package and save it on your system. Selecting a Directory for Installation You have to decide whether Joomla! needs to be installed directly into a document directory or a subdirectory. This is important, since many users prefer a short URL to their homepage. An Example If Joomla! is unzipped directly in /htdocs, the web page starts when the domain name http://www.myhomepage.com is accessed from its local computer http://localhost/ and/or from the server on the Internet. If subdirectories are created under /htdocs/, for example, /htdocs/Joomla150/ and we unzip the package there, we have to enter http://localhost/Joomla150/ in the browser. This isn't a problem locally, but doesn't look good on a production Internet page. Some HTML files and subdirectories, however, are already in /htdocs in the local XAMPP Lite environment under Windows, which, for example, displays the start page of XAMPP Lite. In a local Linux environment, a starting page dependent on the distribution and the web server settings is also displayed. Directory I recommend that you create a subdirectory under the document directory named Joomla150 in Windows by using Windows Explorer. (With Linux, use the Shell, KDE Konqueror, or Midnight Commander.) [home]/htdocs/Joomla150/ The directory tree in Windows Explorer should look like this: An empty index appears in the XAMPP Lite version when the URL http://localhost/Joomla150 is entered in the browser: With Linux or with another configuration it can happen that you get a message saying that you don't have access to this directory. This depends on the configuration of the web server. For security reasons, the automatic directory display is often deactivated in Apache's configuration. A potential hacker could draw many interesting conclusions about the directory structure and the files on your homepage and target your computer for an attack. For security reasons, you are usually not allowed to access the appropriate configuration file of the Apache web server. Should you be able to, you should leave the content directories deactivated and/or only activated for those directories that contain files for downloading.