If you're new here, you may want to subscribe to my RSS feed. So that you can read the latest updates about Web2.0 tools, Making Money Online, Tips in SEO, Ajax and many more. Thanks for visiting ProgramimiCOM!

Every wondered how the Oracle database is structured? To learn more about the structure and how one would create an Oracle 9i database using the latest features read this article.When creating a database, the main concept is to know how the database is structured in Oracle 9i. You should be aware that ever since the release of Oracle 8i, the Oracle database support object orientated structures. This means that Oracle supports abstract data types and methods.

If you are new to Oracle, then perhaps you are unclear on how data is stored and what files are included internally and externally. With this article you will be clear about how to create a database using Oracle 9i’s latest features.

How Data is Stored 

Data in Oracle is stored in tables and accessed data via a relational model. This means that one may use the tables of data items inside the database in a manner such that the tables relate to one another with the use of primary and foreign keys.

Tables that contain a foreign key are often translated as being a lookup table. Each table should have a primary key, so that each row can be uniquely identified. The primary key is used to connect with the foreign key in another table to form a relationship.

Oracle also supports object-orientated structures. This allows the database to include abstract data types and methods. Due to this object orientation property, objects may related to other objects and that object may exist inside other objects.

Files are used to store data in Oracle. Oracle 9i removes the risk of having orphan file. That is, like the name suggests the file doesn’t have a parent, which means that the datafile was not removed when it’s tablespace is removed. To prevent this from ever happening to your database again, Oracle has introduced “Oracle Managed Files”.

Oracle Managed files, abbreviated as OMF, uses a brand new system of storing files. OMF uses file system directories as opposed to filenames for files that are associated with the tablespace.

This means that when a tablespace is created, the files are given a unique system-generated name, using the locations that have been assigned to them along with two new initialization parameters. So when the tablespace is removed, the files will be removed with it.

Another new feature in Oracle 9i is the System Managed Undo, abbreviated as SMO. The SMO was created to make the creation of the database simpler for the DBA and to reduce the problem relating to misused rollback segments. The DBA now creates a tablespace as an UNDO type to allow the Oracle database to dynamically and automatically manage the number of undoes, along with the size of the undo segments within the tablespace.

A database is partitioned using tablespaces. The tablespace named SYSTEM is the databases default tablespace. These tablespaces allows for the grouping of elements within the system that transact with the database.

A tablespace contains files. These files are called datafiles, which are used to physically store data for the database. Notice this property suggests that datafiles are internal and external structure types, since they are parented by a tablespace (internal property) and are physical storage files (external). The datafile may be resized after it has been created.

Rules about Tablespaces and Datafiles

• A tablespace is parented by the database. So a tablespace cannot be a part of another database.
• A datafile is parented by the tablespace. So a datafile cannot be part of another database.
• A datafile may not be removed from a tablespace.

Now that we know how data is stored using Oracle, there are other special physical files that are associated with data storage and will assist in data recovery. The files that are created when the database in created and they are as follows,

• Redo log files, which will monitor transactions in a chronological manner. These files are known as online redo log files. The reason why this is an important file to have associated with the database is evident when the database malfunctions.

According to the Oracle 9i DBA Handbook, a database should consist of 3 or more online redo files. To archive old online redo files before they are inevitably over written, you may set the database to run in ARCHIVELOG mode. This allows the DBA to look further back into the history of transactions with the database.

• Control files, which holds the location of all the files the database will require. Multiple copies are made and stored on different disks to back up this operation-critical file. The CONTROL_FILES parameter specifies the names of the database control files. An instance must be shut down prior to an addition of a new control file.
• Temp files, which acts as a temporary storage for a result set. If the result exceeds the memory available in the RAM’s buffer, then the result set will be stored into the temporary data file. Make sure that the size of the file is large enough to hold large sorting operations.

The other files associated with an Oracle 9i database are called parameter files. There are two types of parameter files. These are,

• Static parameter files – This is what the init.ora file is. This are common known as a PFILE and should be based on the init.ora file and renamed as init{SID}.ora, where SID is the system identifier.
• Server parameter files – This is a new feature in Oracle 9i named the SPFILE. These parameter files are written in binary and should not be altered manually. The files should be named as spfile{SID}.ora, where SID is again the system identifier. The Oracle server always maintains these files.

To create the SPFILE we do the following,

CREATE SPFILE = ‘<directory>\spfile{SID}.ora’
FROM PFILE = ‘init{SID}.ora’

There are two types of parameter that are located in these parameter files. These are,

• Implicit parameter, which are parameters with no value. Oracle therefore assumes that the value for the parameter is the Oracle default values.
• Explicit parameter, which are parameter that have a value assigned to it.

Now we know how the parameter files work. Well, to access data inside the database, Oracle uses a set of background processes that are shared between users. The DBA Handbook states that an instance is “ a set of memory structures and background processes that access a set of database files.” Every instance has a large memory structure known as the System Global Area, abbreviated as SGA. The SGA will be explained in another article.

But where do the parameter fit in?

Well the parameters are used to set the size and composition of an instance and are the stored in one of the two specific parameter files as stated previously. The parameter file is read during the startup process. So, to access a database one must start an instance, which may call either the PFILE or the SPFILE. If there exist an SPFILE, then the STARTUP command will read that parameter file. If the SPFILE doesn’t exist, the default SPFILE is read. If that doesn’t exist than the PFILE is read. If you don’t wish for the server to read the PFILE, then simply override the default SPFILE with the PFILE.

STARTUP PFILE = ‘<directory>.init{SID}.ora’

Now you have a good understanding of architecture of an Oracle database, let us create one.

Create a Database 

There are two ways that you can create a database in Oracle 9i. One way is to use the Oracle Database Configuration Assistant. Using the Oracle Database Configuration Assistant makes sure that the new database is optimized with Oracle 9i’s latest features. Simply read the instruction and follow the prompts. The other way to create a database is to do it manually. This will now be demonstrated.

Create a suitable directory structure for the new database. Once this is done, copy the init.ora file into a new file named init{SID}.ora into new directory.

Now you have created a parameter file, you’ll need to declare an Oracle SID name. Keep the SID consistent with the parameter filename. The command to do this action will depend on the platform you have the DBMS installed. If you are using Windows, simply type,

Set ORACLE_SID = {SID}

Alternatively, on the a unix platform, the DBA must type,

Export ORACLE_SID = {SID}

Use SQL*Plus under / as sysdba and set the database to nomount mode.

So, if we wish to override the default spfile to start the new instance in nomount mode then type,

Startup nomount pfile = ‘<directory>\init{SID}.ora’

Now we are about to create the database. When creating a new database, write the code into an sql file so that your have a copy of the database features as well as the ability to fix any mistakes in the create database command. Here is the code,

CREATE DATABASE ShepIT
Maxinstances   1
Maxloghistory  1
Maxlogfiles  10
Maxlogmembers 15
Maxdatafiles  100
Datafile ‘<directory>\datafile_01.dbf’
size 300M reuse autoextend on next 15M maxsize unlimited
character set WE8MSWIN1252
national character set AL16UFT16
logfile
group 1 (‘<directory>\redo_01.log’) size 75M
group 2 (‘<directory>\redo_02.log’) size 75M
group 3 (‘<directory>\redo_03.log’) size 75M
default temporary tablespace TEMP
tempfile ‘<directory>\temp_01.dbf’
extent management local uniform size 1M
undo tablespace UNDO_TS datafile ‘<directory>\datafile_01.dbf’
size 125M reuse autoextend on next 15M maxsize unlimited;

Oracle, should respond by saying that the database is created. Once this is done you are ready to load scripts that are needed to support your Oracle products by typing the following commands

@<directory>\catalog.sql
@<directory>\catproc.sql
@<directory>\catexp.sql

Ok, the database is configured. Change the SYSTEM and SYS passwords, to ensure better security for your database.

—

by Ben Shepherd

• 0 Comments

In February 2007, Yahoo quietly went live with Yahoo Pipes. Tim O’Reilly described it as “a milestone in the history of the Internet.” It’s the ultimate web mashup tool; keep reading to find out what it can do for you.If you’re at all familiar with UNIX, you understand the concept behind Yahoo Pipes. A “pipe” in UNIX connects two programs, taking the output from one program and using it as the input of the next program. You can even connect a series of programs with a whole set of pipes, performing several different operations until you get the result you need.

For the sake of an example, assume that you are looking for an apartment close to a new job. You might create a program that visits web sites with classified listings, extracts the apartment listings, runs the addresses through a locator program to check the distance, discards all the ones over a certain price range, then sorts the remainder by some factor (say number of bedrooms or closeness to schools). That would be five steps run through four pipes.

Potentially, that would also be a lot of work if you’re actually writing a UNIX program to do this for you. Full disclosure: I’m not a programmer myself, so I wouldn’t know. But Yahoo Pipes lets users do exactly that, and more. It lets you combine many different data feeds (such as RSS) into a single feed. Once you’ve combined all the feeds, you can use “modules,” which are like mini-applications, to sort, filter, remix, and generally pick out whatever is important to you while leaving the rest.

I’m sure I don’t have to tell you that there are a ton of possibilities here. You can consolidate all of your favorite news feeds together into one feed and have it filter for specific words; you can put your entire online life together in one place (LiveJournal, Flickr, Facebook, what have you) to make it easier to tell your friends and family what you’ve been doing; you can even custom build an aggregated feed that covers your web site’s topic. Let’s take a closer look at how it all works.

Getting Started 

It’s easy enough to get started. You go to the Yahoo Pipes page and click on My Pipes. Before I take you there, let me show you a screen shot of the page:

It doesn’t really do the page justice, but I think you can see that it lends itself to poking around. When I checked the page, the left column (“About Pipes”) made a number of interesting suggestions as to what you can do with Yahoo Pipes; the middle column was devoted to popular pipes; and the right column talked about updates. One recent update I’m sure many of you will be interested in explained how to use Yahoo Maps with Yahoo Pipes.

If you’re ready to build a pipe, just click on My Pipes. You’ll need to log in to Yahoo; it should come as no surprise that you can’t use the service unless you’re registered. Once you log in, you reach a page that says “Looks like you don’t have any Pipes. Why not create one?” It links to an editing page for creating your first Pipe. You’ll also find links to example pipes. You should be warned that example pipes seem to take quite a while to load. I didn’t want to wait, so I thought I’d better just try putting one together myself.

Thankfully, Yahoo provides a simple overview so I had some idea of what I’d be doing, at least in principle. I’m not a programmer by any stretch of the imagination, so those of you who are more tech savvy can laugh at my halting steps. You can also find a complete list of Pipes modules and other useful information in Yahoo’s documentation for Yahoo Pipes.

Building the First Pipe 

Before we start building a pipe, you need to be aware that Yahoo Pipes does not work on IE 6. I found this out the hard way. You’ll see the page, but when you try to drag and drop modules onto the editing area, they’ll just disappear. It works in FireFox as long as you’re using the latest version, otherwise it acts flaky.

Anyway, here’s the first page you’re confronted with when you start building your first pipe:

I’ve cut and reduced the image to fit. Now the menu column on the left is what Yahoo refers to as the Library. It lists all of the available modules as well as any pipes you have saved. Yahoo separates the modules into different categories depending on their functions:

• Sources are data sources that return an RSS feed.
• User inputs are input fields that your Pipe’s users fill in at runtime.
• Operators are basic functions like foreach, sort, count, and filter.
• Url modules build and manipulate URLs.
• String modules handle strings.
• Date modules manipulate dates.

Fortunately you get a helpful tool tip when you hover over each module that tells you in a sentence what it does. You’ll usually want to start a pipe by specifying where it will be getting the data. That means you’ll want to grab one of the feed modules, which you find under “Sources,” and drag it onto the “canvas,” like so:

As you can see, the module changed; it’s bigger, it changed color, and it now has a “pipe output” section. It’s waiting for you to put in the URL of the RSS feed you want to use. Yahoo helpfully provides a search box for feeds. You can add more feeds using the same module by clicking the plus sign next to the URL. Below, I’ve added five feeds:

The feeds I’ve chosen aren’t particularly large, but there are plenty of feeds online that are nothing short of huge. Of course, if you don’t think you have enough feeds (and since the point of Yahoo Pipes is to connect lots of different feeds), you may want to drag another feed box onto your editing canvas and connect the two modules. You’ll want to use a “Union” box for this, which you’ll find under “Operators.” You click and drag your mouse from the URL modules to the Union module to hook them up. You can really see how pretty the interface is at this point; you’re dragging some lovely blue connectors. Take a look:

At this point you’ll want to filter your pipe. Drag a Filter box over from the Operators. The Filter box lets you block (or permit) items that match certain rules. Here’s an example, hooked up to my pipe:

You can see how easy it would be for someone who is interested in a particular kind of news or trying to stay up to date in a particular field to pick out the stories that would be of most interest. If you have ever searched for something using key words, you can easily set up a filter.

Once you have finished filtering your pipe, you want to connect the filter to the “pipe output” box that appeared when you dragged your first module onto the editing surface. You do that in the same way that you did it with the other connections.

Finishing Your Pipe 

At the upper right hand corner of your working area are three buttons: New, Save, and Publish. When you have finished your pipe, click Save. You’ll be prompted to name your pipe. Type a name into the text box and hit Save.

After it saves, you’ll see a box at the top of the screen that says “Pipe Saved” and you’ll be able to click on a link labeled “Run Pipe.” That’s always a good idea. Does the pipe grab too much information? Or perhaps it grabs too little (as mine did)? You can always go back and modify your pipe until it gives you what you’re looking for.

You can build much more complicated pipes than the example I gave here. Yahoo points to one called “Apartment Near Something” as a possible inspiration. It starts with a search on Craigslist for apartments as the input and uses the Location Input module to narrow things down by city/state and zip code. Then the pipe accepts text input from the user specifying what they want to find an apartment near (i.e. parks, walking trails, schools, etc). Finally a sort module is added, so the apartments can be sorted by their distance from the desirable item.

As you can see, it’s pretty easy for even a non-programmer to start using this lovely graphical interface. If there is interest, I’ll cover the other areas of the Yahoo Pipes site: the many pipes that are already published, how to publish a pipe so the whole world can see it, the discussion forums, how to clone a pipe, how to build a more complicated pipe, and more. Meanwhile, I think I’ve given you enough to play with for now!

—

by Terri Wells 

• 1 Comment

In the second of two parts, we focus on deploying the EAR we built in the previous article. This article is excerpted from chapter three of the book JBoss at Work: A Practical Guide, written by Tom Marrs and Scott Davis (O’Reilly; ISBN: 0596007345). Copyright © 2006 O’Reilly Media, Inc. All rights reserved. Used with permission from the publisher. Available from booksellers or direct from O’Reilly Media.

Ant EAR task

The final step in the process is to EAR up the results of the webapp and common builds. Just as there is a WAR task, Ant also provides us with an EAR task, as in Example 3-4.

Example 3-4.  master build.xml

<target name=”ear” depends=”compile”>
<ear destFile=”${distribution.dir}/${ear.name}”
appxml=”${meta-inf.dir}/application.xml” >

            <!– files to be included in
/ –>
<fileset dir=”${webapp.war.dir}” />
<fileset dir=”${common.jar.dir}” />
</ear>
</target>

Notice that the EAR task requires us to pass it a well-formed application.xml file. Example 3-5 shows what a simple one looks like.

Example 3-5.  application.xml

<?xml version=”1.0″ encoding=”UTF-8″?>
<application xmlns=http://java.sun.com/xml/ns/j2ee
xmlns:xsi=http://www.w3.org/ 2001/XMLSchema-instance
xsi:schemaLocation=”http:// java.sun.com/xml/ns/j2ee
               http://java.sun.com/
xml/ns/j2ee/application_1_4.xsd”
version=”1.4″>
<display-name>JBossAtWorkEAR</display-name>

  <module>
<web>
<web-uri>webapp.war</web-uri>
<context-root>jaw</context-root>
      </web>
</module>

  <module>
<java>common.jar</java>
</module>

</application>

To verify the results of themasterbuild, change to the build/distribution directory and typejar tvf jaw.ear. You should see webapp.war, common.jar, and application.xml. We are now ready to deploy the EAR file.

Deploying the EAR 

Let’s make sure that the WAR files from the previous chapters don’t end up conflicting with our EAR file. Delete jaw.war from the deploy directory before moving on. Now we’re ready to drop in our newly created EAR file.

Deploying an EAR by hand is no different than deploying a WAR by hand. Copy jaw.ear to $JBOSS_HOME/server/default/deploy. Your JBoss console should let you know that it was deployed successfully, as in Example 3-6.

Example 3-6.  JBoss console output showing a successful EAR deployment

22:37:55,659 INFO [EARDeployer] Init J2EE application:
file:/Library/jboss-4.0.1/server/default/deploy/jaw.ear 22:37:55,853 INFO [TomcatDeployer] deploy, ctxPath=/jaw,
warUrl=file:/Library/jboss-4.0.1/server/default/tmp/deploy/
      tmp25111jaw-ear.ear-contents/webapp.war/
22:37:56,159 INFO [EARDeployer] Started J2EE application:
file:/Library/jboss-4.0.1/server/default/deploy/jaw-ear.ear

___________________________________________

Automated Deployments Using Ant

Ant allows you to do far more than simply compile and bundle up your Java application. It has tasks that let you create and delete directories and copy files to a local subdirectory or a remote server by using ftp or scp. Using tasks like exec, rexec, or sshexec, you can even remotely start and stop JBoss.

It’s not hard to imagine completely automating the deployment process with an Ant script. But just because you can do something doesn’t always mean you should.

Automating deployment to a test server certainly will help speed up your development iterations. But deployments to a production server should be taken a bit more seriously. Upgrading a production application is something that should be done deliberately, and in our opinion, should be done by hand.

If you provide an Ant task to deploy your application to a production server, you almost certainly guarantee that you will invoke it accidentally at the most inopportune time.

Since we point at a test server for this book, we’ve provided a convenient couple of Ant targets to deploy your EAR. To do a hot deploy, make sure that you have the $JBOSS_ HOME environment variable set, and then simply type ant deploy. The Ant task will copy the EAR file to the correct location for you.

If you want to do a cold deploy, shut down JBoss, type Ant cleandeploy, and then start JBoss back up again. The cleandeploy target will delete the existing EAR file and several temporary directories. Running cleandeploy against a running JBoss instance will cause bad things to happen, so make sure that JBoss is not running before invoking it.

___________________________________

Visit http://localhost:8080/jaw to confirm that the application was indeed deployed and still works as expected. Yes, this application doesn’t look or behave any differently than the one in the Web chapter. But we added hundreds of lines of new code—isn’t that the true measure of a successful J2EE project? (Only kidding….)

In all seriousness, we haven’t added any new functionality that the user would notice, but we have set the stage for easy future growth and maximum flexibility. Knowing that the other tiers are coming up soon, these changes will allow you to incorporate the new technology with minimal effort.

Adding a DAO 

In that spirit, let’s add another component that will pay dividends in future flexibility. Right now, your servlet is creating the car list each time a request comes in. This really isn’t optimal. Servlets should deal with the mechanics of the HTTP request/response cycle. They shouldn’t perform persistence tier tasks.

We aren’t quite ready to install a database (that happens in the next chapter), but we can lay the groundwork by creating a Data Access Object (DAO). A DAO is a layer of abstraction—it hides the actual persistence specifics behind a common interface.

The DAO we create in this chapter still stores the DTO objects in a simpleArrayList. In the next chapter, the DAO will pull car data from a database that uses JDBC. In the chapter after that, it will use Hibernate (an Object/Relational Mapper) to do the same thing. By getting the DAO in place now, however, we’ll be able to make these implementation changes without affecting presentation-tier code. Loose coupling and high cohesion comes to the rescue again.

TheCarDAOprovides afindAll()method that returns aListofCarDTOs. The source code in Example 3-7 can be found in the common directory in ch03b-dao.

Example 3-7.  CarDAO.java

package com.jbossatwork.dao;

import java.util.*;
import com.jbossatwork.dto.CarDTO;

public class CarDAO
{
private List carList;

   public CarDAO()
{
carList = new ArrayList();

      carList.add(new CarDTO(”Toyota”, “Camry”, “2005″));
carList.add(new CarDTO(”Toyota”, “Corolla”, “1999″));
carList.add(new CarDTO(”Ford”, “Explorer”, “2005″));
}

   public List findAll()
{

      return carList;

   }
}

The corresponding change in theControllerServlet calls the newly created DAO in Example 3-8.

Example 3-8.  ControllerServlet.java

// perform action
if(VIEW_CAR_LIST_ACTION.equals(actionName))
{
CarDAO carDAO = new CarDAO();
           request.setAttribute(”carList”, carDAO.findAll()); 

           destinationPage = “/carList.jsp”;
}

Not only does this change simplify the code in the servlet, it feels more correct as well. The servlet concerns itself solely with web mechanics and delegates the database tasks to a dedicated class. Another pleasant side effect of this is reuse—your data access code can now be called outside of the web tier. If a business tier object needs access to this data, it can make the same call that we make.

Build and deploy the code to verify that we haven’t broken your application with this change.

Using XDoclet

The last thing we’ll do in this chapter is one more tiny bit of automation.

One of the most important parts of the WAR file is the deployment descriptor—web. xml. It lists each servlet and tells the servlet container how to deploy them. By maintaining this file by hand, you almost certainly guarantee that you will forget to update it when you add new components to your application. By using XDoclet in your build process, we can generate it automatically by using nothing but your source code and some well-placed comments.

XDoclet is a collection of custom Ant tasks that generate code during the build process. Sometimes XDoclet can generate the necessary code or deployment descriptor using just the source code. At other times, you’ll need to add custom comments to nudge XDoclet along in the right direction.

We have only one servlet right now—ControllerServlet. Example 3-9 shows what your web.xml must contain to deploy this servlet correctly.

Example 3-9.  web.xml

    <!– servlet definition –>
<servlet>
<servlet-name>Controller</servlet-name>
<servlet-class>com.jbossatwork.ControllerServlet</servlet-class>
</servlet>>

    <!– servlet mapping –>
<servlet-mapping>
<servlet-name>Controller</servlet-name>
        <url-pattern>/controller/*</url-pattern>
</servlet-mapping>

Look in ch03c-xdoclet/src for the newControllerServletsource code in Example 3-10. Notice the XDoclet comments we’ve added.

Example 3-10.  ControllerServlet.java

/**
* @web.servlet
*    name=”Controller”
*
* @web.servlet-mapping
*    url-pattern=”/controller/*”
*/
public class ControllerServlet extends HttpServlet

See how they correspond to the web.xml elements? Now let’s look at build.xml to see the newly added XDoclet Ant tasks. We first need to create a couple of new variables, as in Example 3-11.

Example 3-11.  Defining XDoclet variables in build.xml

<property name=”xdoclet.lib.dir” value=”${env.XDOCLET_HOME} /lib”/> <property name=”gen.source.dir” value=” ${build.dir}/gensrc”/>

Xdoclet.lib.dir points to the XDoclet jars. If we have a defined $XDOCLET_HOME environment variable, build.xml should be automatically pointed in the right direction. (Recall that we installed XDoclet in Chapter 1.)

The second variable defines a new location for our dynamically generated code. By keeping our compiled code and generated source code in the same location (build. dir), we can easily delete and recreate it each time we run the Ant tasks. It also gently reminds us that we shouldn’t store generated artifacts in source control.

Next, we need to set up a new classpath that includes the XDoclet libraries. We keep XDoclet stuff separate from our regular build process, as in Example 3-12. This ensures that we don’t inadvertently create dependencies in our deployed code.

Example 3-12.  XDoclet Library Path in build.xml

  <path id=”xdoclet.lib.path”>
<fileset dir=”${xdoclet.lib.dir}”>
<include name=”**/*.jar”/>
</fileset>

      <fileset dir=”${compile.lib.dir}”>
<include name=”**/*.jar”/>
</fileset>
</path>

Using XDoclet

Next we create the generate-web target in Example 3-13.

Example 3-13.  generate-web target in build.xml

<!– ====================================== –>
<target name=”generate-web” description=”Generate web.xml”>
<taskdef name=”webdoclet”
classname=”xdoclet.modules.web.WebDocletTask”
classpathref=”xdoclet.lib.path” />

        <mkdir dir=”${gen.source.dir}” />

        <webdoclet destdir=”${gen.source.dir}”>
<fileset dir=”${source.dir}”>
<include name=”**/*Servlet.java” />
</fileset>

            <deploymentdescriptor destdir=”${gen.source.dir}”
distributable=”false”
servletspec=”2.4″ />

        </webdoclet>
</target>

Let’s step through this:

1. To start, we need to define the WebDoclet task. We don’t need to use the <taskdef> tag for core Ant tasks, but for third-party tasks, this directive shows Ant where to find the implementation code.
2. Next, we create the destination directory for our generated code.
3. Finally, we call the <webdoclet> task. As you might guess, it generates web-tier code. In later chapters, we’ll see other XDoclet tasks such as <hibernatedoclet> and <ejbdoclet>.
4. The <filesetdir> tags tells the <webdoclet> task to look for the source code.
5. The <deploymentdescriptor> tag tells <webdoclet> to generate web.xml.
6. We use the distributable=”false” attribute since we are not in a clustered JBoss environment. It adjusts web.xml appropriately.

To make sure that our new target gets called at the appropriate time, we add it as a dependency to thewartarget in Example 3-14.

Example 3-14.  war target in build.xml

<!– ====================================== –>
<target name=”war” depends=”generate-web,compile”
description=”Packages the Web files into a WAR file”>
<mkdir dir=”${distribution.dir}” />

        <war destFile=”${distribution.dir}/${war.name}” 
webxml=”${gen.source.dir}/web.xml”>
        <!– files to be included in / –>
<fileset dir=”${web.dir}” exclude=”WEB-INF/web.xml” />

        <!– files to be included in /WEB-INF/classes –>
<classes dir=”${classes.dir}” />

        <!– files to be included in /WEB-INF/lib –>
<lib dir=”${lib.dir}” />

        <!– files to be included in /WEB-INF –>
<webinf dir=”${web.inf.dir}” excludes=”web.xml” />
</war>
</target>

Notice that we changed thewebxmlattribute in the war task to point to the newly generated web.xml file.

Typeantin the webapp directory to rebuilt the subproject. You should see console output that looks like this:

  Buildfile: build.xml

  clean:
[delete] Deleting directory /Users/sdavis/Desktop/jbossatwork/ ch03/
03c-webdoclet/webapp/build

  generate-web:
[mkdir] Created dir: /Users/sdavis/Desktop/jbossatwork/ch03/
03c-webdoclet/webapp/build/gensrc
[webdoclet] (XDocletMain.start       47 )
Running <deploymentdescriptor/>
[webdoclet] Generating web.xml.

  compile:
[mkdir] Created dir: /Users/sdavis/Desktop/jbossatwork/ch03/
03c-webdoclet/webapp/build/classes
[javac] Compiling 1 source file to /Users/sdavis/Desktop/jbossatwork/ch03/
03c-webdoclet/webapp/build/classes

  war:
[mkdir] Created dir: /Users/sdavis/Desktop/jbossatwork/ch03/
03c-webdoclet/webapp/build/distribution
[war] Building war: /Users/sdavis/Desktop/jbossatwork/ch03/
03c-webdoclet/webapp/build/distribution/jaw.war

  all:

  BUILD SUCCESSFUL
Total time: 6 seconds

Look at the newly generated web.xml in build/gensrc. In addition to the required servlet elements, the comments show the various other parts of web.xml that can be generated as required by our application. Clearly, we have just scratched the surface of what the <webdoclet> task brings to the table.

Deploy jaw.ear one last time to make sure our application still behaves as expected.

Looking Ahead…

We’ve covered a lot of ground in these first few chapters. We now have a single EAR file that encapsulates many moving parts of our J2EE application. We have automated the build process where it is appropriate, and set the stage for future growth.

In the next several chapters, we’ll leave the web tier and move on to the persistence tier. We’ve stored our DTOs in anArrayListfor long enough—let’s tackle saving them in a true database.

—

by O’Reilly Media 

 

• 0 Comments

An EAR file provides a convenient way to bundle up all pieces of a J2EE application. This article, the first of two parts, will show you how to build one and explain its various pieces. It is excerpted from chapter 3 of the book JBoss at Work: A Practical Guide, written by Tom Marrs and Scott Davis (O’Reilly; ISBN: 0596007345). Copyright © 2006 O’Reilly Media, Inc. All rights reserved. Used with permission from the publisher. Available from booksellers or direct from O’Reilly Media.

In the last chapter we introduced you to web applications, but the web tier is just one part of the J2EE spectrum. In this chapter, we’ll expand the JAW application from a simple WAR file into a full-fledged EAR.

We’ll explore the different parts of an EAR file. We’ll build a Common JAR containing classes that can be shared across all tiers of the application. Finally, we’ll play with various Ant and XDoclet tasks to create our EAR and dynamically generate the deployment descriptors JBoss needs.

WARs Versus EARs

The WAR file is a convenient way to bundle up all pieces of a web application. All servlet containers know how to deploy a WAR file—they expand the bundle, look for the WEB-INF directory, and read the web.xml found there for further deployment instructions.

The EAR file provides the same type of functionality for a full-fledged J2EE application. JBoss expands the EAR, finds the required deployment descriptors, and proceeds from there.

An EAR is like a carton of eggs—it keeps everything organized. While the carton doesn’t add any direct value to your omelet, it makes getting the eggs home from the store so easy that you wouldn’t think about transporting eggs any other way.

Each egg in your EAR carton is a specific piece of the J2EE puzzle. These eggs (or JARs) come in three basic varieties called “modules”:

Web module
A WAR file containing presentation tier components

EJB module
An EJB JAR file containing the middle-tier components
(EJBs, MDBs, etc.)

Java module
A regular JAR file containing classes and libraries that
are shared across the entire application. An
application client JAR and a common JAR are two
examples of Java modules.

An EAR can contain at least one of any of these modules. By the same token, any of them can be safely omitted if they aren’t needed. Figure 3-1 shows the structure of an EAR file.

Figure 3-1.  EAR file structure

Application.xml 

Just as a WAR file contains a web.xml deployment descriptor, an EAR file contains a file named application.xml. It is essentially a packing list, telling the J2EE server exactly what files the EAR contains and where you can find the files relative to the root of the EAR. The EAR file’s META-INF directory stores application.xml.

Example 3-1 shows the JAW Motors application.xml file.

Example 3-1.  application.xml

<?xml version=”1.0″ encoding=”UTF-8″?> <application xmlns=http://java.sun.com/xml/ns/j2ee
xmlns:xsi=”http://www.w3.org/ 2001/XMLSchema-instance”
xsi:schemaLocation=”http:// java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/ application_1_4.xsd”
version=”1.4″>
<display-name>JBossAtWorkEAR</display-name>

 <module>
<web>
<web-uri>webapp.war</web-uri>
<context-root>jaw</context-root>
     </web>
</module>

  <module>
<java>common.jar</java>
</module>

</application>

The elements in application.xml should be pretty self-explanatory. We are telling the application server the name of each JAR and what function it serves.

Notice that Web modules allow you to specify one other value—the<context-root>. Recall from the previous chapter that the context root is your web site’s URL. If you deploy a simple WAR file, the name of the WAR will be used as the URL. When your WAR file is deployed inside an EAR, this element allows you to override the physical name of the WAR and use whatever URL you’d like.

Although not shown in this example,<security-role>is another important element in application.xml.The<security-role>element describes (what else?) the security roles used throughout a J2EE application for both web and EJB components. Defining security roles in application.xml provides a single place to set up J2EE declarative security without duplicating it in web.xml and ejb-jar.xml. The Security chapter describes<security-role>in greater detail.

Common JAR 

In the previous chapter, we created a CarBean POJO to hold the various attributes of a car. We stored it in the WAR file because, well, you didn’t have any other choice at that time. We should now reconsider the storage location for the CarBeanto maximize its reuse.

By the end of this book, we will pull cars out of a database in the persistence tier, and hand them to objects in the business tier, which ultimately will pass them up to the presentation tier. An object that is shared across tiers is a perfect candidate for the Common JAR.

In addition to custom domain objects, the Common JAR is a great location to store common libraries such as Log4J or JDOM. While both WARs and EJB JARs have lib directories, they are best used for tier-specific libraries. For example, the JSTL JARs belong in the WAR—they have no other purpose than to support the creation of web pages. On the other hand, logging is something that happens throughout the codebase—it really belongs in a common JAR.

Let’s factor ourCarBean out of the WAR and into the Common JAR. In addition to moving directories, we’re going to rename it to better describe its purpose in the application.

The suffix “Bean” is a bit overloaded: it includes JavaBeans, Enterprise Java Beans, Session Beans, Message-Driven Beans, JMX MBeans, and the list goes on. The design pattern that best describes theCarBean’s function is a Data Transfer Object (DTO), so when we move the bean, we’ll also rename itCarDTO. The source code will remain the same, but the name will give us a better idea about the true purpose of the class.

Exploring the New Directory Structure

The previous chapter included only the webapp directory. If you change to the ch03/03a-ear directory, you’ll see that we’ve expanded to a webapp directory and a common directory.

We also expanded from one to three build.xml files. Each subdirectory has its own build.xml, and the master build file lives in the top-level directory. The goal is to keep each portion of the application as autonomous as possible. Granted, most of the application will depend on the common sub-project, but by providing individual Ant scripts you have the opportunity to build each portion of the project separately.

The common sub-project

Take a moment to explore the common sub-project. It contains a single class—CarDTO. We have created a new package structure to store all DTOs—com.jbossatwork.dto.

You can build this sub-project by typingant in the common directory. It compiles theCarDTOclass and bundles it up into a JAR file. After you’ve built the sub-project, change to the build/distribution directory and typejar tvf common.jarto verify that theCarDTOclass is indeed stored in common.jar.

The webapp sub-project

The only change to the webapp sub-project from the previous chapter is the removal of the CarDTO class. To accommodate this change, we now must import thecom.jbossatwork.dtopackage at the top ofControllerServlet.

We also have to change our build.xml script to include the common.jar in our class-path. Notice that the definition ofcommon.jar.diruses a relative path to step up one level from the basedir of thewebapp sub-project and down into thecommonsub-project’s output directory in Example 3-2.

Example 3-2. webapp build.xml

<property name=”lib.dir” value=”lib”/> <property name=”compile.lib.dir” value=”compile-lib”/>
<property name=”common.jar.dir” value=”../common/build/distribution”/> <path id=”compile.classpath”>
<fileset dir=”${compile.lib.dir}”>
<include name=”**/*.jar”/>
</fileset>

    <fileset dir=”${lib.dir}”>
<include name=”**/*.jar”/>
</fileset>

    <fileset dir=”${common.jar.dir}”>
<include name=”**/*.jar”/>
</fileset>
</path>

Introducing cross project dependencies like this is not without risk. If you try to build the webapp sub-project before thecommon project is built, the build will fail because the dependent JAR won’t be present. Of course, most other sub-projects will have dependencies on thecommonproject by design—thecommonproject is meant to hold objects that will be shared across all tiers.

Having thewebapp sub-project rebuild thecommonproject every time could be an unnecessary step if thecommonproject changes infrequently. If we do not couple thewebappbuild process to thecommonbuild process,webapp developers can informally baseline thecommonproject by only rebuilding it when they make a conscious effort to do so.  

Type ant in thewebapptop-level directory to build the WAR file. Change to build/distribution and typejar tvf webapp.warto see the contents. Verify thatCarDTOis no longer present in the WAR.

The master build

To ensure that each project gets built—in the proper order—we created a master build file. This file doesn’t actually compile any code; rather, it calls the appropriate build files of each sub-project in the proper order and then EARs up the results. Any failure of any sub-build will fail themasterbuild, so we can rest assured that a successfulmasterbuild is predicated on each individual build completing successfully.

To invoke a build script in another directory, we use the <ant> task. Here is what our compile target looks like in themasterbuild.xml file in Example 3-3.

Example 3-3.  master build.xml

<target name=”compile” description=”Compiles all Java code”>
<echo message=”##### Building common #####” />
<ant dir=”${common.dir}” target=”all” >
            <property name=”jar.name” value=”${common.jar.name}”/>
</ant>

        <echo message=”##### Building webapp #####” />
<ant dir=”${webapp.dir}” target=”all” >
<property name=”war.name” value=”${webapp.war.name}”/>
<property name=”common.jar.dir” value=”${basedir}/${common.jar.dir}”/>
</ant>
</target>

Notice that we also can override properties in the child build process. In both instances, we override the name of the JAR or WAR file specified in the child build. In the case of thewebapp build, we can no longer use the same relative path: your base directory is different now, so trying to move up a level and over doesn’t work. We pass thewebappbuild file a fully qualified path to the common output directory.

Please check back tomorrow for the conclusion to this article.

—

by O’Reilly Media

• 0 Comments

It’s important not to skimp on security when setting up a content management system. This article explores an open source, surprisingly secure content management system that works well for both novice and experienced webmasters.

In a recent article about CMS Programs,

I made quick reference to a need to be security conscious when choosing a Content Management System.  Now, I’d like to correct that cursory glance at a subject that really should be of prime importance when making the decision about a system.  The original choice can impose opportunity, or limits, on your web’s safety and have far reaching effects on your success or failure.

Specifically, I want to explore the security solution found in a program that can be easily manipulated by a novice webmaster, while remaining entirely useful to the more advanced security professional.

A Historical Turd

The previous article also gave away my affinity for the Nuke CMS.  Now don’t run off just yet.  I know that if you are like a large part of the programming community, you think of this program as outdated, full of security holes, and not worth bothering with.  Some even claim it’s not really a CMS.  But take a look at what’s new.

The original PHP Nuke CMS, developed in 2001 specifically for novice webmasters, offered core code for the most basic admin functions and controls for building and maintaining a member-based website. To give him credit for honesty, the creator admits that he learned how to code PHP in one week, and then wrote the script for the PHP Nuke CMS in the next three. To give further credit for ingenuity, he created a system that anyone could use to build a web site, leveling the playing field for hundreds of thousands of small concerns who had the desire but not necessarily the money or know how to set up shop on the Internet.

Unfortunately, by nature of the fact that the code is open source, the systems vulnerabilities have been eagerly and aggressively exploited.  Malicious intrusions, by an embarrassingly long list of attacks often left unsuspecting web masters as victims of everything from SQL injection attacks to complete take overs, up to and including being locked out of the admin controls. And those were the easy risks, those that the webmaster could see.

Another not so easy to spot form of malicious abuse included gaining access to a domain’s email systems. Professional spam rings could then launch campaigns mailing thousands of users each day from the victim’s web site’s domain address.

The exploitability has not been helped by the fact that the program was extremely successful in reaching its target audience, namely new web administrators with little experience.  Such webmasters only learned about the abuse taking place on their sites when their IP address became blocked from major ISPs and they could no longer send or receive mail, or when they began getting hundreds of mail daemon messages on days they had sent nothing out. And, of course, the best proof that a site is being exploited, receiving mail offering watches, Viagra and child sex from their own domain.

Though it’s an easy cop out, all of PHP Nuke’s problems did not lie solely with the original creation.  Hundreds of well intentioned writers, eager to add on their own contribution to the Nuke, began developing modules to do this, and do that, also with little heed to security as an initial concern. Layer all of these problems in with the fact that add-on modules and blocks may or may not be updated regularly, if at all, and it’s easy to see how problems developed.

Nuke Community Searches for Answers 

Since the launch of PHP Nuke, a number of developers have recognized the security problems and mounted efforts to clean up the code.  Revisions, forks and complete rewrites have been undertaken with varying success rates.  Some focus on a wider set of user modules and functions, but most focus to some degree on better security.

While novices swarmed to get a site or two published with the new program, much of the web development community dismissed the Nuke because of its flaws.  But a recent registered user count at just three of the popular Nuke sites comes to more than 200,000.  Take into account the fact that many users operate multiple sites and it’s easy to see there are a horde of sites using this programming code, which means it should not be dismissed or ignored.

Having used a number of the variations of this program myself over the years, as well as the original, I want to talk about one that is worthy of some respect.

RavenNuke™ + NukeSentinel – A Knock-Out Punch

Reportedly, the core group of professionals at RavenNuke™ (RN) spent a year rewriting hundreds of core files to address the well documented security problems with the original code.  This resulted in the current RavenNuke™ code which includes “more than 10,000 fixes/patches” according to distribution documentation.  The NukeSentinel system, the flagship product of RavenNuke™, is a security module developed to work hand in hand with the secured RN release.

An accurate description of the overall security project would be the RavenNuke™ distribution with NukeSentinel.  They are two programs, and one does not have to be used with the other.  However, the NukeSentinel system works so well with this particular distribution that it is easy to forget they are not one program.

Raven’s distribution of Nuke still looks like a PHP Nuke program with all its modules and blocks.  An easy to spot difference from most other versions is that this code involves core files and a select few add-ons.  While some systems offer hundreds of blocks and modules with their systems, RavenNuke™ sticks with the basic operating functions, which have been modified to meet strict security standards.

Repackaging the Management of Difficult Security Concepts

 

A hacked website can completely intimidate new webmasters, who have a tendency to become discouraged and abandon their systems rather than regain control or even disable the site. This fact leaves hundreds of sites running malicious attack code all over the net.

See this quick search of a known hacker that shows relevant returns well into 100 sites. These results are only for a search on one name!  You can see a few others have also taken advantage of this site.  Obviously, they have gained control of the admin function enough to alter the title of the web site, and the site has been sitting like this long enough for the search engines to have picked up the change.

 

Look below at an image of just some of the back office controls designed to keep the malicious out of Nuke sites.  For security professionals and code writers, these protective measures will be standard practice.

For the novice, however, injections are something accomplished with a needle, worms live in the garden and a flood is why Noah built the arc.

Controls and blocks against known threats are already included to protect sites from a large variety of moderate to severe attacks.  The image below shows controls on just one branch of the tree menu. Literally thousands of combinations of secured preferences can be assigned to the web site. So, vulnerability in one web site does not automatically mean vulnerability in all. That’s another obstacle for intruders to overcome.

The Sentinel also provides specific admin protections and can be set to automatically write IP blocking information to Apache’s .htaccess file.

 While security programs generally offer a full set of functions to users, NukeSentinel provides an extra layer of protection for the Admin back office, which allows the user complete control over which functions are turned “on” or “off.”  Shown below are the system’s first 2 of 29 General Settings on NukeSentinel’s main menu.

 

Beyond the ability to control a feature’s basic on – off function, the developers of Sentinel also thought to allow varying degrees of protections for each threat.

If, for instance, you decide that you don’t want proxies to access your web site, you aren’t stuck with an all or nothing choice.  A block of this threat can be set to screen on a Lite, Mild or Strong level, directly from the drop down box.

Other threats can be controlled with ten levels of “punishment” for offenders, ranging from an email alert for the admin to an automatic temporary or permanent ban from your site.

This functionality allows tremendous control and customization for the non expert admin.

No longer does the novice, who may know something of PHP, but looks at the code and decides they shouldn’t touch it for fear of “breaking” the application, have to pray for the best.  He can now approach site protection aggressively because security controls have been translated into something with which he is familiar.

Notice in the image above, the inclusion of an upto date! warning and simple links that open into deeper levels of security.

Notice also that Sentinel’s control panel is loaded with helps. A click on a question mark brings up an instant answer to what a function is, or what it does.  A click on the “Blocker Configuration” help button reveals this pop up.

 

The Sentinel is not the most popular of the Nuke alternatives. For one, it is a little more difficult to install. Having been completely rewritten for security, the code is not always as easy to use as an upgrade on the existing version of an alternate Nuke system.

Once installed and working properly, the frequent bug fixes, patches and system upgrades from Sentinel version to Sentinel upgrade are managed without much problem.

With each upgrade, the developers have included an install program that makes much of the required fixes automatic and worry free for those who read the instructions first.

Pluses and Minuses

While a bit of learning curve should be expected when approaching this system, it is not prohibitive, even for a newbie. Documentation on the project is strong, and the support forums are active and responsive.

The one dubious drawback to this system is the tendency for the admin to lock themselves out of the web site. Though this problem is most often caused by admin error, and easily fixed after a search on the official RavenNuke™ forums, it can still be a frustration.  I called this a ”dubious drawback” because aggravating as it is to be locked out of your own web site, it’s a testament to the effectiveness of the system that if you make a security mistake, even you won’t get into the web site protected by this system.

This code is open source.  In this case, that property is an asset because it has attracted a core group of talented and dedicated developers.

Bugs and vulnerabilities are quickly found and closed.  More importantly, users can find answers to why and how to keep their systems safe at the official RavenNuke forums.

An added, and not insignificant bonus, is the HTML and CSS are 100% W3C compliant, making sites built with this version more easily accessed by new and coming web technologies.

Provided an administrator can commit a couple of hours each week to learning the system and checking for developments, this somewhat difficult system is actually the easiest way to Nuke Security.

The RN CMS presents a huge advantage for the entire net community by repackaging the management of difficult security concepts into a familiar interface that webmasters of all skill levels can use to prevent the spread of attack code and spam to other computers.

Once we wrap our brain around that concept, we can add this one. Not only is security repackaged and made easy, Sentinel’s core group of developers are aggressively involved with prevention of future attacks. While no one over at RavenNuke claims the Sentinel will block 100% of attacks now or in the future, it blocks enough of the known attacks to be worthy of praise.

This is not to imply that webmasters have no responsibility for protection and safeguards to their own sites. But the existence of a strong system of protection as a first line defense should make webmasters all over the world breathe a sigh of relief.

Find more about the RavenNuke™ and NukeSentinel at RavenPHPScripts.com

—

by Jessica Michaels 

• 0 Comments

In the previous article, we went through a lot of preparation for building what was supposed to be the easy way to a killer web site. But the good news is, that was the hard part. In this article, I’ll show you the things you need to know to use and maintain your new CMS-based web site. I’ll also warn you about the pitfalls.

Constructing Your Web Site

Now you have a compatible web hosting account and data base. You have the FTP to upload the files to the Internet. You have correctly configured all components to work with your CMS package. Now, the actual management of your website is accomplished by turning on and off the pre-populated CMS control panel modules, or sections.

Simulated CMS Admin Control Panel

Sample of what a CMS Admin Control Panel Looks Like

These modules are already set for you to enter your information which will be published to your website. A click will take you to an Administrators interface where you can build your site content. Entering is as simple as typing a letter or as elaborate as designing the HTML or PHP code and pasting it to the included text editor.

Php Nuke example of an Admin Newsletter module

 

The programs generally have built-in help texts to help when you aren’t quite sure what a direction means. Notice on this system there is also a WYSIWYG editor so you can make attractive content without having to code.

The system also manages the functions of storing, categorizing and creating a directory of your information. This is why you configured your package to access the database which stores your content.

Article Content returned from the CMS database

Now you have the ability to post information and articles via your admin control panel, that you can categorize by month or topic, or group or subscription level. It will allow you to manage images, comments, surveys, links, products and purchases, games, mailing lists, newsletters, customers, submissions to your site and much more.

One of the truly great things about a good CMS is that hundreds of modules are available for almost any function you can imagine. It only takes a search of your favorite search engine to locate one if it exists. For instance, if you would really love a module that will create a calendar on your web site for managers in your company to schedule meetings, or availability, simply search for “planning calendar module for XX CMS.” Nine times out of ten, you will actually find a pre-coded module that you can easily integrate into your system by using the README and Install texts included with that module. Just remember to keep up with the add-on module’s upgrades, as you do with the core system.

A Basic Understanding of HTML and PHP

 

It is true that you can manage an installed system without extensive coding knowledge. It is not true that you can operate the system with any confidence without such knowledge. It is also not true that you can install or trace errors in installation without some understanding of the language in which the system was written.

Understanding simple code, like how a link or an image are constructed, where and how to begin and end a snippet of PHP, or a line within a code block, will save you a lot of frustration.

Grammatical errors often abound in programming because writers come from all over the world. The coder won’t understand proper sentence structure in English, Italian, German and Spanish for instance. Depending on the country for which your web site is intended, particular nuances in language and syntax errors can be embarrassing for a business site intended for professional users. Corrections like simple grammar fixes are very easy to make, unless you have no clue about how the code is written.

When you get to the point of customizing your CMS for look and feel, for language changes to the core system, you will need to understand some HTML and PHP.

You will certainly need an understanding of both HTML and PHP for upgrading the core system when new releases are issued. The same is true for upgrades of any add-on modules that you incorporate into your system.

There will be common changes that many users request or have problems with. These changes or problems are solved in most cases by paying close attention to examples given in the Install or README or on a good support forum. Recall the discussion on choosing a CMS and the need for a community of supporters for the system you select.

CMS packages also have a tutorial. By becoming familiar with the tutorial and the forum that is dedicated to that system, you will be able to work your way through many simple customization challenges.

 Final but Crucial Requirements

Back Up or Beware!

The control panel on your web hosting account or your CMS may have an automatic back up function. Think about how often you make changes to your site when setting the back up function. If your CMS does not have an automatic back up, look on your web hosting control panel to find one that you can use to easily download a copy of your files and database manually. These are easy to operate, but hard to remember to use.

There are any number of reasons as to why you can lose the information contained in your database or your site files. None of them matter when you have a system for backing up your database and your file system regularly. For static sites, the back up can be once a month. For the dynamic or social site, your back up should run every 24 hours and be mailed to you as an extra precaution. You should be backing up your file system as well as the database contents.

Too many webmasters take this function lightly. If you are one of them, don’t worry. After you’ve lost all your content and hard work one time, no one will have to tell you again. Back it up!

An added benefit is that if you find the need to change hosts, you have all your files and data base structure at hand for an easy migration.

Update

Updates on CMS packages are completed when vulnerabilities are found. Certainly check the official CMS site for updates regularly, then upgrade when a new version is released. One of the items on your to-do list should be checking for updates once every four weeks. This will help to keep your Internet website protected from malicious intruders in much the same way as your anti-virus program protects your local PC.

Malware and attack code on websites can affect the users who visit your site, and jeopardize the confidential information of your visitors and customers. The corner store owner has a responsibility to protect visitors from slips, falls and boxes tumbling on their heads. Likewise, one of the responsibilities of a webmaster is to protect those who visit from malicious threats and to keep information submitted to your site in a safe and confidential manner.

The establishment of a CMS system takes a bit of work, but if you are a small or one man operation, this investment of time and knowledge can save you hours and hours of maintenance work later and make your little organization look like one of the big boys… or girls. Besides that, you’ll save yourself thousands in programming and marketing expenses.

If you don’t feel up to the challenge of the set up and configuration, it’s not that big of a problem. Armed with this much information, you can make an intelligent decision in hiring someone qualified to get your CMS up and running.

Make sure your contract includes service and support for a month or more. Test everything. Send mail and PMs to yourself, sign up as a user, take out a subscription, download a product… You’ll know that everything is operating properly, and that you are familiar enough with the control panel and back office functions to take over before going it alone.

When you are happy with your installer’s set up, ask them to show you how and where to change your passwords so you can secure your web site. Change passwords at your web hosting account, your database and your CMS configuration. Also adjust your FTP settings if you’ve used one. It’s a good idea to change passwords periodically anyway, especially if you use easy passwords.

Once your core CMS is operational, take the time to learn all it can do and the many ways it can save you time and make your web site shine. Dig into it, experiment with what works for you and what doesn’t. As your confidence grows, add modules or take a shot at customizing the design of your site.

The time and energy required to choose, install and learn a system is worth one hundred times the investment and will make you a much better business person and web master.

Resources 

Open Source Content Management Options:

Drupal

Joomla

Mambo Open Source

PHP-Nuke (For Information)

PHP-Nuke (Raven Script) (For Secured CMS)

phpWCMS

phpWebSite

Post-Nuke

Siteframe

TYPO3

Xoops

Get a Quick Grasp of Basic HTML and PHP with These Tutorials

Good HTML Primer with Code Examples

Good PHP Primer with Code Examples

A good article on using FTP software is here

Free FTP Programs

FileZilla

Smart FTP

Shameless plugs for my personal favorites:

IMP Hosting (For hosting, support and development)

PHP-Nuke (Raven Script) (For Secured CMS)

FileZilla (For Easy FTP)

—-

by Jessica Michaels 

 

• 0 Comments

If you have a great idea that you want to spread, but are new to web site design, the situation may seem hopeless at first — until you hear about content management systems. On its face, it sounds like magic: a program that will help you manage your site, and you don’t even need to know HTML! Well, not so fast. There are a few things you need to know first.

You’re an expert Life Guard. In fact, you teach lifesaving skills and have invented a miraculous device that will keep drowning victims from panicking in the water once you’ve reached them. The device you have designed could revolutionize the industry. Your business model is perfected and you are dying to make your product available on the Internet. The problem is, you don’t know Jack about web development or design.

After looking around for a while, comparing web developers, your idea seems doomed to die the death of unrealized dreams, unless you shuck out a few thousand to have a site designed and developed. And then…

You hear about this awesome invention called a Content Management System or CMS.

From everything you see, this is the easy way to get a killer web site for your product. For little expense and without the need of an expert, you can create a functional and attractive space on the Internet to market your wares, spread your message and share information with your group of trainees.

You have found a package that appears to meet your needs, looks nice, and has a shopping cart and an email/newsletter system. To top it off, the system is free and it says right on the information page that you don’t have to know any PHP or HTML! All you have to do is down load and follow instructions.

Now you’re thinking, “Who ever invented the Internet was a genius!”

The package is now residing in your computer files, which you eagerly open…

…when the question “What in the heck is all this?” raises the brow over your left eye.

Where to Start

If you were that Life Guard, you would tell students to start with a swimming lesson. If they don’t know how to swim, they sure won’t save any lives.

In the same manner, you aren’t going to run a web site without knowing something about the language and the tools that make it operate.

There are two distinct areas that need to be examined:

• Part One is the selection of the system that is right for your needs, and preparation for operation.

• Part Two is construction of the web site and management after its activation.

The Beginning - The Content Management System

There are many choices for a CMS. These range from free versions with open source code, to those that have a sometimes hefty price tag and code that is not available for you to see. Since part of our premise is that the CMS saves expense, let’s talk about open source systems.

With CMS packages the possibilities are almost endless, depending pretty much on your own imagination. Anything from a simple article and image archive can be created, through an elab