The is the EJB 3.0 standalone bundle that comes already embedded with the JBoss 4.0.4.GA AS installer distribution. We have implemented most of the features of the Final Draft of the EJB 3.0 specification. Only a few minor ones remain (shareable resources for instance). This standalone distribution also comes with 3 new tutorials: ssl, entity security, and Quartz MDBs.
We've had some EntityManager security based on JACC for awhile, but have kept it secret (in other words, we finally documented it). This new feature allows you to set permissions on CRUD actions on the EntityManager.
We've also implemented a Quartz Scheduler JCA Resource Adapter. This adapter allows you to use JCA Message Inflow to write and configure MDBs that can directly receive Quartz Jobs. These Jobs are configured via the MDB's activation config spec. I'll write a blog about this when I get a chance.
The EJB 3.0 RC7 standalone distribution is only usable with JBoss 4.0.4.GA. The EJB 3.0 implementation that comes packaged with the JBoss 4.0.4.GA installer is the same as the standalone EJB 3.0 RC7 distribution with two exceptions. The standalone distribution has been patched to fix the EJBTHREE-573 JIRA bug. Also the JBoss Remoting jar has been patched to fix the SSL problems in the 4.0.4.GA release. If you don't need these fixes, then installing with the installer is fine.
Next week, O'Reilly will publish Enterprise JavaBeans 3.0, 5th Edition by Bill Burke (myself) and Richard Monson-Haefel. It is a comprehensive guide to EJB 3.0 covering everything from Session and Message Driven beans to the new Java Persistence API. About a year ago, O'Reilly asked me to take over the series from Richard. Although EJB 3.0 has drastically changed in many areas, particularly entity beans, Richard had written such a good book that it could easily be adapted (well not too easily) for the new specification.
The new JAX-WS web services programming model and annotations are also covered. Since I'm not well versed in this subject, I asked Jason Greene, a Senior Developer working on JBoss's web services implementation, to write the chapters that discuss this subject. Thanks Jason!
The book also includes a JBoss Workbook. Each chapter of the main book has a parallel workbook chapter that walks you through example programs you can download, compile, and run on the JBoss 4.0 application server using JBoss's EJB 3.0 implementation. This workbook is a great way for you to see EJB 3.0 in action.
I just wanted to jot down some of my thoughts about the acquistion. After a week to digest this I came away with the following feeling.
About 3 years ago JBoss Inc. started the process of recruiting other open source projects. Ben Sabrin and I went out to the TSS symposium in 2003 to recruit Gavin King of Hibernate. Later, others at JBoss enticed Bela Ban (JGroups), Tom Baeyens (JBPM), and Mark Proctor (Drools) to join. Basically, the pitch to all of these guys were:
Last week we became the acquired rather than the acquiring. I think I know how Gavin, Tom, and Mark felt now and why they wanted to join JBoss. Red Hat gives us some of the same benefits that we gave Hibernate, JBPM, and Drools except on a much larger scale.
Marc also shared with us an IRC chat log he had with about 230 Red Hat employees about the acquisition last week. This IRC reminded me a lot of "the core" email list we have internally at JBoss: a lot of opinionated individuals that aren't afraid to ask hard questions or be critical of others. With other companies I've worked for in the past, individuals would be scared to question management decisions or voice controversial opinions at such a meetings fearing that they would rock the boat. Red Hat employees had no such qualms. Its obvious these guys care as much about their company as we do ours. The fact that Red Hat, as a company, would have an open internal IRC chat with Marc tells me alot about the openness of the culture we are joining. I'm glad Marc and Red Hat shared this IRC log with us JBossians. As one of our developers said internally, "This IRC makes me happy on several fronts.".
I hope Red Hat employees see this blog and know that there is at least one JBossian very excited about this acquisition. I think we're gonna mesh quite nicely and I hope I get to meet a lot of the tech guys soon.
RC6 has already been shipped with JBoss 4.0.4CR2 application server. I was on vacation when this went out and just got to putting the binaries together for the standalone distribution.
Things of note?
At Java One last year, I did a presentation on the JBoss architecture. One of the things I talked about was our deployer architecture and how you could define your own proprietary package format that could automatically be deployed/hot-deployed into your environments. I gave the Spring Framework as an example of what you could provide
I had wanted to create a Spring Deployer for over a year, but never had time to do it. Luckily, a few weeks after my presentation, I received an email from a random person named Ales Justin asking if the Spring Deployer was available. I told him it wasn't, that I had no time to develop it. He responded with "I'll do it!". Let me tell you, I get these offers to help about once a week. I give these people a few pointers then usually, almost always, never hear from them again. I pointed Ales to a few example Deployers and told him he was on his own. About a week or so later, he came back with a finished Spring Deployer. What he had seemed to work, so I gave him CVS access. He asked, "What next?" I told him, "why don't you integrate Spring with EJB 3.0 and provide a custom injection annotation for EJBs for Spring deployed object?" He said ok, and later in August 2005, the Spring integration project was begun
Well, we originally wanted to launch this project by writing an article for The Server Side about the project. Ales did this and submitted it to TSS. Unfortunately, TSS seems to be more interested in publishing issues about JBoss rather than anything positive we might be doing for the Java community and the article fell through the cracks. Ales became busy, and we never got the article out.
Strangely enough, even without an announcement, one WIKI page, a downloadable SourceForge distribution, and a User Forum, produced over 1000 downloads of the project. Ales reworked the project using the new EJB 3.0 PFD spec and released another version last week. We gave up with TSS and went to Java Developers Journal instead, and you should see Ales's article printed in the February edition.
So, what about the project you ask? Well, here are the links
I'm pissed at myself for not calling attention to this project earlier, but it seems a lot of you have already found it
Finally, after almost 4 months of development, Thanksgiving, Christmas, consulting priorities, and children being born, JBoss EJB 3.0 RC4-PFD is finally out and available for use. This is a major release with over 68 tasks complete. We are about 99% compliant with the EJB 3.0 Proposed Final Draft and a lot of major and minor bugs have been fixed. You can download the standalone release on sourceforge. This distribution works with JBoss4.0.3SP1 application server. JBoss 4.0.4RC1 will be out soon with a full app-server distribution. You can view documentation at docs.jboss.org, or just download the standalone distribution which has doco as well as 30+ tutorials.
A lot has changed in this release both in the specification and the way JBoss implements EJB 3.0. Check out the EJB 3.0 WIKI for details on how to migrate from an older version of JBoss EJB 3.0. It is going to be an annoying process to migrate because of all the minor annoying little changes here and there, but please have patience. Since our WIKI is editable by anybody, please help us out to expand these guides! BTW, if you get really upset with some of the default JNDI binding changes, please send your hate mail to Gavin King and Christian Bauer.
Special thanks goes out to Gavin King for putting up with all my bitchin' and whining in the late hours of the night. And always, Emmanuel Bernard for doing a kick ass job on the Hibernate side of things.
We were required to be standards based and did some research before the project began and jumped on EJB 3.0 because all the XML alternative approaches just seemed too unproductive
There is no possible way we could have accomplished as much as we did in so short of time if we had gone the EJB 2.1 route. Our developers were amazingly productive using EJB 3.0
The moral of the story is that the more people I talk to about EJB 3.0, the more I learn that it is a vast improvement over the older specification and that the spec is headed in the right direction. I'm trying to extract a testimonial from these guys, so you should see something soon on this.
Ya know? It is refreshing to speak to people that are actually trying out this technology, instead of just blindly denouncing this because they are emotionally attached to some of the EJB-alternative frameworks out there. Anyways...
I've always hated checked exceptions and always preferred using RuntimeExceptions. I usually find that I rarely have the ability in my code to recover from a particular exception thrown by a particular method and adding a checked exception to the throws clause would just require ugly try/catch blocks for my users.
There are occasions though in some methods, I still want to throw a RuntimeException, but want to make it known to users that it is possible to recover from a particular exception. At first, putting these exceptions in JavaDoc seemed like the best idea, but, what if I want to catch a particular exception? I have to look in the JavaDoc to see what runtime exceptions are thrown. I also can't ask my IDE to automatically create a typed try/catch block for me. So...What about declaring RuntimeExceptions in the throws clause? Is this a good convention?
Maybe this is an old practice, maybe not. I first came across this idea of putting RuntimeException exceptions in the throws clause during the EJB 3.0 expert group when all EntityManager exceptions are RuntimeExceptions but there were a few cases where it would be interesting to catch an exception thrown from an EntityManager method. Again, since the RuntimeException would be available in the throws clause, an IDE could automatically generate the try/catch block for me when coding. Is this a good idea or not? Let me know.
Due to our first blog about JBoss EJB 3.0 successes and the fact that TSS picked up that blog, the success stories are starting to pile in. This particular testimonial is from Ron Hatcher of the Millfield Group in the UK. Look for more testimonials to pop up here in the next few weeks. If you have your own EJB 3.0 testimonial, please email@example.com
The Millfield Group plc. is a financial services company with over 1500 advisers, including independent financial advisers, independent mortgage advisers and other specialist advisers in our regional offices throughout the UK. We have adopted JBoss as our strategic platform for enterprise development and have now begun releasing EJB3 based applications into production.
Our recent EJB3 implementation is the first application to take advantage of our evolving service delivery platform - Jupiter. It is based on a three tier physical architecture with Windows/IIS web servers, Solaris/JBoss application servers, and Windows SQLServer database servers. This structure is quite common (and has been for some time). The difference now is the effectiveness that the JBoss EJB3 implementation brings to the whole development process.
Our Jupiter platform provides a core set of services and business objects that are generic across our business domain. These services and objects are then used by applications that 'orbit' around it. Currently these applications invoke the core services by accessing stateless session beans, but these will expand to include web-services and Message Driven Beans in the future.
The first application - Leda - is a mortgage referrals system. Estate agents use it to refer their home buying clients to mortgage selling financial advisors. We use the Front Controller/Dispatcher mechanism to manage the presentation tier, and use a single dispatcher for each use case in the system (there are approximately 12). Our initial user group has been restricted to 250, however we are planning to bring an additional 750 users online in the very near future.
While building the application, I was very pleased with the ease of implementation of the entity model. Although we have built hibernate based applications in the past, the EJB3 entity beans really take all the headaches away from the persistence mechanism.
We did encounter a few issues during the initial build -
There has been much written recently about EJB3 persistence, annotations, and dependancy injection from an implementation perspective, but I feel the real benefit here is in the whole development file-cycle. In the EJB2.1 world, we adopted the many of the Sun Architectural patterns to get the performance and usability we required from the platform, but these mechanisms required a translation from the business requirements and business model to the implementation. Our current development aims to solve this problem by using JBoss Jbpm.
As a financial services company, we are required to implement and use many regulatory processes. These can be quite complex, and code to implement them quickly becomes complex and hard to maintain.
Our first regulatory application - Callisto - uses Jbpm to manage the business process, and invoke our EJB services as required. This allows for the implementation code to be narrowly focused on a specific step in the business use case, and moves any process related code out of the equation. Using this technique, we effectively automate our business process with very little interpretation between the business spec and the final implementation.
Our initial testing has shown this approach to be extremely effective in quickly building applications, and keeping the code very clean and maintainable. Again, we experienced a few issues so far with Jbpm.
All in all, I am very pleased with our success to date using EJB3 and Jbpm, and am confident that this will support our platform development efforts for some time to come. Our current plans involve implementing two more modules in the next 12 months, and expanding the user-base of the platform to 10,000. I would like to take this opportunity to thank all of the JBoss contributors for providing a great environment, and also to our EJB developers Richard King, David Oliver, and Victoria Weston.
Have a look at 24/7 Roadservices Australia It runs on shared hosting at Ala cartejava with JBoss-4.0.3 as the application server. The database is MySQL.
For the next few days (today is the 27th Ocotber, 2005) it will still be in a test phase and everyone can enter dummy transa ctions using imaginary credit card details.
And it is a totally EJB3 application.
The development tools were Eclipse 3.1 with the JBoss 1.5 Milestone 1 IDE. During development it was tested in JBoss-4.0.3R C2 and PostgreSQL.
This application uses the MVC architecture. As far as a framework is concerned, it uses a pure J2EE EJB3 framework as far a s that is possible. No Struts or anything else. Of course, much of the functionality is JBoss specific as the full EJB3 spe cification has not yet been decided upon.
All user response pages (only two) are directly generated by a servlet.
To prevent concurrency problems all database access that will result in database changes requires a transaction. We do not anticipate heavy use at all; if there are 10 users at the same time trying to buy the product the owner will be just too ha ppy. Shared hosting is of course also not the way to go if one anticipates heavy use. Be that as it may, there is a pool o f 20 database connections, more than enough for many times that number of concurrent users.
When it went "on air" I had all the office staff (eight) go on and attempt a transaction without help. There were no proble ms, except for one secretary who could not recognise the end-point of the online credit card transaction. However, my inter est has been aroused. I think I'll get it to run on one machine of the local network, use JMeter from another and send the servlet requests to create contracts and see with how many it can keep up. In the real world I suspect the network (Interne t) will be the bottleneck long before the software falls over.
Problems? A few. At first I could not get the application to create the database tables and keep them when the server shut down. Someone on the EJB3 forum suggested:
<property name="hibernate.hbm2ddl.auto" value="update"/>
It works perfectly for both PostgreSQL and MySQL. Then there were problems with the .par archive andI packaged even the ent
ity classes (POJOs) in the .ejb3. That worked. However,
the final package structure looks like this:
This structure worked from the word go when deployed at Alacartejava.
<description>The 247Roadservices Application</description>
Note that this is really a simple application that doesn't do wonderful things. It takes form input from a user, transfers t he user to a secure payment site, comes back from the payment site when a link is clicked after successful payment and write s everything to the database and gives the user his contract ID no. It gets data from the payment site behind the users bac k as a get request. It verifies that this comes from the payment site's IP address. I know about IP spoofing, but one's car registration no needs to be real for this product to work. Who would commit fraud and supply real contact details?
Did JBoss fall short in any way? Not with this application. I am sure this application did not give JBoss a good work-out. I have a few EJB2.1 applications running at Alacartejava. This one seems faster, especially the form pages which are creat ed by a servlet. Is JBoss-4.0.3 faster than the older versions or is this application on newer hardware? I don't know.
There is of course a log-in page for admin staff without even a link to it. Various things can be done on the admin page. In fact, most of the J2EE functionality is to be found on this page.
Well, that's it folks, A simple J2EE EJB3 application that was created on the cheap and runs for about US$55 quarterly. And everything works.
One caveat; don't install JBoss-4.0.3 and expect to run EJB3 applications in it at Alacartejava. Look one place lower down in the drop-down list and install JBoss-4.0.3EJB3.
What about EJB3? Much, much better than EJB2.1. The ability to extend classes (not used with this application but extensiv ely used with a real estate application I am working on - base class Property, extended classes Residential, Commercial etc) is heaven-sent. I managed something similar with 1:1 tables/classes in EJB2.1, but it was much more work. The thinking par adigm is now almost purely Java (Object Oriented) as opposed to thinking in database terms (tables, columns and rows and rel ationships). I became aware that things are now different to what it was in EJB2.1 while coding. Maybe one can say EJB2.1 was closer to the database and EJB3 is almost pure Java programming.
This is old news, but we never really made any noise about it so I thought I should blog about it. Adrian Brock has completed version 1.0 (and 1.0.1) of the JBoss Microcontainer. Adrian actually prefers to do real work than blog, so he left this job to me, JBoss's Chief Marketect.
JBoss Microcontainer is a complete Inversion of Control, Dependency Injection lightweight container. It allows you to configure POJOs through XML and has lifecycle for these POJOs as well so that they can be treated as services. It does not require the JBoss Application Server to use and can be used in any application whether it be a J2EE app or a plain Java ap.
The JBoss Microcontainer starts JBoss on an evolution to embeddable Java EE. The idea is that all JBoss Java EE and JEMS services will be embeddable and runnable in environments outside of the JBoss Application Server including: JUnit tests, Swing applications, standalone Tomcat, and even other vendor application servers. If you have downloaded JBoss Seam or JBoss Embeddable EJB 3.0 you are already using the JBoss Microcontainer as it is being used to initialize and configure basic services used by these frameworks like a transaction manager, JNDI, JCA-based datasources, and JMS. Over the next few months and quarters you will see more and more JBoss services be converted into POJOs and configurable and usable in non-app-server environment. This will culminate with the release of JBoss 5 sometime in 2006.
The first version of the JBoss Microcontainer is just a plain, but advanced, IoC container. Later versions will allow you to layer additonal kernel-like services like advanced classloading through our Unified Class Loader architecture, as well as a rewrite of JBoss Deployers so that you can package and deploy your components and have them be loaded and bootstrapped by the Microcontainer. Currently though, here's some features that I think are simple, but pretty cool.
So why is JBoss creating its own IoC container when there are a bunch of other frameworks out there that do similar things? Well, to be brief, it would be suicide for us to depend on a third party to provide such a core piece of our infrastructure. For basic IoC, this doesn't really matter, but when we start to layer things like classloading, packaging, deployment, and most importantly management, this will become more and more important to us. Really, JBoss Microcontainer was written as the next iteration of the old JBoss JMX Microkernel so that we could evolve the JBoss Application Server. So, JBoss MC's primary customer is JBoss 5 AS, JBoss Seam, and Embeddable EJB 3.0. JBoss Microcontainer is there for you the community to use if you are interested in it which is why we are calling attention to it and promoting it a little.
Anyways, check it out. Adrian write some pretty high quality code and I have learned a lot from him over the past years. If you didn't know already, Adrian also maintains and leads our current JCA, JTA, and JMS implementation as well, so he's a pretty busy (and talented) guy. Great work Adrian!