ландшафт. the exhaustion that was the combined CampusEAI Portlets2008 and Annual conference is now behind us, and it seems like time for some reflections and observations. Hopefully some of these items will be items which I expand upon at a future date, but in no particular order, dumped straight from my brain:

• JSR-168 is here! Everyone really wants to write good standards compliant portlets. Architecture and engineering is a harder sell (or at least the time/cost trade-off) but there’s wide consensus that standard portlets are the way forward — at least excepting a couple of us widget fans
• SOA is something people are interested in, but that there’s been relatively little forward progress on. Some is governance. Some is tools (SOAP, WSDL, and what’s this REST thing?). Some is just that it’s big and strategic, and there’s many tactical must haves. I suspect some of it is also that much of our interesting data/services are locked in vendor platforms that have shown little interest in opening up. Though, a small trend does exist of creating SOA-style services to reach into vendor platforms and extract data from them
• Mobile wasn’t as big as I thought it would be. Not sure why. Most people seem to be interested in the abstract, but with few concrete plans. Maybe my iPhone has clouded my vision, but I do wonder if we’re going to get blindsided come fall — our target demographic is basically 18-22 year olds, afterall…
• AJAX in portlets is still hard. There are some tricks like wrapper divs, namespacing, and builtin support and integration patterns, but it’s still not a common practice.
• Identity Management is big. Governance is a big thorny issue, though many IT departments are rolling out vendor products from big players (Oracle, Sun, a little IBM) in the interim, tho ugh the exact scope of those items is somewhat unclear.
• Oracle is really putting portlets in lots of interesting places. Webcenter. Product mashups. Inside BI tools, and other GUI devices. I think they’ve probably embraced the architecture more than any other major vendor which is an interesting trend.
• Lots of awareness, and wanting to look at uPortal 3. Ooohs and ahhs over both the AJAX D&D, and maybe more importantly the new content adding UI — good going Jen!
• Really beautiful portals — some, though not all new portals really seem to be breaking out of the lots of boxes approach, or at least wrapping it in neat functionality like Boston College’s Agora design. Nifty trend. Sign of maturity?
• Community Development is hard. Aligning roadmaps, agreeing on implementation strategies, and putting all the pieces together is challenging. Even more so, justifying “doing it right” (and fit to share) versus quick and dirty, or getting a student up and running was a big trend. Makes my inner-engineer quail, but my inner-economist says that throw-away code lowers the barrier for solving problems, which is a good thing. Evolution isn’t always pretty and all that.
• Lots of desire for training, best practices, and advice on policy and governance. Real role for communities of practice, not just code and software.
• Increasing interest in “Enterprise Learning Management”. Lots of worries about migration, but the beginning of seeds wondering whether our current platforms are sufficient for a foundation for the next 10-15 years, and University strategic goals. Of course, some of this is the “enterprise IT guys” getting pulled into the LMS discussion for perhaps the first time in many places.
• Good beer is key to facilitating interesting non-session discussion. Content is king on the program, but largely only because it gets people in one place and produces interesting spontaneous interactions. Hands-on is something everyone wants, but it’s not clear a conference composed of many 1 hour sessions is the right format to deliver it.
• University IT teams wear many, many hats.
• British Universities seem to have a much richer and more abundent IT project management structure than (most) American schools. Really interesting thread about Imperial College in London blending ITIL and Agile methodologies.

JSR-286 (the next generation Portlet specification) was approved last week.

The major new features of version 2.0 include: * Events – enabling a portlet to send and receive events and perform state changes or send further events as a result of processing an event * Public render parameters – allowing portlets to share parameters with other portlets * Resource serving – provides the ability for a portlet to serve a resource. * Portlet filter allowing on the fly transformations of information in both the request to and the response from a portlet

I have to admit I have mixed feelings on the spec. It certainly adds a number of features to facilitate inter-portlet communication, and messaging which were commonly requested. Part of me does wonder though if Gadgets, Widgets, and platforms like OpenSocial are going to leap past the Java Portal space. The aggregation and plumbing aspects which we’ve really focused on in many ways seem much less interesting than standardizing the data model behind obtaining presence, personal, relationship, and other data — something that the social networks seem to be moving full speed ahead on.

Coming soon…

Sitting on a flight, returning from the Sakai conference — still trying to take everything in. There’ll probably be more musing on the significance of specific items coming up, but things that struck me enough to want to brain dump were:

• There was wide consensus during the planning sessions that there’s a desire to focus on quality: reliability, testing, performance, and other traits, over new feature development.
• The community is moving from a development -> production mindset. The transition of many of the core schools from pilots or development efforts into full-blown production instances has certainly changed priorities and outlooks.
• Increased desire to pick up open-standards in preference to inventing our own. JSR-168 (Unicon demoed a cool Portlet-Tool for Elluminate integration), JSR-170 and the good work Ian is doing to integrate with repositories like Jackrabbit and Xythos, CAS Authentication (vis-a-vis Dan M.’s sweet CAS-embedding UserDirectoryProvider)
• There’s a lot of commercial activity around Sakai. RSmart, Unicon, Oracle, IBM, bit players like Mark Norton & Zack Thomas. I sat in a presentation about the work I did with FIDM for CampusEAI. I even talked with another developer who has already resigned (as of Jan 1) from his university to join his part-time venture (with others) full-time. Certainly a large, vibrant marketplace.
• Many sub-groups are organizing around Sakai. In addition to our very own NYC Regional group, there are groups in California, Australia, the Netherlands, and other places. They’re holding events, sponsoring training, and moving forward.
• It’s not just regions — there are an increasing number of functionally aligned teams. Developers, Designers, and Managers are the best organized and served. I also saw a lot of User Support people or academic technologists as well. This is the group I suspect may be the next to organize — a CAFE track focused on bringing user support people up to speed or sharing experiences/resources would probably be really valuable.
• Lots of parallel activities. Many examples of SIS integrations, library integrations, documentation & training, tool development. Unfortunately, communication barriers and other difficulties seem to be producing several duplicate/parallel efforts (e.g. Yale’s SignUp tool, EDIA’s signup tool, Stanford’s efforts around this space) though there is a desire to collaborate.
• Some stuff is still too hard: authentication integration, CourseManagement integration, libraries work, documentation, training are all pain points, especially for smaller teams/schools.
• Strong community. It’s easy to get lost in a group of smart, affable people moving towards a common purpose. Had an excellent time, and there’s a good sense of camaraderie weaving throughout the community. People are friendly and helpful.
• Twitter – yeah, it’s kind of narcissistic, but at an event or convention it can certainly be a lot of fun. Both to do self-organizing (e.g. dinner?) and to pull in people who are in the circle, but not present.

Chuck is talking a bit more about his experience with portlets, and the implications for uPortal, Sakai, etc.

Sakai portlet notes: * Preferences – site.upd to change * Edit Mode – site.upd again * isUserInRole() mapped to Sakai permissions site.upd, content.read, etc.

The isUserInRole() mapping seems a little counter-intuitive — seems like really portlet.xml should be mapped to a particular Sakai role, and that the portlet implementation should decide whether to hardcode the semantics of that role, or look them up based on sakai permissions, or another approach.

Chuck is again advocating JSR-168 as an alternative to the Sakai tool API. At the end of the day, I really feel like the most interesting model might be building Sakai tools that use JSR-168 as the view API. So you throw away the cross-platform promise, and just rely within Sakai on JSR-168 as a well-defined, nicely separated tool component API. Though, he had a note on the end about Sakai-specific portlets, but I don’t think he’s sold yet.

Single Mind Consulting – Summary of Sakai

Furthermore, Sakai is designed as a series of independent tools built upon a robust, standards-based framework (uPortal).

<snip />

Sakai’s uPortal is a powerful portal environment that utilizes the portlet specification to ensure interoperability.

This particular perception – that Sakai contains an embedded uPortal instance which it uses to do the aggregation of tools and services is not correct — (though it’s understandable given historical context — see below). Sakai actually includes a custom developed portal engine “Charon” which is used to handle site aggregation and display. In the 2.4 branch, Charon has some preliminary integration with Pluto 1.1 to handle rendering JSR-168 portlets. While this is the same approach taken by uPortal, the integrations don’t share implementation details beyond the common adoption of the Pluto portlet driver.

The original Sakai vision (I wasn’t involved at the time — this is just my perception/understanding) was for Sakai to just produce a collection of instructional tools. The uPortal angle is that the tools were going to be implemented as JSR-168 portlets, with some framework-style glue to support integration and common functionality, but leveraging the portlet spec to provide isolation, separation, and markup aggregation.

This plan resulted in discussion about partnership, and resulted in a portion of the initial Sakai Mellon grant being allocated to uPortal for development of the PortletAdaptor for uPortal 2.x, as well as creation of uPortal 3 — a rewrite of the uPortal framework intended to enhance/provide native JSR-168 portlet support.

During the course of development of both projects (Sakai & uPortal 3) however, delivery pressures and emerging understanding of the needs of both camps caused development efforts to drift apart. As a result, Sakai 1.0 shipped with a custom portal which I believe was a derivative of CHEF’s portal infrastructure (based on JetSpeed1?). As Sakai has evolved, a number of Sakai-specific metaphors like site-membership have been introduced, further splitting the functionality of Sakai and uPortal.

Currently efforts are focused more on integration between Portals and Sakai. Chuck Severance has done a large amount of work on summary views and other proof-of-concept exercises, and Sakai 2.4 ships with an enhanced Charon portal which supports alternate views like RSS which are intended to aid integration.

Hope this helps clear things up…

Tags: sakai uportal

Building components aimed at serving needs of Kuali (Finance, Research, Student?), but hopefully reusable in other contexts. Kuali Rice – middleware to facilitate workflow, ESB, notification “Nervous System”

“Rice Client” tied into ESB to pass around real-time messages and communication. One of the goals seems to be to limit the amount of Java code in a client through a service layer, supporting RAD against this framework. Then you plug into the bus which provides service registry, remoting, etc. Sounds a lot like the RMI use-case is a key consideration. Client should support a lot of the service wiring and other connection details. Pushing to looslye couple separate products, and provide technical consistency.

Continue Reading »