Saturday, June 27, 2009

EJB 3.1 specs heading in the right direction

Since a long time EJB were loosing ground in favour of simpler and more effective programming models. specifically, Spring has become the leading framework to develop and deploy JEE applications.


For these reasons, a sense of urgency is pushing the new EJB specifications toward a massive simplification. This trend was clearly significant when the EJB 3.0 were introduced, and it is continuing now with the latest EJB 3.1.

Ken Saks, the Specification Lead for EJB 3.1, has written a nice summary of the hottest features. "A Sampling of EJB 3.1" shows you the most interesting news. Together with the upcoming Glassfish V3 , which is a very lightweight and OSGi based application server, the new specs can represent a quantum leap in terms of productivity and win back some developers.

It is difficult to predict if it is too late to regain developers' confidence and market quotas, but the combination of JEE 6 + EJB 3.1 + Glassfish V3 seems to be heading in the right direction: no overload of features but simplification.

Specifically, Ken Saks mentions:
  • Ease of Development: the ability to package enterprise bean classes directly in a .war file, without the need for an ejb-jar
  • No-interface View: you don't have to write interfaces if you don't need it
  • Simplified Packaging: You now have the option of placing EJB classes directly in the .war file, using the same packaging guidelines that apply to web application classes.
  • Singletons: A singleton is a new kind of session bean that is guaranteed to be instantiated once for an application in a particular Java Virtual Machine
  • Application Startup/Shutdown Callbacks: The introduction of singletons also provides a convenient way for EJB applications to receive callbacks during application initialization or shutdown

Simplification, is the way to go.

Stumble Upon Toolbar

Monday, June 22, 2009

JMS Over HTTP Using OpenMQ

DZone has an interesting article about new OpenMQ's features:

"OpenMQ provide different transport protocol and access channels to access OpenMQ functionalities from different prgramming . One of the access channels which involve HTTP is named Universal Message Service (UMS) which provide a simple REST interaction template to place messages and consume them from any programming language and device which can interact with a network server. UMS has some limitations which is simply understandable based on the RESTful nature of UMS. For current version of OpenMQ, it only supports Message Queues as destinations so there is no publish-subscribe functionality available."

Read the full article.
About OpenMQ.

Stumble Upon Toolbar

Thursday, June 18, 2009

The end of the body-shopping model

In the very last few years in Italy I have seen many system integrators undertaking what I have always seen as a dangerous path: progressively moving toward low-valued body-shopping. Healthy companies, with a good track of high-level consultancy and custom product development, decided it was more lucrative to only hire inexperienced kids just out of Universities and send them to customers. Two years of experience was enough to classify those kids as "senior developers" and make good margins out of them.

The mixture looked good: horde of young people, rich of enthusiasm and open to accept ridiculously low salaries have been sent to final customers, where the only selection criteria has been: very low daily rates, please. Really, most customers do not even look at resumes, they just want to keep a pressure on daily rates. On the other hands, it happens to read ridiculous job posts here in Italy, for example "A junior developer with at least 5 years of Java experience and 3 years of SAP". And the proposed salary, of course, even more ridiculous.

A lot of consulting companies have seen only one direction: grow the number of employees, grow sales figures, making margins by selling a lot of very junior developers for low daily rates. This has been perceived as an easy path for growth, less risky than investing in new technologies and growing an high-level consulting profile. On the other side, customers only devoted on reducing visible costs, without any kind of performance monitoring, created a bid competition on the lowest rates, regardless of effectiveness. Now they get what they deserve.

One bad day, the financial crisis comes.... One bad, black day, that big customer tells you he doesn't need your 50 kids anymore, because there is no more budget for that project. And the day after, another customer tells you that the expected budget for that new project has been cancelled, so you don't know where to collocate those 30 kids you have just hired. The game is over, as you have to pay salaries for people hanging around your offices without anything to do. You have to start firing people and fighting with unions (Italy and usually Europe is not US, you can't just kick people out of their cubicles and make your employees paying the bill for your lack of strategy). You don't really know the people you hired, because you have parked them to a customer for the last few years and forgot about them. Maybe now it could be time to invest into quality, but it is difficult and a bit late: you realized that you best people left the company a while ago, now you are full of developers with bad habits - they growth without guidance, they never took any good training. Suddenly your revenues disappear, your margins are red and your credit is over.

However, I rarely encounter other kinds of companies, those who are less greedy, have planned to grow at a sustainable rate, invested in less but more skilled people, train their junior developers and discuss reasonable rates with their customers. Those who think about IT in terms of solutions (quality) instead of man-days (quantity) and reward their own people with challenging jobs and decent salaries. Very often, this smaller companies are the ones surviving better to crisis, because they are in control of their business.

Usually, in a free market quality of supply is driven by quality of demand, so I guess customers need to change their purchase habits soon if they want to shape the IT market differently. Quality pays for itself, sooner or later.

"My personal feeling is that this is how any further improvement of the world will be done: by individuals making Quality decisions and that's all. God, I don't want to have any more enthusiasm for big programs full of social planning for big masses of people that leave individual Quality out. These can be left alone for a while. There's a place for them but they've got to be built on a foundation of Quality within the individuals involved. We've had that individual Quality in the past, exploited it as a natural resource without knowing it, and now it's just about depleted. Everyone's just about out of gumption. And I think it's about time to return to the rebuilding of this American resource -- individual worth."

Quote from Robert M. Pirsig, Author "Zen and the Art of Motorcycle Maintenance"

Stumble Upon Toolbar

GlassFish ESB v2.1 has been released

"New in GlassFish ESB v2.1 is clustering for all components, a great number of bug fixes, the inclusion of the IEP SE and Scheduler BC (a new component!), several component enhancements, inclusion of the latest NetBeans 6.5.1 IDE and the latest GlassFish v2.1 application server, and support for AIX 5.3. "

Look at the release notes for more.

Stumble Upon Toolbar

Sunday, May 24, 2009

dutchman's log: GlassFish ESB BPEL cluster with correlation

Marjo wrote an interesting article about "GlassFish ESB BPEL cluster with correlation".

He wrote:

"GlassFish ESB 2.1 will support GlassFish cluster. BPEL will also run clustered. Cluster support includes support for BPEL processes with correlations.

Once a BPEL process instance starts to wait for a correlated receive activity, the instance will be passivated. If the correlated input comes in to any instance of the cluster, the passivated process instance will be re-activated on that appserver instance, also if it is not the appserver instance where the original process was running, and continue where it left off when it was passivated.

To make this work, BPEL persistence must be enabled, and the BPEL engine must be running in a cluster in an appserver domain set up with the cluster profile."

This feature was missing since a long time. Read Dutchman's full article to learn all details.

Stumble Upon Toolbar

Tuesday, April 28, 2009

Surviving the economical climate as a consultant

These are hard times, but there are in my opinion some healthy rules one should remember to survive in this difficult economical climate. Those are only nine, not to be blaspheme...

  1. Be prepared. It sounds obvious, but you need to know your stuff very well. For example, JEE is not about knowing many different application servers (I don't even understand what it means to "know an application server"), it is about "how to design that process so that I am in control of the distributed transactional context". Something like this. Filling your CV with buzzwords and acronyms can lead you to get interviewed by superficial recruiters, but then you are naked if you don't have concrete skills.
  2. Be versatile. You have to be mentally prepared on how to deal with unforeseen environments, technologies and unknown situations. Be prepared to work abroad and to get a flight early on Monday mornings. This is quite usual for US consultants, but young consultants and consulting companies in Europe should start thinking at the whole Europe as a huge market. Exit your comfort zone.
  3. Be consistent. Deliver quality and think on how to solve your customer's business needs, IT issues can't be your only priority. Do not think on how to consume hours and days, instead focus on delivering useful stuff. Be prepared to suggest fixed-price packages: if you really know your stuff you can make good estimations and take the risk, you cannot just move the deadline's responsibility into your customer's shoulders and throw out a timesheet each Friday, it is no more enough.
  4. Improve your skills. Take time to revitalize some old skills and to learn something new. Buy books and study, but expecially experiment on your own.
  5. Accept short terms activities. Learn to live in a world where things change daily, if you are flexible you will have more chances. Being squeamish about a five days assignment don't provide you with a good credit nowadays.
  6. Do not undersell yourself. Flexibility doesn't mean you have to drastically reduce your consulting rates only because a couple of recruiters tell you to do so, it is easier to negotiate discounts before than to increase rates afterwards.
  7. Be business-oriented. Knowing your IT stuff is no longer enough, try to understand and study basic economy, marketing and generally speaking how your customers make their money. Your salary or your consulting fees don't come from magic, there should be a sustainable business and usually has nothing to do with the latest Linux distribution or that cool scripting language that you are so eager to learn.
  8. Learn foreign languages. I wish I studied another language in addition to English when I was at school. Decent English in IT is of course mandatory, French, German and Spanish can open a wide set of new opportunities. Of course you need to always remember point #1, you need to be technically prepared: a silly thing in seven different languages is still a silly thing.
  9. Sell. Work is no more jumping into our head, it is necessary to go out and find it. Garden your network, market your skills and then be ready to sell them more often than usual, as assignments and contracts are getting shorter. Presentation skills, technical writing abilities and speech skills in front of an audience are the main sales tools of a freelance consultant, being the best hacker is no more enough.
By the way, I think most of these rules apply to both individuals and organizations. I see many consulting companies reacting to the crisis by just enforcing their usual behaviours and keep on providing exactly the same set of services of their competition. Differentiation is key.

Good luck, we need it anyway.

Stumble Upon Toolbar

Wednesday, April 15, 2009

How to call a remote transactional Weblogic EJB from a Java client

My objective here is to show how to call a remote Weblogic stateless EJB from a Java client, then adding the ability to invoke multiple EJBs in a client-controlled transaction.

The code below is very simple and has been tested with BEA Weblogic Application Server 10.0 and developed with the Netbeans 6.1 IDE. The original requirement was to call Weblogic EJBs from Glassfish, using the Weblogic user transactions from the client code. Let's say there is the need to call several EJBs and to make it in a single unit of work, this is not usually a best practice, as client-controlled transactions are usually slower and lead to bad design. The best would be to expose a transactional service from Weblogic which wraps all the calls in one server-side unit of work, but it is not always feasible if we are not in control of the other side and this is also an example how to call a remote EJB from Java, if one removes the transactional code.

Anyway, let's have a look at our sample JEE 5 service (EJB 3), which is deployed in Weblogic:


package com.mt.ejb;

import javax.ejb.Stateless;

@Stateless(mappedName = "CalculatorBean")
public class CalculatorBean implements CalculatorRemote {

public int add(int a, int b) {
return a + b;
}
}



Above is a trivial "hello world" EJB, implementing a Remote interface. The mappedName = "CalculatorBean" is a mandatory parameter for the @Stateless annotation if one wants the EJB to be remotely callable.

I deployed in Weblogic, Netbeans offers the ability to connect to a Weblogic server, even if the plugin has limited functionalities it gives me what I need and allows me to work from my favourite IDE and deploy from there.


Here comes the client code, which is more interesting:

package com.mt.client;

import com.mt.ejb.CalculatorRemote;
import java.util.Hashtable;
import java.util.logging.Level;
import java.util.logging.Logger;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import javax.transaction.UserTransaction;

public class WeblogicTest {

private final Logger log = Logger.getLogger(WeblogicTest.class.getName());

public WeblogicTest() {
}

public void callRemoteEJB() {
InitialContext context = null;
UserTransaction transaction = null;

Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");
env.put(Context.PROVIDER_URL, "t3://localhost:7001");
env.put(Context.SECURITY_PRINCIPAL, "weblogic");
env.put(Context.SECURITY_CREDENTIALS, "weblogic");

try {
context = new InitialContext(env);
transaction = (UserTransaction) context.lookup("javax.transaction.UserTransaction");
if (transaction != null) {
log.info("in transaction context.");
try {
CalculatorRemote calculator = (CalculatorRemote) context.lookup("CalculatorBean#com.mt.ejb.CalculatorRemote");
transaction.begin();
int result = calculator.add(3, 5);
transaction.commit();
log.info("add=" + result);
} catch (Exception ex) {
ex.printStackTrace();
try {
transaction.rollback();
} catch (Exception ex1) {
log.log(Level.SEVERE, "Can't rollback transaction.", ex1);
}
}
} else {
log.info("transaction context is null.");
}
} catch (NamingException e) {
e.printStackTrace();
}
}

public static void main(String[] args) {
WeblogicTest test = new WeblogicTest();
test.callRemoteEJB();
}
}

It is necessary to add the CalculatorBean EJB jar file and the wlclient.jar to build the above client code. The wlclient.jar can be usually found into folder \server\lib of our Weblogic server.


Let's comment the main code sections.

First, I populate the connection properties:

Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");
env.put(Context.PROVIDER_URL, "t3://localhost:7001");
env.put(Context.SECURITY_PRINCIPAL, "weblogic");
env.put(Context.SECURITY_CREDENTIALS, "weblogic");

I look-up the initial context and get the UserTransaction from Weblogic's JTS:

context = new InitialContext(env);
transaction = (UserTransaction) context.lookup("javax.transaction.UserTransaction");

I lookup and call the remote EJB by enclosing the method invocation in transaction:
CalculatorRemote calculator = (CalculatorRemote) context.lookup("CalculatorBean#com.mt.ejb.CalculatorRemote");
transaction.begin();
int result = calculator.add(3, 5);
transaction.commit();
The lookup string "CalculatorBean#com.mt.ejb.CalculatorRemote" makes the trick, it is the Weblogic syntax to identify the Bean and its Remote interface.

Of course, in this trivial case there are not any transactions, but I wanted to keep the example very simple. If the EJB was transactional, the call made use of the transactional context, while in this case it is simply ignored.

Stumble Upon Toolbar