Timeline for Websphere Portal Server 7.0

Websphere Portal Server is our current technology boat anchor. We’re stuck on Websphere Portal Server 5.1 until there’s a new release. Today we got the real picture on the release schedule from an IBM Portal Architect:

  • Portal Server 6.0 late summer
  • Portal Server 6.0.1.x maybe November 2006 (the stable one he recommended waiting for)
  • Portal Server 7.0 early 2007

So possibly this time next year we can finally move up to Java 1.5 after waiting about 2.5 years.

UDDI is Dead?

In a meeting today with a lot of IBM Websphere product architects they didn’t quite come to the conclusion that UDDI was dead, but they did say that at this point UDDI is an important spec, but it’s just not meeting the needs of people trying to roll out SOA architectures.

IBM’s thoughts around this assume that everyone is coming to the same conclusion that UDDI just doesn’t do enough so they’re creating more functional replacements. The replacement is called Websphere Service Registry and Repository Capability at this point. I’m not sure whether there are more WS* specs or Websphere branded products in the world.

At this point they didn’t have a whole lot of details around there product in particular, but they were willing to speculate on where UDDI is going. There idea is that a few proprietary approaches are being developed by vendors and then a spec process will happen after some experimentation and everyone can essentially agree on the UDDI replacement or UDDI 2.0.

They didn’t really seem too out in left field on this as our company architect has been telling me UDDI is pretty much dead on arrival for a while now. In addition at a Bird of a Feather session on SOA at SD West 2006 I asked how many of the 50 participants were using UDDI. One brave soul raised his hand from the State of Oregon. He said they did have a UDDI registry setup and a few web services registered with it. He then explained that everyone using their web services had hard coded them without using the UDDI registry at all.

Test Driven Development Doesn’t Mean Test First?

In a post to the errata for Agile Web Development With Rails, the commenter notices that the the book barely touches on traditional TDD where you actually write the test first:

#2327: The author enters several assertions before ever trying to run the test. As this section is on TDD, it might be better to get the test to pass at the assertion of the flash. Then add the next assertion. The reader would get a better feel of the flow of tdd (write a little bit of test, see it fail, write a bit of code to make it pass, see the test pass, refactor, repeat).

Dave’s follow up is enlightening:

(Dave says: I believe this is a confusion between Test First Development and Test Driven Development. TDD doesn’t require tests to be written first)

So again the argument crops up around what Test Driven Development really is? My experience points to Kent Beck’s explanation that TDD is:

Test-Driven Development (TDD) is the powerful combination of two techniques: test-first programming, in which the programmer writes automated tests in advance of implementation, and incremental design, in which the programmer continually improves the design of the software to match the actual requirements.

Or Scott Ambler’s:

Test-driven development (TDD) (Beck 2003; Astels 2003), is an evolutionary approach to development which combines test-first development where you write a test before you write just enough production code to fulfill that test and refactoring.

Or Wikipedia:

Test-Driven Development (TDD) is a computer programming technique that involves writing test cases first and then implementing the code necessary to pass the tests.

Or Bob Martin:

The steps:

  • Write a test that specifies a tiny bit of functionality
  • Ensure the test fails (you haven’t built the functionality yet!)
  • Write only the code necessary to make the test pass
  • Refactor the code, ensuring that it has the simplest design possible for the functionality built to date

I may have missed a memo somewhere, but TDD doesn’t compromise on test first. I think the only confusion is that the name Test Driven Development isn’t as clear as something like Test First Development or Test First Design. Of course we seem to be headed towards approaches like Dave Astel’s Behavior Driven Development to help alleviate any confusion like this.

Testing Rails Helper Classes

I’m making my way through Agile Web Development with Rails TDD style after an earlier sillier attempt at waiting until the testing chapter about 150 pages into the book. I really like the skeletons for unit tests and functional tests. Then I wanted to test the following helper method in the ApplicationHelper class:

def fmt_dollars(amount)
    sprintf("$%0.2f", amount)
  end

This resulted in a bit of thrashing for about 30 minutes without much luck until I came across a post by Doug Alcorn on Testing Rails Helpers. The solution looks like:

require File.dirname(__FILE__) + '/../test_helper'
class ApplicationHelperTest < Test::Unit::TestCase include ActionView::Helpers::TextHelper include ActionView::Helpers::TagHelper include ApplicationHelper # include whatever helpers you want to test here, sometimes you'll need # to include some of the Rails helpers, as I've done above.
def test_formatting_dollars assert_equal "$29.90", fmt_dollars(29.9) end end

Considering unit testing utility classes are some of the easiest things to test in Java I felt a bit incompetent when I had a tough time with this. I think I need to better understand how Ruby does packaging with modules and how the include keyword really works.

IBM to Support Java 1.5 in 2006

OK, it’s the end of 2006, but at least our development shop can return to Java 1.5 when IBM releases a new version of RAD in the second half of 2006. There exact words from the press release are:

IBM intends to ship a new version of Rational Application Developer in the second half of 2006.

I’m just going to hope for the best here, but realistically I bet the next version of RAD may slip to 2007.

The more interesting statement is:

Full Java 2 Platform, Standard Edition (J2SE) 5.0 support across all offering…

This statement concerns me. They make absolutely no comment on Websphere Portal Server. Currently the boat anchor in our web stack is Websphere Portal Server 5.1. If I’m reading this correctly, they say there going to support Java 1.5 across all their offerings, but they’re not going to release a new version of Portal Server. Hopefully this was just an oversight in marketing.

At least I’ll get a chance to ask some actual IBM Websphere folks in person this week. The first question will be when Portal Server will finally get upgraded to support Java 1.5.