1. Developing the NSDL User Portal Dean Krafft, Cornell University dean@cs.cornell.edu

2. 2 Developing a User Portal: An NSDL Case Study  Quick Overview of Public SourceForge  The NSDL Communications Portal  uPortal and the NSDL.org portal project  Environment: Java, XSLT, and Tomcat  Coding Tools: Eclipse, XMLSpy, Ant, JUnit  Process Tools: CVS, Tasks, Trackers, and Wikis  Experiences

3. 3 Public SourceForge  Supports Open Source projects at http://sourceforge.net http://sourceforge.net  Originally OS tools (CVS, GNU Mailman, Chora) with PHP “glue”.  Provides: Projects, User registration, File Releases, Tasks, Trackers (Bugs, Features, Patches), Docs, News, Mail Lists, CVS Repositories, Web space  versus Enterprise: All code is open to view and must be open source licensed

5. 5 NSDL Communications Portal  Enterprise SourceForge: customized  Multiple workspaces supporting collaboration and code development  Local additions: Wikis for collaboration, controlled read access to CVS repositories  General use of web space, mailing lists, trackers, document mgr, CVS

7. 7 Portals and User Interface workspace  Wiki documentation of system requirements – collaborative updating  Task lists: short term to-do for development process  Trackers: Bugs and modification requests  CVS: Primary store for code – collaborative revision control system

11. 11 Portal Technology for NSDL.org  uPortal (http://http://mis105.mis.udel.edu/ja- sig/uportal/)  Open source from the JA-SIG consortium  Java and XSLT customizable framework  Channel Architecture (portlets)  Uses Apache Tomcat as Servlet engine  NSDL.org: Primary user interface to NSDL. Supports news, help, search, browse, exhibits

15. 15 Java/XSLT Web development  Java code takes input, interacts with DB, and creates small XML document representing unique content in output  XSL Transform “renders” the XML into XHTML targeted for specific browser  Same XML can drive many XSLTs  Separates “business logic” in Java from “display specifics” in XSL transforms

16. 16 Java/XSLT pluses and minuses  Enforces “separation of concerns”  Enables using different levels of developer for different aspects of project  Simplifies retargeting portal to different browser, device, or look&feel  Use of XML enables automated processing and testing  Downside: It’s slower

17. 17 Multiplatform Environment  Develop on Windows, deploy on Linux  Apache, Tomcat, Ant, Java, XSLT, uPortal – all run on both  Identical Ant build.xml files (and everything else) on both platforms  Only a few path names changed (build.properties)

18. 18 Coding Tools: Eclipse  Open source Java IDE – IBM originally, now http://www.eclipse.org  Provides real-time error flagging  Excellent CVS integration and synch.  Direct support for JUnit tests  Good support for Ant build files (2.1 has better)

20. 20 Coding Tools: Ant  XML-based Java automated build system (written in Java)  Supports multiple targets: compile, deploy, db, test (think “Make” for Java)  Supports direct CVS interaction and fully automated testing with JUnit  Other plug-ins available: http://ant.apache.org http://ant.apache.org

22. 22 Coding Tools: JUnit/HTTPUnit  eXtreme Programming (XP) – test first, last, and always  JUnit: Unit testing for Java classes  Builds a suite of tests, piece by piece  XSLT test: Run transform against known input, then validate output against schema  HTTPUnit: HTTP-level request/response testing for running portal.

24. 24 Coding Tools: XMLSpy  XSLT is a non-procedural “stylesheet” language for transforming the structure of XML documents  XMLSpy supports development and test execution of XSL Transforms  Allows creation of XML samples and schema for Java output  Supports validating output of XSL transform against XHTML DTD

26. 26 Process Tools  CVS – Version control, differencing, good cross-platform Open Source sol’n.  Tasks – Important for distributed project, optional for small, local group  Trackers – Critical for tracking bugs, modification requests, etc.  Wiki – Nice collaborative environment for discussion/requirements. There are alternatives (BSCW, Groove, email).

27. 27 Experiences  Java & XSLT worked extremely well as a web development approach – separating concerns and skills  Eclipse IDE is an excellent Java/Ant/JUnit/CVS environment  XP paradigm of continuous build & test worked very well – builds confidence  SourceForge tools helpful but not essential – but we were local