We have always thought that one of the best-kept secrets amongst the ColdFusion "universe" is its tremendous potential and success within select educational institutions. Those that work with or for public educational institutions are very familiar with the staffing and budget issues that often cut resources, making it difficult to provide services to the communities that support them. However, as East Carolina University found, all that is needed is a little funding, some talent, and a willingness to learn.
As subscribers to CFDJ since the first issue, we have often read many "how-to"s with sections of code and invaluable "tips and tricks". While we couldn't be nearly as productive without these articles, we find it extremely beneficial at times to learn from other implementations and methods used to solve potential challenges. At risk of providing an effective sleep-aid, we would like to attempt to share the experiences of implementing ColdFusion at East Carolina University, an emerging national research university with enrollment of nearly 22,000 located in Greenville, North Carolina (www.ecu.edu).
At that time, he was armed with only a Bachelor's degree in Computer Science and a solid knowledge of HTML and general programming. Development of a "web based" employment application seemed a somewhat intimidating task. He sat down, scratched his head, and began designing the employment application. Several chapters into a Perl manual that would make a dictionary seem like interesting reading, he figured there must be a better way to develop this application. As if by magic, a colleague called one afternoon and suggested trying a newly discovered product called (or so he thought at the time) "CoolFusion." After borrowing the manuals, Steven started to dig deep, looking for that better way.
Just a few minutes of reading resulted in actually entering data in an HTML form and submitting, retrieving and displaying that data through a database connection. While this example is extremely elementary, it was nothing short of a miracle at the time. How could a few minutes of reading and programming replace days of reading a Perl manual? Within two weeks, an application and associated database tables were designed and developed, allowing potential applicants search and apply for vacant University positions.
The use of this ColdFusion-based system offered cost savings across the board. Not only did fewer paper applications have to be printed and made available to the general public, but also less staff time was spent processing incoming paper applications as well as mailing paper applications to interested applicants. In fact, nearly 60% of the employment applications are received via this solution. The implementation of this type of solution also allowed for a more diverse applicant pool, as information was made available to a much larger audience and was not restricted to a local area.
Nearly seven years later, with nearly zero maintenance, the same application is running strong and has received nearly 150,000 employment applications from over 20,000 applicants applying for over 2,500 vacancies. In addition, the application has the distinction of having been selected as one of two ColdFusion applications developed by East Carolina University as national "best practices" by a major college and university personnel association, with the other being an employee performance evaluation system.
At the time, the two or three applications available to students via the web were HTML pages generated by a COBOL batch program. While effective in providing information on a daily basis, it did not provide students with the dynamic information they required.
It wasn't long before we were able to develop a system that allowed students to log in and obtain a great deal of personal and academic information via a web interface. This web interface was called "The Student Desktop," and it allowed students to perform many standard student tasks such as check their grades, register for courses, view course offerings, update address information, and so on. The system offered personalized content to the degree that it even "sang" Happy Birthday. Corny? Maybe. Effective? Definitely.
Over a lifetime of nearly two years, the ECU Student Desktop enjoyed usage by nearly 90% of the student community. Though the Student Desktop was functional and provided a robust set of applications for the campus community, it was lacking in several areas. Most importantly, while students could benefit from the information provided, few applications existed to help the academic and administrative staff. In addition, usage peaked during time periods such as final grades and course registration, though the system saw little usage otherwise. From a development perspective, the current system did not make use of a specific development methodology or allow for easy extensibility or customization.
While we knew that we wanted to re-engineer some of the applications made available via the Student Desktop, we needed a delivery method that would give all members of the campus community a centralized location for access to the information and applications needed. We were also determined to design a system that provided greater security while also providing extensibility and a set of APIs to our development team. If we could possibly accomplish all of these tasks while also finding a method to offer maximum code reuse, we would have a winner. This seemed like a rather tall order at the time.
By 1999, the portal buzzword was gaining momentum. We began brainstorming on how to best implement needed capabilities for the university through other portal implementations. However, the best fit we could find was a higher education portal project with a timeline that far exceeded our requirements... not to mention the overly complicated code that would be required for creating new portal channels. While the overall concept was useful, we felt we needed more functionality than any of the current models provided. We wanted a portal that would give developers the capability to quickly write an informational channel while giving them the ability to develop and integrate more complex applications. Naturally, ColdFusion came to mind.
After brainstorming, we felt that we could take the base concept of a portal and create an environment providing an easy-to-use development framework It would be a secure environment with functionality available via "tabs." Each tab would provide separate areas of content with at least one of the tabs providing typical "channelized" portal content. For example, you could simply click on one tab to view typical portal channels such as weather, stock quotes, current courses, and so on and then click on another "tab" to gain access to another area such as users tools. After much investigation and contact with Macromedia, we decided all this could be accomplished with ColdFusion version 5.0 (which was in alpha testing at the time), utilizing some of the newer features promised (e.g. UDFs, query of queries, etc).
The Fusebox specification and development methodology gave us a way to organize project files and abstract global functionality for our developers. Security, customer preferences and organization are all handled by the portal framework. In the past, we simply did not have a good method to accomplish these goals.
Though some additions to the standard Fusebox specification were made to file prefixes, the most drastic deviation from the specification was actually locating all fuses such that they are not directly embedded within other fuses as added functionality. Thus, control of what goes where and who gets what isn't implied by the browser location. Rather, it is managed by the framework that maintains roles-based security information about each fuse (i.e. students and alumni only have access to view their grades and instructors only have access to submit final grades for their courses).
Any fuse can call any other fuse. As this is done, the framework maintains a "breadcrumb" trail that gives the feel of depth through navigation. There are four types of fuses that give developers the capability of creating everything needed within the Fusebox methodology. The four types of fuses are hidden or system, channels, applications, and tabs.
After approximately ten months of planning, arguing, and long nights that ended with sleeping on the floor (well, that was mainly Phil, hehe), we emerged with some carpet fuzz, a strong coffee smell, and our first working prototype. While needing refinement, we knew instantly that this would be a success.
During the development of the portal software and into the beta testing phase, the members of our talented development team were creating the applications using ColdFusion that would run within our managed environment and ultimately breathe life into our software drawing customers back again and again.Whether visiting to check grades or discuss current events using the threaded discussion forums, it was the applications that were to bring the campus to our software. Without the talent of our developers and the functionality of these applications, the portal would simply be an empty shell.
As we brought together our software in preparation for the final release, testing returned such impressive results that we actually planed to release our first version of software using the ColdFusion 5.0 beta. With little announcement and fanfare, we released our portal software as the "ECU Onestop" to the campus community.
In addition, the home tab contains a login channel. This channel passes authentication credentials back to the portal, which in turn verifies and forwards the customer to the appropriate location via the framework's security. In our case, authentication consists of multiple sources including a Permission Structure A typical dynamic role would be that of a student. Once a login is authenticated, the information collected from the LDAP directory is used to execute a series of dynamic role routines. At this point, queries are made to the student database and others to determine what roles this particular customer may have (i.e. freshman, current student, graduate, instructor, staff). Of course anyone may have one or more roles. For example, it is possible for someone to be a student and an employee. The value of dynamic roles is that it provides updated permissions in real-time without having to manually maintain data for large groups. If a student were to be hired by a department, by the time he or she returned to the portal, their new role would be instantly available. The obvious question that arises from this type of update is overhead and delay at time of authentication. However, this was built with a feature that, based on an easily changed parameter, will limit how often these roles are refreshed. So, if need be, this can be increased for high loads. Also, we have a mechanism that allows anyone to update their roles at any given time.
Tools and Applications Many of these applications are written completely in ColdFusion using Fusebox, given the simplicity of the methodology. However, some are simple fuses functioning as an interface to in-house or third-party J2EE applications, COM objects or Web services. This allows us to maintain a diverse development team and allow freedom to develop applications in a variety of ways. For example, "course schedules and payments" was written using ColdFusion/Fusebox, which also relies on a J2EE solution to for e-commerce.
The "my page" tab gives authenticated customers the ability to add, remove and organize their own personally preferred channels. The capability to have more of this type of tab is available. However, we have discovered that simplicity is not only a valuable lesson in art... it's a necessity in software usability (just ask our help desk staff). Default settings for what are considered the most appropriate channels for this tab are loaded when an account is automatically created. This type of tab's interface gives the capability to minimize, detach, edit and remove channels designated as having these capabilities. Some of our most popular channels are Current Courses (Students only), Personal Bookmarks, Weather, University Newspaper Top Stories, News Feeds and People Search. Many of these are syndicated XML content consumed from other sources. Most content from other sources is cached for performance purposes.
Personalization Other tabs within this implementation include "community," which offers a place for anyone to communicate through various roles-based discussion lists, a "profile" tab which allows anyone to see a quick snapshot of their standing at the university and an "e-mail" tab which is obviously a single application tab that offers an IMAP interface to our university mail servers.
While searching for a solution, we found the difficulty in development and deployment of a channel in other portal implementations a flaw. Developing a channel for this portal is extremely simple and could be done with only two files (application.cfm and index.cfm). However, since we display information and are using Fusebox, we like to break out any and all display into a third file (dsp_whatever.cfm). There are specific fuseactions required by the channel standard depending on the functionality of the channel. More complex channels may require edit and other additional capabilities. These all give the channel focus (no longer in a channelized layout) after which the channel functions much like an application. Whether developing a channel that interacts with an internal application or a channel that processes and displays a typical RSS feed, channel development time is minimal.
Much like the simplicity of developing an ECU Onestop channel, a simple application could be developed with as little as four files. These include application.cfm, app_locals.cfm, index.cfm and a single display file. There are no required fuseactions for applications. A default fuseaction is set within the app_locals.cfm file through a custom tag that is used to maintain the ever helpful "bread crumb" trail.
The security API provided by the portal framework gives each channel or application the ability to check the current customer's permissions for any other channel or application. This prevents the mistake of sending someone to a dead-end security error. In addition, this security API, among other things, gives the ability to encrypt and decrypt sensitive data that may sometimes need to be passed between applications through the SSL client connection. Developers also have the ability to check for specific roles for the customer. The "IsDemo()" function is a perfect example of the need for this. Other examples would be the need to check and allow more granular options available within an application (administrator, etc.).
The customer or person API provides access to current customer information. The notion of supplying APIs to developers provides an easy way to reference much needed information while maintaining a level of abstraction that drastically simplifies maintaining an environment such as this. For example, application developers no longer have to worry with developing queries to identify the user of the application as common information such as name and id are provided by this API.
The display API gives developers easy access to the "themes." Inclusion of these APIs allows the developer to develop applications with a consistent look and feel and improved usability.
Implementation of such interfaces drastically reduces development time and eliminates redundant code. Additional APIs are constantly being added for a variety of purposes including content formatting. As with most, our ultimate goal is to entirely abstract our display from our "business logic" while providing developers access to common functionality. This gives application developers a continually growing list of functionality simply built in for their convenience. Need the current semester? How about the department of the employee? Maybe I would like to know if a student is senior. All of these are a simple function call away.
As before, we have chosen the newest beta release of ColdFusion, "Blackstone" (now CFMX 7 of course) as our foundation. In addition, the latest evolution from Fusebox, Mach II, is taking shape to become the methodology upon which our newest portal and internal applications will be built. We are also developing methods allowing content display to be abstracted and managed more by the environment giving back even more valuable time to the developer. Other features include a single-sign-on module allowing single login access to external applications as well as JMS integration giving the portal and internal applications the ability to send and consume pertinent messages. These are truly exciting times! We are currently planning a prototype release during the spring of 2005. Carpet fuzz and coffee makers get ready.
Therefore, the ECU Onestop remains and will provide access to this new enterprise system. Again, the talent of a small group and ColdFusion was able to out-perform a product produced by a multi-million dollar corporation with more resources (and probably more coffee).
Whether it is the access to information or customization features desired by the campus community or the simplified, "drop in and run" approach to applications and channels, the ECU Onestop has proven a huge success. Though presented at many national conferences, nothing is more gratifying and an indication of success than walking through campus and hearing people call what we have created "their" Onestop.
Before we continue, we must mention the roles-based permissions structure used. When a customer is successfully authenticated, his or her role or combination of roles is determined. Unlike some portal adaptations, our primary roles of larger groups (i.e. students, employees, advisers, instructors, etc.) are not manually maintained or batch updated. Instead, we developed a method of dynamic roles. These roles are dynamically updated based on designated information queried from various databases (i.e. human resource DB, student DB, etc.). However, if needed, roles can be added manually as is typical in most portals.
As mentioned previously, it is these roles that determine the applications available to a customer via the "tools" tab. Typical tools available to someone with student permissions would be course schedules and grades, course registration, exam schedules, etc. Instructor tools would include course rosters, final grade entry, etc. Tools available to employees would include access to his or her pay information, employment opportunities, service request system, etc. At this point, the total number of applications available to the campus community is very close to the century mark.
An always-available "personalize" link gives customers the ability to personalize their personal my page tab or change the look and feel of the entire portal. Personalization options for this type of tab include adding/removing/rearranging channels and choosing between a two or three column layout. Customers currently using a typical portal will find this feature most familiar. In addition, customers have the ability to select a "theme" for the portal. A wide variety of themes with custom graphics and colors give customers the ability to change the entire look of the portal with a simple click of the mouse.
Lessons Learned
While the implementation of our ECU Onestop portal has provided benefits to our campus community, our development staff has also reaped rewards. The use of ColdFusion has allowed us to develop powerful channels and applications in relatively short periods of time. This fact, in conjunction with some development features and APIs made available within our portal, have provided a great combination.
Main APIs
One of our goals in the beginning was to extend the functionality of our portal and applications through the use of programming interfaces. Though they are continually growing, the main APIs available are for security, customer or person, permissions or roles and display (allowing applications to utilize the "themes" available providing a consistent "look and feel").
The Future
To date, the ECU Onestop (now running smoothly using ColdFusion MX 6.1) has experienced over 15 million individual logins by nearly 83,000 unique customers. A snapshot of our current customer base shows usage by nearly 98% of the student population and nearly 93% of our remaining campus community. While all is not fuzzy kittens and rainbows, our implementation has been successful. Though it would be easy to enjoy this success, we are now doing what developers do best...developing the next version of our portal.
Conclusion
In the end, two main ingredients made the success of the ECU Onestop portal possible: a dedicated, talented staff - and Macromedia ColdFusion. An additional testimony to a successful implementation surrounds the current purchase of a new, campus-wide, enterprise solution. As with most, this particular company offers an enhanced version of an open-source portal to provide access to their web-enabled software. At the end of our preliminary analysis, it was determined that our "in-house" portal provided greater levels of functionality, flexibility and customer service, while also providing a better environment for software development at a much lower cost and with less overall maintenance.