Who’s On Phirst

Before we get started here are a couple of definitions that may help you understand this example.

• A wizard is a series of pages that guide a user through a complex task.
• JFace is a user interface framework that is used to handle many common UI programming tasks.

JFace provides all the user interface components needed to create a wizard for your application. Most of the time when designing a wizard you will know at design time how many pages are required to complete each step of your wizard. But on occasion you will run across a use case where you need to create pages dynamically based upon the user’s input from a previous page. Solving this problem with JFace is a little tricky, so I’ve created an example program demonstrating how to dynamically create wizard pages based upon the input from the first page. Give it a try and let me know what you think.

import org.eclipse.jface.wizard.IWizardPage;
import org.eclipse.jface.wizard.Wizard;
import org.eclipse.jface.wizard.WizardDialog;
import org.eclipse.jface.wizard.WizardPage;
import org.eclipse.swt.SWT;
import org.eclipse.swt.events.SelectionAdapter;
import org.eclipse.swt.events.SelectionEvent;
import org.eclipse.swt.layout.FillLayout;
import org.eclipse.swt.layout.GridData;
import org.eclipse.swt.layout.GridLayout;
import org.eclipse.swt.widgets.Button;
import org.eclipse.swt.widgets.Composite;
import org.eclipse.swt.widgets.Display;
import org.eclipse.swt.widgets.Shell;

/**
 * Example program demonstrating how to dynamically add pages to a JFace Wizard.
 *
 * @author Shawn Spiars 
 * 
 */ 
public class DynamicWizardPageExample {

      private static class MyWizard extends Wizard {
            public MyWizard() {
                  super();
                  setForcePreviousAndNextButtons(true);
            }

            public void addPages() {
                  addPage(new StartingWizardPage());
            }

            public boolean performFinish() {
                  return true;
            }

            @Override
            public IWizardPage getNextPage(IWizardPage page) {
                  IWizardPage nextPage = super.getNextPage(page);
                  
                  //TODO - create logic here to skip pages that you
                  //have added to the framework, but no longer wish to display
                  
                  return nextPage;
            }

      };

      private static class StartingWizardPage extends WizardPage {
            private Button firstPageButton;
            private Button secondPageButton;
            private Button thirdPageButton;

            protected StartingWizardPage() {
                  super("startingPage");
                  setTitle("Starting Page");
              setMessage("Select the desired pages and press the Next button.");
            }

            public void createControl(Composite parent) {
                  Composite composite = new Composite(parent, SWT.NONE);
              GridLayout layout = new GridLayout(1, false);
              layout.verticalSpacing = 12;
              composite.setLayout(layout);
              composite.setLayoutData(new GridData(GridData.FILL_BOTH));
              
              firstPageButton = new Button(composite, SWT.CHECK);
              firstPageButton.setText("Page One");
              firstPageButton.addSelectionListener(new SelectionAdapter() {
                        public void widgetSelected(SelectionEvent e) {
                              Wizard wizard = (Wizard) getWizard();
                              wizard.addPage(new MyWizardPage("Page One"));
                              getContainer().updateButtons();
                        }
                  });
              
              secondPageButton = new Button(composite, SWT.CHECK);
              secondPageButton.setText("Page Two");
              secondPageButton.addSelectionListener(new SelectionAdapter() {
                        public void widgetSelected(SelectionEvent e) {

                              Wizard wizard = (Wizard) getWizard();
                              wizard.addPage(new MyWizardPage("Page Two"));
                              getContainer().updateButtons();
                        }
                  });
              
              thirdPageButton = new Button(composite, SWT.CHECK);
              thirdPageButton.setText("Page Three");
              thirdPageButton.addSelectionListener(new SelectionAdapter() {
                        public void widgetSelected(SelectionEvent e) {
                              Wizard wizard = (Wizard) getWizard();
                              wizard.addPage(new MyWizardPage("Page Three"));
                              getContainer().updateButtons();
                        }
                  });
              
              setControl(composite);
            }
            
      }
      
      private static class MyWizardPage extends WizardPage {
            protected MyWizardPage(String pageName) {
                  super(pageName);
                  setTitle(pageName);
            }

            public void createControl(Composite parent) {
                  Composite composite = new Composite(parent, SWT.NONE);
                  setControl(composite);
            }
      }

      public static void main(String[] args) {
            Display display = new Display();

            final Shell shell = new Shell(display);
            shell.setLayout(new FillLayout());

            Button b = new Button(shell, SWT.PUSH);
            b.setText("Press here to open wizard");
            b.addSelectionListener(new SelectionAdapter() {
                  public void widgetSelected(SelectionEvent e) {
                        WizardDialog dialog = new WizardDialog(shell, new MyWizard());
                        dialog.open();
                  }
            });

            shell.open();

            while (!shell.isDisposed()) {
                  if (!display.readAndDispatch())
                        display.sleep();
            }

            display.dispose();
      }
}

For more information on JFace, check out these links:

• http://wiki.eclipse.org/The_Official_Eclipse_FAQs#JFace
• http://www.eclipse.org

In Untagged 
Comment (0) Read More...

In the world of fast paced development, you are usually tasked to deliver some features in a very short turnaround time. Does this sound familiar to you? Especially if you are in an IT shop, you find yourself more and more like an assembler, you just integrate and connect software together for the final product, and you have to rely on tools of the 21st century.

I was given, or rather volunteered, to pull data from one web application to display on a client’s web application remotely. The web application that provided the necessary data used EJB for all its CRUD operations. Instead of reinventing the wheel, I added more methods to the stateless session bean to expose the data that I needed.

First step, with EJB 2.1:
Axis is the best tool for this that I have found. Axis is packaged as another web module into your application and exposes the EJB methods as a Web Service.

The Axis server-config.wsdd needs to define the Web Service.

<deployment xmlns="http://xml.apache.org/axis/wsdd/"
             xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
     <service name="AdminService" provider="java:MSG">
     <parameter name="allowedMethods" value="AdminService"/>
     <parameter name="enableRemoteAdmin" value="false"/>
     <parameter name="className" value="org.apache.axis.utils.Admin"/>
     <namespace>http://xml.apache.org/axis/wsdd/</namespace>
     <namespace>http://xml.apache.org/axis/wsdd/</namespace>
    </service>
     <service name="Version" provider="java:RPC">
     <parameter name="allowedMethods" value="getVersion"/>
     <parameter name="className" value="org.apache.axis.Version"/>
    </service>
     <service name="Verify" provider="java:RPC">
     <parameter name="allowedMethods" value="getAxisVerification"/>
     <parameter name="className" value="com.mycompany.dataserver.model.session.DataEJBService"/>
    </service>
   <handler name="URLMapper" type="java:org.apache.axis.handlers.http.URLMapper"/>
  <transport name="http">
     <requestFlow>
         <handler type="URLMapper"/>
     </requestFlow>
  </transport>
  <service name="DataByPersonId" provider="java:EJB">
     <parameter name="scope" value="application"/>
     <parameter name="beanJndiName" value="java:comp/env/DataEJB"/>
     <parameter name="homeInterfaceName" value="com.mycompany.dataserver.model.session.DataEJBLocal"/>
     <parameter name="remoteInterfaceName" value="com.mycompany.dataserver.model.session.DataEJBLocal"/>
     <parameter name="allowedMethods" value="getDataByPersonId,getDataByOrgId,getDataIDsByOrgId"/>
     <parameter name="className" value="com.mycompany.dataserver.model.session.DataEJBBean"/>
     <beanMapping xmlns:ns="urn:DataByPersonId.session.model.dataserver.mycompany.com" qname="ns:DataWsDTO"
          languageSpecificType="java:com.mycompany.dataserver.model.datatransferobject.DataWsDTO"/>
 </service>
  </deployment>

Since the EJB did not support the remote interface, the web.xml for the Axis servlet needs to define the reference to the session bean.

    <ejb-local-ref>
     <ejb-ref-name>DataEJB</ejb-ref-name>
     <ejb-ref-type>Session</ejb-ref-type>
     <local>com.mycompany.dataserver.model.session.DataEJBLocal</local>
     <ejb-link>ListingsEJB</ejb-link>
   </ejb-local-ref>

First step, with EJB 3:
Life is much easier with EJB 3. One just has to use some dependency injection keywords.

The DataEJBBean file:

@WebService(endpointInterface="com.mycompany.dataserver.model.session.DataEJBRemote",targetNamespace="...")
  @Stateless(name="DataEJB")
  @Remote(DataEJBRemote.class)
  @TransactionManagement(TransactionManagementType.CONTAINER)
  @Resource(name="jdbc/MyCompanyDataServerDS", type=javax.sql.DataSource.class)
  @Deployment(contextPath="data-ejb")
  public class DataEJBBean implements DataEJBLocal, DataEJBRemote {
  
     @WebMethod(operationName="featuredData")
     @TransactionAttribute (TransactionAttributeType.SUPPORTS)
     public DataWsDTO[] getDataByPersonId(Integer personId) {
    	.
    	.
    	.
     }
  
     @WebMethod(operationName="featuredData")
     @TransactionAttribute (TransactionAttributeType.SUPPORTS)
     public String getDataIDsByOrgId(Integer orgId) {
     	.
     	.
     	.
     }
    

     @WebMethod(operationName="featuredData")
     @TransactionAttribute (TransactionAttributeType.SUPPORTS)
     public ListingWsDTO[] getDataByOrgId(Integer orgId) {
     	.
     	.
     	.
     }
     
     .
     .
     .
     
    }

The DataEJBRemote file:

    @WebService
    public interface DataEJBRemote extends Remote {
    	@WebMethod
    	public DataWsDTO[] getDataByPersonId(Integer personId) throws java.rmi.RemoteException;
    
    	@WebMethod
    	public String getDataIDsByOrgId(Integer orgId) throws java.rmi.RemoteException;
    
    	@WebMethod
    	public DataWsDTO[] getDataByOrgId(Integer orgId) throws java.rmi.RemoteException;
    }

For EJB 3 at this stage of the game, I would support the remote interface, especially for the Web Services features.

We are all familiar with the software life cycle story, the PM for that container release probably only schedules mainstream use cases into these earlier releases. If you like pain, and you do have the time, you can venture out more.

Second Step, obtaining the WSDL for the Web Service:
If you use Axis, you can use the ant task Java2WSDL to obtain the WSDL. You can also invoke the URL of your web service with "?wsdl" at the end to obtain the WSDL.

Third Step, generate the client stubs for the web service consumer:

I used Axis for this and generated the client stubs from the WSDL obtained in the second step. The client stubs will need to be package into the consumer web applications.

If you are like me, we all have to support the different staging steps: development, QA, and production. Each of the machines for these are different for both the server and the consumers and we only want to move the same ear through these steps of staging.

In the ...SoapBindingStub.java file that is generated by Axis, I modified the static method to pull the Web Service namespace from a properties file. The property file for development, QA, and production will need to reflect its environments.

        public static String getDataWebServiceNamespace() {
            return FileUtils.getDataWebServiceUrl();
        }

Everywhere that the Web Service namespace is needed, use this method to obtain it.

Fourth Step, deployment night:
Deployment night is scheduled late in the evening. Most IT shops do this. After all of the work, the frustration, the hair pulling and frantic reading into Open Source documentation like Axis (we all just LOVE Open Source documentation...), it DID NOT work in the production environment.

So you are now troubleshooting late into the night and the whole deployment team is weary and tempers flare easily.

The deployment system admin person did not move the correct property file into the production environment. Well, it is not their fault totally, you did not spell out exactly what files need to move to where clear enough in the manual deployment instructions.

This is why you need to look into Phurnace Deliver, especially the upload file functionality. It will save you so much time - your time, not machine time, from erroneous manual mistakes.

In Untagged 
Comment (0) Read More...

Let me draw an analogy for you. I want to compare scripting in your IT shop to something near and dear to my heart.

I own over 75 feet of vinyl records, countless organizers that hold 500 CDs each and over a terabyte of MP3, AAC, FLAC and other alphabet soup files. My taste in music runs the gamut of early Jazz to Bop to Soul to Reggae to Punk Rock to…well, you name it and I probably have the album and can discuss it in contemporary context. I not only enjoy music, I have mastered the art of enjoying music. And, like any other passion, my enjoyment of music is enhanced by sharing it with others.

The Mix Tape, now the Mix CD, has been the vehicle by which I have shared my love of music. But, it’s a dangerous proposition. Just like John Cusack’s character in “High Fidelity”, you can easily craft a Mix that only serves to show off your musical taste and not evoke an emotional response from your recipient. The Mix should be treated like a gift. The purpose of a gift is to elicit an emotional response from the recipient, to evoke in the recipient the same feelings that led you to make the Mix in the first place. Look, you don’t by yourself a pair of shoes and tell your wife it’s a gift for her because you really like the shoes. The same goes with the Mix.

That being said, creating a good Mix is a very, very hard task. You must not only have an wikipedic knowledge of music, buy you must also know what the recipient enjoys and what songs will evoke the feelings you are seeking. Fortunately, I have all these things. And, thus, I make really good Mixes for my wife. She loves them and she’s not just saying that to save my feelings. I’ve let a few bad ones slip through Quality Control and I hear about it pretty quickly.

Up until a few weeks ago, the hardest part of the Mix was collecting the songs; in essence, asking the question “What goes with Hot Child in the City by Nick Gilder?” See, my wife loves this song. In fact, she tells me that this is her personal soundtrack that she hears in her head when she’s walking down the street. (Mine is Outa-Space by Billy Preston.)

What has now made this task much easier is the Genius feature in iTunes. I can simply select the song, hit the Genius button and get up to 100 songs in my library that match the song in question. In fact, it uses data from all iTunes users and the iTunes store to correlate songs together. So, if you hit refresh a few times, you get the idea that iTunes thinks “Kiss You Allover” and “Saturday Night” are good fits. That makes sense because “Kiss You All Over” was the song that “Hot Child in the City” knocked out of number one and “Saturday Night” was another late 70’s hit.

But hold on…what’s this?...”Voices Carry” by Til Tuesday!?!? First of all, I hate that song (I like Aimee Mann, though) . Second, I would never even think to put that on a CD. But, I think Maia likes it. So, it goes on the Mix.

So, what would normally take hours and hours of inefficient work, now becomes fun again. “Digging in the stacks” is no longer a reason to not make a Mix. From 100 songs, I can pare down what I think it appropriate and create a good 15 song Mix that really reflects that Maia’s taste and not mine. With some work from the computer, I can get some deeper tracks that I would have never thought off.

This is completely applicable to manually scripting your Java Application Server deployments. Whether you are using your own framework or someone else’s, you’re just working too hard. And for what purpose? Job security, the love of hacking scripts, inability to affect chance in your organization? Well, in fact, those are the most common reasons we have seen that individual contributors cite for using manual scripting.

Unfortunately, not a single one of those reasons will improve your company’s bottom line. Over the next few blog postings, I will revisit each of these ideas to show how all of these reasons are more than false; in fact, they’re dangerous to the individual contributor and the company.

In Untagged 
Comment (0) Read More...

So, as I am sure any reader of this is aware, agile programming methodologies (like Extreme Programming (which for some reason is called XP, not EP)) are all the rage nowadays. Seems like everyone is doing it, from small scrappy ones (ahem) to giant behemoths. Personally, I’m a big fan. Sure, it’s no silver bullet, but it beats the crap out of the age old waterfall projects I worked on back in the day.

Here at Phurnace we try to be agile. We do mostly 4 week iterations, which typically include 1 week of planning and 3 weeks of “doing.” All told, it works pretty well. One thing that we do a bit differently than any other place I work at though is how we approach scheduling – which, shocking, is the subject of this entry. Using this scheduling methodology we have hit the date for 20 of our 23 iterations. Once we were a day early, and twice we were a day late. Personally, I think that’s pretty awesome.

Here’s how we approach scheduling. For those interested, this approach is based in larger part upon work done by Dr. Eliyahu M. Goldratt and his Theory of Constraints (TOC) and Critical Chain Methodology. That, in turn, is also largely based on operations theory and the Central Limit Theorem. We don’t slavishly follow Dr. Goldratt’s methodology, but we borrow heavily from it (so credit where it is due). If you are interested, read Dr. Goldratt’s book The Goal for an intro to the TOC and Critical Chain for more depth on the Critical Chain Method.

Now that you are suitably impressed by my ability to hyperlink, let’s get into some specifics:

Because we are good and agile, all our planning starts with a customer story. You know the drill – “The customer should be able to something when they something in order to accomplish something else.” Stories for the most part come from products land, but anyone can write one. Well, except sales. We tried that once. Let’s just say boundaries are there for a reason. We use Xplanner to organize our stories.

So, at the beginning of the iteration we sit down and figure out what stories we would like to work. We always choose too many stories, but the temptation to “add just one more” is too much to resist. We also prioritize the stories, and try to build one to three central “themes” of the iteration. But once we have the stories selected we present them to Dev. Dev has a week to estimate and plan how to get those stories done.

The thing about estimating development (coding, testing, etc.) work that’s hard is that for the most part you have never done the task to be scheduled before. I mean, sure, you have developed software before; but, you have never developed this software before. If you had, you wouldn’t need to schedule it, right? It would be done already. So, for the most part software estimates are swags – best guesses. Sure, you can do research to improve the swag, but basically it’s still going to have a lot of uncertainty. And it’s that uncertainty that creates one of the big problems with how software tasks are scheduled.

Let me take you through the process that I am used to in a software shop. It goes kind of like this:

Product Manager: “Hey guys! I am super pumped about this next release! This time we are going to add support for 3 new platforms, and also add 2 new UI elements, and fix those 3 critical bugs we shipped with on the last release. So – how long do you think that will all take?”

Developers (thinking): 10 weeks. (This means they think 7 weeks, and give themselves a 40% “fudge factor.”)

Product Manager: Ok. (This means he is planning for 15 weeks, since projects are never on time.)

What’s going on here? The interesting thing is everyone involved is calculating risk, but no one is actually quantifying it. The only thing they are quantifying is an “expected” date – but there’s no analysis as to the underlying risks.

The good news is there are lots of ways to assess risk in estimates. PERT is a good one – and we are going to use a part of PERT to calculate the risk of each task. But PERT has some limitations that we are going to try to jump over. Realize, what we are doing by calculating risk is actually building a probability distribution of the likely completion times of each task.

In Part Two of this series we will go through the exercise of calculating “risk” in software projects, and give a real world example from Phurnace to see how we do it. In Part Three we will take that example and build a schedule that takes into account both actual completion dates as well as the riskiness of the tasks.

In Untagged 
Comment (0) Read More...

This will be exciting news for those of you waiting for the addition of our support of WebLogic 9.2 and 10g. It is now here! Read the press release below for the details:

Phurnace Announces Support for Oracle® WebLogic 9.2 and 10g

Web Application Deployment Software Now Available for All Supported Releases

AUSTIN, Texas — November 21, 2008 — Phurnace Software, Inc., the Java application deployment company, today announced that its flagship product, Phurnace Deliver™, now supports Oracle WebLogic 9.2 and 10g. Phurnace Deliver currently supports WebLogic 8.1, as well as RedHat JBoss™ 4.2 and all of the market available versions of IBM® WebSphere® web application servers. Phurnace Deliver will automate the migration of applications from older to newer versions of WebLogic, therefore speeding the upgrade process for WebLogic customers.

“Phurnace continues to add support for all of the versions of the leading web application servers”, said Daniel Nelson, vp of products at Phurnace Software. He continued, “WebLogic customers have been asking us to support the latest version, 10g, now that they know Oracle will be supporting it far into the future. Deployments of applications as well as migration upgrades will now be seamless for these users.”

Phurnace Deliver provides comprehensive support for IT staff and developers during complex enterprise Java deployments to decrease errors, streamline deployments and avoid the downtime and outages that come with manual or script-based processes. The current user approach of paging through the console or building cumbersome scripts can be reduced or eliminated with Phurnace, therefore freeing up limited IT resources for more value-added tasks.

Phurnace Deliver provides functionality for users including:

• Automated deployment of applications and their required configuration changes
• A “deployment packager” to quickly bundle changes to configurations and deploy them network-wide
• A “migration wizard” for ease of application migration from one version of app server to another
• Ability to compare configurations across environments to aid in troubleshooting
• Direct integration into industry standard source code repositories (e.g. Subversion™, ClearCase®, CVS)
• Direct integration with build and operational systems (e.g. IBM Rational® Build Forge®, HP Server Automation (Opsware), BMC BladeLogic)
• Eclipse RCP graphical user interface and command line interface (CLI) options
• Support for a wide range of web application servers (IBM WebSphere, Oracle WebLogic and RedHat JBoss)

In WebLogic
Comment (0) Read More...

Hi all, we just opened registration for an upcoming webinar we are doing with Forrester Research titled Data Center and Deployment Automation: Stop the Scripting This should be a great session so please join us on December 11th. Details below:

Please join us for this informative webinar featuring Glenn O'Donnell of world-renowned Forrester Research. He will articulate that there is a "much better way" than scripting for repetitive I.T. tasks and that many processes in the data center are now automated. Glenn will also discuss Data Center Automation market trends and share his direct experience with global IT shops in this area.

Phurnace Software VP of Products, Daniel Nelson, will follow up with a brief presentation explaining how application deployments can be automated with specialized software vs. hand-crafted scripts. Daniel will discuss auto-configuration of web application servers and how major corporations are now automating the movement of J2EE apps from dev to test to production.

Date: Thursday, December 11, 2008
Time: 11:00AM - 12:00PM CST
Location: Online
Presenters: Glenn O'Donnell, Senior Analyst at Forrester Research & Daniel Nelson, Vice President of Products at Phurnace Software
Registration: Please register here to reserve your space.

In Scripts, Deployment
Comment (0) Read More...

As my internship comes to a close I look back at the experience and reflect on what I've learned. There has been so much, I won't bore you with all the details, but instead I will summarize the technical skills that I've gained.

First off, some of the main skills that I've learned are related to the Linux command line. Most OSes I've rely on a GUI that gives you point and click buttons. Basically you aren't forced to use command lines day to day in college. But being able to work with some Linux command line gurus I've seen some crazy grep commands. Here's a cheat sheet that's helped me along the way.

Secondly, I've programmed in Eclipse before, but not as extensively as here, my experiences up to this point were simple class projects. I only needed to know some basic debugging and navigation skills. Not here. Now I've learned how to navigate through code fairly quickly to find what I need. Here's another cheat sheet that's helped me.

Next, before I came here I didn't have a clue of what an application server was. Let alone, actually working with one. I've gained valuable experience being able to work with BEA Weblogic, IBM WebSphere and JBoss. I wouldn't have learned this in a common computer science class and have I have also learned that documentation is your friend!

Finally, there are random things here and there that you would pick up from just working with a development team. Like working with VM images, experiencing the day to day operation of software development and taking in all of the information that I can, like osmosis, from my amazing coworkers.

In Untagged 
Comment (0) Read More...

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.0, Properties File Based Configuration PFBC
Comment (0) Read More...

Mark Twain is reported to have once said, “Even if you are on the right track, you will get run over if you just sit there.” How true today when talking about this troublesome economy and I.T. operating plans. The times require action, not just thoughtful direction. I.T. executives across the country have their email boxes full of directives, notes, and “just a thought” memos about cost cutting and doing more with less. Hiring is frozen or worse, cutbacks are being planned. But, the customer-facing applications must continue to be updated at a record pace. System uptime must be maintained or increased to 99.999999%. Is that six sigma or eight? I have never really been clear about that.

Cost containment has always been top of mind for I.T. executives, but right now (post election day, pre-end of the world prediction date by Sequoia Ventures) it is the topic of almost every meeting. So what is a CIO to do? Post internet bubble, costs have already been pulled out, staffs have been reduced and they have never really grown since 2002. Where is the fat? Where is the waste? Where are the savings?

Simple. The answer is Automation. Find manual processes and automate them. Find teams of I.T. people doing the same task month in and month out and that is a target for automation. I, of course, think that automating application deployment is a key. The point however, is to look at all of your repetitive tasks and consider automating them. There are savings there for sure.

Damn, this blog entry is sounding a lot like my last few. But I continue to be amazed at how many manual processes and hacked together scripts are holding corporation’s I.T. together. It seems so Rube Goldberg to me. (Look it up, the old cartoons where the cat chases the mouse which knocks over the glass and spills the water so the waiter slips and throws his tray that hits the light switch …). The answer isn’t a new-fangled SOA-based cloud computing grid that has virtualized instances of web 2.0 socially networked avatars. It is getting back to basics. Define the top priorities. Stop everything below item 5 and then automate where you can and take the time to set realistic expectations with the line of business owners on what is possible and what isn’t.

In Untagged 
Comment (0) Read More...

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 xmlaccess, WebSphere Portal
Comment (0) Read More...