Manage, Store, and Generate Your Web Site Using ... eDirectory?
Novell Cool Solutions: Trench
By Kendall Buchanan
Digg This -
Posted: 19 Jul 2002
Like most businesses, IT in the education sector has a widening gap between the amount of work that needs to be done and the amount of resources, human and capital, available to do the work. Wasatch County School District is no exception. In our district we have over 1700 computers and 30 servers run by one administrator, 2 technicians, and one programmer. Obviously, for our intranet and internet services, we want to design them to be as automatic as possible. With limited resources, keeping up with a general web site that represents our district is far too time consuming to even bother with. In the past, like most districts, we had a single static web site that delivered the most basic information, such as: contacts, Acceptable Use Policies, and links to internal services like GroupWise.
Our goals for a new web site included:
- Must be a one-time setup (no more FTP to update pages).
- It must be fully dynamic and self-sufficient. A person should be able to update the web site with very little or no HTML knowledge, and NO GUI's.
- Must be hierarchal.
- Must be able to update the site from ANYWHERE with a browser and an internet connection.
- Must be easy to give access to certain people for updating certain portions of the web site.
- Must be fast.
Our district network is already built on eDirectory (we store just about everything in it). All permissions for everything related to the network, save the grading system (which will change with DirXML), come from eDirectory. After learning about the LDAP SDK's for Java and C from Novell, we learned that content from a directory could be pulled directly to the browser. We learned that we could design a JSP page and pull things like news posts into a web site from the directory. That's great, but we still wanted to be able to make this much more flexible. We needed entire directories of sites to be dynamic, not just individual pages.
We've taken LDAP and turned it into our hierarchy of web sites instead of a file-system. Instead of individual files holding our framework for dynamic content, we wrote a program that pieces an LDAP directory into the framework of a web site. Not only does an LDAP entry/object contain content, it becomes the web site that the user was looking at. Each object in the directory represents a whole new section of the web site. When a user goes to the "home page," the program decides which object in the tree represents it. It then opens the object, reads in the properties that holds various content, and then checks all of the child objects of the object to decide which links to display on the browser. The child links then become links that the program interprets as directions to get to the child objects of the "home page." Then the cycle repeats itself. The child page has now become the main portion of content displayed to the user. By using an object to represent a whole new page of content, there is no worrying about any HTML file handling whatsoever.
With the help of Novell Portal Services, we could design a gadget to browse the portion of an LDAP directory and edit, add, or delete web site objects. This would accomplish the goal of being able to update the web site from ANYWHERE. In addition to a gadget, conventional directory managers such as ConsoleOne and NetWare Administrator can manage the objects.
Altogether, with this design, the web site is as scalable as we want. With very few people updating the web site, we can keep it large with very little work.
How it works:
When the user goes out to www.wasatchdistrict.org, Apache 1.3, which is running on a NetWare 6 server, hands the job off to a Java Servlet served by Tomcat 3.3 running on the same server. The Java servlet relies on a small number of set properties in a web.xml file. The web.xml file points the servlet to an LDAP server to retrieve data, a base distinguished name (DN) in the LDAP directory to use as the base of all web site objects, and an XSL stylesheet file that will be used to transform the output information from the servlet. The servlet caches the XSL stylesheet for future use and then begins examining the LDAP tree.
The servlet looks at the base DN and determines which object is to be used as the "home page." The servlet always uses the object with a common name of "cn=home" as the main page. The servlet decides which object to display based on a parameter from the HTTP request sent by the user's browser. www.wasatchdistrict.org would point to "cn=home,ou=basednorwhatever". www.wasatchdistrict.org?page=jobs-home would point to "cn=jobs,cn=home,ou=basednorwhatever".
After this, the servlet reads the object from the directory and pulls the needed attribute values from it. It takes a title, the main body content (which is the very small part of HTML that a person can put in), a date creation, a type of web site (the type determines if it can be a news post, etc.), and a description. The servlet gathers this information about the object and then gathers information about each child or sibling of the object which it uses to make links to other web site objects. It then wraps this information into XML which is then passed to the cached stylesheet to be transformed and then sent to the user's browser.
In a nutshell, once the Java application is set up, there is no more web site designing to be done. The stylesheet holds the basic design of the entire site while the objects hold the content and minimal design for each individual portion of the site. While this completely allows for administrators to easily add dynamic content to the web site from just about anywhere from a Novell Portal Services gadget, it also allows for normal NDS rights to users to give control over specific portions of the web site in a scalable way. Other cool features of this have already been used in Novell Portal Services. With a new stylesheet, we can choose specific objects to be read from the LDAP directory through the Java application to be displayed as news for specific groups of people in Portal Services with the use of the XML_Remote gadget.
With more resources, this idea for an LDAP structured web site could be brought to wider uses. Currently, we are working to develop a calendar addition to the Java application which will use LDAP objects as months and events to display on the web site. There are also possibilities of creating design wizards to create automatic setups for LDAP directories and company specific information to use this very same solution. Currently, an entire dynamic web site with a design pertinent to a company can be up and running within a few hours, ready to add news events, pictures, and documents. With a more developed version including wizards and XML capabilities, much larger sites could be up in a matter of minutes.
Kendall Buchanan is the Program Developer for the Wasatch County School District and one of the winners in our "Send us Your Demo" contest. He can be reached at email@example.com
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com