ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button O'Reilly Book Excerpts: Building Java Enterprise Applications, Vol I: Architecture

Business Logic, Part 2

Related Reading

Building Java Enterprise Applications
By Brett McLaughlin

by Brett McLaughlin

This is the second part of an extended excerpt from Chapter 8 of Building Java Enterprise Applications, Vol I: Architecture. This installment focuses on the UserManager component. The first installment covered the facade pattern, a way to use session beans to access entity beans, and introduced the officeManager component.

The UserManager

Once offices are set up, the next logical step is to deal with Forethought users. Users are crucial to any application, which makes the UserManager component a critical part of the Forethought application. This particular manager component will also illustrate some of the important reasons for using managers at all. Chief among those reasons are data source transparency and data format transparency. Both offer advantages to the manager clients and provide many of the security and ease-of-use benefits already discussed earlier in terms of the OfficeManager.

Data Source Transparency

In the case of Forethought offices, all information related to an office is stored in a single table, in a single data source: the Forethought RDBMS OFFICES table, which we set up in Chapter 3. While extremely convenient, this is most often not the case. It's a lot more common to find that a single logical entity (like a user) has its information stored in multiple tables (like the USERS and USER_TYPES tables), and even in multiple data sources (like the Forethought database and the Forethought directory server). As a result, working with one logical piece of data often requires operating upon multiple physical pieces of data. This can become quite a pain for application clients: they must use JDBC to connect to a database, SQL to select from and join together tables, and then JNDI to operate upon a directory server; finally, the resultant information has to be spliced together in some meaningful form. As a good developer, you should seek to avoid this complexity.

The User entity bean and the LDAPManager component have already alleviated some of these problems; these two components abstract all the details of connection and specific SQL and LDAP statements from the client. However, a client (or piece of code) would still have to know that the core information about a user is in the database, and therefore an entity bean is needed, while the authentication information is in a directory server, so the manager is employed. Add to that the need to not only utilize the User entity bean, but the UserType and possibly Office entity beans as well, and things are only marginally better than they were without beans and managers at all. What is obviously needed here is another level of abstraction. As the saying goes, "Everything in programming can be solved with another layer of abstraction." It is here that UserManager-type components come in. By providing a single component for working with users, the data sources involved with that component are hidden from the client. For example, consider the process of adding a new user. Figure 8-5 shows that while the client makes one single method invocation (to add( )), the UserManager bean actually operates upon the directory server as well as multiple entity beans. This transparency of data source not only results in the client having a much easier means of adding a user, but also removes any exposure of the underlying data schema.

Diagram.
Figure 8-5. The UserManager's add( ) method in action.

Data Format Transparency

In addition to data source transparency, designers of complex systems often need to worry about data format transparency. Data format transparency basically means that a client does not have to make distinctions in data that characterize best practices in data storage. In other words, a client does not have to worry about how data is actually stored. The back end can be designed according to the best practices in data storage; the client doesn't know or care about the details. In other words, a client can act logically without having to think physically. Of course, I've been addressing this logical-versus-physical concern for this entire chapter, so there should be no surprises here. Consider that a client will be dealing with a user most often by that user's username (such as gqg10012). However, the directory server and database deal with the user's distinguished name (such as uid=gqg10012,ou=People,o=forethought.com). Forcing the client to worry about that lengthier and less meaningful format is clearly not desired. Your manager components can hide these format details.

As a concrete example, the UserManager component allows users to be specified by their usernames, and then internally handles conversion to distinguished names. Of course, you already have a method to do just this in the LDAPManager component. To accommodate new needs here, it makes sense to make that method public. Additionally, there is no compelling need to require an instance of LDAPManager to be available for using the method; as a result, the method can be modified to be static, as well:

public static String getUserDN(String username) {
    return new StringBuffer(  )
            .append("uid=")
            .append(username)
            .append(",")
            .append(USERS_OU)
            .toString(  );
}

You'll want to make this change in your own manager component (including the getGroupDN( ) and getPermissionDN( ) methods). With that done, the UserManager component, as well as any other session bean dealing with users, can have interactions with users based simply on a supplied username. As a result, clients don't need to deal with, or even be aware of, the format in which usernames are stored in the data sources. In this way, your managers provide data format transparency. Of course, this same principle could be applied to allowing complete names to be specified ("Mike Rhyner" would become "Mike" and "Rhyner" as first and last names), state conversions ("Texas" would become "TX"), and so forth. In these ways, manager components can allow you to simplify the job of a client.

Pages: 1, 2, 3

Next Pagearrow