JBoss Deployment Dependencies of a War

When your war file depends on another service to deploy first you can add a depends element in the WEF-INF/jboss-web.xml. This will guaranty the deployment order, and the war file will not be deployed until the PluginManager Service is deployed first.

 
   
   jboss.admin:service=PluginManager

I know I looked for this before and was not able to find it. Now I won't forget.

--Kurt

Hibernate Interceptors, Events and JPA Entity Listeners

Hibernate became is an implementation of the JPA specification. The JPA specification is part of the EJB3 specification (JSR-220). See, SUNs FAQ on that if you want to know more about that.

Hibernate Interceptors
In a recent project I wanted to intercept Create, Update and Delete events. From the Hibernate Reference Documentation it was pretty straightforward to find out how to create an Interceptor class. I extended my AuditInterceptor class from the EmptyInterceptor interface and implemented the onSave, onFlushDirty and onDelete methods but then was a bit puzzled how to activate the interceptor. Chapter 2 talks about specific hibernate configuration properties, but how to use those when you're using a JPA persistence.xml? It turns out the answer is very simple. Pretty much any vendor specific property can be set in the persistence.xml using a properties block. In this case a property with name hibernate.ejb.interceptor needs to be set to the full name of my AuditInterceptor class.

Some advantages are that

• you don't to change any of your existing code, just add your interceptor and update the persistence.xml
• the onFlushDirty gives you a nice detailed information on what changed

but on the flipside

• the interceptor fires for every entity bean, and chances are you're only interested in a subset. I ended up doing the filtering in my AudutInterceptor.
  
• if your primary key is set by the database, the id is still undefined when onSave fires.

Hibernate Events
The capabilities of Hibernate Events API goes beyond those of the Interceptors. It gives you very fine-grained control over where to hook into the event stream. Check out the org.hibernate.event package for all the different interfaces you can implement.

Some advantages

• fine-grained control over where to hook into the persistence process (lots of Pre- and Post-event interfaces)
• The event objects are contain a wealth of information, including previous and current state of the entity.

but on the flipside

• hooking up your EventListener is either done programmatically or using the Hibernate session-factory configuration block. I guess I could use a hibernate.cfg.xml file and reference that in my persistence.xml, but it started to feel convoluted to me.

JPA EntityListeners
FInally there are non vendor specific JPA EntityListeners. To use an EntityListener you simply add a '@EntityListener (class=)' annotation. Then in your listener class you can use other annotations (like @PrePersist, @PreRemove, @PostPersist, @PostRemove, @PreUpdate, @PostUpdate and @PostLoad) to decorate your listener methods.

Some advantages are

• fine-grained control as to which entities you want to listen to (annotation on the entity, referencing your listener class)
  
• pretty good control on where you want to hook in your listener (annotation on a method on the listeners class)

but on flipside

• the API only gives you the current state of the entity, and does not provide information as to what changed in case of an update.

Conclusion
In my case I ended up with a hybrid solution using a HibernateInterceptor for the Update and Delete, and using EntityListeners for the Create event, listening to the PostInsert events so that the id field on my entities are defined.

Book Review: Business Process Management with JBoss jBPM

Business Process Management with JBoss jBPM
A Practical Guide for Business Analysts, by Matt Cumberlidge

I have been working on Service Orchestration in JBossESB, using jBPM, and a few weeks back PACKT Publishing asked me to review the JBoss jBPM book. I have been reading it whenever I had a spare moment. I have to admit the book was not what I initially expected it to be. For some reason I thought the book would be an in depth text book about jBPM and it's features. It is not, well it's got some of that, but what it really is, is what the title already says: “Business Process Management with JBoss jBPM; A Practical Guide for the Business Analyst”. So I guess I skipped over the 'for the Business Analyst' part. However after actually reading the book, I think the author picked the right subject by explaining how to do a BPM project in the first place.

Truth be told I may have some idea about it, but I never read anything that formal on the matter, and the best part is that Matt simply follows a fictitious (or is it?) project about a record company called “Bland Records”. In Matt's words “Bland Records' specialty is in finding talentless, yet attractive youths, assembling them into bands of four or five, partnering the ready-made band with a songwriter and some real musicians, who finish the product with an addictive set of tunes. The end product is released on an unsuspecting public who promptly shoot the band to number one in the charts”.

The book is to the point and an easy read. The first few chapters are about what a Business Process actually is, what the interaction the Business Analyst and the Developer should be and how to set up interaction channels with the customer, how to put together the project team and how to find the right project sponsors to optimize the chances to deliver a successful product. In his book he sets up a workshop for the project team where the business process is analyzed and a flow diagram is created, before breaking for lunch. After lunch the team goes through the flow diagram to identify the roles and responsibilities. He goes over terminology like PID (Process Identification Document), SME (Subject Matter Experts) and RACI (Responsible, Accountable, Consulted, Informed), and how to use the RACI Matrix, and finishes by how to end up with a realistic implementation plan. I really enjoyed these two chapters.

Chapter 3 explains how to install jBPM and it gives a quick introduction to the product. The chapter has plenty of screenshots to keep you on track and you should get a good visual picture in your mind about jBPM capabilities, the chapter finishes by implementing the business process as a proof-of-concept system. Chapter 4 adds a user interface to the prototype and by the end of the chapter you have a fully functional system, for which you can get sign off from the client. This is a nice break point in the project where some wrinkles can get ironed out before putting more time into making the thing look nice. Chapter 5 speaks to how to deploy and setup the proof-of-concept and how to go through some iterations with the team. At this point the integration points with other systems should still be stubbed out. Finally, when the iterations have honed the business process implementation, another sign off follows and in Chapter 6 he describes how to convert the proof-of-concept to a production ready system and by setting up a BAM (Business Activity Monitor) to gather process metrics in production. At the end of chapter 6 the project goes to production and in chapter 7 the team comes together for a post mortem, where they try to evaluate the success of the project, and they try to come up with an ROI of the system. Assuming all is in order a final sign-off from the client can now be obtained. Over time the process metrics can be tracked and future projects may implement process change requests.

The book is a quick read and I think it very wise to hand out a copy to each of the members on your team when starting a BPM project. The price may be a little steep, but part of it goes to the jBPM project and I'm sure those costs can be expensed on the project anyway ;). Thumbs up on this one.

JBoss SOA Platform (SOA-P) Documentation

The SOA-P team incorporates a team of technical writers who take the project specific documentation and turn it into documentation for the SOA Platform, which is the supported 'RHEL' version of JBossESB (where JBossESB would be Fedora). In the true spirit of Open Source, this documentation is available for free, under the support/documentation tab of the Red Hat homepage, or you can go directly to the SOA-P 4.2 docs. I was quite impressed with what they did to some of the docs I wrote! Thanks guys.

Single SignOn (SSO) with Seam using JOSSO

I recently used seam_gen to create a josso_console application. If you want to use JOSSO, but you don't yet want to take the leap to hook it up to an LDAP or other industrial strength credential store, then this is the app may come in handly. Figure 1 shows the welcome screen of josso_console application.


Figure 1. The JOSSO console.

If your objective is simply to hook your Seam application up to JOSSO then you should keep reading too.

1. Seam and JAAS
Seam comes with its own security framework which is based on JAAS. The easiest way to hook Seam up to JOSSO is to first configure your Seam-based application the conventional JOSSO way and then hooking up Seam and JOSSO using a Seam authenticator. I worked on a jossoAuthenticator that will set the SSO user and roles information into Seam context, so that you can use all the Seam security features while using JOSSO.

2. Configure JOSSO
In your josso-agent-config.xml add the josso_console in as a partner app


Now your application will have access to the JOSSO cookie.

3. Configure Seam
Next we're going to protect our application using the standard security constraints to the web.xml. For instance if we only want users that have the admin role to access our console you would add


This web.xml references the login-redirect.jsp which you will need to add to the root of your war file. Now, you will be redirected to the josso login screen when trying to access the web application.

Next we have to propagate the authorization information into Seam context. For this we use the jossoAuthenticator.
Next you need to reference this class in your pages.xml, by adding

and commenting out the default authenticator

Finally we need to modify the pages.xml, where we reference the jossoAuthenticator on our welcome page (index.xhtml) like

which will cause the jossoAuthenticator.checkLogin to be called for this page, and in the exception class configuration we specify the index.xhtml page


All should now be working. If you want, you can obtain the full sources from the josso_console application to see the complete application.

Some other resources in this context you may find useful are:
http://www.josso.org/confluence/display/JOSSO1/JBoss+4.2
http://sdudzin.blogspot.com/2007/12/windows-sso-with-jboss-seam.html, and
http://www.ja-sig.org/wiki/display/CASC/Seam+Identity+Integration+(Seam+1.2.1+-+2.0.0)