Who’s On Phirst

Official blog of Phurnace Software.

Tag >> WebSphere 7.0

Posted by: Robert Reeves on

Both WebSphere Virtual Enterprise (VE) and ND 7.0 have the ability to remotely stop and start Node Agents, install WebSphere on remote servers and a whole host of handy remote activities. To perform these actions, WebSphere takes advantage of Tivoli Remote Execution and Access (RXA).

Luckily, you too can take advantage of RXA to manage your remote servers. Below, I’ll show you how to create a very simple Java class that will connect to your local windows machine and perform a directory listing.

First, you will need to create a new Eclipse project and add the following JAR to your Build Path as an external library: ${WAS_INSTALL_DIR}/plugins/com.ibm.ws.prereq.rxa.jar.

Second, create a new class and add the following main method.

      public static void main(String[] args) throws Exception {

            RemoteAccess ra = new LocalWindowsProtocol();
            ra.beginSession();
      }

At this point, you can really take advantage of the RemoteAccess object to gather information about your Local Windows host, or to run commands, manage processes, you name it. For example, the following lines added to the main method will perform a directory listing on your Local Windows host:

            ProgramOutput programOutput = ra.run("dir");
            String stdOut = programOutput.getStdout();

Of course, you might want to get STDERR while you’re at it…

Finally, RXA is not just limited to a Local Windows host. Here is an example on how to connect to a Remote SSH host:

            String username = new String("root");
            String strPassword = new String("p4ssw0rd");
            byte[] bPassword = strPassword.getBytes();
            ra = new SSHProtocol(username, bPassword);
            ra.setHostname("myhost.domain.com");
            ra.beginSession();

If you are going to be running a series of identical commands on a bunch of different servers, all with different OS types, I would recommend using the Factory design pattern to generate a RemoteAccess object of the correct Protocol type. Below is a list of the Protocol objects. As you can see, you have a very broad assortment.

AS400Protocol
LocalAS400Protocol
LocalUNIXProtocol
LocalWindowsProtocol
REXECProtocol
RSHProtocol
SSHProtocol
UNIXProtocol
WindowsProtocol

In WebSphere VEWebSphere 7.0Tivoli Remote Execution and Access
Comment (0) Read More...


Posted by: Pete Pickerill on

Being the honorary dev environment manager at Phurnace is a lot like being the employee of the month at a pig farm. Sure it sounds prestigious, but it really just means that you are able to deal with a lot of crap and you never mention how much it stinks. On the plus side, holding this title has given me a lot of insight into what our customers experience on a day to day basis. J2EE web application environments are difficult to manage. While the common commercial offerings provide great performance and availability for your web applications, the management and configuration of these platforms seems to have escaped the consideration of vendors for the most part. It doesn’t take long to become hopelessly mired in a deep directory tree digging through XML or a labyrinthine administration console that might as well be written in cuneiform.

The inclusion of Properties File Based Configuration (PFBC) in WebSphere 7.0 signifies a change in how platform providers view configuration challenges. They have recognized the pain and are now starting to address it. The aim of PFCB is to make the configuration data more accessible to users by storing it in key value pairs that are a little easier to read and understand than XML might be. The interface between these properties files and your application server configuration is a command line tool aptly named the Properties File Based Configuration Tool (PFBCT). The PFBCT is an extension of the wsadmin scripting interface and has 4 main modes of operation:
  • applyConfigProperties - applies properties in a specific properties file to the configuration
  • deleteConfigProperties - deletes properties in your configuration as designated in a properties file
  • extractConfigProperties - extracts configuration data in the form of a properties file
  • validateConfigProperties - verifies that the properties in the properties file are valid and can be safely applied to the new configuration

On the surface this sounds great. We have the methods we need to collect, test, update, and delete configuration information, and it seems pretty straight forward. This approach is similar to the approach of Phurnace Deliver because it abstracts the configuration data from the configuration mechanism. This makes configuration data easier to propagate in a large environment or port during environment updates.

Ultimately, I have to chalk this one up as a swing and a miss for IBM. PFCB (and its associated ‘T’) fails to simplify configuration management. In light of the following, I feel it complicates it further.
  • The implementation is woefully inefficient - One of our fundamental beliefs as a company is that SCRIPTING IS NOT THE ANSWER and IBM has not given us a reprieve with this new tool. The implementation relies on the CLI and is very reminiscent of the wsadmin interface. In fact the only palpable difference is that the wsadmin syntax has been replaced with a different, but equally confusing PFBCT syntax. For example, to create a properties file for a server object you’d have to execute the following using the tool:
    AdminTask.extractConfigProperties('-propertiesFileNserver1Config.props, -configData Server=server1')
  • The abstraction stops at resource attributes. You’ll notice from the example above, the object ‘server1’ must be explicitly declared in order to act on it. So if you have dozens of application servers and you need to collect configuration data from all of them, it requires dozens of individual PFBCT executions. In Phurnace Deliver, you just need to supply connection information and Deliver interrogates the server, gives you a choice of nodes to work with, and you’re off to the races, collecting the configuration data for all servers on the node or a subset of servers that you define. You also can get all the configuration data from Cluster, Cell, and Node scoped resources in your environment in the same shot.
  • PFBCT supports only the most commonly used configuration attributes. Most notably absent are the attributes pertaining to Service Integration Busses.
  • Absolutely no reporting of changes made. Nothing has been done to provide administrators with a summary of the changes made on execution. Instead, the PFBCT assumes you’re cool with “no news is good news.” When your company’s point of transaction is on the line, is that really sufficient?

On the one hand it’s heartening that IBM recognizes and has started addressing the problems associated with managing complex application server environments. On the other hand, this solution is anything but complete and seems like little more than an afterthought. I’ll be interested to see where they go from here. In the meantime I’ll stick with Phurnace Deliver.

In WebSphere 7.0Properties File Based Configuration PFBC
Comment (0) Read More...


Posted by: Robert Reeves on

IBM has begun the WebSphere 7.0 Open Beta program. Here is a snippet from the email notice:

You may review the features and highlights on the Open Beta overview page at this URL:
https://www14.software.ibm.com/iwm/web/cc/earlyprograms/websphere/
wasndv7/

The Code and Library downloads may also be found at these URLs:
https://www14.software.ibm.com/iwm/web/cc/earlyprograms/websphere/
wasndv7/download.shtml
https://www14.software.ibm.com/iwm/web/cc/earlyprograms/websphere/
wasndv7/library.shtml

For support issues related to this Open Beta program, we have also provided a discussion forum, which you may access from this URL:
https://www14.software.ibm.com/iwm/web/cc/earlyprograms/websphere/
wasndv7/support.shtml

 

The first thing I noticed about this release is the VMWare images. IBM has included SuSe images with WAS 7 previously installed. Just download the images, point your VMWare Player or Server at them, and test drive WAS 7. (Hint: root password is ‘password’.) I hope this means that IBM will be releasing other WebSphere based applications as VMWare images for evaluation, such as WebSphere Portal.

After starting my standalone Profile and visiting the Admin Console, I was struck by how similar to the WAS 6.1 console the WAS 7.0 console is. There was quite a bit of change from WAS 5.1 to WAS 6.0 and some marginal change in WAS 6.1. But, it seems that WebSphere has stuck with the same layout. That’s very good news for companies that rely on manual deployment.

However, there is cause for concern. The following MBeans have been removed:

 

  • SIBJMSConnectionFactory
  • SIBJMSProvider
  • SIBJMSQueue
  • SIBJMSQueueConnectionFactory
  • SIBJMSTopic
  • SIBJMSTopicConnectionFactory

Of course, this might simply be an oversight that the Open Beta program is meant to address. Or, it appears the JMS aspects of the Service Information Bus have been removed.

We’ll do some sleuthing on our end to see where they went to. But, this marks a change in how IBM has done WebSphere releases in the past. In fact, they still have WAS 4.0 MBeans in WAS 7.0 (e.g., WAS40ConnectionPool, WAS40DataSource). Heck, they still have it in the Admin Console, too!

In WebSphere 7.0Open Beta Program
Comment (3) Read More...