Andreas Schaefer's Blog

J2EE Archives

GlassFish: Too Little, Too Late?

After the magical dust of JavaOne has settled the reality is reappearing and we can start thinking about the results. Especially Sun's announcement (beside buying my current employer) of open-sourcing their application server was a hot topic here even though I did not quite trust all the fuss around it. Now over the long weekend I had time to figure out what happened and the result, quite frankly, is disillusioned and I get the feeling that this was just the last phase of this application's life cycle.

First I want to make clear that what Sun open-sourced is the code base of the 1.4 reference implementation one can already get for free. This means that the Enterprise Edition is still closed-source and with it the advanced features like clustering. On the other hand JBoss is a 1.4 certified application server with all these features and so I think that open-sourcing the RI is just not enough (too little). In order for GlassFish to be a successful open-source project it needs a good and broad developer and user community but I am very skeptical that they can accomplish that. Yes, Sun has successful open-source projects like NetBeans and OpenOffice but they did not have to compete with another well known open-source project when they started. This time they have to "fight" against JBoss and Apache's Geronimo project making it very difficult to build a community around it especially when the project is lacking some key features and so this step is maybe taken too late.

I am not saying that this project is going to fail because it is the RI and so it must be done one way or the other and Sun has the brain power and resources to keep it afloat but that does not guarantee that it becomes an exciting and vibrant open-source project. It may end up as a project on "life support". Maybe it would more sense to make JBoss or Geronimo the RI so that Sun can focus on the Enterprise Edition or maybe not. If someone would ask me, but who cares, I would rather work on JBoss again but that will also only happened after some bottles of Fleury with a good vintage.

At the end only time will tell which project will succeed and what fails. I am already surprised that Geronimo is still an active project passing the CTK 1.4.1a just recently.

Have fun – Andy

JCA 1.5: Choices are not Always a Good Thing

In JCA 1.5 Inbound Connection (IC) is added allowing developers to invoke Message Driven Beans (MBD) with other types of messages than JMS like emails, files etc. When a MDB is deployed using an IC the application server is calling endpointActivation() on the Resource Adapter (RA). This is the point when a RA can start sending messages to the MDB. The application server is providing a Message Endpoint Factory (MEF) to the RA so that it can create Message Endpoints (ME) acting as a proxy of the MDB to be invoked. This proxy implements the interface of the MDB and so works like a local interface of a Stateless Session Bean (SLSB).

Because the MDB works more or less like a SLSB MDB instances are pooled and used only for the duration of an invocation on the interface. So an invocation of a MDB could be delayed if there is no MDB instance available in the pool. The JCA specification leave the application server the choice to either throw an exception when no instance is available when the ME is created or to block the invocation on the ME. But this leaves the RA developer in limbo and is quit a headache also due the inability of the specification to provide enough information to separate an empty pool for another, maybe permanent, failure.

When a RA creates an Endpoint on the MEF it can throw an UnavailableException if something goes wrong but it has no information if this is a permanent or temporary failure that is vendor neutral. So, for example SunOne, is throwing immediately an UnavailableException when the MDB pool is depleted. Personally, I think this is not a good thing because a depleted pool is a natural state of a pool and not an exception. Other application server block the invocation on the ME until a MDB instance becomes available preventing the RA to react on a depleted pool.

I would like to see some changes on the MEF/ME specification:

• createEndpoint() should not throw an UnavailableException when the MDB pool is depleted
• MEF/ME should have a timeout attribute specifying a timeout when a MDB pool is depleted (either on the creation or invocation of the ME)
• createEndpoint() and the invocation on the ME should throw a Timeout Exception if a MDB instance does not become available so that the RA can react on that

A Generic Application Server

Since over a year I am thinking about the next generation Application Server that takes the route of JBoss as an flexible J2EE based server and just go through with it and make everything generic. In this server everything is deployable like Containers, Services (as of Transaction, Security, Persistence, Pooling etc) and Applications. The application server specification is replaced by a contract each deployment unit exposes with their requirements and features they offer. The server will then match the components together so that a fully deployed application is formed. If a component is missing a deployment unit will remain inactive until everything becomes available. Even a naming service is deployed and therefore one server can hosts multiple naming services at once.

Such a server allows an administrator to tailor the server to the hosted applications needs and nothing more. So if no Entity Beans are needed this Container must not be deployed. If an Entity Container is needed based on JDO either a particular JDO Container or a JDO Persistence Service is deployed. It would also allow a Container to expose the Home and Remote Interface in a JMX fashion where a global interface exposes the list of supported methods as well as their invocation. I guess, this would make Web services much simpler.

For more information about this ideas please feel free to visit my personal log.

RE: File Access in EJB

As Simon Brown pointed out the J2EE specification restrict you to access files on the file system but sometimes you have to and then you need to control the damage by keeping the breach of the specification local and not to spread it all over your code. Being confronted with this question just recently I came up with these ‘solutions’:

• Putting a file into the archive and read it out as resource. Note that you can only read from this file.
• Using a JNDI environment entry containing the path to the directory and/or file that then can be used to open the file later in the code. This allows the deployer to adjust the value before deployment so that it points to a valid file/directory the application can read from and write to.
• Using JCA to expose a connection to a file that allows the client to retrieve the connection and then open an input stream like you do with an URL.

First I was thinking that only a file service (like JDBC or JMS) provided by the server could solve the problem. But after thinking it through using Entity Beans seems to be a much better way to share the data on a cluster than through a file service. Then I realized that maybe each deployed EJB needs to have its own file that is not shared on the cluster. I think it is very important for each J2EE developer to see that there is much more between heaven and earth that a specification can ever capture. But it is important for the future of the code/project that ‘unportable code’ is kept localized and under control and that the assumptions and restrictions of that code is documented well.

SLSB -> SFSB: Meaningless ?

A colleague of mine just pointed out that in Richard Monson-Heafel’s EJB book (3rd edition) configurations like Stateless Session Bean (SLSB) -> Stateful Session Bean (SFSB) are considered meaningless. I understand that any EJB book cannot deal with all possible scenarios otherwise you need a truck to take the book home but I find it too interesting not to talk about. Luckily I can discuss in my weblog any scenario I like and hopefully I can show you that rules are meant to be broken even when the result only confirms the rule.

Let us assume that we have a SLSB that has at least one business method in it that is quite elaborate and performs many tasks. In addition we want to have multiple resources or a non-standard resource wrapped in an EJB like a raw TCP/IP socket. Because the resource(s) should participate in a transaction and must be opened before usage and closed at the end it cannot be a SLSB because we never know what instance we get back on each invocation due the fact that the pool is returning the next free instance before a method is invoked. The only way left is to use an SFSB because a particular instance is available to the SLSB instance during the entire method call and so at the end I can close the resource(s) or do any other cleanup task. In this case the SLSB method does represent a client towards the SFSB even thought the life span of the SFSB is not that long.

Now one could object that I could just use a plain Java class instead of wrapping the resource(s) into an EJB but an EJB can use JNDI environment variable to specify setup properties, I can look it up very easily on a JNDI server and use an EJB reference in the Environment Naming Context (ENC) of the SLSB. Finally I can deploy the EJB in a separate application and use it throughout the server. One could also suggest using JCA instead but this could either overkill or what is wrapped in the SFSB does not adhere to JCA specification.

I want stress the fact that this rule should only be broken when there are compelling reasons to do so and you checked out the other options like keeping the code in the SLSB, creating a plain old Java object or using JCA and then selected the best solution that does not only fit you best now but also in the (near) future.

How to Handle Permanent Exceptions after EJB Deployment: a Proposal

Finally I found time for a technical log here at Java.net. This time I want to discuss a shortcoming of the EJB specification and how they can be fixed to make the life of EJB developers and application server administrators easier and the deployed applications more robust.

Originally the EJB specification assumed that the applications are deployed at startup of the application server and the environment remains stable for the time the server is up. With the broader acceptance of the J2EE application servers the dependencies between remote servers (DB, application servers, JMS etc) grows and a successful deployment does not mean that an application will run smoothly all the time. In some cases application server are just used to host application on the user’s computer and there is not full time administrator on duty.

Let us assume that an application contains one or more message driven beans (MDB) and they invoke other EJBs or resources to help execute the handling of a message. Now a resource used is becoming unavailable for a longer period of time and the message cannot be handled anymore. In the current specification then only thing the MDB can do is to either swallow the message and therefore lose all the pending message on the destination the MDB is registered on or it can rollback the message causing the server to resend the message immediately. The second option of course will put a drain on the server because every message will be resent until the message could be handled again or the server is putting the message away in some sort of a dead letter queue. Just imagine that a destination contains thousands of messages which are resent multiple times just to end up in a dead letter queue. What a waste of resources, isn’t it.

A similar problem occurs when a client access a stateless session bean (SLSB) because the SLSB instance is not created when the “create” method is invoked on the home interface but somewhere between the deployment and the first invocation of a business method on the SLSB instance. This means that any exception in the “setSessionContext” and “ejbCreate” method is not available to the client.

Both problems can be solved if the EJBContext would allow the EJB to inform the server about an unrecoverable error with a message and a Throwable instance. This allows the server to take the EJB and/or the entire application in question down and return an appropriate EJB- or RemoteException to a caller to inform about the original problem. The server then can inform the administrator about the problem or can try to restart the EJB/Application periodically (in the case of MDBs). Such a hook in the EJBContext could look like this:

public void reportException(String message, Throwable cause, int severity, int hintForServerHandling);

This work is licensed under a Creative Commons License.