Configuration Model

You can choose from three different configuration models, which are defined below:

• HTML-based model
• Configuration server-based model
• Combined model

HTML-based model Specifies that all session information is defined and managed in this HTML file. You have the same set of session options that you would have if using the configuration server.

Necessary configuration information and user preferences (for example, changes to color), if allowed, are stored locally on the user's machine.

User preferences for Z and I Emulator for Web portlets are stored in WebSphere Portal, not on the user's local machine. However, this is true only if you have granted users the appropriate access to the portlet and the Web page that will access the portlet. WebSphere Portal V4 users must have Edit or Manager access, and WebSphere Portal V5 users must have Privileged User, Editor, Manager, or Administrator access. For more information about how to grant access to users, refer to WebSphere Portal documentation.

The configuration server is not used for sessions or preferences, and user IDs do not need to be created on the configuration server.

The HTML-based model is the recommended configuration model for Z and I Emulator for Web portlets. Refer to Special considerations when using a Z and I Emulator for Web portlet in the Planning, Installing, and Configuring Z and I Emulator for Web guide to compare it with other configuration models.

Choosing this model has several benefits:

• The configuration server is not used. Therefore, you do not need to start the Z and I Emulator for Web service manager unless you are using Z and I Emulator for Web services, such as the Redirector, i5/OS and OS/400 proxy, or license use counting (license use counting is enabled by default, but can be disabled).
• Performance may be better than using the configuration server because you do not have large numbers of users accessing personalized configurations on the configuration server.
• You do not have to create or maintain Z and I Emulator for Web user IDs.
• There is no user logon.
• There are no firewall issues because you do not have to open a separate port to access the configuration server.

Choosing this model may have some limitations (depending on your environment):

• If users make changes to their personal configurations, those changes may not be available on other machines without physically copying them.
• If the administrator needs to define a large number of different configurations, it may become cumbersome maintaining all the HTML files.
• The Deployment Wizard does not run remotely. Therefore, there is no built-in mechanism for administering sessions remotely.

If this option is selected, the administrator uses the Deployment Wizard to define sessions in the HTML. Any changes the user makes are stored on the user's machine. (However, you can still choose to not allow users to save any session changes or to lock particular properties.) If the Administrator then updates the session data using the Deployment Wizard, those updates will be merged with any changes the user has made previously. In this case, all user preferences will be kept unless the administrator chooses to override those preferences.

HTML-based model is the default value.

Configuration server-based model Specifies that all sessions are configured and managed on the configuration server using the Administration Utility and that each user has an ID on the configuration server where user-specific information is maintained.

Necessary configuration is stored in group or user IDs on the configuration server; user preferences, if allowed, are stored in the user's ID. One user ID per user is required on the configuration server.

Choosing this model has several benefits:

• It allows users to access their personalized configurations from any machine with network access because those configurations are stored on the configuration server.
• For large numbers of different configurations, it might be advantageous to organize them using the configuration server group and user structures.
• It allows remote administration of sessions using the Administration Utility.

Choosing this model may have some limitations:

• Multiple Z and I Emulator for Web portlets cannot reside on a single WebSphere Portal page. If you want to display multiple Z and I Emulator for Web portlets on a single WebSphere Portal page, use the HTML-based model. The HTML-based model is the recommended model for using Z and I Emulator for Web portlets.
• There are very high administrative requirements to create and maintain all of the user IDs. (However, you can optionally have user IDs created automatically based on Windows usernames to help simplify this process).
• Performance may be diminished with large numbers of users accessing personalized configurations in the configuration server.
• Requires each user contacting the configuration server before using Z and I Emulator for Web.
• Users must log on. (However, users can be automatically logged on using their Windows username.)

In this model, the Administrator uses the Administration Utility to define session information for users and Groups.

If the Administrator then updates the session data using the Administration Utility, those updates will be merged with any changes the user has made previously. All user preferences will be kept.

Combined model Like the configuration server-based model, specifies that all session information is defined and managed on the configuration server using the Administration Utility (users get their default sessions from a specified group on the configuration server).

However, unlike the configuration server-based model, necessary configuration information and user preferences, if allowed, are stored locally on the user's machine rather than on the configuration server in the user's ID.

User preferences for Z and I Emulator for Web portlets are stored in WebSphere Portal, not on the user's local machine. However, this is true only if you have granted users the appropriate access to the portlet and the Web page that will access the portlet. WebSphere Portal V4 users must have Edit or Manager access, and WebSphere Portal V5 users must have Privileged User, Editor, Manager, or Administrator access. For more information about how to grant access to users, refer to WebSphere Portal documentation.

This option requires you to create at least one group on the configuration server.

Choosing this model has several benefits:

• No Z and I Emulator for Web user IDs to create or maintain.
• Performance may be better than using the configuration server because, while you still have to access the configuration server, you will not have large numbers of users accessing personalized configurations on the configuration server (some information is stored locally).
• There is no user logon.
• For large numbers of different configurations, it might be advantageous to organize them using the configuration server group and user structures.
• It allows remote administration of sessions using the Administration Utility (however, you still have to use the Deployment Wizard for information in the HTML files).

Choosing this model may have some limitations (depending on your environment):

• If you make changes to your personal configurations, those changes are not available on other machines without physically copying them.
• Performance may be diminished with large numbers of users simultaneously accessing the configuration server to obtain their default configurations. However, users will not be accessing the configuration server to obtain or store their user preferences.

If this option is selected, the Administration Utility is used to create a group on the configuration server and create necessary sessions for that group. Then, the Administrator uses the Deployment Wizard to configure the HTML files that users will access, where the HTML files specify the configuration server group from which the default session configurations should be obtained. If the Administrator then updates the session data using the Administration Utility, those updates will be merged with any changes the user has made previously. In this case, all user preferences will be kept unless the administrator chooses to override those preferences.