The short answer is that it is designed around Ahmdahl's law (effective parallelization of work) as opposed to Moore's law (waiting for hardware with a faster clock rate). Almost every CPU powering desktops, laptops, and servers is now at least dual core, and the trend is rapidly expanding. The days of the frequency race are essentially over. So, now software must adapt to tap into the power of the hardware of today and tomorrow.
JBoss AS underwent an aggressive transformation to achieve this critical evolution. With AS 7 we started from scratch and built an entirely new, highly performant, and manageable core architecture from the ground up. With some truly amazing engineering effort we were able to go from a tiny prototype on github, to the full blown Java EE Web Profile compliant container of today in a little over a year (not to mention that during all of this we also delivered AS 6 which allowed JBoss users early access EE6 technology).
Before explaining, allow me to provide some background. The core problem an application server is tasked with is managing services. Nearly all components in a modern application have some kind of life-cycle, meaning that there is some point at which it must be started, and some later point at which it must be stopped. We label anything that has a life-cycle a service. Another important property of a service is that they typically have relationships that impact their respective life-cycles. As an example, we might say that a servlet's service depends on a web server. In addition we would probably say that if that servlet uses some other resource like a database connection or an EJB that it depends on those being being available as well. When an application server starts or deploys it must make sure that it starts all of the various services in the correct order. Further if any of these services are somehow stopped, it must stop all dependents first (essentially reverse order). This is a fairly simple problem when this is done in a single thread.
JBoss AS 7 on the other hand starts and deploys all services in parallel. This complex problem is solved by our new service container, the JBoss Modular Service Container. MSC is essentially an advanced concurrent state machine. It analyzes the dependencies between all services on the fly and attempts to start as many as it can at the same time, while still adhering to the relationship requirements. This means that not only is startup blazing fast, but you also now can deploy multiple deployments in parallel.
In addition to parallel services, JBoss AS 7 also has modularity and concurrent class loading. By segmenting classes into proper modules, the app server can naturally optimize access patterns, and only look in the spot that truly owns the classes. Also, since the visibility between modules is intentionally limited, searching is cheap. In the case of JBoss Modules, module resolution and class lookup are O(1). All of this has a very high degree of concurrency, even a significant portion of class definition.
Deployment processing is also very efficient. One major optimization is that we index annotation information by quickly scanning a subset of the class file data. For even greater efficiency we allow modules the ability to pregenerate a space efficient index which is designed to be loaded very quickly. Yet another deployment optimization is that we carefully cache and reuse reflection data, since the JVM is not very efficient at doing so.
Finally the last major reason I wanted to highlight is that we have and will continue to be very militant about our CPU and memory usage on the start and deploy path. This is all about making good choices starting at the design phase. An interesting example is our moratorium on using JAXB (or any other introspection driven binder) to parse configuration that is only read once. It ends up spending the same or more time figuring out how to parse than it does doing the actual parsing. This adds up. In fact, just the XML processing in AS 5 and 6 took longer than the entire 7 boot time.
Hopefully this provides a better picture as to how we made the efficiency gains, and why some things are very different in 7 than in the past. This, however, is just the beginning. Stay tuned for my next blog which will talk about the overall 7 roadmap.
JBoss Application Server 7 has been released !
Java EE Connector Architecture (JCA) is one of those
hidden technologies in the Java Enterprise Edition platform and if you asked me the specification should be used a lot more to implement enterprise solutions.
You may ask
So, what is so special about JCA ?. If we take a look at the introduction of the specification we see
The Java Connector Architecture (JCA) defines a standard architecture for connecting the Java EE platform to heterogeneous Enterprise Information Systems (EIS). Examples of EISs include Enterprise Resource Planning (ERP), mainframe transaction processing (TP), databases and messaging systems.
Hey, wait a minute... databases and messaging ?!?
Yes, every time you hit a database or a messaging system - or use technologies that hides those systems like JPA and EJB/MDBs - in your application they go through the IronJacamar container.
The resource adapters - the enterprise archive format for deployment - provides the specific interface for those system, like exposing a JDBC or JMS API to the applications - this means that the JCA container is
hidden from the applications.
Which leads to
So why should I care ?. Well, since the IronJacamar container controls all connections and their properties that means that the JCA container can add extra features
on-top of APIs - like connection pooling, connection validation, a flush strategy in case of an error, reauthentication of connections and more.
Things that you take for granted that an application server will provide you - now you know how we do it :)
As I mentioned above the IronJacamar project provides the JCA container for JBoss AS 7, so the features of the project really mandates what datasource can do and which features that are available to a resource adapter deployment.
I wrote a blog about our 1.0.0.Final release here - that will give you some insight to what the project is about.
And yes, the project is included in our Java EE 6 Web Profile bundle too.
The documentation shows you how to deploy an application in different ways, but for now we will just assume that you manually copied the
eis.rar file to the deployments/ directory.
Next you will need to configure the resource adapter like provide the JNDI name for a connection factory.
An example could look like this
<subsystem xmlns="urn:jboss:domain:resource-adapters:1.0"> <resource-adapters> <resource-adapter> <archive>eis.rar</archive> <config-property name="Server">localhost</config-property> <config-property name="Port">19000</config-property> <transaction-support>XATransaction</transaction-support> <connection-definitions> <connection-definition class-name="com.acme.eis.ra.EISManagedConnectionFactory" jndi-name="java:/eis/AcmeConnectionFactory" pool-name="AcmeConnectionFactory"> <pool> <min-pool-size>10</min-pool-size> <max-pool-size>100</max-pool-size> </pool> <security> <application/> </security> </connection-definition> </connection-definitions> </resource-adapter> </resource-adapters> </subsystem>
which configures the connection factory of
com.acme.eis.ra.EISManagedConnectionFactory to be located under
Alternative - you could add a
META-INF/ironjacamar.xml file to the .rar archive with the configuration.
Be sure to also read Stefano's blog about how to do datasource deployments in AS 7.
For Those About to Rock, We Salute You !
You may have heard that AS7 Final has been released! . I plan to say a lot about this, but before I do, I wanted to call attention to the many heroes whose contributions made this monumental release possible.
- Dan Allen
- Max Rydahl Andersen
- Dimitris Andreadis
- John E. Bailey
- Marius Bogoevici
- David Bosschaert
- Heiko Braun
- Tomaz Cerar
- Jean-Frederic Clere
- Thomas Diesler
- Andrew Dinn
- Vladimir Dosoudil
- Stuart Douglas
- Steve Ebersole
- Paul Ferraro
- Howard Gao
- Paul Gier
- Stefan Guilhen
- Ales Justin
- Kabir Khan
- Aslak Knutsen
- David M. Lloyd
- Darran Lofthouse
- Alexey Loubyansky
- Jim Ma
- Stefano Maestri
- Scott Marlow
- Rémy Maucherat
- Shelly McGowan
- Bob McWhirter
- Marcus Moyses
- Emanuel Muckenhuber
- Pete Muir
- Richard Opalka
- Jaikiran Pai
- Jonathan Pearlin
- Jesper Pedersen
- James Perkins
- Flavia Rainone
- Andrew Lee Rubinger
- Anil Saldhana
- Stan Silvert
- Alessio Soldano
- Brian Stansberry
- Scott M Stark
- Andy Taylor
- Carlo de Wolf
- Jeff Zhang
- The JBoss Community, and all our excellent first class components whose authors are too many to mention.
You might have heard the news: JBoss AS 7 is out :) What does it mean from an Hibernate user perspective?
Back to the subject: JBoss AS 7 and Hibernate.
First of all, JBoss AS 7 comes with Hibernate Core 4. This essentially means that AS 7 will be using the new foundational grounds for Hibernate Core. Hibernate Core 4 comes with many internal changes:
- A new ServiceRegistry interface: many pieces of Hibernate are now service based and many contracts have been enhanced (like connections and second level caches)
- A MetadataSources interface: instead of mixing configuration and mapping like the Configuration class was doing, we have now split the concerns and lifecycles
- A package refactoring splitting classes into api, spi and internals: if your application depends on internals, you know you might get burnt by a minor/micro update
- A new class loader service (see below)
- Better logging with consistent error id (our goal is to build an error-id to solution database somewhere over time)
- A move to Git and GitHub for version control: hopefully this is speeding up community contribution integration
Historically, Hibernate relied on standard class-loading paradigms that targeted JSE and JEE deployment environments. However, with the growth of OSGi and other modular systems like JBoss AS 7, those same approaches no longer always work. So Hibernate needed a new approach that would allow it operate in all possible deployment environments.
In Hibernate 4 we leverage the ServiceRegistry to define a pluggable service for providing interaction with the class-loading of the semantics of the environment in which Hibernate will be run. Specifically, the idea is to allow external entities (the user, the environment developers, etc) to define and
plug in a custom scheme for class path interactions. For example, an OSGi container could choose to provide Hibernate (either directly or as its JPA provider) and install a custom service for class loader interactions to override the default one.
JBoss AS 7 integrates with Hibernate 4.0.0.Beta1, to provide both the EE container managed JPA features and application managed access as well. The AS7 JPA subsystem integrates with Hibernate via the JPA specification SPI interfaces. In earlier releases of JBoss AS, JPA integration code was part of the EJB3 container (reflecting the evolution from EJB entity beans). Moving the JPA integration code into its own subsystem helps simplify the code and makes it easier to make changes.
Enabling the (Infinispan) second level cache should be as simple as including the following in your persistence.xml file:
<shared-cache-mode>ENABLE_SELECTIVE</shared-cache-mode> <properties> <property name="hibernate.cache.infinispan.cachemanager" value="java:jboss/infinispan/hibernate"/> <property name="hibernate.cache.region.factory_class" value="org.hibernate.cache.infinispan.JndiInfinispanRegionFactory"/> </properties>
I (aka Scott Marlow) would like to thank the following people for contributing to the JBoss AS7 JPA subsystem:
- Stuart Douglas for contributing to the JPA subsystem.
- Steve Ebersole for contributing to the JPA subsystem (especially Hibernate 4.0 integration).
- Jaikiran Pai for contributing to the JPA subsystem and answering an amazing number of questions in the forums (JPA + hundreds of other topics).
- Emmanuel Bernard for answering my never ending JPA 2.0 specification questions.
- Carlo de Wolf for answering my questions about the EJB3 subsystem (which the new code is based on).
Improving support for applications that use a different version of Hibernate than is packaged with JBoss AS 7. The plan is to let users deploy the Hibernate jars as well as a hibernate-jbossas7 integration jar. The integration jar will be tailored to the specific couple of Hibernate / JBoss AS version (or families of).
To be clear, Hibernate native applications can already include their own version of Hibernate in JBoss AS 7 simply by including the jar in their deployment. But we want JPA applications to benefit from this enhancement as well. Because it involves specification classes, this requires a bit more work.
We will also include additional tuning options to disable some of the JPA integration (ie prevent the container from starting the persistence unit).
What's new in AS7 in relation to Bean Validation? The short answer - nothing. It was already awesome ;) The initial version - AS 7.0 - ships with Hibernate Validator 4.1.0.Final. This is the same Validator version as in AS 6 so no change there.
The long answer is that Hibernate Validator 4.2.0.Final merely missed the AS 7.0 release train and an upgrade is planned at the latest in AS 7.1. What will the update mean for AS users? Besides the usual bug fixes and performance improvements, the biggest new feature is the implementation of appendix C of the Bean Validation specification: method level validation.
With this API a Seam Validation module. Another new feature is the ability to combine the composing constraints with AND and OR operators. There is also a fail fast mode in which validation stops on the first validation error and a new message interpolator which is able to interpolate the validated value.
As you can see AS 7.0 is just the beginning. More is to come in the coming releases...
We are working on Hibernate Search 4 which will be compatible with Hibernate Core 4. As a matter of fact, we have already published a compatible version via a Maven SNAPSHOT but expect a first alpha release soon.
Hibernate Search 4 is our chance to fix mistakes from the past. To be honest, the codebase and concepts have aged quite well despite the massive feature shifts we have done in Hibernate Search. Anyways, we are doing some changes including splitting API/SPI/implementations to help people discover when they use a class that is subject to change.
We are also working on a new per index manager to better use some of the new features and design changes of Lucene. This will give you more flexibility on how to index data on a per entity level (sync/async etc).
Happy code/fast deploy/test cycles :)
Steve, Hardy, Scott Marlow and Emmanuel
First, watch Jason introduce you to what's new and cool in JBoss AS 7, then, you can watch Dan and myself show you how to write apps for JBoss AS 7. Next up was Brian, showing you the JBoss AS 7 domain model and how to manage your subsystems, finally we have Paul and Bela showing you how to cluster JBoss AS 7.
This was a great series of tutorials, full of live demos, so check it out.
If you are looking to get started with JBoss AS 7, you might want to take a look at the 5 ways to deploy an application to JBoss AS 7 screencast I recorded yesterday.
The quickstarts will be used as the basis for the JBoss AS 7 webinars we are hosting today and tomorrow. There is still time to join us - check out jboss.org for more, or use this quick reference:
|June 29, 2011||16:00 UTC, 17:00 London, 18:00 Berlin, 12:00 (Noon) US Eastern, 09:00 US Western||Register|
|June 30, 2011||07:00 UTC, 08:00 London, 09:00 Berlin, 12:30 Mumbai, 15:00 Bejing, 17:00 Sydney||Register|
I just got back from the excellent Paris JUG where I presented CDI to a packed room.
We started by covering the basics - the Java EE 6 platform, before doing a deep dive (using the Weld Pastecode example) into the various features CDI offers and when you might want to use them. We also took a look at EJBs and how you can use them to supplement the programming model offered by CDI. The slides I used are available .
After the break, we then took a look writing CDI extensions. We took a look at the way you can observe the events CDI fires when the container starts, and how you can use these to modify the deployment. We then used a few examples from the cdi-extensions-showcase to show how simple yet powerful the extensions SPI is. The slides I used are available .
You can hardly fail to have noticed that JBoss AS 7 is coming any day now - everyone at JBoss is pretty excited by this!
We want everyone to check it out, as we think the improvements it offers (2.5s boot, small memory footprint, super easy config and more) will have you dancing in the streets. To get you going, we've arranged a special series of webinars covering AS7 for the end of June. Jason Greene will give you an overview of AS7, Dan Allen and myself will show you how to write and test Java EE6 apps for AS7, Brian Stansberry will demonstrate exactly how easy it is to configure a JBoss AS 7 domain and Paul Ferraro and Bela Ban will show you how to cluster JBoss AS 7.
Get your registration done today!
I am happy to announce that last week we officially kicked off the beta stream for AS7. This will be a very rapid biweekly release schedule up until we hit CR. So expect to see a lot coming from us very quickly.
The first release of this series is AS 7 Beta1,
Ides of March (released on the 15th), and it includes a number of significant changes/improvements over the original alpha.
On the management front, we have moved to fully detyped management model which will allow for Java based management clients to use a single, small library, for controlling any subsystem in AS7. We also now have a new HTTP/JSON interface that allows for applications/tools to be easily written in any language, since most have a number of JSON frameworks already. Finally, we have an initial implementation of our CLI (command line interface). The CLI included in this release focuses on exposing the lower level operation API that is part of our other management interfaces. Future releases will include a more task/command driven layer, which we expect to be the most commonly used.
On the EE front, we have completed the core foundation of our unified component infrastructure. All EE components (Servlets, EJBs, Managed Beans, etc) have common annotation processing, naming, injection, lifecycle, proxy, and interceptor facilities. All of it is dependency based and takes advantage of our lightweight service container. This means that deployments will automatically start in the correct order even with complex relationships. Also if one fails it can succeed later if the facility it depended on becomes available.
In addition we have initial support for a number of the EE web profile (and beyond) technologies including:
- EJB - Annotation driven SLSBs, SFSBs, and Singletons
- Bean Validation
- JAX-RS / Resteasy
You'll also notice that even with all of these additional services running we still have a very fast boot-up time (1800ms on my system).
You can download the Beta1 release in the usual location
The current getting started wiki is here.
Stay tuned for Beta2...
We just recently released new JBossAS7.0.0.Beta1 (great work guys!):
While I’m not so involved (as with JBossAS5 and JBossAS6) with this new runtime / platform, I do still closely follow what and how things are done. And I must say it’s a real pleasure to work with the new concepts and super easy to add anything new, meaning the good old JBoss user experience  is here to stay!
To borrow a saying from my colleague, let’s put the code where the mouth is. So, let me list a few things I did lately to see what could be done with new JBossAS7. Note: this is experimental stuff, and as such no guarantees apply :-)
Back to JBoss2?
As probably some of you remember, JBossAS used to also ship with Jetty as web container. Since I was already working on Weld and Jetty7/8 integration, I started wondering what it would take to have that old web container option again.
And it turned out, as I expected, that having hello-world functionality was really easy to do. But since my goal was to be able to deploy Weld’s Permalink example, it took a bit more work to get JSF and CDI in place. Specially JSF was a bit of an issue, with all the static factories, etc, not to mention the fact I know little about JSF. While CDI integration turned out to be fairly easy, as it wasn’t much different from what I already did for pure Weld servlet integration.
The code is here: https://github.com/alesj/jboss-as/tree/jetty but with JBossAS7 super fast progress it’s already far behind the current upstream master. So rebasing this would not be so trivial. Hence leave it at POC. :-)
Grapher2 strikes back
Another history artifact brought back to life. :-)
This is something I did to inspect MC’s dependencies. But with a bit of refactoring and better OO practice, I easily managed to turn this into generic dependency displaying web app .
Since JBossAS7’ new classloading layer is modular, it is probably a good thing to know what some of these dependencies are. And this is where this tool helps you. At the moment I quickly added just two “commands”:
Pull my finger
As already mentioned, the new classloading layer is 100% modular. And looking at JBossAS7 standalone.sh, you can see that the whole app server is actually started as single module, which then pulls in its dependencies and so transitively-forth. So, what about if we only shipped this single jar plus a few descriptor files, making the distribution only (that-jar-size) big?
It turns out this is really easy to do. The whole module loading is left to ModuleLoader class, meaning if we properly implemented this, it would be able to pull our modules remotely.
This is the remote ModuleLoader class that does it:
And this is my experimental distribution -- only 377kb!. :-)
(this pulls modules from googlecode project experimental repo)
With sub-systems and services already being on demand, this is how you can do the same with modules. Also you can simply delete the existing module from your disc, and the remote ModuleLoader will pull it down for you again, making updates sharing really easy.
OK, back to my Weld work now, and onward to 7.0.0.Beta2!
 -- as a user (cca 5y ago) I always loved the way you could easily change default AS behavior, or add new things; aka SpringDeployer ;-)
 -- yeah, I know, the default layout sucks :-)
Congratulations to the whole AS team on the release of version 6! JBoss AS 6 is a Java EE 6 compliant application server, so it includes built-in support for many of the technologies we talk about here: CDI, JPA 2, Bean Validation, EJB 3.1, JSF 2.0, Servlets 3.0, along with many major enhancements in other areas.