Tapestry: A centralized user management system

Simplify application development with a ready-to-use centralized user management system

You are a developer embarking on an ambitious project to create the grandest and most powerful visionary system in the world. After designing the most amazing architecture and laying out the most meticulous plans, you start to assemble the necessary components to begin the project. But which module do you deal with first?

Discounting utilities and similar applications, most systems need to identify their users. Without this ability, a system would be incapable of ensuring its own security. Further, it would not be able to provide appropriate access levels, personalized services and functions, or usage tracking. User identification proves critical, especially in enterprise systems, systems built for businesses, and generally any system that needs to have accountability for its users. Unfortunately, it is also the most often overlooked feature during systems development.

This article describes Tapestry, a centralized user management system that allows developers to reuse the same set of users for every application system they build. Tapestry is a work in progress. For more information, visit the Tapestry Website.

After reading this article, you will be able to:

  • Understand why it is easier and more productive to employ a centralized user management system compared to other schemes
  • Understand what Tapestry provides for you as a developer
  • Learn more about Tapestry's design and architecture

User management

When creating application systems, whether client-server or Web-based, the first module to be developed usually concerns user management. Some application systems hook themselves with the operating system or database management system to provide this function. Others develop their own user management and tracking capabilities. Indeed, no single converging standard exists for user management because most are proprietary and not usable beyond similar platforms or systems.

User management's ubiquity underlies its importance: every system needs to create and manage users, to control access, and to configure who can use or administer it. The user management module represents one of the most necessary modules of any application because an application's whole premise centers on its value to users.

Naturally any module with such critical and essential functions needs to be robust and fail-safe. An application system without a running user management module is for all practical purposes crippled.

Considering its importance, it is quite surprising to realize that most, if not all, applications create their own user management system, often from scratch. From the arguments given above it would be logical to assume that reuse of a common user management module (see Figure 1), either built new or as a centralized user management platform, would be a better choice for development in a new system. Besides reducing development time, the developers of the new system would have the advantage of a tried and tested user management module to rely upon.

Figure 1. Centralized user management

The advantages of a centralized user management system include:

  • Development time is reduced because there's no need to reinvent the wheel.
  • A ready-for-deployment user management system allows developers to concentrate on the business application.
  • In an enterprise environment consisting of many systems, each system does not need to manage its own set of users; a separate system is dedicated to managing all its users, which allows for separation of tasks.
  • A single sign-on system in which all applications that use the separate user management component would have one single login and password. User management and security authentication would be cleanly and modularly decoupled from the application itself.

However, separation of user management from the application logic proves more difficult than it looks. The initial euphoria stemming from the benefits will soon bring doubts as to how realistically it can be achieved.

Development approaches

So how can we create a centralized user management system that circumvents the issues highlighted above? There are three approaches:

  • Ground-up approach
  • Framework approach
  • Central server approach

The ground-up approach

With the first approach, we build the user management from the ground up by embedding it within each system. Ground up represents the most common method, with each application system possessing its own user management. One drawback: the different application systems cannot communicate user information with each other, resulting in isolated islands of automation. Application systems work perfectly well with their respective user management modules because they are tailored specifically to them. However, integration is a major issue, which frequently plagues most enterprises.

The framework approach

The second approach uses frameworks, an abstract collection of software objects dedicated to solving a class of problems through a flexible and extensible architecture. It is prefabricated software that can be reused, extended, or customized for specific computing requirements. Frameworks have no real infrastructure, so building new systems can be as flexible as necessary. However, the framework approach takes some upfront work. After all, nothing concrete has been built yet, although a significant amount of infrastructure has been laid. In the end, overall development time is reduced and, because the framework standardizes access to the user data, there is a certain level of uniformity. Frameworks are usually tried and tested as well.

However, frameworks are white-box tools and the reuse favors extensibility, not direct usage. As such, you will still need to build a user management system, although it will move along faster. You'll still need to understand its internal structures, and the learning curve can be steep.

The central server approach

The third approach employs a central server, actually the single-server, multiple-client approach widely used for client-server systems. In this case, a central user management server controls all user information, with client systems requesting the information from the user management server. The advantages: the application system is decoupled from the user management module, and user management is controlled at a single point of access. Moreover, it is much easier to develop with a central server approach since the developer does not need to create the user management module at all.

However, because the application system is decoupled from the user management server, it is necessary for the user management server to provide the correct user data to each application system that accesses it -- not an easy task. It's difficult because user data is often tightly coupled with the application system itself. The ability of a user to access a system can be highly dependent on the existing user types.

Another problem: a user in a particular application system possesses attributes completely different from users in other systems, not to mention different access rights. As an example, consider a scenario in which the initial environment includes a single user management system and three application systems. Moreover, we've solved the previous user/application logic coupling problem. However, by adding a fourth system, we will throw a monkey wrench into the delicately balanced ecosystem (see Figure 2). The user attribute needs and user/application coupling of the fourth application system will render the user management system useless, unless major changes are made to the system itself, which will cause repercussions to the other three applications. This will in turn cause negative feedback rendering the system unstable.

Figure 2. Adding a new application system

The industrial factory analogy

As an analogy, consider the construction of industrial factories. The main component of every factory is the power generator. Every factory needs different power supplies, depending on the type of factory, its location, and the type of equipment used. Despite the differences, some form of power supply is always needed. In an industrial zone that contains many factories, power generators prove critical to their continuing operation. Imagine that you are the industrial zone operator responsible for providing power to all the different types of factories in the zone. How would you go about doing this?

The ground up approach would be to build a power generator for every factory in the industrial zone, specific to the needs of each factory. In this case, to build each factory, the owner must find out his needs and build the power generator. While it's a flexible choice, it can prove difficult to manage and maintain because each generator type would require its own spare parts and fuel types. Besides, building a new power generator for each factory is very time consuming and unproductive. The time spent could be used to concentrate on building the equipment used for manufacturing -- the factory's real purpose. The bottom-up approach represents the traditional approach to software construction.

The framework approach is equivalent to building components that allow you to build power generators. This ensures certain uniformity in building generators that are easily maintainable, and all of which uses the same fuel and parts. In addition, you can build generators quickly, yet be able to tailor each generator to the specific needs. Still, each factory must build each power generator itself. (Of course you can also buy the power generators from suppliers and customize it to your needs, which, for the purpose of this mental exercise, is the same as what has been just described.) Frameworks represent the currently popular component-based approach to software construction.

As for the central server approach, you as the industrial zone's operator would build a powerful and robust power generator to supply power to all of the factories in the zone. This is the most effective means of managing the power supply to the factories; you need to take care of only one generator, one type of fuel, and one set of parts. At most, for power supply fail-over and load balancing, you can build two identical generators. Dependency is decoupled and based on interfaces. On the downside, each factory must conform to the standards of a single power generator -- a very restrictive proposition.

Returning to the discussion on user management and comparing all three approaches, we see the pros and cons of each software development model. What is needed is an approach that combines the flexibility of ground-up development, the easy assembly of standard components, and the loosely coupled interfaces of the central server.

Tapestry

The Java-based Tapestry Web services provide a user management system that address the requirements outlined above. It is defined with WSDL and SOAP, and published using UDDI. Tapestry clients do not need to be Web-based, as they can be activated via any SOAP-compliant client running on any platform. Further, it employs HTTP to transport the SOAP information to and from the client, which in turn is translated by the SOAP router to access the actual services.

What does Tapestry do?

Tapestry uses three mechanisms to provide the best-of-breed features from the three approaches above, while solving the problems stemming from each approach. Firstly, Tapestry is a Web service. Requests are made as SOAP envelopes encapsulated in HTTP requests to Tapestry, and returned as SOAP envelopes encapsulated in HTTP responses to the application systems. Therefore application systems that use Tapestry do not necessarily need to be Web-based or even Java-based, as long as they can understand SOAP. This effectively decouples the application systems from the service itself. In other words, there is no need to develop any user management system, or even extend from it.

Secondly, Tapestry employs a package of dynamically generated base Java classes that represent the user data. A developer-modifiable configuration file dynamically generates these classes. Coding is not necessary or even possible for the base classes. This way, configuring for new applications is easily done, as long as the user's older attributes are not removed. This plays on the strength of component frameworks: Tapestry is an open and flexible system. Classes are dynamically generated to hide away the complexity of coding the base classes. It also reduces the probability of errors in the code.

1 2 3 Page 1
Page 1 of 3