Highway Three Solutions

I’ve sat on the fence for a number of years on the topic of using XML for configuration. Being familiar with XML helped me to overcome the nagging feeling that it just doesn’t seem ideal. Well, I’m no longer on the fence and I can thank Stripes for it.Stripes is a web application framework for Java, it falls in the same category as Struts. Stripes takes the “Convention over Configuration” approach and this really separates Stripes from the pack. Utilizing Annotations instead of XML, streamlined configuration requirements, and (my favorite) event binding, I am able to get projects started quickly and easily. Seasoned developers of other frameworks will tell me they are able to do the same, and of course they can, they’re seasoned experts. But, the simple configuration requirements in Stripes leaves little room for snags and bugs found when configurations don’t match up (struts-config.xml anyone?). Developers shouldn’t have to battle with configuration, especially when so many applications all start the same way. This is where Annotations over XML comes in.

Because I can annotate my action bean in Stripes I can localize configuration errors to the responsibility or set of responsibilities I’m developing (Yay event binding !). Now my configuration is clearly and cleanly attached to my code, making it easy to find, easy to adjust, and easy to debug. The days of massive XML files containing all process flow for your application in a single file are over!

Event Binding is something I really enjoy about Stripes. Event Binding allows me to put multiple responsibilities into my Action bean, reducing the number of files required for the application. Using Annotations I can create a single Action bean designed to handle all responsibilities for a common subsystem, such as user management. In other frameworks I may have created Action beans such as: AddUser, UpdateUser, ShowUserForm, etc. With Stripes I can create a single action bean called Users and put all the functionality in it, bound to callable events using Annotations. This, to me, is a prime case of convention over configuration. It’s more simple and less complex. There is cleverness in simplicity.

Although I’ve compared to Struts this isn’t a “Stripes is better than Struts” article. Preference, requirements, obligations, and suitability all factor into a decision for Java frameworks. If you’re seeking some functional examples of how Annotations can be used in place of typical XML configurations I highly recommend you try Stripes. Hibernate is another fine example as well, but that’s another post in another category.

http://mc4j.org/confluence/display/stripes/Home

http://www.hibernate.org/

If you use an LDAP server for authentication, and work for a company with legacy applications, you have probably explored the option of LDAP synchronization. Particularly if you are using Oracle, the integration with OID is tightly coupled with the middleware applications. Historically, OID synchronization has been difficult to configure, has significant performance impacts, and requires regular monitoring of the replication.

In Oracle Internet Directory 10.1.4, there is a new option - Server Chaining. You can use server chaining to ‘virtually’ link to another LDAP Server. I have implemented this architecture so that we could take advantage of the Oracle integration with OID but also include a large group of users existing in an external LDAP server.

The actual server chaining takes about 5 minutes of configuration, and all of the users in the remotely mapped container appear in the local OID. Authentication via SSO is immediate - both OID and chained users authenticate seamlessly.

Group management can be done on both types of users, and this group membership is recognized by Oracle SSO-enabled applications including Portal. You can add a chained user to an OID group via OIDDAS or directly in the oidadmin utility. Presumably you could also include a local OID account in a remote chained group but I didn’t use this functionality.

There are some issues with server chaining though - the oracle OIDDAS interface throw an error if you log in as a chained user. You can log in as an OID account and search for the chained users, but there is some kind of error in the OIDDAS that just throws a proxy privilege exception and does not allow you to continue (or log out) once you have entered chained user credentials.

There are several Oracle and third party applications that use direct LDAP authentication, such as Application Express, Confluence, XML Publisher. These application generally require a specific realm within the LDAP server that is used for access. It is not recommended to map the chained users into the root realm within OID, so it is difficult to allow both chained and local users to authenticate into these ldap-direct applications. However, this would also not be possible in the original architecture since the users were distributed in the source LDAP.

The biggest issue I have experienced is that currently you can only chain one remote LDAP of each type (Active Directory and SunOne). It would be great if you could map to different ldaps, or have filter control on the mapping. Because our chained accounts were in many realms, we had to map at a very low level and degrade search performance on OID because of a lot of (unnecessary) account mappings.