Michael Ellis, one of my colleagues in ISSW is one of the worst people to have in attendance at a talk. I like Michael a lot and he's a great team player (and a decent Curler I understand), but he also likes to put you on the spot and ask the hard questions. A few years back, I delivered a talk on Iterative development at some conference (WebSphere Technical Exchange, I think). Michael sat in the front row. That's intimidating enough.
Anyway, I was a few minutes into my talk when he asked me if I distinguished between "incremental" and "iterative" development. At the time, I told him "no". That was the wrong answer, but he had me on the spot and I panicked. My problem was that I've only ever done iterative development and never really considered what the differences might be.
I caught myself thinking about this as I prepared the talk for WebSphere Technical Exchange this year. My colleague Isabelle Mauny will be delivering the talk in Dusseldorf, and I will be delivering it in Miami. Thinking of Michael, I have added a slide to the all-new talk that distinguishes between the two.
Iterative development, as the name suggests involves iteration. Iteration means that you're going to revisit code that you've already written to either add to it or updating it (i.e. you will spend time refactoring existing code). Incremental development doesn't necessarily imply that you're going to revisit existing code, but more that you are going to incrementally add to the code. In both cases, you visit all stages of development frequently, but the big difference with incremental development is that you don't necessarily make changes to what you already have.
Iterative development is more change-friendly.
If you're interested in further reading, check out Iterative Vs Incremental.
So there, Michael.[Read More]
Eclipse hints, tips, and random musings
I can't see that I see a lot of use of entity beans with container-managed persistence. On the other hand, I do see it every so often. It seems that not everybody has given up on CMP. CMP has taken a bit of a hit over the years. The early versions of the specification were horrible and the first implementations weren't all that good. Still, some folks pushed through and were able to be successful with them. EJB 2.0 addressed some of the shortcomings of entity beans, but the masses don't seem to have flocked back to them. Still, I do see them once in a while.
There are problems with CMP. They still feel a little more coarse grained than entities should be. The features provided in Rational Application Developer for building entity beans are quite good, but do lack a few essential features. Specifically, it is pretty cumbersome to specify EJB-QL for a a finder query. I wonder if the problem is that we've come to expect things like code completion, and when it's not provided we get lost. Perhaps worse is the fact that RAD doesn't give you very much help when there's a problem with the EJB-QL (I recently fought with a particularly annoying misdiagnosed error). I also find specifying relationships a little "clunky" and have to spend a few minutes trying to sort out what all the controls on the dialog actually mean.
Still, CMP is a reasonable solution if you have relatively simple persistence needs. Perhaps the most compelling reason to look at CMP is the fact that there is built in support for it with RAD and WebSphere Application Server, so you don't have to go looking for it. I always consider it first when I need a persistence solution; if after deeper reflection I find CMP wanting, I'll consider some other options.
So... have you given up on CMP? If so, drop me a line and tell me what you use.[Read More]
While Java is intended to be "write once, run everywhere", it's more the case that J2EE is "write once, redeploy everywhere". Actually, as I recall, isn't it more the case that Java is "write once, debug everywhere"? But I digress...
Migrating from a competitive J2EE platform like JBoss or WebLogic tends to be primarily an exercise of redeploying the J2EE artifacts contained in the application. I frequently run into platform-specific things, but very often those things require a relatively small effort to migrate.
Redeploying J2EE artifacts can be time consuming. In some cases it can be hard work. The J2EE specifications stop short of specifying how everything you need to have in a J2EE application. For enterprise beans in EJB, there is no standard way of providing a JNDI name; nor is there any standard way of providing persistent field mappings for entity beans using container-managed persistence (CMP). This sort of information is provided in different ways by the different vendors. Normally, this information takes the form of extended deployment descriptors (actually, I'm pretty sure that it always takes that form).
For applications deployed on WebLogic Server, you provide a weblogic-ejb-jar.xml file that contains all the name bindings (along with lots of other useful information) along with a weblogic-cmp-rdbms-jar.xml file to specify the mapping between the entity beans and database tables. In WebSphere Application Server, this information is represented in the ibm-ejb-jar-bnd.xmi and Map.mapxmi files respectively. I strongly discourage anybody from trying to build either of these files by hand; while XML-based, the format is not intended to be human readable, nevermind writeable.
Your best bet to redeploy the application is to use the editors and wizards in Rational Application Developer or the Application Server Toolkit. If your code uses XDoclet annotations, you may be able to leverage WebSphere Rapid Deploy as well.
This discussion has come a long way to arrive at the point of this posting. Is it all worth it? It can be a heck of a lot of work to redeploy J2EE artifacts. Especially if you have a lot of them. I once spent two weeks redeploying ninety entity beans (it's mind-numbing work). Would it be better to instead use a third-party or open source framework? As a consultant, I am (of course) not going to give you a firm answer. I'm falling back on age-old consultant non-answer: it depends.
Two questions (it's actually one big question) you have to ask yourself when you adopt any technology is what is it going to cost me now? and what is it going to cost me later?
Some factors to consider:
There are no easy answers.[Read More]
A common mistake made in migrations from competitive products to WebSphere Application Server is that of only thinking of the application code. In my experience, in most cases, the code is a relatively small part of the migration equation.
Application code from, say, WebLogic Server, can very often be migrated in a matter of a few days or even hours. Of course, sometimes it can take weeks or months, especially if a lot of WebLogic-specific code is used. As a general rule, however, most of the time you spend migrating the "code" will be during the migration of the extended deployment descriptors.
In general, an organization will spend more time in skills development, testing, and production rollout than they will in making changes to code. Of course, the best way to know what you have to do is go through a proper assessment.[Read More]
My talented colleague Ahmed and I ran into a pretty common "bug" today while working on a migration from JBoss to WebSphere Application Server.
We used Rational Application Developer and a little home brewed tool to migrate the application code. I'd like to say that it went off without a hitch, but it didn't. It did, however, get done. One of the nastier problems we had to deal with was a rather healthy set of EJB-QL queries with some proprietary JBoss constructs. Nasty stuff. Anyway, we got it running.
During testing, we encountered an exception that indicated a serialization problem. These are (as I stated earlier) pretty common. After careful inspection, it turned out that a parameter to one of the methods in a session bean's remote interface was itself serializable, but one of the values it contained was not. In order to pass an object to an enterprise bean with a remote interface, that object and all the contained objects must be serializable (an object is serializable if its class implements
But it worked in JBoss. We reasoned that JBoss should have the same serialization requirements as WebSphere Application Server. After some digging, we determined that JBoss must automatically pass values by reference when the client and server are in the same JVM (we assume this because our client was not aware of having explicitly turned on this ability). Of course, WebSphere Application Server can also do this. The difference is that the feature must be explicitly turned on in WebSphere Application Server.
This, of course, touched off a debate. Should this just work automatically as JBoss does, or should you have to explicitly turn it like WebSphere Application Server requires? In my biased opinion, I believe that WebSphere Application Server does the right thing. What do you think?[Read More]
Bobby wrote about this a few months back, but I thought it might be time for a refresher.
It's perfectly natural to have more than one workspace with Rational Application Developer. However, you'll quickly run into "odd" problems if you attempt to share a single WebSphere Application Server instance between your workspaces.
You need to create a separate profile for each workspace. Since the test environment in Rational Application Developer is just WebSphere Application Server, you can use the profile creation wizard to do this (it's found in the "runtimes/base_v6/bin" directory). I tend to create profiles with names that have some connection to the set of projects contained in the workspace. I might name the profile after the client I'm working for, for example. This helps to keep it clear in my mind.
If you don't intend to have multiple test servers running at the same time, you can have your profile use the default ports (this makes configuration easier later). If there is some chance that you might be running multiple servers (perhaps you may have to test in multiple workspaces concurrently -- in which case you'd better have gobs of RAM). Whatever the case, keep track of the "ORB bootstrap port" or "SOAP connector port"; you'll need it when you configure servers in Rational Application Developer.
When you use the "Servers" view to create a new server in Rational Application Developer (or edit an existing configuration), you'll need to specify the name of the profile and the ORB bootstrap port or SOAP connector port (whichever you choose to use).[Read More]