Frequently Asked Questions

FAQ administration

Who maintains this FAQ?

~jaf30@cornell.edu, our Documentation Coordinator, with help from other active participants in the uPortal development effort. We encourage contributions of questions (and answers), comments, and corrections.

How can I contribute to this FAQ?

You can contribute to this FAQ in any of these ways, depending upon your comfort level:

1. Sending your ontributions, suggestions, feedback, etc. to ~jaf30@cornell.edu via email and he'll incorporate them when possible.
2. Commenting directly on this page (see facility at end of page).
3. Editing this page. This is a Wiki.

General Questions about uPortal

What exactly is uPortal?

Simply put, uPortal is a framework for producing a campus portal. We don't intend it to be an out-of-the-box or "turn key" portal "solution". Instead, uPortal is a set of Java classes and XML/XSL documents that you can use to produce a portal for use on your campus.

Who is developing uPortal?

JA-SIG, the Java in Administration Special Interest Group. Several JA-SIG member institutions are collaborating on the development of uPortal, and they make the code itself available as a reference implementation to any member institution of higher education free of charge.

What level of Java knowledge is required to use JA-SIG's uPortal framework?

This is really three different questions rolled into one, because there are three different "levels" that we can use to discuss what you have to understand in order to "use" the uPortal framework. These levels aren't totally distinct - there's considerable overlap between them. Let's consider them one at a time.

One level addresses what you have to know in order to keep an instance of the portal, customized for your campus' requirements and IT infrastructure, running under your chosen application server. I'll call that the "administrative" level, since a lot of the tasks are closely analogous to administering a DBMS or HTTP server. See the section called "Deploying, administering and maintaining your portal", below.

The second level addresses what you must know in order to do the development necessary to produce an instance of the portal, customized for your campus' needs and IT infrastructure, that you'll use to facilitate the delivery of content and services to end-users. I'll call that the "implementation" level. See the section called "Developing your campus portal", below.

The third level addresses what you must know in order to develop programs (which the uPortal developers call channels) that will work within the portal to actually deliver the content and services. I'll call that the "content development" level. See the section called "Developing content and applications for use with uPortal ", below.

Will uPortal run on all platforms?

uPortal will run on any platform that has a Java 2 implementation available for it. JA-SIG members are running uPortal for development and deployment purposes on a number of different platforms, including Microsoft Windows, Solaris, Linux on 3 different architectures and MacOS X.

What differentiates uPortal from other portal solutions?

The primary differentiator is that uPortal is focused on the requirements of higher education institutions, whereas other products are mostly focused on the requirements of large corporations, even if the product is marketed to higher education institutions. uPortal is a framework that provides the Java programmers on your staff with the classes, interfaces, XML data files and XSL stylesheets they need to develop a customized portal for your campus. JA-SIG realizes that a portal, in order to be truly useful, can't something you take out of a box and install, it has to be something you customize for the needs of your institution. Some portal "solutions" are actually third party packages that a vendor of a non-Java, non-portal product acquired in order to enter the portal market without doing any R & D. uPortal was designed from the ground up to provide the tools you need to build a portal and has always been is a 100% pure Java. Still other portal "solutions" are services that are no charge to your campus, but require your campus to accept advertising in exchange for the use of the service. With uPortal, you don't have to run advertising in your portal, but if you wish to, your campus can keep the revenue produced. Last but not least, uPortal is also available free to member universities, most commercial portal "solutions" cost upwards of $50,000 per year for a typical campus' license.

Does uPortal support Portlets (JSR-168) and WSRP?

Web Services for Remote Portlets (WSRP) is supported by uPortal as of uPortal 2.2. The WSRP Proxy channel type replaces the Remote Channel that was introduced in uPortal 2.1. This WSRP Proxy acts as a WSRP consumer that can consume content from any WSRP producer, including another uPortal channel. uPortal 2.2 also partially implemented a WSRP producer. Support for that WSRP producer code has since been withdrawn, the code formally deprecated and finally removed from uPortal in uPortal 2.5. Also, WSRP authentication is not (yet) supported.

uPortal partially supports JSR-168 Portlets in uPortal 2.3 through a Portlet-to-Channel adapter. The Portlets will be managed by Apache's Pluto portlet container. As of uPortal 2.5, we expect uPortal to be fully JSR-168 compliant. Beginning in uPortal 3.0, Portlets will become uPortal's native content module, replacing the Channel. Support for IChannels will continue though a Channel-to-Portlet adapter.

Deploying, administering, and maintaining your portal

What kind of Java expertise would I need to have in order to successfully deploy and keep my campus instance of the portal running?

In general, over and above a working knowledge of and substantial experience with your chosen application server, you really have to understand the issues related to server-side application deployment and support in a modern, web-based environment. If you understand how to start, stop, and backup your your application server and a database server, and how to deploy a JSP 1.1/Servlet 2.2-based web application, then you know enough to administer a uPortal instance. Your application server vendor will be able to help you on this front with training and documentation if you don't.

What application server should I use for my campus uPortal instance?

uPortal will run in conjunction with any application server that complies with the Java Servlet 2.2 and Java Server Pages 1.1 specifications. There are members of JA-SIG currently operating uPortal instances with BEA's WebLogic, IBM's Websphere, and Caucho's Resin, among others. Please don't think that uPortal is somehow dependent upon Tomcat, the open-source JSP and servlet container from the Apache Jakarta project that ships with the existing "monterey" distribution and soon-to-be-released "plymouth" distribution. You can use any JSP 1.1/Servlet 2.2-compliant container or application server, and if you want commercial quality tech support, formal training or documentation, then a commercial application server is something to consider.

Does uPortal support single-sign in?

A qualified "Yes". The uPortal framework does provide an authentication system that explicitly supports the notion of single sign-on, but as of this writing there are few channels that ship with the framework which take advantage of it. Of course, any campus that wants to write their own channels that will use the uPortal single sign-on capabilities are certainly able to do so.

Does uPortal support LDAP authentication?

Yes. The problem, however, is that there are dozens of possible ways to do an LDAP authentication for uPortal and hence what is available now may not be useful for your campus. But there are a few Universities now who are using uPortal in conjunction with an LDAP server to authenticate users. There is a reference implementation available now for uPortal which handles authentication of users to the portal from information
stored in an LDAP server.

What doesn't uPortal use JAAS for authentication and/or authorization?

JAAS enables services to authenticate and enforce access controls upon users, but as currently specified by Sun, it makes many assumptions about how the services which use it will operate for effective use in a portal. JAAS allows authentication modules to be "plugged in" but doesn't allow services to modify the behavior of the system as a whole.

uPortal doesn't operate the way that JAAS assumes because a portal, any portal, must aggregate content and applications from disparate sources. uPortal must have an authentication mechanism that behaves differently than JAAS does because a portal must support single sign-on to applications which have their own, disparate authentication and/or authorization requirements.

The bottom line is that the uPortal developers think that authentication and authorization are currently too tightly coupled within JAAS, and would therefore delay the implementation of single sign-on in uPortal until Sun publishes a later revision of the JAAS specification which decouples them. Perhaps in the future JAAS could provide uPortal with security services, but in it's current state it does not have the flexibility nor the functionality to be incorporated well into uPortal.

How do I upgrade from one version of uPortal to another?

uPortal 2.1 comes with a database upgrade tool. See convert.xml which is an Ant build file that contains upgrade targets. Unfortunately, there is not yet a similar tool to help upgrade an existing uPortal installation to uPortal 2.2. The project desperately needs a volunteer to write such a tool. If you are interested, please email ~kweiner.

Developing your campus portal

What kind of Java expertise is necessary to develop a campus portal using uPortal?

In general, to use the uPortal framework to develop a campus portal (the "instance" of the portal for use with your application server), over and above the level of expertise necessary to administer your application server (see above), you must be an experienced Java programmer, familiar with the JDK 1.2 tools for compiling, packaging, deploying and running server-side Java programs, and conversant with most of the technologies that comprise the J2EE specification. Specifically, at a minimum, you must have experience with:

• XML. The uPortal framework uses XML and XSLT extensively to ensure the platform independence of data and to separate that data from it's presentation. To develop a portal with uPortal, you will have to create/edit XML files and create/edit XSL stylesheets. If you're not fluent with the XML-related APIs in Java, (McLaughlin2000) provides a comprehensive tutorial on writing Java programs that can create and manipulate XML documents. The uPortal developers highly recommend (Kay2000) to those looking for a tutorial and in-depth reference guide to XSLT. (Bradley2000) provides a guide to the overall XSL standard.

• JSP: The portal framework uses Java Server Pages to facilitate the intermixing of markup language code required by a web browser and programming language code that leverages the underlying Java Runtime environment. If you want to change the look and feel of the portal substantially, you'll have to edit Java Server Pages, so you should understand how to use JSP syntax correctly. For those looking for a tutorial on JSP, (Manning) is an excellent choice.

• Servlets. JSP works as an abstraction layer on top of the Java Servlets API and because of this, experience writing servlets will come in handy. Several programming 'idioms' in the portal code originated with Servlet programming. Although now a little dated, (Hunter1998) is a great tutorial on Java Servlets. The publisher expects to release a new edition soon.

• SQL. The portal requires the use of a relational database to store some user, authentication, and channel subscription information, and the standard way to issue requests to a relational database server is using SQL, the Structured Query Language. You must therefore be familiar with the syntax and proper use of SQL in order to work with the uPortal framework. (Gulutzan1999) offers comprehensive coverage of the SQL standard. I say these are minimums because if you want to deliver something over and above the minimum functionality (for example authenticating via an LDAP server) then you'll have to be familiar with other J2EE technologies and/or APIs (for example, JNDI).

You keep writing that uPortal is a framework. Isn't that just an empty yuppie marketing word?

No. I'm using the word 'framework' in its widely-accepted, Software Engineering sense (Wirfs-Brock1991). A framework is a reusable design, expressed as a set of classes, that can serve as a solution to a family of related problems and support reuse at a larger granularity than classes. A mature framework allows components to be reusedas "black boxes", that is, a programmer can incorporate them into a system under construction without knowing their implementations (Johnson1998). Most frameworks in widespread use today are for constructing graphical user interfaces (GUIs) for traditional desktop applications. uPortal is different in that it's a framework for developing a web portal and developing content for display within that portal, but the underlying principal of both kinds of frameworks is the same: the framework provides programmers with an infrastructure that supports a coherent architectural model, allowing developers to concentrate on applying their expertise to the problem domain. In the case of uPortal, the framework takes care of the common functionality that every portal needs, so that you can implement the parts that are important and specific to your campus.

Developing content and applications for use with uPortal

What kind of experience is necessary to develop content and/or applciations for use with uPortal?

It depends upon what kind of content you want to deliver through the portal. For simplest content provision, you only have to know how to produce an html document. One of the defined kinds of channels for use with uPortal is an RSS (RichSite Summary) channel, the same format that Netscape uses for their Internet portal. If you create an XML document which adheres to this standard , the uPortal framework will handle formatting and presenting the output for you. To deliver content which requires complex user interaction, you'll have to create a complete web application which uses a channel as its user interface. This approach requires that you have the XML, Servlets and SQL skills that someone developing a campus portal instance using uPortal has (see above) as well as experience with:

• JDBC. It's likely you will want your application to store information in and retrieve information from a database, so the ability to use the Java Database Connectivity API will be essential. The portal itself requires a relational database to store information related to users and their preferences, and the standard way for your application to access this information is by using JDBC. If you're not familiar with the JDBC API, (White1999) is a comprehensive tutorial, reference and source of sample code.

• EJB. If your application requires distributed data access, transactions and persistence, the Enterprise Java Beans distributed component model will probably become an important part of your architecture. For EJB beginners, (Monson-Haefel2000) provides a complete reference. To get an idea of what you're in for when you begin developing channnels, carefully read Michael Oltz' tutorial.

My university has a large number of legacy applications that we want to provide access to from the portal. Can I do this?

Maybe. It depends upon the application. Did you write the application (and have the source code) or did you purchase a binary package from a vendor? If you have the source code, its relatively easy to create an alternate user interface to the application that operates within the portal. in uPortal parlance, this would be called a "channel". Your channel would display itself to the user in the portal and feed the input from that user to your application. Your legacy application would then process the data and send the output back to the channel, and the channel would in turn display the results to the user inside the portal.

If you purchased an application from a vendor, things are a bit more complicated, but the high-level approach is the same. You'd have to write an adaptor that would wrap the output of the legacy application in XML so that it can be displayed inside the portal. When you have this, you can then write a channel for use with the portal that interacts with your adaptor and actually facilitates the translation of the XML so that the portal can display it.

Appendix

References

Books

[1] [Bradley2000] Neil Bradley. Copyright © 2000 Neil Bradley. 0-201-67487-4.
The XSL Companion. Addison-Wesley Publishing Company.

[2] [Gulutzan1999] Peter Gulutzan1999 and Trudy Pelzer. Copyright © 1999. 0-879-30568-1.

SQL-99 Complete, Really. CMP Books.

[3] [Harold1999] Elliotte Rusty Harold. Copyright © 1999. 0-764532-36-7.
XML Bible. IDG Books.

[4] [Hunter1998] Jason Hunter and William Crawford. Copyright © 1998. 1-565923-91-X.
Java Servlet Programming. O'Reilly & Associates.

[5] [Kay2000] Michael Kay. Copyright © 2000 Wrox Press. 1-861003-12-9.

XSLT Programmer's Reference. Wrox Press.

[6] [Fields2000] Duane K. Fields and Mark A. Kolb. Copyright © 2000.1-884777-99-6.
Web Development with JavaServer Pages. Manning Publications Company.

[7] [McLaughlin2000] Brett McLaughlin. Copyright © 2000 O'Reilly & Associates.0-596-00016-2.
Java and XML. O'Reilly & Associates.

[8] [Maruyama1999] Hiroshi Maruyama, Kento Tamura, and Naohiko Uramoto. Copyright © 1999. 0-201-48543-5.
XML and Java : Developing Web Applications. Addison-Wesley Publishing Company.

[9] [Monson-Haefel2000] Richard Monson-Haefel. Copyright © 2000 O'Reilly & Associates. 1-56592-869-5.
Enterprise JavaBeans. O'Reilly & Associates.

[10] [White1999] Seth White, Maydene Fisher, Rick Cattell, and Graham Hamilton.
Copyright © 1999. 0-2014-3328-1.
JDBC API Tutorial and Reference, Second Edition: Universal Data Access for the Java 2 Platform.
O'Reilly & Associates.

Articles

[1] [Bosak1999] Jon Bosak and Tim Bray. XML and the Second-Generation Web.
Scientific American. 16-25. May 1999.

[2] [Johnson1998] Ralph Johnson. Designing Reusable Classes. Journal of
Object-Oriented Programming. 19-45. June/July 1998.

[3] [Wirfs-Brock1991] Rebecca J. Wirfs-Brock. Object-Oriented Frameworks.
American Programmer. 21-29. October 1991.

Originally written by:
Bill Brooks
California Polytechnic State University

Modifications and conversion to html by:
~jaf30@cornell.edu, Cornell University