Introduction

OK, you've installed and started the server. Now what do you do with it? I went back and forth on whether to put this chapter ahead of Chapter 4 ("Architecture") before finally deciding that doing so was logical. You will be better equipped to understand the discussion of architecture after you've installed a domain. However, if you're not too impatient to get started, you might want to read both chapters before you do any actual typing.

This chapter deals with the creation and administration of domains, the basic unit of WebLogic organization. Not to be confused with the Windows NT or DNS concepts of the same name , a WebLogic domain consists of exactly one Administration server and zero or more Managed servers.

Administration Server: Special Considerations

Because the managed servers rely on the Administration server to provide configuration information at startup time, the Administration server can be a single point of failure for your entire domain. For that reason, special care should be taken to ensure that your managed server is as disaster proof as it is possible to make it. For example, you should consider:

Hardware Redundancy

At the high end, this takes the form of identically configured duplicate servers in another time zone. If that's impractical from a financial standpoint, a number of intermediate solutions are available, including disk mirroring, hardware clustering (for some operating systems), or, at the very least, having your replacement-part vendor on speed dial.

Regular Backups

This should go without saying, but you'd be amazed at how many otherwise reasonably professional shops don't have a good backup program in place. Regardless of how good you think your backup procedure is, you should perform periodic audits to ensure that you are backing up all necessary files. It is also a good idea to do a full-scale test of your recovery procedures. Yes, it's a lot of work, but there is such a thing as an unacceptable risk.

Particular attention should be paid to the config.xml file. Store backup in secure locations onsite and offsite each time changes are made to the configuration of the domain.

Backup Servers

It is a good policy to configure one or more separate servers to serve as a backup for the Administration server. In the event of a failure of the primary Managed server, identically configured servers can be restarted and insinuate themselves in a domain as a new Administration server without interrupting the domain's functioning.

I'll talk more about this in Chapter 4, but it is a bad idea to configure your domain so that the Administration server does anything but administer other servers. That is to say, the Administration server should not be responsible for handling client requests .