Mike could you tell us a little bit about yourself?

I've been involved for the most part in persistence over the last number of years, in object oriented systems particularly, and distributed systems. That is mostly my background. I come from different companies (big ones and small ones) and more recently I've been at Oracle for the last few years working on Enterprise Java Persistence and regular java persistence outside the enterprise.

Recently you have become co spec lead on EJB 3. How has that been?

That's been a good experience for us. Oracle had the chance to be very involved in the specification now at a level that they haven't been able to reach in the past with other specifications of this magnitude. This has been great. We had the chance to work with Sun more closely and work with the rest of the expert group, and that has been a real combined effort and a chance to come up with a specification that we hope would be a big success.

What impact do you see EJB 3 having on the community?

I think the community is ready for a change of pace. I think they are ready for a slightly revamped model, an upgraded model that allows them to do more things easier. I think the community wants to be able to come up to speed with technologies in a way that allows them to pick these technologies up and use them quickly without having to have a huge learning curve to get the developers on board. What we are hoping for is a community that is excited about the technology and community that accepts it.

What are some of the most common praises and criticisms you gotten about EJB 3?

We had a lot of praises and some criticisms as well. I think some of the most common praises have been that this is tremendously easier to use than it has ever been in the past, that it has been a step forward in terms of not only ease of use but ease of development. The developer can go to this technology and use it right away but also the fact that they feel they can do more with it, because they understand it more clearly. There are a lot of enablements that have happened recently within the VM as well as in the enterprise and these have all contributed to a technology which is more developer friendly. People have been very happy about that, we've been getting a lot of good feedback about that. Some of the criticisms have been more in the area of users wishing they had more features. Some of the features they are using are not in the spec and they asked that they be included. We can not include every feature in the specification in this release but we do intent to have more and more features as time goes on. I would say that the 80-90% percent feature range people have expected is pretty much there in this version, so we are pretty happy about that too.

What were the top two hardest features that you broke your heart to give up on?

I haven't got a list of them but there's a few of them that come up and we had to put away for now. Mostly were in persistence areas, one of them we had a number of questions about was pessimistic locking; that's not something my heart was broke about not offering but we had a fair number of people ask for it so in the future that will come along. The other one was asked for fairly frequently was more support for a parent-child relationship. We have some support for that now, but in terms of orphan relationships that is still coming; there are still many deluxe features that people have asked for and it's not frequent that we get lots of people asking for the same feature but everybody has got their favorite feature that they ask for, that may not be there. These are the small percentage of applications that use them. They'll come along in due time as more and more people want those features.

Why the continued support for message driven beans which are basically like message driven components over message driven pojos?

People are very happy with the message driven bean contract. We really didn't get many complaints about message driven beans in the past specifications so we didn't really feel the need to twiddle with them. If it wasn't broken we didn't feel the need to fix it. From the asynchronous model with message driven beans I think people are ok with that. They would like to see a little bit more, perhaps make it a little bit easier to use, particularly in the area of getting session beans to be asynchronous as well. That's a slightly different application of the same model. That could come along as well. We toyed with the idea at some point but it didn't follow through. For now the asynchronous part of message driven beans is pretty much good for most people.

What about aspect support? Is it up to people's expectations?

A lot of people are hesitant to use AOP in mainstream technology now. I would say that there's a minority of applications that actually use it right now. However people like the idea and they would like to use these features when they need them. In other words, they like them to be there. What we've done is we've added this interceptor technology, this feature where you can add interceptors that essentially model the AOP style of programming. It's enough of the AOP style to satisfy most people and I think it's really going to make AOP more mainstream as it's becoming part of a specification, whereas in the past there was no specification that defined it. This will contribute to helping AOP becoming a little bit more used than it was in the past and I think that would be enough for the vast majority of people to use it.

Can you tell us a little bit more about the dependency injection features of EJB3?

Dependency injections are the minimum requirements that people really wanted and expected. It's not what I would call a full feature dependency injection in the sense where you can inject any kind of dependency that you may have, but it's limited in the platform scope to be resources and enterprise dependencies that you would have. Those are defined in a very Java EE centric way. I think it makes sense for this round of the iteration process specification. There's probably more than we can do there. We've had so many requests from people to inject regular Java objects as opposed to just enterprise resources. I think that's something that we're looking at in the future. For now we're going to solve 80-90% of the people's dependency injection problems and people seem pretty satisfied with this level. For the more developed and advanced programmer they might want to have this extra level of dependency injection that would come later on.

How does EJB 3 help inside of a Java EE container?

EJB 3 has made some great strives in the deployment story. In the past deployment was very structured, very restrictive and many people complained about that as well. They found that deployment was kind of cumbersome and a little bit too limiting in many ways. EJB has come out, especially with respect to persistence, with new ways of deploying your application in ways that allow you more flexibility to modularize what you have to deploy inside your application. The example is that in the persistence side of things, when you got a bunch of entities sitting around and you want those that are essentially coupled together as a persistence unit, then we really want those to be able to sit both in an EJB jar as part of your other components as part of that module itself or perhaps separately so that it can be reused across multiple components. These classes should not be duplicated; they should not have to be specified more expressively than they need to be. They can be set aside somewhere and then pointed to by reference by the different modules that make use of them. They might even be sitting in the application itself, sitting in a lib directory for example as a shared library. All these sorts of different application deployments can be tailored by the application developers according to what they want.

How is EJB going to improve testing support?

Testing is one of the complaints people had with versions of EJB. The new version of EJB is actually going to provide testability not only for much of the component support but obviously for the persistence support which is just a light weight POJO now. Even though there are still some features within the session layer and the component layer of EJB that still has to be done inside the container, where the container is under complete control, much of the unit testing and the logic of that session bean can actually be tested outside the container altogether. This will avoid the need for a complicated test framework that runs inside the server that many people have had to do in the past. And a lot just had to run J Unit test or some other test framework sitting in the regular VM, outside the container altogether. That's going to be very helpful to people and to the development process.

How do you see EJB 3 impacting on design enterprise applications?

I think it is going the change the design enterprise applications in a way that has not been offered in the past. One of the things people had to do because EJB forced all the entity beans and session beans and all of the enterprise Java beans had to stay on the server. The result of that server side component meant that none of these things could be taken and moved around inside of the system of the server. That provided a sort of problem where you had to mirror the setup in order to ship it off somewhere else. People typically did this using DTO objects. They would have to come up with different architectures for accessing that state because they didn't want the state to keep going back and shoveling it off in bits and pieces. That in fact was one of the things people did. They would take bits of pieces of it and in unstructured ways access their data.

What EJB does is it introduces an access state in the object itself, so the entities for example are completely mobile. You can take them and move them on the client's side or to a different tier locally or remotely accessible and at that point once you have the objects in your hands you can access it, modify it, do anything you want with it and then bring it back to the server again. That power allows you to be more flexible in what architecture you choose.

You can still choose to keep the same architectures that you had before if they serve your purposes. On the other hand, if you want to go to a more loosely coupled architecture that you can avoid the need to having to redefine many of these objects hierarchies in the form of DTOs and transfer those objects directly so that they can move back and forth to the client and server.

How do you see people using EJB3 different from how they use EJB2?

In particular the client model has changed a little bit. The usage model, not just the development of the component itself, and the entities, but the way that you use them is going to be slightly different. It's different in that you don't longer have to go through all of the hoops that you had to go through. You can go right to the thing that you need, access it either through injection or look-up. Even look-up is made easier. The usage by the client is quite dramatic.

In the past there was quite a lot of knowledge that had to be had by the client. Now the client is really a simple client. It only has to know about the interface and some very basic enterprise patterns that are prevalent across the specification in the platform. The client's experience is actually changed in the sense that is much easier and simpler to develop from a client perspective.

A lot of people are saying that EJB won't matter because you've got Spring and Hibernate. Given the open source, who cares about standards? What's your response to that?

I think there's a certain role for open source products in the market. Some people have a real kinship with open source, they have a preference for open-source. There are other people who maybe want to shy away from it a little bit or have to approach it a little more warily than other companies. There are a lot of corporations in the world where IT divisions want to make sure that they program a very large application using a safe technology, something that is not going to change, because they can't afford to make any small change underneath they are dependent upon. So they need to program the standards.

An IT division in a large corporation is going to demand a standard and that's why everybody's so happy about the specification; it standardizes all these technologies people have been using for a lot of time. With a standard now, an IT manager can rest a little bit easier given that they can pull a vendor our and put another one in, should one vendor fail to provide the feature they wanted or the performance they wanted, or the scalability they absolutely needed.

This reference implementation has been said to be production ready as opposed to previous ones. Can you tell us a bit more about that?

The reference implementation for EJB is quite a unique experience now in that it is a two pronged application, a two pronged product. It is made up of the application server itself which is a Sun open-source project. It has been around for a little while in production actually, and it's also made up of the persistence portion, which is a derivation of Oracle toplink. It is called Toplink Essentials and it's derived from the official Oracle Toplin product and Toplink Essentials is providing basically all the functionality that you need to develop your persistence applications.

Combine these two together and you have a fully production ready product that people can use in their applications and be confident knowing that is has been proven already. Both of these products have had many customers that have relied upon them, that have showed them to be robust and that are very happy with the performance and scalability. People can now take this and use it just as they would use any part that they paid for, understanding that they get a really mature product underneath.

Have you received any early feedback on Toplink Essentials?

We have actually had a number of people wanting to integrate with Toplink essentials. Some well known products and vendors that have wanted to use it and are interested in using it. Both in the integration sense and in the product sense people would like to make sure that they are using the implementation they can count on and that they know it's going to be stable going forward. This Toplink essentials has proven to be a very stable product so we've had a number of different integrations that have been going on in parallel with the specifications. That seems to be going very well.

What is on your own personal wish list for EJB3? Where do you want to take the spec as co spec lead?

I'm co spec lead so I don't have full control over the specifications. It's an expert group and there are a lot of people contributing to the specification. It's been really a joint effort we've been really happy with the way that it has worked. If I had a choice and was able to exactly say what it was going to happen in that release I certainly have a few things I would like to add to it. There's a direction I think we'd like to go with the specification. I think that's more in the area of what to do in regards to the persistence part and the component part.

We've already seen that these two can be separated clearly and easily and that separation has already happened in the specification revision with a separate documentation; so there's a document for persistence, a document for the simplified API and then a core contrast document that specifies all the base underline technology for the components and such. I think in the future we will see this kind of division continuing perhaps in an entirely different JSR even and perhaps a different venue.

This whole JDO versus EJB beans is that war over or is it going to be a merger?

I think that kind of war is over and it has been over quite a long time ago. I think Sun did their best to make that thing come to completion when they sat down at the table and they said: what are we going to do with these technologies that are quite similar and yet simply going along parallel paths. The JDO technology was a decent one that had a lot of good things going forward and EJB was emerging to become the same sort of thing with a decent technology but yet integrated with the enterprise. The trick was to try to harmonize those two; I think we did a pretty good job in doing that and I think the JDO vendors have also been reasonably happy with what has emerged. Things seem to be going much better now and everybody seems to be quite happy about the results.

If the persistence spec gets removed from EJB, will there be enough there left for a specification?

I think that if you printed the spec out and picked it out, you'd see that there's still quite a lot of material there. The whole component mode itself is what remains. And there is quite a sizable amount of specification verbage in that part of it. I think that probably puts it down to what a spec should be in terms of length and in terms of target functionality and what the technology should do. I'm not worried about there not being enough specification at that point. I think there's more to deal with at the component level.

Any final words?

Thank you very much for this interview. It's been a pleasure talking with you and I look forward to people using the specification in the coming months as vendors who're able to give people a chance to try things out and prototype their applications and then go production with them.