IBM WebSphere Process Server 7 and Enterprise Service Bus 7 : Solution administration tasks (part 1) - Performing common tasks using the administrative console

After the Sales Fulfillment Application has been deployed, Sales Fulfillment Application for JungleSea Inc., we enter the fourth phase of the IBM SOA Architecture-Manage. In this phase, the SOA solution, business process, and related assets are monitored and managed to ensure they continue to deliver the business value they were developed for. Typical solution administration tasks encompass tasks such as deploying modules, enabling and configuring security, viewing and administering modules, configuring resources, monitoring modules, troubleshooting modules, and so on. In order to be able to accomplish these, WPS and WESB provides administrative capabilities to manage and monitor applications running on them. By leveraging these features, system administrators can accomplish common administration tasks such as review logfiles, start/stop servers, install/remove applications, define security settings, and manage integration with other tooling and databases. These capabilities are exposed to the system administrators and other interested groups through the Integrated Solution Console, also known and used interchangeably as the Administrative Console or Admin Console.

Using the administrative console

The admin console is the integrated browser-based interface used to administer, manage, and monitor modules, applications, services, and other resources at a cell, node, server, or cluster level. Using the integrated solutions console, you can:

• Deploy the various modules that make up the Sales Fulfillment Application

• Use a common interface to administer the application, which in turn reduces time and expense required for training administrative personnel

• Manage applications, buses, servers, and resources for a standalone server, network deployment cell, manage node, and deployment manager node

The wsadmin tool is a command-line version of the administrative console and can be used to script any activity executed in the administrative console.

You launch the admin console from WID by right-clicking on the UTE server and by selecting Administration | Run administrative console from the context menu. You can also directly launch it in a web browser by going to the URL https://<server IP>:<port:>// ibm/console/logon.jsp. (https://localhost:9048/ibm/console/logon.jsp, for example). Administrative console pages are of three types, as shown in the following screenshot:

1. Collection Page: A Collection Page manages a collection of existing administrative objects normally displayed in the form of a table of objects, events, or resources with administrative functionality to control them.

2. Detail Page: These are used to view detail and configure objects and resources.

3. Wizard Page: These pages help you complete a configuration process comprised of several steps.

Let's take a closer look at the landscape of the admin console. This page essentially has four main areas-Navigation Tree, Work Area, Task Bar, and Page help, as shown in the next screenshot:

1. Task Bar: The Task Bar is located at the very top of the console. All tasks like saving changes, logging out, specifying preferences, and accessing product information are provided here.

2. Work Area: The Work Area is located in the center of the console. It displays the main content of the page where you can create and administer servers, applications, and other resources. You access these pages by clicking the links in the Navigation Tree or by clicking links within the workspace pages themselves.

3. Page help: The right side of the workspace provides brief information about each field on the current page, as well as a link to more detailed information in the help browser.

4. Navigation Tree: On the left side of the Work Area is the Navigation Tree. It provides links to console pages that you use to create and administer servers, applications, and other resources. You can expand or collapse each item in the Navigation Tree using the plus or minus icon respectively or by clicking on the item itself. The various items provided by the Navigation Tree are expanded and shown in the following screenshot:

Performing common tasks using the administrative console

Our next step will be to get our hands dirty and walk through some of the more common tasks that any administrator would need to do using the admin console.

In the case of clustered WPS/WESB, it is recommended that you ensure the deployment manager is running before you use the widget. In addition, the node agents must be running in order to see the module status in the widget.

Enabling server and application security

Security is an integral part of WPS and is based on the WebSphere Application Server (WAS) version security. Security can be established both at a global, administrative, and application level. Global security helps provide the basic security for all administrative functions and user applications. During installation of WPS, administrative security is enabled by default and will require you to define a user with an administrative role. If needed, this option can be unchecked to turn Global security off but this is not recommended. This can be configured later through administrative console.

Application security helps control and secure identity, access, and data flowing to and from the modules. Application security can be established programmatically or declaratively through the administration console. It should be noted here that administrative security needs to be established before security for applications can be configured.

WPS also helps define security to communicate with external and internal system components like databases, messaging engines, and connection factories.

The Navigation Tree, as shown in the following screenshot, provides these options to configure and define security settings for the server and user applications that run on it.

The Business Integration Security panel is used to define and manage authentication aliases for various runtime components including the Business Process Choreographer, Common Event Infrastructure, and Service Component Architecture. You are also given the option to define users and groups for the different default roles for Business Process Choreographer, as shown in the following screenshot:

By default, they are all set to the default administrative user.

• The Global security panel is used to configure administration and the default application security policy. We shall cover this in more detail under the Administrative Security procedures section.

• The Security domains panel is a new feature in version 7.0 that allows for greater flexibility in configuring and applying security settings. This is used to manage multiple security domains by providing the ability to create new domains, delete existing domains, or copy domains that can be scoped to an entire cell or a specific server, cluster, or service integration bus. It can also be used to configure separate security configurations for administrative applications, end user applications, and third-party security providers.

• The Administrative Authorization Groups panel is used to create and manage the current Administrative Authorization Groups available in the cell.

• The SSL certification and key management panel is used to manage security for Secure Socket Layer (SSL) and key management, certificates, and notifications.

• The Security auditing panel is used to capture and store auditable security events like authentication, authorization, and resource access that can then be presented in a consumable form through user-friendly reports.

• The Bus security panel is used to manage security for the Service Integration Buses.

Administrative Security procedures - Enabling administration security at profile creation

When installing WPS or WESB or when creating a new profile in the server, you are given the option to Enable administrative security, as shown in the following screenshot:

If Administrative security is not enabled at installation, it can be established during post installation. Steps to do this have been documented in the IBM Redbook WebSphere Application Server V7.0 Security Guide under the Administration Security section.

Installing SCA modules using the admin console

You can use the admin console to deploy an SCA module or a mediation module to the WPS/WESB server. While there is a certain possibility to automate the deployment of these modules using Jython or Java Application Control Language (JACL) executed using the wsadmin tool, we will see in this section how to use the admin console. To export a module for deploying through the admin console, execute the following steps:

1. In WID, right-click on the module or modules and select Export.

2. In the Export wizard, choose Business Integration | Integration modules and libraries, and proceed with the Wizard by clicking on the Next button.

3. Select the appropriate modules in the list.

4. Proceeding with the wizard, select the Target Directory where you want to export the EAR files.

5. Finally, complete the wizard at the end of which you will find the EAR versions of the module(s) that can be deployed on the server.

Once you have exported the module(s) from WID, you will, most likely, want to version control the exported EAR file using CVS or ClearCase as part of a software configuration management procedure.

In WID, the default sharing behavior for modules and libraries is share-by-copy.

By default, when you export a module for deployment from WID, modules bring along with it a copy of the library that contains WSDLs, XSDs, and so on). These shared SCA library projects are exported (as .jar files) and each included in an SCA module application enterprise archive (.ear) file. When the size of the libraries becomes large, you don't want to do share-by-copy. Sharing these assets by reference can reduce this memory footprint. The solution is to use a WebSphere shared library (SL) instead of the default share-by-copy method.

In the Library Dependency editor, if you look at the Sharing across Runtime Environments section, you have two radio button choices:

• Global (share-by-reference)

• Module (share-by-copy)

If you want the library to be deployed as a shared/global library, select radio button Global. You need to do this for each library in the workspace. When you export the module, the libraries will be exported as individual JARs and the module EAR of course.

Now in the admin console, select the Install New Application wizard that guides you through the deployment of a new application onto WPS or WESB. Now let us go through the steps involved as follows:

1. In the Navigation Tree under Applications, click on Install New Application.

2. The application EAR file that you exported from WID may be on the local file system or at a remote location; specify the location.

3. Select if you want to be prompted for the additional information that is needed in the installation or if you want to view all installation options and procedures. The first choice is quicker than the second.

4. Click on the Next button.

5. Follow the required installation steps as directed.

6. Save the installation if everything goes through successfully.

7. Click on Applications | Enterprise Applications to list all the installed applications.

8. Locate the application just installed. It has not yet been started.

9. Enable the checkbox next to the application on the table.

10. After installing a module it is not automatically started. The application needs to be started manually using the admin console. Click on the Start button, as shown in the following screenshot:

Congratulations! You have completed installing an application module.

Managing Users and Groups

User management is an integral part of deploying and administering any application. It is critical to ensure that the end user is given just the right level of access to serve the business need. In WPS or the WESB admin console, these features are listed under Users and Groups, as shown in the following screenshot:

Now let us look at the steps involved in the creation of a new group Jungle Sea Users with one user JoeUser:

1. Under Users and Groups in the Navigation Tree, click on Manage Groups.

2. Click on the Create button.

3. Enter a group name Jungle Sea Users, and click on the Create button.

4. Click on Manage Users under Users and Groups in the Navigation Tree.

5. Click on the Create button.

6. Enter user details, as shown in the following screenshot:

   

7. Click on the Group Membership button.

8. When you return to the Create a User page, click on the Create button.

Congratulations! You have created a JungleSea user group with a user Joe User.

Integration with LDAP

WPS or WESB can be easily integrated with your existing LDAP, Federated repository, Local operating system users, or any other customer user registry. These settings are found under Security | Secure administration, applications, and infrastructure in the Navigation Tree.

Configuring Resources

Most production applications in today's world need to leverage resources for security, persistence, integrations, and other operation needs. The various modules and mediation modules we have developed so far make use of a wide range of resources including JMS, JDBC, service integration (destinations), CEI, and so on. To administer these resources, you can use the admin console, commands, and scripting tools. As shown in the following diagram, WPS and WESB provide administrative capabilities to manage these resources under Resources in the Navigation Tree. Let's take a closer look at some of the more commonly-used applications:

• JMS is used to create, configure, and manage JMS providers, queues, topics, connection factories, and activation specifications.

• JDBC is used to create, configure, and manage JDBC settings for the applications. The JDBC providers object encapsulates the specific JDBC driver implementation class for the data sources that you define and associate with the provider.

• Mail is used to create, configure, and manage mail sessions needed for the applications and server.

Start the wsadmin tool to run the following commands.

Some of the common commands to manage and get information about the modules include:

• To list the SCA modules deployed on the server:

  $AdminTask listSCAModules

• To display the details of a particular SCA module:

  $AdminTask showSCAModule {-moduleName moduleName}

• To display the properties of a particular SCA module:

  $AdminTask showSCAModuleProperties {-moduleName myModule}