IBM has made some significant enhancements to the Administrative Console with the introduction of V4.01 Advanced...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Edition. Unfortunately, the product's origins on the NT platform present challenges to multiuser machines like the iSeries that were not anticipated or handled well by the cross-platform development team.
You may associate a single user profile and password with the console (actually the administrative server) on the console by selecting Console, then Security Center, and the Authentication Tab.
But what do you do if you have multiple developers or, worse, multiple development teams working in one WebSphere environment? Large shops working with WebSphere isolate development from production or quality assurance environments by using physically separate machines and giving developers full console access to development machines.
The problem that exists is deploying Web Archive (WAR) or Enterprise Archive (EAR) files. To deploy an EAR or WAR at V4.01 and V4.02, you must stop, delete, recreate and then start your Enterprise Application to properly deploy a WAR or EAR. The console has no granularity. You either have complete access to the console or none. The extreme programming (XP) model dictates deploying executable code for testing as rapidly as possible and adding functionality throughout the life of your project. That means you may need to redeploy your WAR or EAR files frequently, often several times a day.
You don't need to delete or recreate your Enterprise Application when you replace individual objects, but you must when you add or remove objects from your application. While I certainly "trust" my developers, the auditors do not. When it comes to WebSphere, giving a developer full WebSphere console authority opens the same exposures as giving a developer QSECOFR with *ALLOBJ authority.
As you can see, we have a change control nightmare. Many large shops give developers free access to their development machines and require that applications be turned over to a separate deployment group to deploy, to quality assurance or to production environments.
An alternative is the new WebSphere Control Program (WSCP). The WSCP is a scripting language based on tool control language (TCL). Almost anything that can be done via the console can be done via WSCP scripts, which on the iSeries may be run via Qshell (QSH). Unfortunately, IBM has not provided a batch command level framework, so you must write your own scripts and integrate that scripting into your systems. I strongly suggest you look into developing WSCP scripts and using WSCP to provide some form of managed change control in your WebSphere environment. Detailed information on WSCP may be found in the WebSphere "Documentation Center."
About the author: Bob Cancilla is managing director of IGNITe/400, an electronic iSeries 400 Internet users group. He is also author of the book Getting Down to e-business with AS/400.
- Introduction to QShell: Administer Java applications
When it comes to running more advanced or more automated administration tasks, QShell offers the power you need.
- Basic WebSphere troubleshooting concepts
This tip introduces WebSphere basic concepts and a simple process to identify some WebSphere configuration problems quickly.
.osrxa7uufIJ^2@.ee84637/224>WebSphere setup on client and iSeries
Site expert Jim Mason gives advice on running STRCODE on the iSeries when setting up WebSphere.
.26RlaSVDeTg^1@.ee84637>WebSphere/Web development discussion forum:
Post your WebSphere and Web development questions here. You'll get advice from our site experts who monitor the forum, as well as ideas and suggestions from other users.