Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 14 Next »

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

  • No labels