Table of Contents
- About the Evolution Hosting User Manual
- I. Overview
- II. Setup and Migration
- 6. Tutorials and Samples
- 7. DNS
- 8. Domain Parking
- 9. Accesssing System (JVM) Properties From within an Application
- 10. Working With Files and Directories From Within an Application
- 11. Account Directory Structure
- 12. Secure Sockets Layer (SSL)
- 13. Commerce
- III. Management
- 14. myEvolution - General Operation
- 15. myEvolution - Deploy Section
- 16. myEvolution - Server Section
- 17. Web Server
- 18. Application Server
- 19. Database Server
- 20. E-mail Server
- 21. Version Control
- 22. Audio and Video Streaming
- 23. Application and Account Monitoring
- 24. Web and Application Reporting
- 25. Bandwidth
- IV. Troubleshooting and Support
- A. Evolution Hosting Frequently Asked Questions
- myEvolution Properties Glossary
- myEvolution Glossary
The Evolution Hosting User Manual is the place to find out what Evolution Hosting is and how it works. It describes the high-level operation of Evolution Hosting including its architecture and functionality, as well as providing low-level configuration and troubleshooting steps
Questions or information not found in the user manual can be obtained by contacting Evolution directly. Visit Evolution Hosting on the web to find full contact information or e-mail <support@evolutionhosting.com>.
Table of Contents
Evolution Hosting is a Web Hosting service that specializes in the Java programming language. It offers simplified deployment of Web sites and applications to the Internet via the myEvolution hosting control center.
myEvolution allows customers to do things like upload files, start application servers, query databases, and add e-mail accounts - all via a simple web-browser interface. myEvolution has special features that make the deployment of enterprise applications based on J2EE and Web Services simple and fast.
Evolution Hosting has been perfecting Java application deployment since 1999 and has consistently been an active member of the Java community. Evolution has served in various Java Community Process roles including the application deployment API expert group and has contributed to many of the Java related open-source projects. Much of this knowledge has been built into myEvolution providing a robust and full-featured Java hosting environment for Evolution customers.
To foster clear reading of the Evolution Hosting User Manual, it is helpful to point out a few terms that appear throughout this document. These glossary links define a brief nomenclature. Please visit the glossary for other terms not explicityly mentioned in this list.
myEvolution simplifies Java application deployment and offers control of standard hosting systems such as e-mail and DNS servers. Some of myEvolution's capabilities include: starting and stopping servers, deploying and updating applications, adding e-mail addresses, changing databases, and scheduling data backups.
Figure 3.1 illustrates an instance of the myEvolution Hosting Control Center alongside an Evolution Hosting customer account . The account has three production tiers: web, application, and database; each with one physical server. The myEvolution instance is shown with its remote agents deployed, providing constant communication between myEvolution and the production environment
Account holders access myEvolution via a web browser. Developers and even business users can manage complex environments with myEvolution rather than being forced to rely on deployment experts and system administrators. Globally dispersed groups can deploy applications as a team. Different users can simultaneously make database updates, deploy new content, and add new e-mail addresses.
myEvolution is taylored to the Java platform and offers the ability to validate WAR and EAR files, start Java Virtual Machines and provisions resources on the fly. Part II explains how to get started using myEvolution.
Table of Contents
Evolution Hosting's technical architecture provides a robust environment for enterprise websites. The environment allows for powerful application management and monitoring. It also provides the ability to move and provision new resources as accounts change and grow.
Figure 4.1 represents a high-level view of the Evolution Hosting environment. A customer account is shown along with common services, including DNS, e-mail, and backup. The account is fronted by a firewall and all servers are controlled by myEvolution agents.
Accounts can be custom provisioned to exactly match customer requirements. Either shared or dedicated platforms can be requested by account holders to best fit budgetary and performance needs.
Evolution Hosting's technical architecture is designed for reliability and manageability. The environment provides monitoring, application management, resource provisioning, and automated corrective action capabilities to all accounts.
Figure 4.2 illustrates a typical Evolution Hosting account setup with the myEvolution hosting control center.
A major feature of the architecture shown in Figure 4.2 is the separation of the management area from the production servers. myEvolution has all of the information it needs to recreate any of the production tiers on new physical servers in the event of a catastrophic failure . The net result is increased reliability for Evolution Hosting customers.
Account holders use their myEvolution to deploy applications to a working area. From this location, the application needs to be pushed out to the account's live production servers. Content is pushed using a publish process.
The Publish process is more correctly a synchronization process due to the fact that content can move both directions between myEvolution and the production environment. When the same content exists in both places, the one with the most recent modified date is used as current. The current content item is then copied to the opposite server, overwriting old content in the process.
Figure 4.3 illustrates the publish process pushing files out to a live customer account.
The recommended method of moving content to Evolution accounts is first to upload content to the myEvolution hosting control center and then to Publish it to the production environment.
There is an optional Direct Upload process that account holders can use to push content directly to production environments. The Direct Upload eliminates the extra step of clicking the publish button in myEvolution.
The advantage to using Publish versus the Direct Upload method is that there is an instant backup of content in the myEvolution control center. If an account holder wishes to switch between shared and dedicated packages, or if an error occurs in the current physical server, the entire account can be immediately restored to a new server.
Content placed directly into the production environment via Direct Upload will be synchronized to myEvolution only after a Publish command is given or when one of the servers is restarted by the account holder from inside myEvolution.
Instructions on executing the publish command are available in the section called “Publish”.
Table of Contents
In the event that a catastrophic failure occurs in an Evolution account's application or database, Evolution has put in place a comprehensive set of technologies and procedures that allow a quick and complete recovery. This system consists of hardware, software, and remote storage appliances that provide for the backup, analysis, and restoration of an account.
Evolution's disaster recovery system allows for either coarse or fine-grained restoration. Backups and Evolution Administration tools can be used to recreate an individual user's mailbox or an entire database server. The overall suite of disaster recovery procedures translate into increased uptime and reliability for account holders.
The details below are a minimum feature set that every Evolution account has. Dedicated hosting has additional options above and beyond the list below. This may include changes to the frequency of backups, application or server clustering, and other recovery measures that an account holder may wish to implement. Please contact <sales@evolutionhosting.com>. to discuss specific needs in further detail.
The Evolution hosting platform is built from the ground up with redundancy in mind. Some examples of this include:
Redundancy Examples
Multiple Internet data connecitons to tier 1 providers
All account configurations stored in databases
Replication based site-publish architecture allows for dynamic account moves or restorations.
Redundant central infrastructure such as DNS and mail servers
Advanced monitoring of systems in all respects, both at the central infrastructure and individual account level.
Evolution Hosting has built its systems to continue functioning in the event of a catastrophic failure.
Evolution maintains hot-standby servers that are preconfigured with the myEvolution hosting environment and remote agent. Should an account's server become unusable, Evolution staff can use a myEvolution administration console to dynamically move the account from the corrupt server to a new hot-standby server. This feature is automated and takes only a matter of seconds.
RAID stands for "Redundant Array of Independant Disks". RAID allows a server to continue functioning if one or more hard disks fail. Each server in the Evolution environment has RAID and therefore has increased reliability at the disk-hardware level.
This section contains information on each type of backup that Evolution monitors and runs for account holders. One important metric with regard to backups is the frequency with which they run. Table 5.1 illustrates the schedule on which Evolution backup tasks occur.
Table 5.1. Backup Frequency Summary Chart
| Backup Frequency Table | |||||||
|---|---|---|---|---|---|---|---|
| Backup Type | Default Frequency | Is User Configurable | End-Location | Downloadable | |||
| Shared | Dedicated | Shared | Dedicated | Shared | Dedicated | ||
| Files and Content | Daily | Yes | Yes | Storage Area Network (SAN) | SAN | Yes | Yes |
| Database Data | Daily | Yes | Yes | SAN | SAN | Yes | Yes |
| Full Database Schema and Content | Weekly | No | Yes | SAN | SAN | No | Yes |
| Configuration | Upon Publish or Server Restart* | No | No | myEvolution Database | myEvolution Database | Yes | Yes |
| Content | Upon Publish or Server Restart* | No | No | myEvolution Server | myEvolution Server | Yes | Yes |
| Daily | No | Yes | SAN | SAN | No | Yes | |
| Server | Weekly | No | Yes | SAN | SAN | No | No |
| Off-Site | Monthly | No | Yes | Geo Remote SAN | Geo Remote SAN | No | Yes |
* Configuration changes and content are synchronized between a myEvolution Server and the Customer Application Server.
Each account's entire directory tree, including all of its files and content, is backed up daily to a remote SAN.
Database data is exported and moved to a remote SAN on a daily basis. These daily backups include only data and do not include database schema information (e.g. table definitions, stored procedures, etc.). Evolution recommends customers always maintain a current DDL set used to create and recreate databases. Full database backups, including schema information, are included in database backups.
Account holders may schedule and access Evolution data backups at any time from within myEvolution. This backup can be downloaded by the account holder via FTP or web browser (secure download via SSL is also available).
All databases in the Evolution hosting environment are fully backed up once per week and saved to a SAN. This includes both schema information and data. In the event of a database failure, the backups are quickly restored to a hot-standby database server.
In the Evolution environment, all application configuration settings are stored in a myEvolution database. myEvolution Database instances are located in a separate location from application server production environments. In the event of a failure with the application's configuration, this environment may be dynamically recreated to the existing production deployment server, or it may be dynamically recreated to an entirely different hot-standby server.
In the Evolution environment, all web and application content is backed up via the myEvolution replication feature. When content is uploaded, it is placed in a myEvolution server. This content remains on the myEvolution server until it is published to its respective production deployment server, where the application runs. In this way, the current content set is always in two places. Should the production deployment server experience problems, the entire application can be immediately published to a new hot-standby server.
Evolution e-mail accounts are backed up daily and saved to a SAN. These backups can be used to recreate an account's entire mailbox structure, including all folders and messages. Should a single mailbox become corrupted, Evolution staff can also use these backups to restore an individual account.
All servers in the Evolution environment are backed up on a regular schedule to a SAN. These backups ensure that in the event other restoration steps fail, the server itself, with all of its data, can be restored to a new platform.
Table of Contents
- 6. Tutorials and Samples
- 7. DNS
- 8. Domain Parking
- 9. Accesssing System (JVM) Properties From within an Application
- 10. Working With Files and Directories From Within an Application
- 11. Account Directory Structure
- 12. Secure Sockets Layer (SSL)
- 13. Commerce
Evolution has created a number of tutorials to assist account holders with the development, testing, and deployment of applications to myEvolution. The tutorials are one of the cornerstones in the Evolution Hosting system and it is highly recommended that each account holder download and take advantage of the tutorial that corresponds to his or her account.
The tutorials generally correspond to a particular application server. As vendors release new application server versions, Evolution staff update or create new tutorials to best fit the new offering.
Although each tutorial is different, they all are based on the same design and have similar layers of functionality. These layers are discussed in the next section.
To understand how the turorials work from a high-level, the tutorials can be divided into layers. Each layer has a different purpose:
Tutorial Layers
Layer 1: OS/Environment Layer
A base-level environment layer that investigates the local computer to find out things like the OS version, location of the JDK, etc. This layer is used by other layers that need access to various resources. This level is written in Perl to take advantage of its excellent file and command line capabilities. The main file driving this layer is /bin/library.pl. Take a look at this file to adjust where the tutorial should look for your JDK and what information it should use to connect to your local database, etc.
Layer 2: Compile/Build Layer
A Java-Ant based compile-build environment that controls the main tasks that the tutorial can perform. This layer uses settings and information from the OS Layer to do things like start and stop the server, compile all classes, build a WAR file, and more. All of these tasks are built in Ant "targets" and can be viewed and modified in the file /bin/verge.xml.input.
Layer 3: Application
The application layer refers to the actual Web application that contains the example code for the particular tutorial. In the Odin tutorial, for instance, a number of Java classes, Servlets and JSP's are provided that demonstrate features such as the Orion security UserManager. Full source code is provided. Look for this code in the /src/, /vroot/html/, and /war/warname/ directories.
| Evolution Tutorial Contents | |||||||||
|---|---|---|---|---|---|---|---|---|---|
| Aligo | Bossman | Cheetah | Deity | Anubis6 | Anubis7 | Khufu | Odin | Sphinx | |
| Build/Compile/Run Environment | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
Building and Deploying EAR's | No | Yes | Yes | No | No | No | No | Yes | No |
Building and Deploying WAR's | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | |
| No | Yes | No | Yes | Yes | Yes | No | Yes | No | |
| No | Yes | No | Yes | Yes | Yes | No | Yes | No | |
| Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | |
| Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | |
| No | Yes | No | Yes | Yes | Yes | No | Yes | No | |
| No | Yes | No | No | No | No | No | No | No | |
| No | Yes | No | Yes | Yes | Yes | No | Yes | No | |
| No | Yes | No | Yes | Yes | Yes | No | Yes | No | |
| No | Yes | No | Yes | Yes | Yes | No | Yes | No | |
Wireless Concepts | Yes | No | No | No | No | No | No | No | No |
Uploading Files | No | No | Yes | No | No | No | No | No | Yes |
Securing via JDBC Realm | No | No | Yes | No | No | No | No | Yes | Yes |
| Loading Property Resources | No | No | Yes | No | No | No | No | No | Yes |
| Processing Credit Cards | No | No | Yes | No | Yes | Yes | No | No | Yes |
Sending E-Mail with JavaMail | Yes | Yes | Yes | Yes | Yes | Yes | No | No | Yes |
| Example Discussion Forum | No | No | No | No | No | No | No | No | No |
Download the Aligo RestaurantGuide here.
Download Bossman here.
Download Cheetah here.
Download Deity here.
Download Anubis6 here.
Download Anubis7 here.
Download Odin here.
Download Sphinx here.
Contact <support@evolutionhosting.com> for Khufu.
Contact <support@evolutionhosting.com> for Horeb.
Table of Contents
Note: please also read the Domain Parking section of this manual for more information related to domains, URL's, and IP addresses.
The Domain Name System (DNS) is a physical address lookup utility that has evolved as a core piece of the Internet's operation. The DNS allows Internet addresses in mnemonic form such as www.companyx.com to be resolved into a corresponding numeric IP address such as 134.220.4.1 . It is this numeric address that allows computers to locate one another.
To ensure that addresses are not changed by anyone but the registered owner, the DNS requires that addresses be changed through a Registrar. Evolution takes care of a majority of DNS configuration, but the Registrar changes must be done by the customer.
This section of the Evolution manual explains when and how to change DNS settings so that Evolution accounts can be located on the Internet.
When any account is signed up via the Evolution Hosting automated signup process, two (2) domains are instantly set up within the Evolution DNS infrastructure. Evolution calls these domains the primary domain and the auxillary domain.
The primary domain will usually be the domain customers use to access the site. It will not be available, however, until the account holder completes the DNS Server Name Change process with their Registrar. Prior to the DNS change, the auxillary domain is used by the customer for immediate access after signup and for initial testing. In the following example a primary domain and auxillary domain are listed. Note that the auxillary domain is simply the primary domain with .evohst.org appended to the end of it.
Example Domain Set
Type: Primary Domain
Example URL: www.companyx.com
Derived From: Entered by customer during account signup
Use: Used by site visitors
Available: Only after account holder updates DNS settings with their registrar
Notes: Evolution accepts all valid domain names, including International domains
Type: Auxillary Domain
Example URL: www.companyx.com.evohst.org
Derived From: Created by myEvolution by appending .evohst.org to the primary domain.
Use: Used by Evolution staff and account holders
Available: Available immdeiately after account signup
Notes: The auxillary domain is not valid for e-mail address use - it is intended for web browser use only.
The primary domain is not available for use until the account holder changes the Internet's central DNS records. This change causes the Internet's global DNS system to point to the Evolution DNS subsystem. The end result is that when a URL is typed into a web-browser anywhere on the Internet, the browser will successfully find the Evolution hosted web site.
The Internet's DNS system has a time lag of up to 72 hours (three days) in propogating DNS updates to all DNS servers around the world. In cases where a previously existing site is active, it is advisable to keep both the previous site and the new Evolution site live during the 72 hour transition period. If the previous site is turned off before 72 hours has passed some customers may still be sent to the old site and receive an error.
Evolution has two (2) DNS servers that must be communicated to registrars for each new Evolution account. Please note that Evolution servers should not be used by your own network. Please be sure and use the DNS servers provided by your local internet access provider.
Table 7.1. Primary and secondary DNS server
| Evolution DNS servers | |
|---|---|
| dns1.evolutionhosting.com | |
| dns2.evolutionhosting.com | |
The two subsections that follow give step-by-step instructions for updating DNS records with a few of the Intenet's leading registrars.
BulkRegister is Evolution's recommended Registrar due to its excellent web-based administrative tools. There aren't any instructions for BulkRegister at this time, partly because of the simplicity of their site. Note there is a minimum fee for signup.
Evolution's second choice in registrars is Register.com.
Register.com Update Instructions
Browse to the Register.com website.
Click on the Manage My Account link and login.
Select Modify DNS.
Replace all existing names with the two DNS names as listed in Table 7.1. Click Yes. to proceed.
Validate the changes and click Yes to confirm.
An e-mail will be sent to the registered contacts with a confirmation URL that must be clicked on. Check mail on the registered address and follow the instructions to verify the changes.
The updated domain registration will take up to seventy-two (72) hours to propagate throughout the Internet.
Network Solutions was the first registrar on the Internet and as a result it currently maintains the largest amount of domains. Evolution, however, recommends against Network Solutions due to their extremely difficult change procedures.
Network Solutions Update Instructions
Browse to the Network Solutions website.
Click on Manage Account.
If the domain has an account number or login then login to the admin site. Older domains may not have an account number or login so the second method must be used: Enter the domain name to manage and click 'Go'.
Select the form: I want to transfer my domain name to another ISP and then click Go.
Enter an active e-mail address that matches the one Network Solutions has on file for the administrative or technical contact for this domain name (help is available on the web page). Enter the domain name of the site to change and click Go. Note that if the account holder has set up another security method, such as userid / password (CRYPT-PW), then that is the authentication method that should be used.
Change the host name and address form fields to match those given in Table 7.1. The primary and secondary DNS servers should be the only host names listed.
Click on Submit this form for processing.
For the e-mail address that was used above, check mail for the Modify Domain Form from Network Solutions and verify the changes are correct.
Reply to the e-mail to begin the update process. Note that the e-mail must be sent from the e-mail address that Network Solutions recognizes as being authorized for the domain. Also note again that if another another security method was previously set up, such as userid / password (CRYPT- PW), then that is the authentication method that must be used.
Once accepted by Network Solutions the updated domain registration will take up to seventy-two (72) hours to propagate throughout the Internet.
Table of Contents
A standard myEvolution account will have a single domain name that points to a single set of content. Some accounts, however, require multiple domain names and have multiple sets of content that correspond to the different names. Domain Parking is the term that Evolution uses to describe the process of working with more than one domain name in the context of a single account.
An example of domain parking is as follows: Company X may have a primary domain name of www.companyx.com, but may have another domain name of internal.companyx.com and require that they point to two different applications within their account. Using properties within myEvolution, account holders may set up their account to forward requests for www.companyx.com to one set of application content, while requests bound for internal.companyx.com are forwarded to a second set of application content.
Note: please also read the DNS section of this manual for more information related to domains, URL's, and IP addresses.
The following sections illustrate various domain parking scenarios, explaining both when they should be used, and how to configure them.
If an account holder is changing domain names (zones), from, for example, companyx.com to newcompany.com, myEvolution will automatically create the appropriate e-mail, DNS, and application server entries. The two domains behave and respond identically so that site visitors experience a smooth and uneventfull name change.
Note that the the account will still be listed under the primary domain name in myEvolution for consistency.
Using domain parking, one myEvolution account can answer correctly for more than one domain name. This parking scenario is accomplished by adding the additional names as described in ejip.domain.parking.zones, for situations requiring entirely new zones; or in ejip.domain.parking.subdomains, for situations requiring only new subdomains. Visit the above links for instructions on how to update the myEvolution properties.
When accounts require a many-to-many relationship between domain names and applications, this is the scenario that should utilized. This technique is used when different domain names must be routed to different content sets. Table 8.1. illustrates this scenario:
Table 8.1. Configured to Point to Different Applications Within an Account
| Example Parking Scheme | |
|---|---|
| Incoming Request Domain Name | Intended Destination Domain Name |
| http://www.companyx.com | http://www.companyx.com/mainsite/ |
| http://guest.companyx.com | http://guest.companyx.com/guestsite/ |
| http://www.companyz.com | http://www.companyz.com/companyzsite/ |
In the above example set, there are three content sets:
These contexts may be implemented by an account holder as separate JSP pages or as separate WAR's. For the detailed example below, we will demonstrate the JSP page setup.
Steps to set up Multiple Domains and Content Sets
Obtain the Domain Names
Follow the steps in Chapter 7 to register and point the required domain names to Evolution Hosting's DNS servers. In this example, the domains that would require registration are companyx.com and companyz.com. The domain with guest in its name is only a subdomain of companyx.com and is therefore covered in the companyx.com registration.
Set the myEvolution Domain Parking Properties
Assuming domains companyx.com and companyz.com are now active, and assuming that companyx.com is the primary domain name for the account, add:
companyz.com
to ejip.domain.parking.zones, and add:
quest.
Create Content Directories
In the root content area (depending on the account, this is most likely under the Default Web App) create the context subdirectories as listed:
Place the content for each domain entirely within its respective subdirectory.
Create Main index.jsp Page With Redirection Logic
In the same directory that the above subdirectories were created, creata a top-level index.jsp page and add Java code similar to the following pseudo code:
For precise code, see helloWorld.jsp located in the section called “Cheetah (Apache Tomcat 4.x)”.
String serverName = null ; String proxyName = null ; // when using Apache ProxyPass must check Via header //ProxyVia on //Inserts Via: 1.1 www.myserver.com in the header so programs can use real server name // 1.1 == http version sent by the browser // www.myserver.com == Host header sent by the browser proxyName = request.getHeader("Via") ; if (null != proxyName) { //with ProxyPass int index = proxyName.indexOf(' ') ; if (-1 < index) { serverName = proxyName.substring(index+1) ; } } else { serverName = request.getServerName() ; if (80 != request.getServerPort() && 0 != request.getServerPort() && 443 != request.getServerPort()) { serverName += ":" + Integer.toString(request.getServerPort(),10) ; } } System.out.println("Server name (and possibly :port) is: " + serverName) ; if (serverName.equalsIgnoreCase("www.companyx.com")) { response.sendRedirect("http://www.companyx.com/mainsite") ; } else if (serverName.equalsIgnoreCase("guest.companyx.com")) { response.sendRedirect("http://guest.companyx.com/guestsite") ; } else if (serverName.equalsIgnoreCase("www.companyz.com")) { response.sendRedirect("http://www.companyz.com/companyzsite") ; } else { System.out.println("Error, serverName " + serverName + " has not been redirected.") ; }Create Welcome pages for Subdirectories
Create simple welcome index.jsp pages in each subdirectory. All myEvolution ccounts are initially configured to redirect to a page titled index.jsp when no file is explicitly specified in a url, so the redirects in the step above will eventually resolve to these welcome pages.
In summary, when a site visitor enters guest.companyx.com into their browser, they will see guest.companyx.com/guestsite/ in their browser's address bar and see the content in the /guestsite/ directory. With this technique account holders may host multiple domains within one account. A more robust, but more complicated, method is to create three webapps (e.g. mainsite.war, guestsite.war, and companyzsite.war). Webapps have the advantage of separate classpaths so that classes of the same name do not conflict. There are many more advantages to webapps not covered here.
Note that since Evolution already uses virtual hosting in the shared environment it is not possible to nest virtual hosting within an account.
Account Holders have complete control over MX (mail exchange) records in myEvolution. Account Holders may use Evolution mail servers or change the MX records to point to their own external mail servers. Mail exchange settings are set in the myEvolution ejip.server.mail.mx and ejip.server.mail.mx2 properties.
Account Holders have complete control over additions to DNS zone files. Via myEvolution, account holders may add ejip.domain.parking.arecord and ejip.domain.parking.cname records at any time.
Some account holders prefer to maintain their own DNS servers. Evolution can accomodate this request while still managing everything else. Account holders need only modify the ejip.domain.parking.externaldns myEvolution property to indicate this preference.
An Evolution Account may exist on multiple physical servers, or may be moved at anytime in the event of a system failure. In order to help applications remain portable, Evolution sets Java system properties in each account. These system properties enable applications to do things like find their root file directory. System properties are set into each account's JVM at application startup. This allows developers to execute commands such as
String myAppHome = System.getProperty("app.home") ;
from within their program. Once retrieved, file properties are used to set the base path in file operations.
To view exactly which properties are in their account, account holders can login to myEvolution and go to the Server | Logs | Startup Log section. Here, properties are shown exactly as they are entered into the JVM in the form
-D[name]=[value]
The example property above is set with this entry: -Dapp.home=/home/vhost1/www.companyx.com/
Applications deployed into Evolution Hosting accounts should use the provided System Properties when working with files and directories. A full explanation of working with these properties is provided in Chapter 9.
Two examples of directory related system properties are app.home and app.data. See the Table 8 for a complete list.
In this section, Evolution illustrates its standard account directory structure to help account holders understand where their files are kept after upload to myEvolution. This entire directory structure is replicated for every account, although slight variations may exist based on application server type and version. Further, this structure exists both on the myEvolution server and on the Application Server at the same time, and is periodically synchronized as explained in the section called “The Publish Process”.
+---bin <-- ** Server build/start/stop scripts
+---conf <-- ** Configuration files for the application server
+---dynamic <-- ** Working directory used by application server
+---lib <-- ** Required Java Class Jar files - registered directly in JVM's classpath
+---log <-- * Application server logs
+---mail <-- ** IMAP mailboxes
+---vroot
+---data <-- * Simple storage of miscellaneous files by account holder
+---database
+---backup <-- ** Database data backups
+---export <-- ** Database data exports
+---import <-- ** Temporary upload area for CSV data files to be imported
+---html
+---ejip <-- * Used by myEvolution in application monitoring
+---images <-- * Served directly by Apache WS to optimize performance
+---WEB-INF <-- * Default-Web-App Config Files (e.g., web.xml)
+---classes <-- * Java Classes for use by Default-Web-App
+---lib <-- * Java Class Jar files for use by Default-Web-App
+---j2ee <-- * EAR or WAR files
+---lib <-- * Jar files, property files, etc. - registered directly in JVM's classpath
+---log <-- * Apache access log directory
KEY:
* = Fully accessible/viewable by account holder through myEvolution
** = Only indirecly accessible by account holder through myEvolution configuration settings
The Secure Sockets Layer (SSL) is a commonly-used protocol for managing the security of a message transmission on the Internet. Account holders who require transimission security on their site for tasks such as credit-card processing may set up SSL encryption by purchasing an encryption key from any of the industry recognized vendors. Once purchased, the user's site is updated with the key and SSL-enabled.
To simplify the background check that certificate issuers perform on anyone wishing to obtain a certificate, Evolution recommends that customers first obtain a Dunn and Bradstreet® (D-U-N-S Number) number before requesting a certificate. The D-U-N-S Number is a nine-digit identification sequence, which provides unique identifiers of single business entities, while linking corporate family structures together. The SSL Certificate Authorities (E.g., Thawte® or Verisign®), who authorize SSL Certificates, use D-U- N-S numbers to make certain that certificate requests are valid and not fraudulent.
Note that the D-U-N-S number should correspond to the owner of the URL that the certificate will serve. For example, if a certificate is being requested for www.CustomYachts.com, attempting to use a D-U-N-S number for Great Java Programmers, Inc. may be rejected by the Certificate Authority. Rather a D-U-N-S number for Custom Yachts, Inc. would be preferable.
Typically, the process to set up SSL in an Evolution account proceeds as follows:
SSL Setup Steps
Following their registrar's instructions, the account holder first updates domain name contact (WHOIS) information to make certain it is exactly correct and current. Registrars demand that the WHOIS information match that of the certificate request precisely.
Account holder sends Evolution technical staff the D-U-N-S number, exact contact information, and the requested SSL URL. Evolution verifies this information using a WHOIS query.
Evolution generates an initial certificate and requests a signed certificate from the Certificate Authority using the provided D-U-N-S number.
Account holder works with the Certificate Authority to verify their identity.
Certificate Authority generates final certificate and Evolution installs it on the production server.
Evolution Hosting fully supports e-commerce applications and offers a range of solutions to help account holders accept payments from their customers.
Summary of Evolution Hosting Credit Card processing options
Third Party Dynamic URL
Customer dynamically creates simple URL's with vendor ID and order items
Account holder does not need to store credit card numbers or build billing system
No SSL Certificate Required
Verisign/CyberCash API
Full Java API for processing credit card transactions.
Account holder has more control over billing system.
OfBiz Full Blown Java Shopping Cart and Commerce System
Use of Evolution Hositng custom CyberCash API
Requires standard credit card merchant account at a bank
Custom Billing
Evolution Hositng installs third-party software
Evolution Hositng supports third-party software
The most basic form of commerce integration that an account may choose is to frame-in a third-party processor. Under this option an Evolution account creates an HTML frame on their order processing page and loads an external web page. The external page is managed by the third-party and the Evolution account holder need only ensure that the proper order and account paramaters are passed in the frame's url string. This option is by far the simplest way to add purchasing to a web site, because it eliminates custom programming and the requirement for a merchant-account (the third-party provides a shared merchant account).
Another options allows Evolution account holders to develop or integrate custom payment processing systems. Evolution supports account holders in this task by modifying firewall rules to allow interaction with external payment gateways.
For programmatic payment processing, Evolution Customers may choose to integrate with Cybercash , the Internet's leading credit card processing company. Evolution has fully integrated the Cybercash payment gateway into its environment via a custom Java API. This API provides the ability to securly process credit card transactions when combined with a credit card merchant account, as is required by Cybercash.
The final e-commerce option, Custom Payment Processing, allows Evolution Hositng customers to supply special software to Evolution Hositng for installation and configuration. Contact Evolution sales for more information.
Table of Contents
- 14. myEvolution - General Operation
- 15. myEvolution - Deploy Section
- 16. myEvolution - Server Section
- 17. Web Server
- 18. Application Server
- 19. Database Server
- 20. E-mail Server
- 21. Version Control
- 22. Audio and Video Streaming
- 23. Application and Account Monitoring
- 24. Web and Application Reporting
- 25. Bandwidth
Table of Contents
A high-level description of myEvolution can be found in Chapter 3. This chapter explains basic operating procedures for myEvolution such as logging in, finding help, and signing off.
Account holders sign into myEvolution via the login page. A username and password are required. If an account holder misplaces their username or password, they may use the reminder feature on the same page to have login credentials e-mailed to the account's primary contact.
Account Holders access the various sections in myEvolution by clicking on the primary and secondary navigation links at the top of the page. These links utilize JavaScript and HTML Frames to optimize performance. The primary navigation links (top row) dictate what is displayed in the secondary links (bottom row). For example, once the database tab is clicked on, the bottom row of links is updated to display the SQL Tab, the Import Tab, etc.
The Server Control is located in the upper right corner of myEvolution and is used to control the life cycle of an account's application server.
Stages of the Server Control (color coded)
Stopped (Red)
The application server and its JVM are not running.
Starting (Yellow)
The application server and its JVM are in the process of coming online, but are not yet running.
Running (Green)
The application server and its JVM are started and capable of fielding incoming requests.
To start, stop, or restart an account's application server the Server Control Buttons are used.
Server Control Buttons
Start (Left Side)
Starts an account's application server. If the server is currently Running, the Start button will Restart the server (the server does not have to first be Stopped).
Status (Middle)
Indicates the current state of an account's application server.
Stop (Right Side)
Stops an account's application server.
myEvolution has context-sensitive help in every section Help appears to the right of the navigation links and contains both a section description and a link to the user manual for more information. For additional help, the Support section of myEvolution contains links to the user manual, Evolution Support contact form, and priority electronic paging system.
Table of Contents
The Deploy Section of the myEvolution Hosting Control Center is one of the most frequently accessed areas in the Evolution environment. From Deploy, account holders can upload new application content, validate EAR's or WAR's, and Publish applications.
For a quick-start to deploying applications to myEvolution, skip ahead.
A majority of the Deploy section is devoted to uploading files to directories in the Evolution environment. It is helpful to view Chapter 11 for reference on the underlying directory structure behind the various myEvolution Deploy sections. Account holders should also read the Publish section before working in the Deploy section to understand the underlying architecture of myEvolution and its method of delivering applications to production servers.
The remainder of this chapter explains the Deploy subsections in detail.
This section gives tips and abridged deployment instructions to deploy a J2EE WAR into the Evolution environment.
Log into myEvolution and navigate to the DefaultWebApp section. From there, click on the directory named ejip and examine the file named monitor0.jsp. This file is configured and included with all accounts and is used for monitoring. It demonstrates how to get a connection to a database using J2EE DataSources.
While still in the DefaultWebApp section, click on the WEB-INF directory and examine the web.xml file. This is a standard WAR configuration file, but it shows entries tailored for myEvolution.
Any standard J2EE WAR file can be deployed to Evolution. Use the examples in Step 1 as a guide to make any necessary changes to database code and the WAR file's web.xml configuration file.
Package the WAR normally using a command similar to the JAR command. Note that the /WEB-INF/web.xml WAR configuration file may be included, or the default that is already created in the account's DefaultWebApp section may be used.
The WAR may be uploaded into either the DefaultWebApp section, or the EAR's, WAR's, Etc. section. Read each section to find out which method is best for the account and then follow the instructions to deploy. In general, the DefaultWebApp technique is the preferred method for a single WAR, whereas multiple WAR's can be deployed in the EAR's, WAR's, Etc. section.
The application server and deployed application should now be running. The web server, application server, and database server can be tested by accessing the monitor page. If the account's Auxillary Domain were www.companyx.com.evohst.org , the monitor page could be checked at the auxillary url http://www.companyx.com.evohst.org/ejip/monitor0.jsp. If the WAR was deployed in the EAR's, WAR's, Etc. section and was named WARB, it could be checked at http://www.companyx.com.evohst.org/WARB/.
There are multiple ways to deploy J2EE applications in myEvolution. The various techniques map to supported deployment approaches in each application server vendor's deployment implementation. The following table lists the techniques supported by each vendor platform.
Table 15.1. J2EE Application Deployment Matrix
| J2EE Application Deployment Matrix | |||||
|---|---|---|---|---|---|
| DefaultWebApp | EAR's, WAR's, Etc. | ||||
| WAR | EAR | SAR | Service Definition | ||
| JBoss 3.0 | Yes | Yes | Yes | Yes | Yes |
| Oracle 9iAS | Yes | Yes* | Yes | No | No |
| Orion 1.5.x | Yes | Yes* | Yes | No | No |
| Tomcat 3.x | Yes | Yes | No | No | No |
| Tomcat 4.x | Yes | Yes | No | No | No |
| WebLogic 5.x | Yes | Yes | No | No | No |
| WebLogic 6.x | Yes | Yes | Yes | No | No |
| WebLogic 7.x | Yes | Yes | Yes | No | No |
* WAR files may be deployed in these servers by first packaging them in an EAR.
All vendor platforms accept the deployment of Java Classes. These classes should either be deployed within the above mentioned applications (such as in a WAR's WEB-INF/lib/ directory), or via the JAR's Section of the myEvolution deployment area. Deploying a JAR file to the JAR's Section will automatically add it to the JVM's. -classpath setting.
This section of myEvolution is where simple HTML pages and images are generally deployed. Although the DefaultWebApp is technically a J2EE WAR file, it can be used as a simple web site deployment directory by non-java-experts. Just upload an HTML page, click publish, and the new content will be live.
The DefaultWebApp is simply an exploded WAR file. Instead of keeping all of the WAR's content inside of a single file, it is exploded or extracted so that all of the files are more easily accessible. Evolution account holders may deploy one (1) WAR in this fashion, additional WAR's must be deployed as explained in the WAR Section.
Although the concept of a DefaultWebApp is not part of the Sun J2EE Specification, it is implemented by most J2EE application server vendors as an alternative to deploying via a WAR file, which bundles an application's contents into a single file. The primary advantage of a DefaultWebApp deployment is the ease with which individual files may be updated in a deployed application.
Steps to Deploy to the DefaultWebApp
Upload Content
Files may be uploaded individually, as an archive (e.g., Zip file), or as a full WAR file. To upload, click on the File button, select the file on the local PC, then click upload. Be sure to click Overwrite if there is already a file with the same name.
Extract Content
If a Zip, JAR, or WAR file was uploaded, they must be extracted by clicking on the uploaded file and then clicking the Unjar link in the lower pane of the browser.
Publish Content
In order to become part of the live site the content must be transferred to the production server. Follow the instructions in the publish section to move the files. Note that if the server is to be restarted, Publish can be skipped, because it is executed upon server restart.
Start the Server
If the server is not running, it must be started. The Server Control section explains how to start the server.
Check the Startup Log for messages
Consult the Startup Log to read deployment messages.
EAR's and WAR's are the prescribed deployment medium of the J2EE specification. They are complete web applications contained in a single file.
SAR's, and Service Definitions's are deployment mediums specific to the JBoss application server.
The recommended (best practice) in deploying an application via the EAR's, WAR's, Etc. Section of myEvolution is as follows:
Steps to Deploy to the EAR's, WAR's, Etc. Section
Upload
Upload the EAR, WAR, SAR, or Service Descriptor file to the EAR's, WAR's, Etc. Section.
Validate
Click on the file and view validation messages in the lower pane of the browser.
Start (or Restart) the Server
Click on the Server Control's Start button.
Check the Startup Log for messages
Consult the Startup Log to read deployment messages.
The JAR's section of myEvolution allows multiple Java Classes to be deployed in aggregated form.
To deploy JAR files to myEvolution:
Steps to Deploy JAR's
Upload
Upload the JAR file to the JAR's Section of myEvolution.
Start (or Restart) the Server
Click on the Server Control's Start button.
The Classes contained in the uploaded JAR files are automatically added to the Classpath of the pertinent Classloader(s) for the account. Exact classpath settings for an application can be viewed in the section called “Startup Log”. Account holders should note that myEvolution includes all core classes required by various application servers and these files should not be uploaded into the JAR's Section or ClassCastExceptions may result.
The Data Section can be accessed by applications and is specially configured to not be accessible via site visitor's web browsers. An example use for this tab would be to store signup confirmation files generated by an application. The files could later be downloaded via the Data Section for review. To see how applications access the Data directory and related properties see Chapter 9
The FTP Section contains reference information and credentials explaining how to transfer files to and from an account via FTP. Figure 4.3 illustrates FTP upload options.
The Publish Section has one link, which activates the Publish routine for an account. Read more about Publish in the section called “The Publish Process”.
Table of Contents
The Server section of the myEvolution Hosting Control Center contains logs and property information related to an account's servers and other resources such as DNS.
The logs section should be consulted frequently by account holders to check server startup results and application output.
Contains vital information related to the application server startup such as classpath settings, J2EE deployment information, and summary success or failure messages.
Access to the Webalizer reporting suite as described in Chapter 24. To view the Webalizer reports, simply click on the link for this section.
The properties section contains server properties and other settings for various aspects of the Evolution Hosting environment. A description of all properties can be found in myEvolution Properties Glossary.
Evolution utilzes the industry leading Apache Web Server to optimize the performance of every account. Apache is used for Virtual Hosting and to directly serve certain files, bypassing the JSP/Servlet Engine, in order to optimize performance. Content in the /images/ directory in each account's Default-Web-App, for example, is served directly by Apache.
For information on working with application servers within myEvolution accounts, please see Chapter 6.
Table of Contents
Each Evolution Hosting account has at least one database. Evolution databases are primarily used by an account's Java application, but may also be used by other applications (e.g., cgi-bin). This section provides information on the general setup and management of databases, as well as instructions on how to connect to a database from within an Evolution hosted Java application.
For answers to frequently asked questions, visit the Evolution Hosting Databases.
Each account's database tablespace is created automatically by the myEvolution Hosting Control Center upon account signup and is immediately ready for use. Account holders do not have to do anything extra related to the tablespace and can immediately begin creating the database schema.
It is worthy to note that the term database actually refers to a software application that can contain multiple tablespaces. Evolution Accounts each have at least one tablespace, but may share a database. The term database may be used in place of tablespace, because of its common understanding.
The database schema is the unique definition of an account's database structure. The schema is created via the myEvolution database tab using SQL statements.
The databases that Evolution Hosting offer fully support the SQL standard, in addition to offering proprietary extensions to do special tasks. Vendor specific documentation should be consulted for information on a particular vendor's SQL implementation.
Evolution Hosting recommends that account holders maintain a full set of SQL scripts (sometimes referred to as DDL) to create, recreate, or modify the account's database schema at any time. Ideally, these scripts should be maintained in a code versioning system, such as CVS.
Evolution Hosting provides tutorials, modifiable account properties, preconfigured application server setttings, and other tools to assist account holders in connecting to their database from Java applications. This section explains these tools in detail.
The first stop for account holders investigating how to connect to their database should be the Evolution tutorials. These are fully functioning Java applications that demonstrate concepts such as JDBC access from a Servlet, and updating records from a Bean Managed Entity Bean. Account holders should read Chapter 6. and examine the tutorial that corresponds to their account type.
Access to all Evolution databases is accomplished via Java DataSources. Datasources are a Java standard for obtaining a JDBC connection to a database in a generic fashion. At startup, the application server registers a DataSource in JNDI. The JNDI name is application server-specific. However, to remain portable, J2EE defined 'resource-references' for use in application source code. The database property, ejip.datasource.name, refers to the application server's JNDI name. This property value can be changed to rename the datasource, but must comply with the naming conventions imposed by the account's application server JNDI Namespace.
Resource-references are mapped to the application server-specific DataSource name in JNDI. There are two ways to get a handle to a DataSource in an application server.
Through the application server-specific JNDI name (non-portable, not advised). These do not require a "java:comp/env" lookup into the InitialContext.
Through resource-references (portable, advised) in code and deployment descriptors. These use the "java:comp/env" prefix for lookup into the InitialContext.
The following details the steps required for database access from a JSP or Servlet via DataSources. Details for setting up EJB access to DataSources is similar, but use different deployment descriptors. Container-managed Entity Beans would not require these steps, but Bean-managed Entities and Session Beans using JDBC will need to define resource references similar to web applications.
Setting up an Application to Use Datasources
Register the desired name for the Datasource with myEvolution.
Modify the myEvolution property ejip.datasource.name as desired
This property represents the application server's JNDI name of the DataSource. It is NOT the JNDI name you use in your application code. Since it is application server specific, it must follow the JNDI naming conventions of the server. Typically, the server allows slashes '/' for subcontexts. The name can be left as default or changed. Whatever name is given, the application should use the identical string in the application server-specific descriptor when mapping the resource reference string to the actual JNDI name specified in ejip.datasource.name.
Set the correct datasource name in the application's /WEB-INF/web.xml file
Modify the application's web.xml so that it matches the ejip.datasource.name property.
<resource-ref> <! - - res-ref-name is the JNDI name used in application's code - - > <res-ref-name>jdbc/myDataSource</res-ref-name> <res-type>javax.sql.DataSource</res-type> <res-auth>Container</res-auth> </resource-ref>Map the resource reference to the ejip.datasource.name in the application server-specific descriptor.
For instance, here is an example of a jboss-web.xml file that maps to the ejip.datasource.name of 'jdbc/DefaultDS':
<jboss-web> <context-root>/mywebcontext</context-root> <resource-ref> <res-ref-name> jdbc/myDataSource</res-ref-name> <!- - Server-specific JNDI name. Ex: "java:/"+ "ejip.datasource.name" - -> <jndi-name>java:/jdbc/DefaultDS</jndi-name> </resource-ref> </jboss-web>Notice, the ejip.datasource.name property does not have "java:/" ; however, the jboss-web.xml requires this prefix for this resource reference mapping.
Write the Java code
Write the Java code, making sure the DataSource name matches the resource-reference established in the web.xml deployment descriptor. Remember to prefix your web application's lookup into JNDI with "java:comp/env".
//get DB connection... Connection con = null ; try { Context jndiCntx = new InitialContext(); out.println("Looking up jdbc/myDataSource"); DataSource ds = (javax.sql.DataSource)jndiCntx.lookup("java:comp/env/jdbc/myDataSource"); out.println("Found. Connecting to jdbc/myDataSource"); con = ds.getConnection(); if (null != con) { out.println("Connection successful!"); } } catch (Exception ex) { out.println("getConnection failed. See error log for stack trace."); } finally { // close the Connection try { if (con!=null) con.close() ; } catch(SQLException sqle) { con = null ; } }Note that the close() method on the connection actually returns it back to the database pool for other resources to use.
This section of myEvolution is where account databases can be modified, exported, and backed up.
The myEvolution SQL Tab allows execution of database queries and is automatically connected to the account's live database. It has three primary sections:
Subsections of the SQL Tab
Table Listing (top)
This section is always visible at the top of the SQL Tab and lists all tables currently in the databse. Clicking on one of the tables will display its definition.
SQL Commands (middle)
The SQL Execution Area allows the input of any standard SQL command that is compatible with the account's database. Output from the SQL Execution Area appears in the SQL Output area, which is described below.
Results / Messages (bottom)
The SQL Output Area displays output from database queries that were previously input in the SQL Execution Area.
The Backup Tab allows account holders to create a full data backup of an account's database. This file can then be downloaded for backup or analysis purposes. The Backup Tab also provides facilities for scheduling backups to occur on a regular basis. These backups augment other global database backups that Evolution Hosting performs on a regular schedule for all accounts.
Table of Contents
Evolution Hosting offers full e-mail hosting facilities to account holders. These services can take the form of simple e-mail aliases, or dedicated e-mail servers with custom Servlet based management facilities. This section of the Evolution User Manual details the various options and their use.
| Evolution E-mail Packages | |||||
|---|---|---|---|---|---|
| Option | Includes | Monthly Price | |||
| Shared | Dedicated | ||||
| Base Fee | Per Account | Base Fee | Per Account | ||
| 1 | JavaMail , Aliases , and Distribution Lists | $0 | $0 | Request a quote. | Request a quote. |
| 2 | IMAP Mailboxes (includes option 1) | $10 | $3 | Request a quote. | Request a quote. |
| 3 | Webmail and Portal Mail-API (includes options 1 and 2) | $20 | $4 | Request a quote. | Request a quote. |
JavaMail allows account holders to send e-mail from within programs. An example use of JavaMail is a shopping cart application that sends a confirmation e-mail when an order is processed.
The full JavaMail API is supported. The SMTP host name is available via the system property ejip.smtp . Sample code to send e-mail via the JavaMail API is included in the Cheetah tutorial.
Account holders use aliases to forward messages addressed to an Evolution account e-mail address to another Evolution account e-mail address or to an externally hosted e-mail address. For example, mail sent to JohnDoe@companyx.com will forward to JohnDoe@companyz.com . Evolution Hosting supports an unlimited number of aliases and changes can be made by account holders at any time with myEvolution.
Account holders use aliases to forward messages addressed to an Evolution account e-mail address to a list of e-mail addresses. For example, mail sent to SalesTeam@companyx.com will forward to JohnDoe@companyx.com and JaneDoe@companyz.com . Distribution lists may include other lists, which makes it easy to organize related groups of e-mail addresses. Evolution Hosting supports an unlimited number of aliases and changes can be made by account holders at any time with myEvolution.
IMAP is an e-mail protocol that was selected by Evolution for its ability to be used in multiple locations at the same time (e.g., work laptop, home computer, remote Internet kiosk). Account holders select IMAP if they wish to have their mailboxes hosted with Evolution (as opposed to forwarding to a third-party e-mail hoster).
Account's may choose to have mailboxes on a shared or dedicated IMAP e-mail server. An unlimited number of accounts is supported and changes can be made with myEvolution at any time. Disk quotas and password management is included. IMAP mailboxes may be accessed with e-mail clients, such as Microsoft Outlook and Netscape Communicator, or via Webmail .
Webmail allows IMAP mailbox owners to check e-mail from any Internet browser. It can be used as a sole means of sending or receiving mail, or in conjunction with an e-mail client (recommended). Webmail is especially useful for individuals who travel frequently and are away from their desktop computer. The webmail login is located here .
All of the e-mail maintenance tools for aliases, distribution lists, IMAP, and webmail (create, update, delete, and list) are available to account holders via an API . The API is implemented using simple HTTP . GET requests to myEvolution. Fully functional administration screens are provided. Complete Java source code is included so that customers may integrate e-mail capability into their applications.
Aliases are described in the E-mail Options section. To set one up, simply enter the origin address and the forward-to address in the fields provided, then click the Save button.
Lists are described in the E-mail Options section. To set one up, simply enter the origin address and the forward-to addresses in the fields provided, then click the Save button.
Maiboxes are described in the E-mail Options section. To set one up, simply enter the mailbox address, quota, and password in the fields provided, then click the Save button. The Quota field determines how much disk space the mailbox account may utilize. For information on what happens if an account reaches its quota, see the E-Mail FAQ .
This section explains how to set up Outlook for use with Evolution IMAP accounts. Questions can be directed to <support@evolutionhosting.com> . The following instructions utilze the sample domain www.companyx.com . The account's primary domain should be substituted for the sample domain.
Steps To Set Up Outlook with Evolution IMAP
Start Outlook
Go to Accounts
Click on Tools | Accounts to navigate to the Internet Accounts dialog box.
Add the Account
Click on Add | Mail . Enter the name of the mailbox holder (e.g., John Doe). Click Next .
Enter the Incoming Address
An example incoming address is JohnDoe@companyx.com and should match the address entered in the Mail Section. Click Next .
Enter Server Information
Select IMAP server as the incoming mail server type.
Enter the incoming e-mail server as imap.primary domain, where 'imap.' is added to the domain name, companyx.com. In this example the incoming server is imap.companyx.com.
Enter the outgoing e-mail server (SMTP): smtp.evolutionhosting.com.
The account name must match the one in the Mail Section. It is usually a concatenation of the e-mail name and domain name (e.g., johndoe_www_companyx_com ) Replace all periods ( . ) in the domain with underscores ( _ ). Join the e-mail name and domain name with an underscore ( _ ).
Use the password as entered in the myEvolution Mail Section . Do not check SPA. SPA is Windows challenge/response.
Do check the field "My server requires authentication." Click on the Settings button. Select the option "Use same settings as my incoming mail server." Click OK.
Click Next .
Finish
Choose the pre-selected connection method and click Finish .
Some users may not have consistent access to the Internet and therefore wish to save e-mail messages from the IMAP server onto their local e-mail client. This has the effect of making IMAP function similar to the POP mail protocol, while still keeping the server-side benefits of IMAP.
Making IMAP function on a local basis involves creating an Outlook rule to move all messages coming in from the IMAP account to the traditional Outlook Inbox folder. Messages will still also be delivered to the IMAP Inbox where they will be marked for deletion. These steps enable off-line or disconnected operation, whereas the IMAP Inbox requires a connection.
Making Outlook Save Messages to the Local Client
Click on the standard Outlook Inbox folder (not the IMAP Inbox)
Click on the Tools drop-down menu and select the Rules Wizard .
Click the New button.
Click on Check messages when they arrive .
Click the Next button.
Select the checkbox When received through the specified account .
Click on Specified in the rule description text-box.
Select the IMAP Account from the drop-down box.
Click the Next button.
Select the checkbox Move it to the specified folder .
Select the standard Outlook Inbox from the directory tree.
Click the Next button.
There is nothing to do on this screen, because exceptions are not required for this rule.
Click the Next button.
Name the rule.
Click the Finish button.
At this point, all incoming messages from the IMAP server should be transferred to the Outlook Inbox for off-line manipulation. Note that Outlook sometimes has trouble with multiple levels of rules and some existing rules, such as incoming mail filters, may no longer function.
This section explains how to set up Netscape Communicator 4.x for use with Evolution IMAP accounts. Questions can be directed to <support@evolutionhosting.com> . The following instructions utilze the sample domain www.companyx.com . The account's primary domain should be substituted for the sample domain.
Steps To Set Up Netscape Communicator 4.x with Evolution IMAP
Start Communicator
Go to Messenger
Click on Communicator | Messenger .
Verify Version
Verify the version by clicking on Help | About Communicator . The version should be version 4.x (e.g., 4.72)
Go to Preferences
Click on Edit | Preferences .
Go to Identity
Click on Identity .
Fill out Name , E-Mail Address , Reply-To , Organization , and Signature File .
Add the Mail Servers
Click on Mail Servers .
Click on Add .
There are three tabs to edit:
Tab One: General
Server Name : Enter the incoming e-mail server as imap.primary domain, where 'imap.' is added to the domain name, companyx.com. In this example the incoming server is imap.companyx.com.
Server Type : IMAP
User Name The account name must match the one in the Mail Section. It is usually a concatenation of the e-mail name and domain name (e.g., johndoe_www_companyx_com ) Replace all periods ( . ) in the domain with underscores ( _ ). Join the e-mail name and domain name with an underscore ( _ ).
Check Remember Password .
Set to check Every 30 Minutes .
Close Server Section
Click OK to close the Add Server dialog box.
If prompted for a password, enter it now. Use the password as entered in the myEvolution Mail Section .
Close Server Section
Enter the outgoing e-mail server (SMTP): smtp.evolutionhosting.com.
Close Preferences
Click OK to close these preferences.
Finish
The newly created mailbox should appear in the left-side Names pane. Click on the + sign to expand and see the Inbox and mail messages.
Webmail is available to account holders as indicated in the Options section. Webmail login credentials (username and password) are set in myEvolution as explained in the Mail Section . Properties such as return address and mail signature are set here, as well.
Version control is also called source code management (SCM) or configuration management (CM) and refers to the process of managing and tracking changes to application content. Evolution offers account holders the leading option in version control software - CVS.
CVS Features
Its client-server access method allows developers to access the latest code from anywhere there's an Internet connection
Its unreserved check-out model to version control avoids artificial conflicts common with the exclusive check-out model
Its client tools are available on most platforms
For more information on CVS or other version control system options, please contact <support@evolutionhosting.com>.
For customers requiring audio and video broadcast capabilities, Evolution offers the RealSystem® Server by Real Networks®. The RealSystem server includes streaming for RealVideo, RealAudio, Flash, RealPix, RealText, SMIL, MP3, and QuickTime. All streaming protocols are supported including http and rtsp. Each RealSystem Server is hosted on a dedicated streaming platform, separate from account holder's application server and database server platforms.
Included in Evolution streaming services is a publishing tool that can be used to push streaming content from an application server out to a streaming server. This publishing tool can also be used to automatically transfer content that is uploaded by website visitors to the streaming server for immediate availability.
Evolution hosting offers application monitoring as an optional service to all account holders. Monitoring refers to the process of testing an account's application on a regular schedule and taking action if any problems are found. At a minimum, monitoring checks the status of the web, application, and database server within an account. It can also be customized to check specific features within an application, and take specific actions based on what is found.
Once selected, application monitoring is automatically set up and instantly activated. There are multiple options in account monitoring, each configured to fit an account's specific needs.
Monitoring Options
No Monitoring
This option includes no monitoring of an account's appliction server. If the application server stops running, the account holder is responsible for detecting the outage and restarting the application server manually.
Basic Monitoring
Evolution proactively restarts an account's application server if it stops running. A monitoring program continually checks the health of the application and automatically takes action if a failure is detected.
Intermediate Monitoring
Includes the features contained in Basic Monitoring, in addition to instant account holder notification via e-mail and pager of any problems encountered.
Advanced Monitoring
Includes the features contained in Intermediate Monitoring, in addition to running a custom user-written program at specified intervals.
Web Reporting refers to web server log file analysis and related web site analysis. All Evolution Hosting accounts have full reporting tools and information as part of their myEvolution account.
For statistical information, all accounts have access to detailed reports generated by the Webalizer web server log file analysis suite. It includes highly detailed usage reports on site access, bandwidth usage, and more. Instructions on how to access Webalizer in myEvolution are located here.
All accounts should follow the logging best practices outlined in Chapter 27. With proper logging, the application and web logs listed in the section called “Logs” will be invaluable in analysis and debugging.
Evolution has no hard limits on bandwidth; accounts can burst to whatever level of bandwidth is necessary to meet demand. There are additional fees, however, for bandwidth usage above an account's pre-selected level. Traffic that is internal to the Evolution network is not included in bandwidth usage calculations (e.g. application server querying database server).
Evolution provides a base level of bandwidth for each account. Currently, the base level is set at 5 GB. This bandwidth quantity is allocated to any incoming or outgoing traffic associated with the account's web site, e-mail server, streaming server, etc.
Accounts that use more bandwidth than is allocated in their package incur an additional $2.00 charge per GB transferred.
The above paragraphs are summarized in Table 25.1.
Table of Contents
Evolution strives to provide the best possible technical support to all account holders. This section provides account holders with a sequence of steps that will help quickly resolve most support issues.
Steps Toward Problem Resolution
Repeat the Problem in the Evolution Production Environment
Take steps to repeat the problem in production and document them in the event that Evolution support needs to be contacted.
Repeat the Problem in a Development Environment
Take steps to repeat the problem in a local development environment. If the problem can be repeated here, it eliminates the possibility that it is associated with the myEvolution environment.
Check Log Files
Follow the steps in the Logs chapter to help clearly identify the problem, and to provide clues to its resolution. It may be necessary to add logging to the application to help clearly define the problem.
Contact Support
Follow the steps in Chapter 28 to contact the Evolution support team. The support team will request a description of troubleshooting steps taken by account holders and may request a support fee if the problem is determined to be application specific.
Table of Contents
Although distributed debugging and automated server-side analysis software has made significant improvements in the past few years, there is still no better means of quickly debugging distributed applications as the thoughtful use of log files. Evolution supports account holders in the use of log files by providing access to all logs from within myEvolution, and by providing a means for account holders to message themselves as errors occur.
Evolution recommends that account holders e-mail errors to themselves so they are kept abreast of application problems immediately as they occur. A rapid response to application problems will simplify troubleshooting. If errors are found quickly, downstream problems are avoided and bad data is kept to a minimum. Evolution provides access to SMTP e-mail servers from within applications for all accounts. The SMTP server can be used to send error alerts.
Logs are only as good as the messages that they contain. Evolution account holders are encouraged to build their applications with extensive logging. This includes logging for system errors such as database connectivity issues, and business logic errors such as a problem in a custom shopping cart application. Ideally, each method has a logging message as it is entered and exited. These messages are helpful for tracking program flow. The following pseudo-code is an example of effective logging within a Java applicatoin:
private static int DEBUG = 255 ;
private static String CLASSNAME = "ExampleClass" ;
/**
* Sample method to illustrate effective logging
* Uses proprietary "Log" class
* Account holders should use the JDK's new java.util.logging package
*/
public void init() {
Log.debug(DEBUG, CLASSNAME,"init()", null, "Entering" );
//code...
List aList = null ;
try {
Log.debug(DEBUG, CLASSNAME,"init()", someUsefulID, "Retrieving list of profiles." );
aList = profileClient.getByStatus(listFactor,Constants.STATUS_SCORED);
} catch(Exception e) {
// This "error" call to the Log class could trigger an e-mail to be sent
Log.error(CLASSNAME, "init()",someUsefulID , "Error getting scored list - ExampleClass Failed: " , e );
}
//code...
Log.debug(DEBUG, CLASSNAME,"init()", null, "Leaving" );
}
Logs can be viewed at any time from within myEvolution. Read more about what logs are available and how to view them in the section called “Logs”.
This chapter lists out the procedure that account holders should use when contacting Evolution support. These instructions should be used in order to achieve the fastest possible resolution to a problem.
Whenever contacting Evolution support account holders should first follow the steps outlined in Chapter 26. If the problem persists, account holders should then e-mail <support@evolutionhosting.com> and provide the following information:
Information Required by Evolution Support
The primary domain name that the account was originally signed up with.
Full contact information including name, e-mail address, and telephone number.
A detailed description of the problem.
A description of initial steps taken by the account holder to resolve the problem.
Any error messages, screenshots, or files that help illustrate the support issue.
Table of Contents
Information contained in the Evolution Hosting public website, the myEvolution Hosting Control Center, certain computer programs authored or licensed by Evolution Hosting, and various associated whitepapers and manuals is Copyrighted by Evolution Hosting - 2002. This information may only be used in the evaluation or paid use of Evolution products and services - unauthorized use is strictly prohibited.
The Evolution Privacy Policy has been created and is available to all Evolution site visitors and account holders to communicate Evolution's firm commitment to privacy. The following section governs the information gathering and dissemination practices of Evolution Hostiing.
Evolution requires certain personal and confidential information from its account holders in order to provide web hosting services. This information may be used by Evolution for billing and account holder contact purposes on an as needed basis.
Information provided by Evolution site visitors or account holders will not be sold or given to third parties without explicit advance permission from the site visitor or account holder. Permission must take the form of written correspondence, either in paper or electronic form.
Cookies may be used in certain sections of the Evolution product suite to improve system usability. At no time will Evolution store any personal or financial information in cookies, nor will it use any information contained in cookies in a manner inconsistent with the Evolution privacy policy.
Evolution contains links to other sites and is not responsible for the privacy practices or content of those sites.
To answer any questions or concerns related to this policy or other policies of Evolution, Evolution support may be contacted through one of the following methods.
This section describes the terms that every Evolution account holder must agree to in order to begin receiving service. Evolution reserves the right to change these policies at any time without notice.
Eligible account holders include any person eighteen (18) years of age or older, or any lawfully formed legal entity.
Evolution will make a reasonable effort to insure quality service and adequate facilities, though a guarantee that access will be available at all times cannot be made. Evolution will publish any scheduled outages in advance within the myEvolution Hosting Control Center and/or make notification to account holders via e-mail. All accounts are dynamically configured via the myEvolution automated Java provisioning engine and are available for account holder use in a matter of minutes following signup. Maximum setup or upgrade time is guaranteed for shared accounts to be less than one (1) business day; dedicated accounts may require up to five (5) business days to create (or upgrade). Custom configurations (e.g., configurations not listed on the Evolution Price Quote page) may require additional setup time.
A component of the Evolution Hosting Monitoring Suite resides and executes in the Customer's application server. The customary locations are /app/*.jsp, /app/*.asp, or /app/*.php depending on the application server. Customer agrees to not to block or otherwise hinder the component. If this component is blocked or otherwise rendered unusable to the Evolution Hosting Monitoring Suite then any uptime commitment is reduced to 0% and no credit will be refunded for any outage.
Evolution bills each account holder's credit card on a monthly basis. Setup fees and prorated first month fees are billed instantly upon signup. Subsequent monthly charges are billed on the first of the month. Evolution may bill special one-time support or upgrade fees at any time during a given month, on a case-by-case basis. Account holder agrees to supply Evolution with updated credit card information prior to the card's expiration date.
Evolution reserves the right to change its prices at any time and may apply these changes to existing account holders. This is true for all prices, including, but not limited to, the on-line price quote page and prices listed in custom hosting quotations.
Evolution is not intended to be used for stress testing unless account holders have either purchased a dedicated hosting package, or have obtained special approval from Evolution staff.
Prior to contacting Evolution support, account holders are required to deploy and test applications in their local environment using identical product versions as those in their Evolution environment (e.g., JDK, application server, database server, etc.). This policy is designed to prevent account holders from contacting Evolution support with programming errors that are most quickly resolved on a local system with less variables than in a production environment.
In order to receive Evolution support, account holders must first follow the Preliminary Application Testing policy listed above. Evolution will promptly work to resolve any issue that is a result of the Evolution hosting environment. For issues submitted to Evolution support that can be reproduced locally outside of Evolution servers (e.g., application specific problems that are not related to the Evolution environment), a $130.00/hour support fee will be billed. For custom configuration requests, Evolution will notify account holders prior to beginning any work.
Account holders may close their account at any time from within myEvolution. Account closing functionality can be accessed in the Profile Section | Payment tab. Written notice via e-mail, fax, or postal mail is also acceptable. Account holders may not cancel by non-payment. Accounts may be cancelled by Evolution upon thirty (30) days notice. Accounts may be cancelled by Evolution immediately, without notice, and without refund, if account holder violates any of the provisions specified in the Use or Delinquency sections. Shared accounts will be refunded a portion of paid monthly charges on a prorated basis. Dedicated accounts will not have partial months refunded. Dedicated accounts who have made payments to Evolution for a period of less than thirteen (13) months may be required to pay a termination fee equal to the last month's recurring monthly fee. Account holders may incur a finance charge of 1.5% per month on all amounts past-due. If any account is referred to an attorney for collection, account holder agrees to reimburse Evolution for reasonable collection and legal fees.
Evolution may modify this agreement from time to time. Revisions will be published on the Evolution web site Policies page.
It is an account holder's responsibility to keep current payment information in myEvolution. Payment information may include a credit card and/or a billing address. Should this payment information become unusable due to expiration, lack of funds, change of address, or any other reason out of Evolution's control, Evolution will send an e-mail messsage to the primary and secondary contacts on file for the account informing them of the issue. Account holder has one (1) week to update account information after notification is sent. Failure to update account information within one (1) week's time will result in the account falling into delinquent status and triggering a $30 late payment fee. Accounts that fall into delinquent status more than two (2) times in a twelve (12) month period will be charged a $30.00 delinquency fee, prior to sending out notification, any time payment information is found not to be usable. Account holders who pay by check are required to ensure that Evolution receives payment no longer than fifteen (15) days from receipt of invoice. If Evolution has not received a check within fifteen (15) days, the account will fall into delinquent status until payment is received and incur a $30 late payment fee.
Account holder agrees to be responsible for all account use and to keep account login name and password confidential. If account holder's password is compromised or disclosed to a third party, account holder agrees to notify Evolution immediately.
If any provision(s) of this agreement is found to be invalid or unenforceable by a court of competent jurisdiction, the remaining provisions shall continue in full force and effect.
Account holder may use account(s) only for lawful purposes. Account holder shall not attempt to access, convert for personal gain, or interfere with the operation of any other account holder, computer, modem, router, server, or any other device connected to or accessible via the Internet that account holder does not have the authority to access. Account holder shall not send or cause to be sent any unsolicited commercial or non-commercial bulk e-mail (SPAM). Any violation of any provision in this paragraph may result in the immediate cancellation of account holder's account as provided above under Cancellation. In addition, account holders who violate the Use policy are subject to civil liability and criminal prosecution.
A.1 EAR's, WAR,s, and DefaultWebApps
This section of the FAQ covers J2EE deployment in EAR's, WAR's, SAR's, and DefaultWebApp's.
A.2 General Information
Q: Does each account in myEvolution get its own dedicated JVM?
A: In the Evolution Hosting evironment each account is given its own dedicated JVM in which to run. This improves performance, reliability, and security as compared to environments that offer a shared JVM.
A: Evolution does not directly offer domain name registration services, but it does take care of DNS configuration for each account. For more information read Chapter 7.
A: Evolution allows account holders to select the number of System Units allotted to their account. System units are originally selected at account signup, however, changes to the quantity of system units can be done at any time from within myEvolution.
A.3 Databases
A: Evolution Hosting offers a wide range of Database Servers, from the powerful open source database PostgreSQL, to the industry standard Oracle. To view specific databases currently supported by Evolution Hosting, visit the Price Quote page. Note that some databases require that a license be uploaded by account holders - this is indicated in the Price Quote page when those databases are selected.
Evolution Hosting highly recommends PostgreSQL, which is gaining popularity worldwide. Visit the PostgreSQL FAQ page for more information. Evolution Hosting can host databases not currently listed in the Price Quote page; inquire here.
Q: Which JDBC databases drivers does Evolution Hosting use?
A: myEvolution configures all database connection settings for accounts. Account holders access their database via datasources. No knowledge about the specific drivers is necessary for deployment.
For development and testing purposes Evolution Hosting provides driver information, here:
JDBC Drivers
PostgreSQL
Evolution Hosting uses the standard PostgreSQL JDBC Driver. More information can be found here.
MySQL
Evolution Hosting uses the standard MySQL Driver. More information can be found here.
MS SQL Server
Evolution Hosting uses the free MS SQL Server JDBC Driver provided by Microsoft. More information can be found here here.
Oracle
Evolution Hosting uses the Oracle JDBC driver. More inforamtion is available here.
A.4 E-Mail
Q: I sent an e-mail to an Evolution-hosted e-mail account and received an automated reply saying: "The specified account has surpassed its quota...". What does this mean?
A: This message means that the account has surpassed its allocated disk space and needs to delete messages or increase its quota. More information on increasing mailbox quotas is available in the Mail Section.
Q: When I try to delete e-mail messages they are not completely removed. How do I permanently delete e-mail?
A: Since the IMAP e-mail protocol stores e-mail messages on the server, not on the e-mail client on a local PC, deletion is a two-step process.
Steps To Delete E-Mail
Mark Messages for Deletion
In Microsoft Outlook 2000 and Netscape Communicator 4.x this is accomplished by highlighting the one or more messeges to be deleted and pressing the Delete key.
Purge Deleted Messages
In Microsoft Outlook 2000 this is accomplished by accessing the menu option Edit | Purge Deleted Messages.
In Netscape Communicator 4.x this is accomplished by accessing the menu option File | Compact Folder.
myEvolution is a data-driven application that utilizes many properties in its operation. myEvolution properties can be divided into two primary categories: JVM Properties, which are set into an account's JVM at runtime; and Account Properties, which are used by myEvolution in configuring an account's servers. Table 8 summarizes these properties and contains links to their definitions.
Table 8. myEvolution Properties
Database Properties
- ejip.datasource.name
This property allows account holders to set the name of their DataSource. More information can be found in the section called “Datasources”.
DNS Properties
- ejip.domain.parking.arecord
A comma delimited list of name-value pairs. An example is:
production=192.168.10.14,staging=200.100.50.25
Arecord entries are used to explicitly point certain domain names directly to a physical IP address. This may be useful, for example, if an account has a test or staging server that is located in a location outside of the Evolution data center.
Each entry creates appropriate entries in the DNS and Apache configuration files. If the example in ejip.domain.parking.zones is used as a basis, the above arecord entries would result in the following list of DNS entries:
Configured to Point to Customer Application Server
production.companyx.com IN A 192.168.10.14
production.company-y.com IN A 192.168.10.14
production.businessunitz.com IN A 192.168.10.14
staging.companyx.com IN A 200.100.50.25
staging.company-y.com IN A 200.100.50.25
staging.businessunitz.com IN A 200.100.50.25
Note that the second part of the domain name list above, the part that contains the IP address, is the physical address that the domain name will be configured to point to.
- ejip.domain.parking.cname
A comma delimited list of name-value pairs. An example is:
production=production.companyx-offsite.com,staging=staging.companyx-offsite.com
Similar to the ejip.domain.parking.arecord property, cname entries are useful when an account has a test or staging server that is located in a location outside of the Evolution data center.
Each entry creates appropriate entries in the DNS and Apache configuration files. If the example in ejip.domain.parking.zones is used as a basis, the above cname entries would result in the following list of DNS entries:
Configured to Point to Customer Application Server
production.companyx.com IN CNAME production.companyx-offsite.com
production.company-y.com IN CNAME production.companyx-offsite.com
production.businessunitz.com IN CNAME production.companyx-offsite.com
staging.companyx.com IN CNAME production.companyx-offsite.com
staging.company-y.com IN CNAME production.companyx-offsite.com
staging.businessunitz.com IN CNAME production.companyx-offsite.com
- ejip.domain.parking.externaldns
If this property is set to
true
for an account, then myEvolution will not use the local DNS servers. The default value is
false
- ejip.domain.parking.subdomains
A comma-delimited list of single subdomains (e.g. one word). An example is
www,guest,other
Each entry creates appropriate entries in the DNS and Apache configuration files. If the primary_domain_g is known to be companyx.com, the resulting list of configured domain names that would point to the account's application server is:
Configured to Point to Customer Application Server
www.companyx.com
guest.companyx.com
other.companyx.com
Note that the manipulation of subdomains has no effect on e-mail routing.
- ejip.domain.parking.zones
In myEvolution, zones are entered as a comma-delimited list of single domains. An example is:
companyx.com, company-y.com, businessunitz.com
Each entry will automatically update or create appropriate entries in the DNS system and web server configuration files. The end result is that all of the domains listed will point to the same customer application server:
Configured to Point to Customer Application Server
http://companyx.com
http://www.companyx.com
http://company-y.com
http://www.company-y.com
http://businetunitz.com
http://www.businessunitz.com
If this example list of Zones is combined with the example list of subdomains from the ejip.domain.parking.subdomains section, the list becomes large.
Configured to Point to Customer Application Server
http://companyx.com
http://www.companyx.com
http://guest.companyx.com
http://other.companyx.com
http://company-y.com
http://www.company-y.com
http://guest.company-y.com
http://other.company-y.com
http://businetunitz.com
http://www.businessunitz.com
http://guest.businessunitz.com
http://other.businessunitz.com
E-mail is also updated to route all mail sent to company-y.com and businessunitz.com. to companyx.com (the primary domain name for the account). This feature is very important to customers changing domain names or trading-as multiple domain names.
E-Mail Properties
- ejip.server.mail.mx
The primary mail server for an account and all additional ejip.domain.parking.zones . The default value is mail.evolutionhosting.com.
- ejip.server.mail.mx2
The secondary mail server for an account and all additional ejip.domain.parking.zones The default value is mail2.evolutionhosting.com.
- ejip.smtp
The address of the SMTP server that the account may use for sending e-mail. This property is most often used with JavaMail.
File and Directory Properties
- app.data
A directory in every myEvolution account in which miscellaneous files may be kept. It can be used as a "temp" directory or for any other purpose account holders may wish.
One use for the data directory is as a working directory for an application that needs to read and write files. This directory can be located programatically from within an account's application as described in Chapter 9.
See Also app.home.
- app.home
The root directory on a server in which an account's configuration files and content are stored. app.home can be located programatically from within an account's application as described in Chapter 9.
See Also app.data.
A
- account holder
A customer or individual who has access to manage a myEvolution hosting account.
See Also site visitor.
- Account Property
Any account configuration property that is stored in the myEvolution database. Many of these properties are modifiable from within myEvolution. To prevent accidental updates of key attributes, some properties are only available to account holders with special permission.
See Also JVM Property (Evolution).
- Ant
A one-hundred-percent Java based build tool that is used to compile, assemble, and run applications. Instead of the traditional model where build envionrments are extended with shell-based commands, Ant is extended using Java classes. Instead of writing shell commands, the configuration files are XML-based, calling out a target tree where various tasks get executed. Each task is run by an object that implements a particular Task interface. Ant is open-source and is an offering of the Apache Group. Visit Ant's official web site for more information.
See Also Java.
- Application Programming Interface (API)
A set of routines, protocols, and tools for building software applications. A good API makes it easier to develop a program by providing all the building blocks. A programmer puts the blocks together.
Although APIs are designed for programmers, they are ultimately good for users because they guarantee that all programs using a common API will have similar interfaces. This makes it easier for users to learn new programs.
An example API in the Java programming language is JavaMail.
See Also Java.
- application deployment
The delivery of a software system into a production environment.
- application server
A J2EE server forms the core of an account. The application server encapsulates the Java code that runs in an Evolution account. Application servers are provided by third-party software vendors and are integrated into the myEvolution hosting control center.
- auxillary domain
The auxillary domain name (e.g., www.companyx.com.evohst.org ) is one of the domain names that myEvolution automatically sets up as part of the initial signup process. It is simply the primary domain with .evohst.org appended to the end. The auxillary domain is intended to be used for initial testing and configuration. This is especially important for sites that have an existing website elsewhere. In this way, the Internet's DNS servers do not need to be pointed to the Evolution site before it is completely set up.
See Also Domain Name, Domain Name System (DNS), primary domain, registrar.
B
- best practice
Used to refer to preferred techniques of working in the Evolution Hosting environment or to refer to techniques explicitly outlined by Sun Microsystems® and the J2EE Specification.
See Also J2EE.
C
- ClassCastExceptions
A type of Java Exception often caused when Class files are included in more than one place in a Java application.
See Also Classloader, Java Exception, Java Class File.
- Classloader
A part of the Java Virtual Machine that handles the loading and accessing of Java Classes by Java applications. There may be one or more Classloaders for a given JVM and Java application. Classloaders allow the segmentation of class sets to appropriate portions of an application for efficiency and security.
See Also Java Class File.
- Concurrent Versions System (CVS)
The dominant open-source network-transparent version control system. CVS is offered by Evolution as a tool to manage application updates. Visit the the CVS website for more information.
- connection pool
A group of database connections allowing an application to retrieve and save information in an efficient manner. The pool is managed by the application server, which loans connections to the application as needed. Access to the connection pool is achieved through datasources.
See Also database connection, System Unit, DataSource.
- container - EJB
An distributed component runtime environment that implements the EJB component contract detailed by the J2EE architecture. This contract specifies a runtime environment for enterprise beans that includes security, concurrency, life cycle management, transaction, deployment, naming, and other services.
A full explanation on EJB containers can be found at Sun's Java site under: EJB
See Also Enterprise JavaBean™ (EJB).
- content
Web pages, Java classes, JSP's, Servlets, EJB's, Images, or any other component that comprises an application.
D
- data definition language (DDL)
A language used by a database management system which allows users to define the database, specifying data types, structures and constraints on the data. Examples are the CREATE TABLE, CREATE INDEX, ALTER, and DROP statements. Note: DDL statements will implicitly commit any outstanding transaction.
See Also database management system (DBMS), data definition language (DDL), schema, Structured Query Language (SQL).
- data definition language (DDL)
The data manipulation language for all databases offered by Evolution Hosting is SQL. These commands manipulate data within existing database objects. Examples are the SELECT, UPDATE, INSERT, DELETE statements.
See Also database management system (DBMS), data definition language (DDL), schema, Structured Query Language (SQL).
- database
A database is an indexed collection of information. The index imposes an order on the information and also provides access to the information in the database. The information in a database can be retrieved, modified, or deleted using a query language. Some common database systems are Oracle, DB/2, Sybase, Informix, etc.
See Also database management system (DBMS), schema, Structured Query Language (SQL), tablespace.
- database management system (DBMS)
Software designed to manipulate the information in a database. It can add, delete, sort, display selected information, search for specific information, and perform many other tasks of a database.
See Also database, schema, Structured Query Language (SQL), tablespace.
- DataSource
The preferred means of getting a connection to persistent storage in J2EE applications. Datasources are accessed via JNDI and provide access to database connections.
See Also Java Naming and Directory Interface™ (JNDI), database connection, connection pool.
- database connection
A channel of communication opened to a persistent store. In Evolution Hosting this is most often a channel from the Java application server to a relational database.
See Also connection pool.
- database server
A persistent storage medium with methods to create, read, update, and delete records while maintaining data integrity. The database server is accessed from within an application via data sources.
See Also DataSource.
- database space
The amount of room available to an Evolution Hosting account's database server to store persistent data. Database space is measured in Megabytes and can be increased or decreased by changing the number of System Units assigned to an account in the myEvolution hosting control center.
See Also database server, System Unit.
- dedicated hosting
When a single organization's web site or web sites run on physicaal hardware that is exclusively available to them. This hardware is not shared with other organizations and therefore can provide increased security, scalability, and other features not available in a shared hosting situation.
See Also shared hosting.
- defacto standard (proprietary standard)
A standard which has been endorsed by industry or government, but not officially approved by an accredited standards body such as ISO.
- DefaultWebApp
A J2EE term referring to a special web-application that is served up by the JSP/Servlet engine unless another specific web-app is referenced. The default web-app usually also has the convenient trait of being "exploded" or extracted. This means that the individual files that make up the default web-app are not archived in one large file, but are accessible individually.
See Also JSP/Servlet Engine, Web Archive (WAR).
- direct upload
The process of pushing content straight to an account's production environment, bypassing the publish process. Direct upload utilizes either the FTP or SCP protocols.
See Also production environment, publish.
- disk space
The amount of room available to an Evolution Hosting account to store content. Disk space is measured in Megabytes and can be increased or decreased by changing the number of System Units assigned to an account in the myEvolution hosting control center.
See Also content, System Unit.
- Domain Name
An address that is used to lookup and access a web site or resource on the Internet. An example domain name is www.companyx.com. Domain names must be registered with a registrar prior to use.
See Also primary domain, auxillary domain, registrar.
- Domain Name System (DNS)
The Domain Name System (DNS) is the method by which Internet addresses in mnemonic form such as www.companyx.com are converted into the equivalent numeric IP address such as 134.220.4.1 .
See Also Domain Name, primary domain, auxillary domain, registrar.
E
- Enterprise Archive (EAR)
A file with an .ear extension that contains Web and EJB components, deployment descriptors, and archive files.
See Also Enterprise JavaBean™ (EJB), Web Archive (WAR).
- Enterprise JavaBean™ (EJB)
A component architecture for the development and deployment of object-oriented, distributed, enterprise-level applications. Applications written using the Enterprise JavaBean's architecture are scalable, transactional, and secure.
A full explanation on EJB can be found at Sun's Java site under: EJB
See Also J2EE.
- Enterprise Java Internet Provider (EJIP)
An alias or short-name used in Evolution Java package names and domain names.
H
- HyperText Markup Language (HTML)
A file format, based on SGML, for hypertext documents on the Internet. It allows for the embedding of images, sounds, video streams, form fields and simple text formatting. References to other objects are embedded using URLs.
See Also HTML Frames.
- HTML Frames
Frames are used in HTML to allow an author to divide a browser window into multiple (rectangular) regions. Multiple documents can be displayed in a single window, each within its own frame. Graphical browsers allow these frames to be scrolled independently of each other, and links can update the document displayed in one frame without affecting the others.
See Also HyperText Markup Language (HTML).
- HyperText Transfer Protocol (HTTP)
The Internet protocol, based on TCP/IP, used to fetch hypertext objects from remote hosts. See also TCP/IP.
See Also HTTPS, Transmission Control Protocol (TCP/IP).
- HTTPS
HyperText Transfer Protocol layered over the SSL protocol.
See Also HyperText Transfer Protocol (HTTP), Secure Sockets Layer (SSL).
I
- Internet Message Access Protocol (IMAP)
A protocol for retrieving e-mail messages. The latest version, IMAP4, is similar to POP3 but supports some additional features. For example, with IMAP4, users can search through e-mail messages for keywords while the messages are still on the mail server. Users can then choose which messages to download to their local machine.
IMAP permits a "client" e-mail program to access remote message stores as if they were local. For example, e-mail stored on an IMAP server can be manipulated from a desktop computer at home, a workstation at the office, and a notebook computer while traveling, without the need to transfer messages or files back and forth between these computers.
IMAP's ability to access messages (both new and saved) from more than one computer has become extremely important as reliance on electronic messaging and the use of multiple computers increase, but this functionality cannot be taken for granted: the widely used Post Office Protocol (POP) works best when one has only a single computer, since it was designed to support "offline" message access, wherein messages are downloaded and then deleted from the mail server. This mode of access is not compatible with access from multiple computers since it tends to sprinkle messages across all of the computers used for mail access. Thus, unless all of those machines share a common file system, the offline mode of access that POP was designed to support effectively ties the user to one computer for message storage and manipulation.
IMAP was developed at Stanford University in 1986. For more information on IMAP, visit IMAP.org
See Also Post Office Protocol (POP), Simple Mail Transfer Protocol (SMTP).
- Internet Protocol (IP)
The basic protocol of the Internet. It enables the unreliable delivery of individual packets from one host to another. It makes no guarantees about whether or not the packet will be delivered, how long it will take, or if multiple packets will arrive in the order they were sent. Protocols built on top of this add the notions of connection and reliability.
See Also Transmission Control Protocol (TCP/IP).
- Internet Service Provider (ISP)
A company that provides access to the Internet. For a monthly fee, these companies provide a software package, username, password and access method (e.g., dial-up telephone number. Equipped with a modem, users can then log on to the Internet and browse the World Wide Web and USENET, and send and receive e-mail.
In addition to serving individuals, ISP's also serve large companies, providing a direct connection from the company's networks to the Internet. ISP's themselves are connected to one another through Network Access Points (NAP's).
J
- J2EE
The Java 2 Enterprise Edition (J2EE) is an environment for developing and deploying enterprise applications. The J2EE platform consists of a set of services, application programming interfaces (API's), and protocols that provide the functionality for developing multitiered, web-based applications. A full explanation on J2EE can be found at Sun's Java site under: J2EE
- James Gosling
Considered the father of the Java programming language, James Gosling was the main developer/inventor of Java at Sun Microsystems.
See Also Java Community Process (JCP).
- Java Archive file (.jar)
A file format used for aggregating many files into one. A .jar file is analogous to a .zip file and can be opened in WinZip®.
A .jar file can be created by typing jar- cvf jarName directoryName where jarName is the name of the file that is to be createed and directoryName is the base directory of directory tree to be jarred.
See Also Java Archive file format (JAR).
- Java Archive file format (JAR)
A platform-independent file format that aggregates many files into one. For example, multiple applets written in the Java programming language, and their requisite components (e.g., .class files, images, sounds and other resource files) can be bundled in a JAR file and subsequently downloaded to a browser in a single HTTP transaction. This format also supports file compression and digital signatures.
See Also Java Archive file (.jar).
- Java
The object oriented programming language developed by Sun Microsystems that is distinguished by its wide acceptance in Internet applications and its collaborative development approach via the Java Community Process.
See Also JavaScript, J2EE, Java Web Services, Java Community Process (JCP).
- JavaMail
A Java API for sending and receiving e-mail.
See Also Java, Application Programming Interface (API).
- JavaScript
A Web scripting language that is used in both browsers and Web servers. Like all scripting languages, it is used primarily to tie other components together or to accept user input.
JavaScript is not Java, nor is it maintained by Sun or the Java Community process. JavaScript was originally developed by Netscape as an entirely separate language than the the Java language that has gained widespread acceptance in Web development.
See Also Java.
- Java Class File
A type that defines the implementation of a particular kind of object. A class definition defines instance and class variables and methods, as well as specifying the interfaces the class implements and the immediate superclass of the class. If the superclass is not explicitly specified, the superclass will implicitly be Object.
See Also Classloader.
- Java Community Process (JCP)
An open organization of developers and licensees whose charter is to develop and revise Java technology specifications, reference implementations and technology compatability kits. The JCP homepage is located here .
See Also Java.
- Java Exception
An event during program execution that prevents the program from continuing normally; generally, an error. The Java programming language supports exceptions with the try, catch, and throw keywords.
See Also ClassCastExceptions.
- Java Database Connectivity (JDBC)
An industry standard for database-independent connectivity between the Java platform and a wide range of databases. JDBC provides a call-level API for SQL-based database access.
See Also Java, JDBC Driver, Structured Query Language (SQL).
- Java Management Extensions (JMX)
A universal, open technology for management and monitoring ready to be deployed across all industries, wherever management and/or monitoring is needed. By design, this new standard is suitable for adapting legacy systems, implementing new management and monitoring solutions and plugging into those of the future.
For more information, see Sun Microsystem's® Java Management Extensions (JMX) site.
See Also J2EE, Managed Bean (MBean).
- JDBC Driver
Software that resides between a Java application and a database that allows the two to communicate. JDBC Drivers are specific to a particular database vendor.
See Also Java Database Connectivity (JDBC).
- Java Messaging Service™ (JMS)
An API that enables the development of portable, message based applications in the Java programming language. JMS will work in concert with other technologies to provide reliable, asynchronous communication between components in a distributed computing environment.
A full explanation on JNDI can be found at Sun's Java site under: JMS
See Also J2EE.
- Java Naming and Directory Interface™ (JNDI)
A standard extension to the Java platform, providing Java technology-enabled applications with a unified interface to multiple naming and directory services in the enterprise. As part of the Java Enterprise API set, JNDI enables seamless connectivity to heterogeneous enterprise naming and directory services.
A full explanation on JNDI can be found at Sun's Java site under: JNDI
See Also J2EE.
- JavaServer Pages™ (JSP)
An extensible Web technology that uses template data, custom elements, scripting languages, and server-side Java objects to return dynamic content to a client. Typically the template data is HTML or XML elements, and in many cases the client is a Web browser. The JSP specification is defined and evolved through the Java Community Process and can be found here: JSP Specification.
See Also Java Community Process (JCP), Servlet™, J2EE.
- JSP/Servlet Engine
A software program that serves Java specific web content to fill client requests.The Servlet and JSP specifications are defined and evolved through the Java Community Process and can be found here: Servlet Specification or JSP Specification
See Also Java Community Process (JCP), J2EE, container - EJB.
- JVM Property (Evolution)
A property set into an account's JVM by myEvolution at runtime. These properties are accessible from the account's application.
See Also Java Virtual Machine (JVM), Account Property, runtime.
- Java Virtual Machine (JVM)
A software 'execution engine' that safely and compatibly executes the byte codes in Java clsss files on a microprosessor (whether in a computer or another electronig device).
See Also Java.
- Java Web Services
Java Web Services refers to the set of specifications and technologies that make up the Java implementation of Web Services. More information on JWS can be found here.
See Also J2EE, web services.
M
- Mail Exchange Record (MX)
An entry in a domain name database that identifies the mail server that is responsible for handling e-mails for that domain name.
When more than one MX record is entered for any single domain name that is using more than one e-mail server, the MX record can be prioritized with a preference number that indicates the order in which the mail servers should be used. This enables the use of primary and backup mail servers.
See Also Domain Name System (DNS), Domain Name.
- Managed Bean (MBean)
A Java object that implements a specific interface and conforms to certain design patterns outlined in the Sun Java Management Extensions (JMX) Specification, which is designed to standardize the management and monitoring of software and related systems.
The above mentioned object requirements formalize the representation of a resource's management interface in the MBean. The management interface of a resource is the set of all necessary information and controls that a management application needs to operate on the resource.
For more information, see Sun Microsystem's® Java Management Extensions (JMX) site.
See Also J2EE, Java Management Extensions (JMX).
P
- Post Office Protocol (POP)
A protocol used to retrieve e-mail from a mail server. Most e-mail applications (sometimes called an e-mail client) use the POP protocol, although some can use the newer IMAP (Internet Message Access Protocol).
There are two versions of POP. The first, called POP2, became a standard in the mid-80's and requires SMTP to send messages. The newer version, POP3, can be used with or without SMTP.
See Also Internet Message Access Protocol (IMAP), Simple Mail Transfer Protocol (SMTP).
- primary domain
The domain name (e.g., www.companyx.com ) is the domain name that is entered in the first step of the account signup process. This domain is automatically set up in the Evolution DNS system at signup and is ready for direct access as soon as the account holder completes the DNS Server Name Change with their registrar.
See Also Domain Name, Domain Name System (DNS), auxillary domain, registrar.
- production server
A single unit of hardware or software, referred to singly or collectively, that hosts a live website or application. Types of production servers include: web, application, and database servers. Note that a single physical (hardware) web server can house multiple (software) web server instances.
See Also production environment, production tier.
- production environment
The term used to refer to the collective group of production servers in the Evolution data center that host an account's website or application.
See Also production server, production tier.
- production tier
One or more production servers that carry out a major subset of an application's work. The data tier, for instance, is responsible for persistent storage of information. Other tiers include the web tier, which serves web pages; and the application tier, which runs server side components.
See Also production server, production environment.
- publish
The process of pushing content to an account's production environment from myEvolution.
See Also production environment, direct upload.
R
- Random Access Memory (RAM)
In this context, RAM refers to the memory available to an account's Java Virtual Machine (JVM). JVM RAM is utilized by all Java programs in the account, including the JSP/Servlet Engine and the EJB server.
RAM can be dynamically added or removed from an account by increasing or decreasing the number of System Units from inside myEvolution.
See Also Java Virtual Machine (JVM), System Unit.
- registrar
An organization that registers and keeps track of domain names. Customers use a registrar to reserve domain names and change DNS settings.
See Also Domain Name, Domain Name System (DNS), primary domain, auxillary domain.
- runtime
Occurring while a program is executing. For example, a runtime error is an error that occurs during program execution and a runtime library is a library of routines that are bound to the program during execution. In contrast, compile-time refers to events that occur while a program is being compiled.
See Also Java Virtual Machine (JVM).
S
- schema
The data definitions that comprise a database created with SQL data definition statements (tables, views, indexes, etc).
See Also database, database management system (DBMS), Structured Query Language (SQL), tablespace.
- Service Archive (SAR)
A JBoss definition of a service archive (.sar) file. An archive contains both a service.xml file and the supporting JAR files for the service bundled into an archive similar to an EAR. SAR's are generally 1-n MBeans and can be deployed in the EAR's, WAR's, Etc. section of myEvolution for JBoss accounts.
See Also Java Archive file format (JAR), Managed Bean (MBean), Service Definition file (service.xml), Enterprise Archive (EAR).
- Service Definition file (service.xml)
A service definition file is used specifically in the JBoss application server. Service.xml files define custom MBeans for the JBoss server and can be deployed in the EAR's, WAR's, Etc. section of myEvolution.
See Also Service Archive (SAR), Managed Bean (MBean).
- Servlet™
A Java program that extends the functionality of a Web server, generating dynamic content and interacting with Web clients using a request-response paradigm. The Servlet specification is defined and evolved through the Java Community Process and can be found here: Servlet Specification.
See Also Java Community Process (JCP), JavaServer Pages™ (JSP), J2EE.
- shared hosting
When multiple web sites run on a single physical server, thus allowing multiple organizations to share resources.
See Also dedicated hosting.
- Simple Mail Transfer Protocol (SMTP)
A protocol for sending e-mail messages between servers. Most e-mail systems that send mail over the Internet use SMTP to send messages from one server to another; the messages can then be retrieved with an e-mail client using either POP or IMAP. In addition, SMTP is generally used to send messages from a mail client to a mail server. This is why e-mail clients require that either POP or IMAP server information and the SMTP server information be input when being set up.
See Also Internet Message Access Protocol (IMAP), Post Office Protocol (POP).
- Secure Sockets Layer (SSL)
The Secure Sockets Layer is a commonly-used protocol for managing the security of a message transmission on the Internet.
SSL uses a program layer located between the Internet's Hypertext Transfer Protocol (HTTP) and Transport Control Protocol (TCP) layers. SSL is included as part of both the Microsoft® and Netscaape® browsers and most Web server products. Developed by Netscape, SSL also gained the support of Microsoft and other Internet client/server developers and became the de facto standard. The "sockets" part of the term refers to the sockets method of passing data back and forth between a client and a server program in a network or between program layers in the same computer. SSL uses the public-and-private key encryption system from RSA®, which also includes the use of a digital certificate.
SSL is an integral part of most Web browsers (clients) and Web servers. If a Web site is on a server that supports SSL, SSL can be enabled and specific Web pages can be identified as requiring SSL access.
See Also HyperText Transfer Protocol (HTTP), HTTPS.
- Structured Query Language (SQL)
Structured Query Language (SQL), pronounced "sequel", is a language that provides an interface to relational database systems. It was developed by IBM in the 1970s for use in System R. SQL is a de facto standard, as well as an ISO and ANSI standard.
See Also database management system (DBMS), data definition language (DDL), defacto standard (proprietary standard), data definition language (DDL).
- site visitor
Any person who accesses an Evolution Hosted site. This does not refer to account holders or administrators accessing a site through myEvolution, but rather those that access a site from a user's perspective.
See Also account holder.
- Subdomain
A DNS term that refers to a domain name that is a subset of a zone. Examples of subdomains may include www, staging, or test When combined with a full zone, the above subdomains would make the following three-part domain names: www.companyx.com, staging.companyx.com, and test.companyx.com
See Also Domain Name System (DNS), Domain Name, Zone, ejip.domain.parking.subdomains.
- System Unit
A term created by Evolution to denote a logical grouping of resources that is used to increase or decrease capacity in an Evolution Hosting account. System Units allow account holders to instantly provision resources to their production environments.
A System Unit is an aggregate of the following resources:
RAM available to the J2EE application's JVM when it is running.
Disk space available for the account's site content and data files.
Database space available for application data that is stored in the account's database instance.
Database connections utilzed by the application server.
To view System Unit quantities and pricing, visit the Price Quote page and look under the "Capacity" drop-down box.
See Also Random Access Memory (RAM), disk space, database space, database connection, Java Virtual Machine (JVM).
T
- tablespace
Databases have one or more tablespaces, each made of one or more data files. Tables and indexes are created within a tablespace.
See Also database, database management system (DBMS), schema, Structured Query Language (SQL).
- Transmission Control Protocol (TCP/IP)
Transmission Control Protocol based on IP. This is an Internet protocol that provides for the reliable delivery of streams of data from one host to another.
See Also Internet Protocol (IP), HTTPS.
U
- Uniform Resource Locator (URL)
A URL is the address of a resource, or file, available on the Internet. A URL contains information about a resource, including the protocol of the resource (e.g. http:// or ftp:// ), the domain name of the resource, and the hierarchical name for a file (address). For example, a page on the Internet may be at the URL http://www.companyx.com/define/u/url.jsp . The beginning part, http:// provides the protocol, the next part www.companyx.com is the domain, the main domain is companyx.com, while www is a pointer to a computer or a resource. The rest, /define/u/url.jsp is the pointer to the specific file on that server. The URL could point to other things, CGI programs, Java programs, graphic files, or other resources available on the Internet.
Note that in the Evolution hosting environment, text following a primary domain name is Case Sensitive. This means that, for example, http://www.companyx.com/dEFIne/u/url.jsp is not substituitable for http://www.companyx.com/define/u/url.jsp.
See Also Domain Name System (DNS), primary domain, auxillary domain, registrar.
W
- Web Archive (WAR)
A file with a .war extension that contains the components that make up a web application.
See Also Enterprise Archive (EAR).
- WHOIS Query
The acronym that refers to a request for information about a specific domain name. For instance, if a person wanted to find out who owns the domain www.companyx.com, they could execute a WHOIS query on companyx.com (only the last two parts of the name are used). A WHOIS query shows business contact information, technical contact information, expiration information, and more. A WHOIS query can be performed on the command line of some computers (e.g., whois companyx.com) , otherwise it can be performed at certain websites. Here are a few sites that currently offer the free service: BulkRegister®, Thawte®, and Varisign®.
See Also Uniform Resource Locator (URL), registrar.
- web server
A software program that serves images and static content, such as html pages, to fill client requests. In the Evolution environment, web servers are configured to work in conjunction with JSP/Servlet Engines in order to optimize performance. Images, for instance, are handled by the web server rather than by the JSP/Servlet Engine, thereby offloading work from the JVM.
See Also JSP/Servlet Engine.
- web services
Web services refers to the set of specifications and technologies that make up the new service-based software paradigm that is sweeping the Internet. A majority of the specificatoins for web services can be viewed here.
See Also Java Web Services.
Z
- Zone
A DNS term that refers to a two-part domain name such as companyx.com or businessunitz.com. An example of a domain name that is not a zone is www.companyx.com, due to the inclusion of the www prefix.
See Also Domain Name System (DNS), Domain Name, Subdomain, ejip.domain.parking.zones.