Who’s On Phirst

Official blog of Phurnace Software.

Category >> WebSphere

Posted by: Daniel Nelson on

I love talking to customers. It makes product planning so much easier if all you do is listen to them and give them what they want. And from the looks of things, most all of our large WebSphere customers are planning to or have already moved to WebSphere Virtual Enterprise (VE).

Quick synopsis of VE (or the product-formerly-known-as OO or XD; IBM has played around with the name more than Prince). Virtual Enterprise allows WebSphere clusters to dynamically allocate resources to applications based on a series of policies, either for service levels or health statistics. The VE on-demand router can gather utilization information and then implement topology or prioritization changes. It’s pretty cool.

There are some challenges though. Just like anything in WebSphere (or middleware in general), it’s a bear to configure and maintain. It’s critical to implement the policies correctly and unlike static configuration where it’s often immediately evident if something isn’t right, with policy based configuration everything can look perfectly fine, but under load the environment might behave quite a bit differently than anticipated -- if the policies aren’t set up exactly right.

About 80% of our Fortune 500 customers that use WebSphere are either currently using VE or have concrete plans to move to it in the next six to nine months. That’s pretty compelling. That’s also why we have extended our products to support VE. With our VE support we help insure that our customer’s environments are set up exactly the way they want them and eliminate a lot of the complexity and heart burn that comes with the added functionality. So, rest assured: go ahead and move to VE, we have your back.

 

In WebSphere VE
Comment (0) Read More...


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: Robert Reeves on

This week, Phurnace announced our support for WebSphere Application Server for z/OS. You can read more about it in our Press Release.

To be honest though, we have always worked on WebSphere for z/OS. However, we were unable to give it the official Phurnace stamp of approval until we ran it through our testing battery. As you know, z/OS is IBM’s mainframe operating system. Thus, for an ISV like Phurnace, procuring a z Series machine and the skills to manage it is a bit outside our skill set and budget. Not to mention the raised floor room, cooling pipes and tanks of Halon (not really, I think they finally banned that stuff).

Thankfully, we were able to secure a z/OS virtualized machine from the IBM Innovation Center in Dallas. The support we received from the team in Dallas was phenomenal. Patient and helpful, they provided us with a turnkey z/OS image with WebSphere ND installed and ready to test against. Moreover, the entire process was at no charge because we were validating that Phurnace Deliver™ would work with z/OS and WebSphere for z/OS.

We have access to the z Series system and z/OS for demonstrations. Please contact us if you would like to see it - sales@phurnace.com.

In zOSWebSphere
Comment (0) Read More...


Posted by: Robert Reeves on

Last week the Phurnace team visited Las Vegas to attend IBM’s Impact 2009. We presented a “Bird’s of a Feather” talk and spent some great time with customers (current and future) at our booth and at dinners.

While at the conference, the most often asked questions were about WebSphere 7.0. It seems that the upgrade is getting rolled up into renewed IBM software contracts. This is turning out to be a surprise to our customers as they are now forced to move to WebSphere 7.0 a bit sooner than they had expected. The good news is that Phurnace can certainly help with their migration from previous versions of WebSphere to the latest. This Phurnace-enabled migration will eliminate the need to re-craft a customer’s deployment scripts. Migration to new WebSphere versions is an “impending event” that motivates many of our customers to act.

Also, we did get some questions about properties-file based configuration in WebSphere 7.0. I directed most of those folks to our previous blog entry about it. Though it does gladden our collective hearts that IBM has addressed customers concerns about WebSphere configuration, the customers we spoke to are still not happy. The major complaint we got was about the explicit nature of the properties files and the inherent messiness of properties files. Simplicity does not seem to have been a design objective on this new feature.

Specifically, if you want to extract configuration data, you have to explicitly tell wsadmin the Object that you wish to extract. Moreover, if you extract a large amount of data, the structure of the properties file is sequential, so edit at your own peril.

Finally, we got rave reviews about our IBM WebSphere Portal 6.1 support. Give us a call and we’d love to show it to you if you missed it at the conference.

Remember, kids: friends don’t let friends write scripts.

In Untagged 
Comment (0) Read More...


Posted by: Jessica Gass on

Phurnace is a Silver Sponsor next week at the IBM IMPACT 2009 conference. The conference is focused on SOA and the leveraging of WebSphere products – WebSphere application server, WebSphere Portal, WebSphere Process Server, and more. There are even going to be sessions and announcements related to IBM and Amazon and the cloud platform AWS, including some exciting news on this topic from Phurnace.

We found this to be a great event last year. It was good to connect face to face with our customers and our prospects. We generated good quality sales leads and the audience was perfect for us. I encourage any WebSphere system admins or IBM Portal customers to stop by and see us in our show floor booth or join us Monday morning for a “birds of a feather” session that will discuss how to eliminate your deployment scripts and the headaches that they present . We will be demonstrating the deployment of java apps into WebSphere, the management of updates and changes to IBM Portal and how to use Phurnace as an “on ramp” into the Amazon cloud (Amazon Web Services).

Finally, set a meeting with us if you plan to be there. If you would like to reserve a time slot or just want to let us know that you will be there for us to keep an eye out, please email jessica.gass@phurnace.com. She will make sure you connect with all of the right Phurnace people. This is a must go conference if you are a WebSphere user. If you don’t have your ticket, go online and sign up now. You shouldn’t miss this one.

In WebSphere
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: Alexander Bibighaus on

A Portal represents a web site that provides a single point of access to applications and information. IBM WebSphere Portal is highly complicated software that enables companies or organizations to host their own portal.

WebSphere Portal offers two main tools to help manage WebSphere Portal configuration: XMLaccess and ReleaseBuilder. Besides automation, the major benefit of XMLAccess is its ability to update pages and portlets without losing user customization. If you perform your updates via XMLAccess, any user customization to a page or a portlet is retained because the object IDs are retained. Release Builder, helps you deploy new applications from staging to production. It captures the differences between two versions of the configuration and builds a delta XML configuration file that can be imported in the production environment to represent the new deployment.

However, neither of these tools solve the problem of updating the theme or skin artifacts or updating the portlet .war. WebSphere Portal does offer a means to update the wps.ear file with the new theme or skin as well as deploy new portlets. This common task requires the administrator to learn two additional tools such as wsadmin and wpconfig.

Most WebSphere Portal sites use the Personalization features offered. Again, WebSphere Portal offers yet another tool that allows the administrator to stage personalization rules from one server to another. This tool is called pznload.

At this point, you are probably getting the sense of what is required to manage WebSphere Portal.

We are not done. Almost every WebSphere Portal deployment relies on at least one enterprise application deployed to WebSphere. Therefore, upgrades to portlets sometimes require upgrades of the Enterprise application that supports the portlet. Now, the WebSphere Portal administrator needs knowledge about WebSphere administration too.

It is easy to draw a conclustion that because WebSphere Portal encompasses so many topics, the management of WebSphere Portal is extremely difficult, especially in a fault-tolerant, scalable solution.

We at Phurnace experienced these difficulties first-hand. From a developer's point of view, this pain was the driving force behind creating a new product, Phurnace WebSphere Portal Deliver. Phurnace WepShere Portal Deliver leverages each of these tools that IBM provides internally. Phurnace utilizes the same technology and tools that a WebSphere Portal administrator does today. However, it offers additional intelligence around working with these tools, handling errors, and even working around defects in ReleaseBuilder. Finally, with Phurnace, the processes can be fully automated and after deployments are complete the user is left with a report detailing what changed. Therefore it is faster, easier and there is an audit trail that is automatically produced. With Phurnace WebSphere Portal Deliver, the administrator only has to learn a single tool and that tool will make their jobs a whole lot easier.

In WebSphere Portal xmlaccessWebSphere Portal
Comment (0) Read More...


Posted by: Wesley Willard on

Scala is yet another modern programming language which has received a lot of attention in the last few years. It compiles down to Java bytecode, therefore can take full advantage of existing Java libraries.

I'd like to take a few moments to share a couple of examples of one area that I think Scala shows great strength, processing of XML data. For my examples, I will be using XML data that has been aquired through using the WebSphere Portal tool, xmlaccess. This tool accesses a portal instance's configuration data and returns an XML file that can in turn be used to modify the portal's configuration.

So, assuming we have an XML file that has been created via xmlaccess, we can then use Scala to process it. To load the file, we define a Scala object, import some library packages, and then call :

object ScalaXML extends Application {
import scala.xml._
import scala.collection.mutable.HashMap
import scala.collection.jcl.ArrayList
import java.util.Set
import java.util.HashSet
import java.util.Map
import java.util.TreeMap

//
// Load the XML file
//
val xml = XML.loadFile("test.xml")


In Scala, the '_' symbol serves the same purpose as the '*' in Java in an import statement. The XML.loadFile takes a file path, and creates a val variable, which is immutable. The value in the variable 'xml' is now the parsed XML data. This statement displays the simplicity of coding that is also makes Scala very powerful. Java would require several lines of code to do the same thing.

Next, we do a simple XML pattern match to find the version of the XML data that is in the xmlaccess file.

//
// Search for an XML element with an attribute named
// 'version', and print out the value of that attribute
//
println("Version " + ( xml \\ "@version").text)


The text method is a method on the Node class, and is used to access the 'version' attribute's value. The method println is a method on the Scala class scala.Console, which is implicitly imported.

Here is an example of creating a Scala Map of the elements from the file:

//
// Create a Scala Map by pattern matching 'Skin' elements
// The map's value object is the map of attributes
//
var oidMap = new HashMap[String, MetaData]
for (val entry <- xml \\ "skin") {
val objectid = (entry \\ "@objectid").text
val attributes = entry.attributes
oidMap += (objectid -> attributes)
}


The Scala Map functions the same as a Java Map, but uses some different syntax for adding objects. The '+=' symbol is actually a method defined on the class HashMap. In this example, the variable 'objectid' is the map's key, and 'attributes' is the map's value for each entry. We have a for loop here, in which the values of an XML pattern match are assigned to the val variable 'entry'.

To illustrate usage of a Java class in Scala, here is the same for loop, but now we are creating a Java TreeMap:

//
// Create a Java Map of the same elements
// The Set's value object is again the attributes
//
var oidJavaMap = new TreeMap[String,MetaData];
for (val entry <- xml \\ "skin") {
val objectid = (entry \\ "@objectid").text
val attributes = entry.attributes
oidJavaMap.put(objectid, attributes)
}

Now, let's process the Scala Map:

//
// Now iterate through the Scala Map to create
// a new List of Node which contains new Element
// objects replicating the original XML for the Skin
//
println("Iterating through Scala Map");
var nodes = new ArrayList[Elem]()
oidMap.foreach{ (nvPair) =>
val objectid = nvPair._1
val attributes = nvPair._2
var elem =
var newElem = elem.%(attributes)
nodes += newElem
}

This loop will create a new Scala ArrayList. The foreach construct allows you to iterate through the Scala Map, executing the body of code enclosed in the braces (a closure) with the argument 'nvPair'. Closures are common in functional languages like Scala, where functions can be passed around as arguments. The elements of our new list are of type Elem, even though we do not explicitly declare a variable of this type. Scala is able to infer the type of the variable from the text on the right side of the '=', which is a well-formed XML tag. The '%' operator is a method on Elem, an returns a new Element that contain the updated attributes in the variable 'attributes'. Because we are operating on a Map, the variable 'nvPair' is a key-value pair, which can be access with the _1 and _2 syntax for key and value, respectively.

We can output our new list as XML by doing the following:



//
// Create a new XML snippet with the Node objects from above
//
def xmlString =

xsi:noNamespaceSchemaLocation="PortalConfig_6.0.1_1.xsd">
{nodes}

//
// Output a prettied-up version of the new XML
//
println( new PrettyPrinter(80 /*width*/,4 /*indent*/).format(xmlString) )




This code shows us again how you create an XML object by simply in-lining the XML data. You can also embed the values of variables in this XML, as we do with the variable 'nodes'. Scala provides a built-in "pretty print" class, PrettyPrinter, which is used to make the output more readable.

The last bit of example code shows how you can use what looks like plain old Java to iterate through our previously created Java Map.

//
// Iterate through the Java Map and print out some attributes
//
cnt = 0;
println("Iterating through Java Map");
var iterMap = oidJavaMap.keySet().iterator();
while (iterMap.hasNext()) {
var key = iterMap.next();
var attributes = oidJavaMap.get(key)
var objectid = attributes.get("objectid")
println("Objectid " + cnt + " is " + objectid.get)
var resourceroot = attributes.get("resourceroot")
println("Resourceroot " + cnt + " is " + resourceroot.get)
var uniquename = attributes.get("uniquename")
println("Unique name " + cnt + " is " + uniquename.get)
cnt += 1
}


This is pretty straight-forward code, and look almost identical to Java code. You might notice how we access indvidual attribute values with two different get methods. This first is a method on the class MetaData, which is the abstract base class for the element's attributes. This returns an Option object, which also has a get method. This second invocation returns the value of the attribute.

In WebSphere Portal xmlaccessScala
Comment (0) Read More...


Posted by: Robert Reeves on

On September 26th, IBM will stop supporting WebSphere 5.1 and its various flavors. Nothing is particularly unusual about software companies ending support for aging products. But, the timing is terrible for customers who wish to upgrade to WebSphere 7.0.

IBM does provide an option for extending your support in a new “5 + 3” support policy. The policy has expanded the standard length of support to five years from three and the length of available extended support to three years from two.

Applying this new policy to WebSphere 6.1, we can expect IBM to reach end standard support on June 30, 2011. If one was to upgrade immediately to 6.1, you would have to migrate again in less than three years. Considering that most upgrades are measured in months, if not years, one could argue that three years is simply not enough time to amortize the upgrade costs. The end result: with the end of life of 5.1 happening before the general availability of 7.0, customers are feeling pressure to purchase the extended support to help them bridge to 7.0.

Moreover, the uncertainty of how long that migration will take is unnerving. Without a large investment of time and energy, one is unable to effectively estimate the migration effort. Simply put, most companies will have to leap before they look. Scary.

There is another option. Phurnace Deliver provides customers the ability to Snapshot a 5.1 instance and Deploy to a 6.1 instance. We will take your System Resources, Servers and other usual suspects, and migrate them to a 6.1 instance. Phurnace Deliver will even redeploy the Applications for you. You might find that you don’t need to rewrite any code and simply needed to move the EAR and System Resources to the new 6.1 instance. Or, you may be able to quickly identify problem areas to resolve before migration.

Either way, it’s a simple, cost effective way to have a look before you leap into an upgrade.

In WebSphere
Comment (0) Read More...


Posted by: Robert Reeves on

MCC

Phurnace Software makes its home at the MCC building, which is owned and managed by the Unversity of Texas at Austin . Quite a few really neat companies are located here, including Bigfoot Networks . But, there is no company in the building named MCC. So, what the heck does MCC stand for? Short answer: Microelectronics and Computer Technology Corporation

Wikipedia has a brief article on MCC . Here's a brief snippet:

"In late 1982, several major computer and semiconductor manufacturers in the United States banded together and founded MCC ... as an American answer to Japan's Fifth Generation Project, a large Japanese research project aimed at producing a new kind of computer by 1991."

Most of the projects they worked on involved Artifical Intelligence. A really cool project, InfoSleuth which was a very early web search engine. This focus on AI can still be seen, to some degree, at the University's CS department. Of course, the good times couldn't last forever. Mainframe companies began to get pushed aside by IT companies, but when the bubble popped, the members support for external R&D evaporated. MCC ended in 2000.

So, what happened to the Fifth Generation Project? Total and complete failure . They got their butts whipped by Sun and Intel processors. Cheap and fast beats expensive and fast. Always.

The reason I began thinking about this is because of the NY Post article yesterday about the Abu Dubai Investment Council purchasing the Chrysler Building. Of course, Drudge picked up on it and has had it in RED as the top link all of yesterday. Seeming to say that our most treasured symbols of America are being purchased by a foreigner. OH NOES!

 Please. Sony bought Columbia Pictures. Matsushita bought Universal Studios. Mitsubishi bought Rockefeller Center. From my perspective, when a foreign investor starts investing in the US, they are typically 12 months from a fall . You read it here first, folks.

So, what is the difference between Sun and Intel versus MCC in the 1980s? Profit. Pure and simple. By allowing the companies that researched and developed x86 and RISC to directly profit, we have provided them a strong incentive to create jobs and wealth.
 
Thankfully, profit is a better motivator than hand-wringing, chicken-little jingoism.
 

In Untagged 
Comment (0) Read More...


<< Start < Prev 1 2 Next > End >>