Transcript The Developer Perspective

The Developer Perspective
Michelle Osmond
Design – Requirements Gathering
•
Sales & Research projects
–
Prototypes/Demos
•
User group meetings
•
Usability workshops & questionnaires
–
With close collaborators: resource-intensive process
–
Focus on Java Client, not portal
•
Support calls
–
Bugs
–
Feature requests
Design - implementation
•
Service-oriented approach to implementation
–
J2EE, EJBs / Java RMI / Web Services
Servlets
Java Client
Web services
Data/WF Storage
Configuration
Command line
Deployment
Server
Portlets
Web Portal
Execution
Task Archive
Design – create workflows
•
Main focus on Java client for workflow development, execution and deployment
Design – deploy workflows
•
Provide framework for users to develop and deploy their own workflows to the
portal
– Users manage their own design and evaluation of portal services
Design – web portal (servlets)
•
Basic portal:
– Userspace (file) access
– List of services
– Dynamically generated
page for each service
Design – web portal (portlets)
•
Jetspeed (portlet-based) portal:
– Users additionally have control over the whole portal site layout
– Can integrate own custom tools as portlets
Technical Strategy
• Technologies
– J2EE (JBoss) server, includes portal on embedded Tomcat (servlets, JSPs,
Struts).
– Portlets: JSR-168, on Jetspeed 1.6
• Portal Functionality: subset of Java Client, for simpler use
– Userspace access (files and workflows)
– Execution of deployed workflows (services)
– Task management
Also:
– Server administration
Development Issues
• Time / Resources
– Portal & its usability not a top priority
– Engine and Java Client have the focus
– Many developer skills needed:
• Java RMI, Swing GUIs, Tomcat/J2EE, XML, HTML, CGI,
JavaScript, JSP, Servlets, Struts & Tiles, JSR-168, Applets, AJAX…
• Web design, accessibility, usability, compatibility
Development Issues
• Browser differences
– Discourages development of rich interfaces using JavaScript
– Plugin support, e.g. SVG
• Technology limitations
– Struts & portlets
• Portal QA
– Difficult to do comprehensively
• Maintainability/testing of rich JavaScript interfaces
Evaluation
• Java client has the focus
– Usability workshops, questionnaires
• Portal not formally evaluated
– Bug reports, feature requests
– Users design and evaluate their own portal services
Lessons Learnt - Good
• Deployed services are useful and popular
– Easy to parameterise and execute
– Easy to update and add functionality
• Users have complete control over portal services: design, construct
workflow, deploy to web
• Flexible and powerful workflow system
• Portlets allow portals to be easily customised further
– Skinning, layout
– New, custom or third-party tools
• Continually developing new features, driven by user requests
Lessons Learnt – Not so good
• No formal UI design stage or manager
– Inconsistent look & feel
– UI convenient/intuitive for the developer, not the user
– Deployment tool UI in particular (working on this)
• Awareness of UI problems: existence, importance
– “INVALID” bugs, “it’s documented in the manual”
• Interactivity, rich interfaces
– More web renderers for parameter entry
– Result visualisation
– Service linking
Future Plans
• Better deployment tool GUI
• More custom, interactive web visualisers for data
• Service linking & interactivity
– More web renderers, e.g. applets & JavaScript, for complex input
– Smoother use of multiple services
• Update technology:
– newer versions of JBoss, Tomcat
– Look at newer portals: Jetspeed 2, JBoss Portal
end