 | Level: Introductory Anitha Krishnasamy (kanitha@in.ibm.com), Software Engineer, IBM
Mansoor Ahmed (manahmed@in.ibm.com), Software Engineer, IBM India Software Lab Services and Solutions
21 Feb 2007 IBM® WebSphere® Application Server Community Edition takes much of the complexity out of creating key stores, security realms, and database pools by letting you perform these advanced administrative tasks with the administrative console, rather than requiring you to manually enter commands.
Introduction
IBM WebSphere Application Server Community Edition (hereafter called Community Edition) is an open source Java™ Platform, Enterprise Edition (Java EE) application server, based on Apache Geronimo. Community Edition has a very small footprint and is available free of charge.
Community Edition's JSR-168-based administrative console is essentially a Web application, deployed in Community Edition, that provides a user friendly Web-based interface for administering many aspects of the local or remote server. If you are new to Community Edition and the administrative console, the article Using the Web console in WebSphere Application Server Community Edition will give you a good head start with many of the common administrative tasks that can be performed with the console. With that basic foundation, this two-part article will help you use the Community Edition console to perform advanced administrative tasks:
Part 1 discusses how to:
- Work with an IBM DB2® Express-C database.
- Create a DB2 Express-C database pool.
- Specify the database pool in the deployment descriptors.
- Create security realms.
- Create key stores.
Part 2 looks at:
- Thread pools statistics.
- Redeploying an application from the console.
- Apache mod_jk configuration.
- Creating and installing Geronimo plug-ins.
Working with a DB2 Express-C database
The article Using the Web console in WebSphere Application Server Community Edition explained how to work with the IBM Cloudscape™ database embedded in Community Edition and how to create a database pool. Here, we will look at how to work with and create a database pool for DB2 Express-C.
DB2 Express-C is a leading edge hybrid data server capable of supporting both relational and pure XML storage. DB2 Express-C is a no-charge data server for use in the development and deployment of applications created using XML, C/C++, Java, .NET®, PHP, and more. It can be run on up to two dual-core CPU servers, with up to 4 GB of memory, any storage system setup, and no database size restrictions -- or any other types of artificial restrictions.
Both DB2 Express-C and Cloudscape are high value data servers for production and development use and available free of cost. Cloudscape is well suited for applications that require a completely invisible, embedded data server for Java applications. DB2 Express-C can be used when applications require high performance and a highly scalable data server with advanced features, such as enhanced scalability, manageability, and SQL support. DB2 Express-C is ideal for all data server applications including those created using PHP, .NET, C/C++, Java and other non-Java programming languages.
You can easily interact with DB2 Express-C databases using the command-based user interface tool, called the DB2 Express-C Command Editor (Figure 1), which consists of two panes:
- A Command pane in which to enter commands.
- A Results pane to view the results of command execution.
To open the DB2 Express-C Command Editor, navigate to Select Programs => IBM DB2 => Command Line tools => Command Editor.
Figure 1. DB2 Express-C Command Editor
Create a database and table
Here is a short exercise to help you get a little hands-on experience with DB2 Express-C. In this exercise, you will create a database and table for DB2 Express-C using the Command Editor. Later you will see how to create a database pool from the admin console for the sample database you will create now:
To create a new database called "student", enter this command in the Command pane and click the Execute (green arrow) button:
Create db student
Upon successful creation, this message will display in the Results pane:
The CREATE DATABASE command completed successfully
To create the JDBC connection to the database so that we can work with it, execute this command:
Connect to student
To create a table called "student", enter this command in the Command pane and click on the Execute button:
Create table student(rollno VARCHAR(30), name VARCHAR(50), dob VARCHAR(40))
If you get this error message:
SQL1032N No start database manager command was issued
then your database manager is not started. Start it by executing this command in the Command Editor:
db2start
Create a DB2 Express-C database pool
A database pool is a data structure that contains information about a specific database that the JDBC driver needs in order to connect to it. Community Edition provides database connection pools with which you can bind a certain database to a JNDI and access it from your applications.
The article Using the Web console in WebSphere Application Server Community Edition elaborates on how to create a database pool for the Cloudscape database embedded in Community Edition. Here, you can create the database pool for DB2 Express-C. The same method can be followed for any other databases that are supported by Community Edition.
To create a database pool for the DB2 Express-C database:
From the Console Navigation pane, select Database Pools under the Services category. The Database Pools portlet displays (Figure 2).
Figure 2. Database Pools portlet
Select Using the Geronimo database pool wizard. In the Database pool creation wizard (Figure 3), enter or select the following values:
- Pool Name:
studentpool
- Pool Type: select DB2 XA to use the database available in DB2 Express C
- Driver JAR: select both com.ibm.db2/db2jcc/8.2/jar and com.ibm.db2/db2jcc_license_cu/8.2/jar
- Database Name:
student (this is the database we created before)
- User and Password: enter any valid values
- Port Number:
50000 is the default value for DB2 Express-C. If you changed this during installation, specify the actual port number.
Leave the remaining fields as they are.
Click Deploy to deploy this pool to the server. Click Show Plan to see the deployment plan (covered next) for the pool.
Figure 3. Database pool creation
Deployment plan for the database pool
Community Edition uses a Geronimo-specific deployment descriptor, hereafter referred as the Geronimo deployment plan. This Geronimo deployment plan format looks like a Java EE deployment descriptor in Java EE 1.4 but differs in that it is specific to the application server. It is an XML file based on XML schemas, that holds configuration information related to the application module or service.
As an alternative to using the database pool creation portlet on the console, you can also create a new database pool for any database by deploying the corresponding deployment plan, which would be an .xml file. However, you need to manually create the plan with the right XML schema, which is specified in the <WASCE_HOME>\schema directory. This step is made easy with the console by just selecting the values in a few fields, above.
Listing 2 shows the deployment plan for the database pool created in the previous section. This is the plan that displays when you select Show Plan (Figure 3).
Listing 1. Database pool deployment plan
<?xml version="1.0" encoding="UTF-8"?>
<connector xmlns="http://geronimo.apache.org/xml/ns/j2ee/connector-1.1">
<dep:environment xmlns:dep="http://geronimo.apache.org/xml/ns/deployment-1.1">
<dep:moduleId>
<dep:groupId>console.dbpool</dep:groupId>
<dep:artifactId>studentpool</dep:artifactId> ----> Database pool name
<dep:version>1.0</dep:version>
<dep:type>rar</dep:type>
</dep:moduleId>
<dep:dependencies>
<dep:dependency>
<dep:groupId>com.ibm.db2</dep:groupId> -----> Dependency files
<dep:artifactId>db2jcc</dep:artifactId>
<dep:version>8.2</dep:version>
<dep:type>jar</dep:type>
</dep:dependency>
<dep:dependency>
<dep:groupId>com.ibm.db2</dep:groupId> ----> Dependency files
<dep:artifactId>db2jcc_license_cu</dep:artifactId>
<dep:version>8.2</dep:version>
<dep:type>jar</dep:type>
</dep:dependency>
</dep:dependencies>
</dep:environment>
<resourceadapter>
<outbound-resourceadapter>
<connection-definition> ----> Database connection information
<connectionfactory-interface>javax.sql.DataSource
</connectionfactory-interface>
<connectiondefinition-instance>
<name>studentpool</name> ----> Database pool JNDI name
<config-property-setting
name="User">Anitha</config-property-setting>
<config-property-setting
name="Password">bc0nf1dent</config-property-setting>
<config-property-setting
name="PortNumber">50000</config-property-setting>
<config-property-setting
name="ServerName">localhost</config-property-setting>
<config-property-setting
name="DatabaseName">STUDENT</config-property-setting>
<config-property-setting
name="DriverType">4</config-property-setting>
<connectionmanager>
<local-transaction/>
<single-pool>
<max-size>10</max-size>
<min-size>0</min-size>
<match-one/>
</single-pool>
</connectionmanager>
</connectiondefinition-instance>
</connection-definition>
</outbound-resourceadapter>
</resourceadapter>
</connector> |
You can see that all the configuration information related to the DB2 Express-C database, such as database name, connection information, JDBC driver dependencies, and so on, has been specified in the above plan. The same can be applied to any database, whether it be for DB2 Express-C, Cloudscape, or any other supported database. All you do need to specify are the JDBC driver dependencies and the corresponding connection information.
Making the application access the database pool
As per the specification, two steps are needed for an application module to use a database connection pool:
- The deployment information for the module must declare a resource reference and map it to a specific connection pool available to that module.
- The module's code must look up the connection pool through JNDI.
Specify the database pool in the deployment descriptors
There are two files in which you need to specify the resource references for the database pool. One is the Standard deployment descriptors file in the Java EE 1.4 specification, another is the Geronimo specific deployment plan. Table 1 shows the actual files corresponding to the type of the application archive.
Table 1. Deployment descriptor files
| Deployed archive | Standard deployment descriptors in the Java EE specification | Geronimo-specific deployment plan |
|---|
| Web application archive (WAR) file | web.xml | geronimo-web.xml | | JAR containing EJBs | ejb-jar.xml | openejb-jar.xml | | Enterprise Application (EAR) file | application.xml | geronimo-application.xml | | Java EE connector resources archive (RAR) | ra.xml | geronimo-ra.xml | | Java EE client application archive (JAR) | application-client.xml | geronimo-application-client.xml |
For an example, let us see how to specify the resource references in the deployment plans of the Web application.
In WEB-INF/web.xml
Once the database pool has been deployed, application modules can refer to it using the name specified during configuration. To do this, you should declare a resource-ref with a type of javax.sql.DataSource in its standard Java EE deployment descriptor (web.xml). Listing 2 shows how to specify the resource reference in the web.xml file.
Listing 2. web.xml
<resource-ref>
<res-ref-name>jdbc/MyDataSource</res-ref-name> ---> Resource reference
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
<res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref> |
In WEB-INF/geronimo-web.xml
In the Geronimo deployment plan for that module, you need to specify which connection pool in the server will be used to satisfy the data source required by the Web module. To do this, you need to specify the name of the database pool to the ref-name, which should be mapped with the resource-ref in web.xml. Listing 3 shows how to specify the resource reference in the geronimo-web.xml file.
Listing 3. geronimo-web.xml
<?xml version="1.0" encoding="UTF-8"?>
<web-app
xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-1.1">
<environment>
<moduleId>
<artifactId>MyWebApp</artifactId>
</moduleId>
<dependencies>
<dependency>
<groupId>console.dbpool</groupId>
<artifactId>studentpool</artifactId>
</dependency>
</dependencies>
</environment>
<context-root>/MyWebApp</context-root>
<!-- security settings, if any, go here -->
<resource-ref>
<ref-name>jdbc/MyDataSource</ref-name> ---> Resource reference
<resource-link>studentpool</resource-link>
</resource-ref>
</web-app> |
When you deploy the application, it will look for the Geronimo deployment plan. If you attempt to deploy a Java EE application module without a deployment plan, the server will do its best to perform the operation with default values.
This Geronimo deployment plan can be kept as a separate file or it can be packaged within the application. If it is not packaged with your application, then you can specify the plan file in the Plan field during application deployment. If the deployment plan is part of the archive, the chances of it getting lost are much less. However, keeping the plan as a separate file gives you more flexibility since you don't need to repackage the application as many times as you do when changes are made in the deployment plan.
In the application module
Listing 4 shows the code in the application module needed to lookup the created database connection pool.
Listing 4. Application code
InitialContext ctx = new InitialContext();
DataSource ds = ctx.lookup("java:comp/env/jdbc/MyDataSource"); ---> Resource reference
Connection con = ds.getConnection(); |
The JNDI lookup string is java:comp/env/ plus the res-ref-name used in web.xml (Listing 2). Also, keep in mind that the resource reference name, jdbc/MyDataSource, should be the same in web.xml, geronimo-web.xml, and in the application code.
Community Edition does not support a "global JNDI space" where all resources are listed. The only portable way for an application to access a database pool is to use a resource reference and access the pool through the component's local java:comp/env/ namespace, as described above.
Creating security realms
A security realm is a mechanism to protect the Web application resources. It gives you the ability to protect a resource with a defined security constraint and then define the user roles that can access the protected resource. Community Edition provides various types of security realms and they are classified based on the back end considerations for its authentication mechanism. The types of security realms supported by Community Edition include:
- Properties File realm: Credentials stored in properties files on disk.
- Database (SQL) realm: Credentials stored in database tables.
- LDAP realm: Credentials stored in an LDAP server.
- Certificate Properties File realm: Uses digital certificates and properties files on disk.
- Custom realm: Based on user-implemented login module(s) and user-defined principal(s).
Properties File realm
Let us look at an example creating a Properties File realm using the admin console and see how it works. Others types of realms can be created in a similar fashion. We chose this realm for our purposes here only because it is the simplest among all types of security realms, doesn't require any prerequisite setup, and a text editor is sufficient for creating a properties text file, which contains user and group information.
To create a Properties File realm from the admin console:
Under the <wasce_home>\var\security directory (where <wasce_home> is the Community Edition installation directory), create a text file called user1.properties file. In this new file, specify user name and the corresponding password in line-by-line format for the users to whom you want to give application access to, as shown in Listing 6. Each line of this file represents <username>=<password>. Save the file.
Listing 6. user1.properties
Anitha=anitha123
Sridhar=Sridhar123
Manu=manu123
Vamsi=vamsi123 |
Under the <wasce_home>\var\security directory (where <wasce_home> is the Community Edition installation directory), create a text file called group1.properties file. In this new file, specify the group names and the users that belong each group in line by line format, as shown in Listing 7. Each line of this file represents <group name>=<username1>, <username2>, ... ... Be sure that <username1>, <username2>, and so on, are included in the user1.properties file. In the example in Listing 7, Anitha and Sridhar belong to group1; Manu and Vamsi belong to group2. Save the file.
Listing 7. group1.properties
group1=Anitha, Sridhar
group2=Manu, Vamsi |
From the Console Navigation pane on the admin console, launch the Security Realms portlet by clicking on the Security Realms link under the Security category. Figure 4 shows the Security realm portlet, which displays all the available security realms.
Figure 4. Security Realms portlet
By default, Community Edition uses the security realm called geronimo-properties-realm (Figure 4) to authenticate users via the properties file. The corresponding files are users.properties and group.properties, located under the <wasce_home>\var\security directory.
Select Add new security realm to launch the Create Security Realm wizard. On the Step 1 panel (Figure 5), enter or select the following values:
- Name of Security Realm: any valid value.
- Realm Type: Properties of File Realm.
Click Next.
Figure 5. Create Security Realm, Step 1
On the Step 2 panel (Figure 6), enter the following values:
- Users File URI: in our case,
var/security/users1.properties
- Groups File URI: in our case,
var/security/group1.properties
Click Next.
Figure 6. Create Security Realm, Step 2
(In URI fields use only forward slashes, and do not start the URI with a slash. Specify the location relative to Community Edition's home directory.) On the Step 3 panel (Figure 7), select any or all of the three options, if applicable (Enable Auditing, Enable Lockout and Store Password). Click on Test a Login button to test whether the credentials are working fine. To view the deployment plan of the realm, select Skip Test and Show Plan. To deploy the realm, select Skip Test and Deploy.
Figure 7. Create Security Realm, Step 3
| | Developing and configuring application to authenticate against the realms is beyond the scope of this article. |
|
Upon successful creation and deployment of the realm, the realm name will be listed in the Security Realm portlet (Figure 4). You can edit or view the usage of this realm in the deployment descriptors by using the edit and usage links available on the portlet.
The realm is now available and ready to use. Using these realms, you can secure your application from being accessed by an unauthorized user.
Keystores
A keystore is a facility for storing cryptographic keys and certificates. You need a keystore to configure Community Edition to support HTTPS access to Web applications. That is, to define a Tomcat HTTPS connector, you must specify the name of the keystore file containing a certificate used to encrypt the data exchanged using SSL (Secure Socket Layer) protocol, along with the password.
The certificate within the keystore has two important features:
It contains a public key and a private key used to encrypt the data exchanged over the SSL connection. The encryption prevents the data from being observed or modified while it travels through the network. The server's certificate is automatically sent to every client that desires using the SSL connection. It contains a set of credentials that identify the server and the company associated with the server. Whether or not these credentials can be trusted will depend on whether or not the client can trust the certificate authority that digitally signed the certificate.
In Community Edition, the Keystore Configuration tool (Figure 8) is available on the console. You can use this tool to create, edit, and delete the keystore and its contents. To launch the tool, go to the Console Navigation pane and click on the Keystores link under the Security category.
Figure 8. Keystore Configuration tool
The Keystore Configuration tool displays the keystore files, the keystore contents, and the status of Editable and Available flags; that is, whether a key is locked or unlocked.
The default keystore in Community Edition with a certificate provided is "geronimo-default." You can use this to test the SSL connections. The password for this keystore is "secret" and the corresponding keystore file is located under the <wasce_home>/var/security/keystore directory.
Keystores start out as locked against editing. The Editable flag indicates whether the keystore has been unlocked for editing (by entering the keystore password); this status lasts for the duration of the current login session. The Available flag indicates whether that password has been saved in order to make the keystore available to other components in the server.
To unlock the Editable keystore lock:
- Click on the lock icon in the Editable column (Figure 8).
- Specify the password in the Enter keystore password field in the portlet (Figure 9).
- Click on the Unlock Keystore button.
Figure 9. Unlocking the keystore
Only when the Editable lock is opened will you be able to view and edit the contents of the keystore, which is made of the keys and certificates that are available (Figure 10). When opened, you can create, modify, and delete private key and trusted certificate entries.
Figure 10. Displays unlocked keystore
Follow the same method to unlock the Available lock. When unlocked, you will be able to generate a CSR (Certificate Signing Reply) or import a CA (Certificate Authority) reply. More on these elements later.
Create a keystore
As mentioned earlier, to configure Community Edition to support HTTPS access to Web applications, you need a keystore with a certificate. You can either use an exisiting keystore or create a new one.
To create a new keystore:
- On the Keystore Configuration Tool (Figure 8), click New Keystore.
- Enter values for Keystore file name and Password for new keystore fields (Figure 11).
- Click on Create Keystore button.
Figure 11. Create a keystore
Upon successful creation of the keystore, the keystore will be displayed on the Keystore Configuration Tool (Figure 8), and the corresponding keystore file will be stored in the <wasce_home>\var\security\keystores folder.
Generate key
To define an HTTPS connector in Community Edition, you need a keystore with a certificate. When you create a private key, it creates the key pair and the self signed certificate. You can use this certificate to configure Community Edition to support HTTPS access to the Web application.
To create a new key:
- Click on the keystore file name in the Keystore configuration portlet (Figure 8). The Keystore contents portlet (Figure 12) displays the keys and certificates available in that particular keystore.
Figure 12. Keystore contents
- Select Create Private Key link.
- Specify the values required for the key as shown in Figure 13 and described below, then click the Review Key button.
Figure 13. Configure key data
- Alias for new key: The unique name used to identify this keypair in the keystore.
- Key Algorithm: The private key algorithm to be used to generate the keypair. The administrative console supports only RSA.
- Key Size: Length in bits of the modulus of RSA keypair. The higher the key size, the more secure is the keypair. The administrative console supports 512, 1024, and 2048 key sizes. In our example, we use a key size of 2048.
- Algorithm: The signature algorithm to be used to sign the self-signed certificate generated as part of generate keypair (LINK) exercise. The administrative console supports MD2withRSA, MD5withRSA, and SHA1withRSA signature algorithms. In our example, we use MD5withRSA.
- Valid for (#days): Indicates the validity of the keypair in number of days. In our example, we use a validity value of 180 days, or approximately 6 months.
- Server Hostname (CN): The hostname of the Web server hosting your Web application(s) that wants to authenticate the server to Web clients. For example, if the application is to be hosted on www.mywebsite.com, use the same as the common name so that clients will use http://www.mywebsite.com or https://www.mywebsite.com to access the application. In our example, we use localhost as the common name.
- Company/Organizational (O), Division/Bussiness Unit (OU), City/Locality (L), and State/Province (ST): Complete these fields to reflect the identity of the requestor.
- Country (C): The two-letter ISO 3166 country code of the requestor's country. In our example, we use IN, which is the country code for India.
- When you click on the Review Key Data button, the information you entered for the key (Figure 14) displays.
Figure 14. Generate the key
- Once you have verified the values are correct, click the Generate Key button to generate the key.
Immediately after clicking the Generate Key button, the new private key is generated and will appear in the Keystore contents portlet (Figure 12). Click on the generated key and the self-signed certificate information created along with it will display (Figure 15).
Get your certificate signed by Certification authority (CA)
Once the private key is successfully generated, you can use the self-signed certificate generated along with it to configure Community Edition to support HTTPS access to the Web application. In a production environment, it is always better to use the certificate which is signed by a well known Certification authority (CA), such as VeriSign. The clients that designate this CA as trusted will readily accept any certificates issued by the CA.
To obtain a signed certificate in Community Edition, you need to generate a CSR using a keystore configuration tool that can be sent to the internal or external CA. The CA will verify the request and issue a certificate in reply. Once you receive the reply from CA you can import that certificate into the keystore. To do this, go to the Keystore Contents portlet (Figure 12) of the Keystore configuration tool and click the private key that you generated. The contents of the key will display (Figure 15).
Figure 15. To generating a CSR and import the CA reply
Click Generate CSR on the keystore configuration portlet and the certification request will be generated using the PKCS10 standard that defines a binary format for a CSR. Copy the text area into a file and save to a file (as, say, csr.txt).
Figure 16. Generated CSR
Next, you need to request the CA to issue the certificate using the above generated CSR. To request a certificate, go to the CA's Web site and order your certificate. You need to provide the CSR obtained in step 1 (that is, the contents of csr.txt), as requested by the CA. You should then receive your certificate from the CA. Save it in a file (such as ca_reply.txt), and be sure to include the "BEGIN CERTIFICATE" and "END CERTIFICATE" lines in the file, such as:
-----BEGIN CERTIFICATE-----
The certificate contents...
----END CERTIFICATE----- |
(The example above omits the actual certificate data.)
In this example, we used an internal CA to get the reply and pasted it below to show you a complete certificate. (Figure 17).
Figure 17. CA replied certificates
Once the certificate is signed by the CA for the CSR (usually PKCS7 encoded certificate reply), it needs to be imported into the keystore so that if any client request comes to the Web server with a certificate signed by a CA, the Web server will be able to perform SSL handshake successfully. To import the keystore:
- Click on Import CA reply on the Keystore configuration panel (Figure 15).
- Paste the copied CA reply into the text area (Figure 18).
- Click Save.
Figure 18. Import the CA reply certificate
Configure support for HTTPS access to Web applications
To configure Community Edition so that it support HTTPS access to Web applications, you need to create an HTTPS listener with client authentication option. To do this:
From the Console Navigation Pane on the right side of the console, select Web Server under the Server category. Select Add new HTTPS Listener for Tomcat (Figure 19).
Figure 19. Network Listeners portlet
Specify the values for the fields described below and click the Save button (Figure 20).
Figure 20. Segment of Add new HTTPS listener for Tomcat portlet
- Unique Name: A name that is different than the name for any other Web connectors on the server.
- Host: Host name or IP address to which the port will bind. In our example, this is
0.0.0.0.
- Port: Network port to bind. In our example, we use
8444, which is the default port for HTTPS.
- Keystore File: File that holds the keystore. You can specify this as
var/security/keystore/SampleKeyStore, which is the location of the keystore SampleKeyStore you generated earlier.
- Keystore Password: Password used to access the keystore file and the private-key entry.
- Keystore Type: The keystore type of the Keystore File field entry. The default type is JKS.
- Truststore File: The file that holds the truststore. In our example, the trusted certificates are added to var/security/keystore, which itself will act as truststore. Therefore, we use
var/security/keystore/SampleKeyStore for this field.
- Truststore Password: Password used to verify the Truststore File field, which in our example is the password of var/security/keystore (that is,
secret)
- Truststore Type: The keystore type of the Truststore File field entry. The default type is JKS.
- HTTPS Algorithm: The HTTPS Algorithm provider. This should typically be set to match the JVM vendor. Using JVM Default for this field will not require reconfiguring the HTTPS listener when the server is run on a different JVM than the selected value.
- Client Auth Required: If this field is set, then clients connecting through this connector must supply a valid client certificate.
| | Additional details on HTTPS and SSL connectors are beyond the scope of this article. |
|
When you click Save button, the new HTTPS listener for Tomcat is created and starts with the above mentioned configuration. The new listener will also display on the Network listeners portlet (Figure 17).
Conclusion
Part 1 of this two-part series described advanced console features that enables the administrator to:
- Create a database base pool for any database.
- Create a security realm to secure an application from unauthorized party access.
- Generate a keystore and certificate to configure Community Edition to support HTTPs access to your Web application.
Additionally, this article gave you a head start with a DB2 Express-C database, which you began working with using the Command Editor.
Part 2 will offer information on other advanced console features, including thread pools statistics, Geronimo plug-ins, redeploying an application, and more. These advanced features can help you increase the availability and scalability of your application, plus tune performance. You can also import and export the complete configuration of an application or service as a plug-in to the server.
Deploy and see the sample applications available for download from the Community Edition's download page. The Resources provided will help you learn even more about WebSphere Application Server Community Edition.
More in this series
Part 2: Working with thread pools, clustering, and configuration plug-ins
Resources Learn
Get products and technologies
Discuss
About the authors | 
| | Anitha Krishnasamy is a Software Engineer working with WebSphere Application Server Community Edition Business Development team in IBM India Software Labs, Bangalore. Her area of expertise includes business integration and J2EE technologies. She holds a masters degree in Computer Applications from National Institute of Technology, Trichy. She can be reached at kanitha@in.ibm.com. |
| 
| | Mansoor Ahmed is a Software Engineer in IBM India Software Labs, Bangalore. His area of expertise includes Open Source projects and Java EE technologies. Mansoor holds a bachelors degree in Computer Science from Visvesvaraya Technological University. He can be reached at manahmed@in.ibm.com. |
Rate this page
| |
