Why Forte mi­gra­tions should use Atomikos

Forté/UDS is an end-of-life tech­nol­o­gy that used to be in Sun's prod­uct port­fo­lio. When talk­ing to peo­ple who have been do­ing a lot with Forté in the past, it seems that Forté can be con­sid­ered an an­ces­tor of Java:

• It has an ob­ject-ori­ent­ed (4GL) de­vel­op­ment lan­guage.
• Like Java's JMX, Forte also has in­stru­men­ta­tion (the agent is even called icon­sole - like jcon­sole for Java's built-in JMX agent these days!).
• It has dis­trib­uted trans­ac­tions.
• It has a strong no­tion of events as first-class cit­i­zens in the lan­guage.

The only thing that Forté does not have is En­ter­prise JavaBeans (EJB), nor XML con­fig­u­ra­tion is­sues for the ap­pli­ca­tion serv­er. This means that Forté de­vel­op­ers who mi­grate to Java (be­cause they are left lit­tle choice) get con­front­ed with com­plex­i­ties that they did not have to both­er with in their 4GL en­vi­ron­ment.

Thanks to Atomikos and the J2EE with­out ap­pli­ca­tion serv­er method­ol­o­gy, teams who used to work in Forté can eas­i­ly do Java/J2EE with­out hav­ing to both­er about the clut­ter of EJB nor about the ap­pli­ca­tion serv­er's XML hell. What's more, in com­bi­na­tion with Spring, Hiber­nate and JMS there is an equiv­a­lent, light-weight Java stack that (thanks to Atomikos) can still do all the con­nec­tion pool­ing, event-dri­ven and trans­ac­tion­al pro­cess­ing that is need­ed.

What makes it even bet­ter is that this method­ol­o­gy seems to achieve equal pro­duc­tiv­i­ty as with the 4GL en­vi­ron­ment in Forté, which is pret­ty good giv­en that Java is a 3GL and is not wide­ly known as a pro­duc­tiv­i­ty mir­a­cle.