Web 2.0 at WebSphere Portal Technical Conference 2007

For the next release of WebSphere Portal, we are working on on exciting new Web 2.0 function, including AJAX based client side aggregation, navigation and customization, AJAX based feed aggregation, AJAX proxy capability, support of semantic tags and semantic tag based context menus, Atom/APP based access to portal data and portlet programming model extensions to allow easy access to portal data exposed via Atom/APP from JavaScript embedded in portlet markup.

Apart from the new Web 2.0 technology added to WebSphere Portal, Lotus has Web 2.0 applications under development for collaboration and social networking: Lotus Quickr and Lotus Connections which can both be integrated with WebSphere Portal. This allows to use the portal as a central entry point providing the right content, information, processes and applications to the right people at the right time and links to and integrates with the collaboration and social networking capabilities provoided by Lotus Quickr and Lotus Connections.

These new Web 2.0 capabilities will be featured in presentations at the WebSphere Portal Technical Conference 2007 in Munich, from September 10th-12th.

The event focuses on WebSphere Portal based solutions and is organized to provide IBM customers, business partners and colleagues with latest technical and strategy directions for IBM WebSphere® Portal Version 6.0.x and Lotus technologies, including extended support for Web 2.0 services, performance enhancements and new IBM Accelerator solutions that help customers to easily create a variety of SOA based composite applications, enabling faster deployment and user productivity.

Using Spring with WAS and WAS ND

Interface21, the company behind Spring, announced in June 2007 that it has certified and will support WAS as a deployment platform for the Spring application framework. This is as a result of a collaborative effort between Interface21 and IBM to test - on all WAS platforms - a number of scenarios that use Spring with WAS. There's also an interview, on developerWorks, between IBM's Paul Buck and Interface21's Rod Johnson, discussing the impact of this effort.

One of the results of this collaborative effort is an update to the paper on developerWorks that describes some of the best practices for using Spring with WAS. For example, this illustrates how Spring's declarative transaction demarcation is configured for WAS and how data sources should be declared in a Spring application context definition for injection into a transactional application.

A quick glance over at Rational

Yeah, this is a WebSphere blog, but I thought this eWeek Rational article would be of interest to WebSpherians as well. It's an interview with Rational's Lee Nackman about Jazz.

Honestly, I thought the questions left a lot to be desired, as if the interviewer had not done their homework before talking to Nackman (like "When will Jazz be done?", which is like asking "When will Eclipse be done?"). In spite of the questions, there's some interesting tidbits in there. For example:

Question: You said Jazz is like a middleware layer for building collaborative tools. Can you expand on that?

Answer: The way that I like to think of it is that the Jazz platform provides a middleware layer for software development and delivery. And so the way that that's related to the ESB idea is things happen and notifications need to happen. So somebody might create some sort of a work item, and somebody might be subscribed to a feed for those kinds of work items. And how does that get transported? The nice thing for us that there is so much good collaboration technology, things like RSS feeds, that exist now that we can just exploit.

Sounds like an interesting project.

Simple Ajax

I've been at a couple of conferences recently, and one of the hot topics that everyone is talking about is "Web 2.0". The great thing about these cool buzzwords is that they mean different things to everyone - but "Web 2.0" generally implies web sites that provide a richer, more interactive experience. In turn, one of the technologies that is used to provide this experience is Ajax (Asynchronous Javascript and XML). Ajax is not new, the technologies have actually been around for many years, but the pattern has recently been popularized by modern browsers and high profile applications such as Google Maps, GMail, etc.

AJAX is not a framework or library, it is an application pattern (although many frameworks are emerging to help, such as Dojo). An Ajax enabled page uses Javascript to send an XML request to call back to the server, the server asynchronously completes the request and sends back results, and then more Javascript in the page updates some parts of the page (rather than refreshing the entire page).

The problem is that developing AJAX based applications is hard - it requires writing complex Javascript and DHTML, and the asynchronous nature of the pattern further complicates debugging. There are also a series of other problems that have solutions - but are easier to get wrong, than they are to get right: Making the browser's 'back' button work is tough; Javascript has a tendency to leak memory; you must test your code on many browser variants, etc. As noted, frameworks that will help are starting to emerge, most notably Dojo - but they are still immature, and still require that you write JavaScript code in your page.

WebSphere and RAD have supported JSF (Java Server Faces) based applications for several releases now, and the combination of JSF and the JWL component library we ship offers a powerful combination that simplifies the development of applications. What's new is that RAD v7 has introduced some common AJAX behaviors into our JSF component library; you can now provide capabilities such as scrolling data tables with no page refresh, dynamic menus, and entry fields that support type ahead. The nice part is that none of this function requires you (the developer) to write any JavaScript - the bulk of the function is encapsulated in the JWL component library, and the tiny snippets that are required can be generated for you by RAD. In turn, this means you get to avoid most of the problems listed above - but still provide the enhanced interaction that people are starting to expect from modern web pages.

JSF based pages can co-exist quite happily with "normal" JSP and HTML pages, so there is no requirement for you to make a huge investment and redo your entire site. Instead, you can update just the pages that you wish to modernize, and provide the basic interaction patterns that are the hallmark of "Web 2.0". There are several resources available to help you understand the new capabilities, but a couple of articles on developer works provide a good starting point. The first one is "JSF and Ajax: Web 2.0 application made easy" and provides a general overview, and a second article titled "Improve the usability of Web applications with type-ahead input fields" walks you through adding typeahead to a JSF based page.

As Ajax continues to mature, frameworks such as Dojo will continue to add value to the development of advanced web pages - but the capability that's available in RAD v7 and WAS 6.1 today is more than enough to allow you to provide your customers with a modern, interactive site, without forcing your developers to go through a painful development process.

Tim Francis

Multi-Cores, SOA, SCA and the Incredible Lightness of Being

I received a link from a colleague regarding a recent article "SCA applies SOA principles to Apps Design" by Andy Dornan. The article starts off with a slant that SCA enables runtimes to take advantage of multi-core CPUs; further implying that while Moore's law still is applicable for making the processors themselves faster, that the real leverage in software gains comes from building applications that can have multi-core processors thrown at them. He theorizes that in order to really leverage the multi-core processor future, that applications must be broken up into small loosely-coupled components. And this was just the first paragraph.

Whoa. Where to start. I can say the article made me think, does SOA, or SCA for that matter really help applications deal with multi-core processors? Far be it for me to criticize semantic English, but multi-core processors imply same-box, and the focus of SOA and SCA relate to the wider, distributed network; which may be comprised of multi-core processor nodes. Certainly SOA does help application developers in arriving at application patterns and best practices that lend themselves to being advantaged by multi-core processors, or even more importantly a set of distributed processes and processors. Simply using container-based applications like JEE or even Spring put the majority of the burden of thread management in the hands of the middleware, where presumably there are appropriate controls and exploitation of multi-core processors have been meticulously built; that really doesn't have much to do with SOA or SCA. Billy Newport has blogged numerous times about applications and multi-core issues as well. While there has been lots of research in predictive instruction execution and pipelining, SCA offers more like a circuit board assembly than a flow chart (perhaps like BPEL) and its model doesn't really imply any ordering or sequencing which would afford any great advance in multi-tasking. Certainly SCA has asynchronous invocation concepts which would allow for a greater opportunity for muli-tasking, but I would hardly say they are transparent to the application.

To cut Andy a break, perhaps what he intends to say is the SOA and SCA programming style of providing declarative dependencies and policies allow the runtimes to better understand the application and therefore, de facto have a better chance of exploiting the hardware available to solve the problem.

The article then diverges into other topic areas for which I also have some comments.

• Java is certainly an important language for SCA to embrace and to treat in a first class manner, but it is hardly the only language. Certainly at least BEA and IBM and keenly interested in SCA assemblies with BPEL implementations, but there is lots of activity in other languages. Of course WebSphere is going to focus on Java -- it is a Java runtime. What will be interesting is how vendors choose to slice and dice the type of component implementations they support and in what form factor they will deliver that support.
  
• I didn't quite understand his comments about requiring a higher-level intermediary to embrace WCF components. Certainly WCF components can consume or be exposed as Web Services, using WSDL and XML for interface definitions -- SCA embraces both service consumers and providers. Perhaps I'm missing some other point Andy is trying to make. Certainly, as I've blogged about before, SCA embraces existing (legacy) technology and I don't understand why anything would have to be rewritten. This seems just wrong to me.
  
• I don't agree with the statement that the vendors believe SCA is needed to achieve "tru(e) platform independence." What SCA allows you to do is to compose and assemble applications written in a variety of implementation languages, hosted on a variety of platforms and insulates the business logic developer from having to have unnecessary knowledge of these implementations.
• Microsoft is not interested in application portability, so certainly aspects of SCA are not interesting to them; however, the author does seem to be unaware that SCA, albeit in its original proprietary, has been shipping in WebSphere Process Server 6.0 for some time now.
• Service Data Object is not an optional subset of SCA. SDO is orthogonal to SCA, but is rather complementary... to be honest, I just don't know what Andy was trying to articulate in his closing paragraph about SDO.

At the end of the day, I suppose its nice to see some articles coming out regarding SCA.... even if the ideas in the articles, I can't get my head around.

Integration of Google Gadgets in WebSphere Portal

Since a while, we have worked together with Google to create a generic portlet called "IBM Portlet for Google Gadgets" in order to easily and seamlessly integrate any Google Gadget into WebSphere Portal. We first mentioned and demoed this new integration capability at Lotusphere 2007, issued a press release more recently, and subsequently presented this new capability for WebSphere Portal at IBM Impact 2007.

The IBM Portlet for Google Gadgets is available for WebSphere Portal customers to download from here: http://catalog.lotus.com/portal?NavCode=1WP1001AJ

It allows portal administrators or users to easily select which Google Gadgets they want to integrate in portal pages using an AJAX-based user interface giving access to Google's gadget catalog. The selected gadget is then displayed on the page exactly like any local portlet and can be customized by end users like any local portlet, i.e. for end users, the integration of Google Gadgets in WebSphere Portal is seamless.

More information on this topic can be found here.

"My Tasks" in WAS V6.1

Here's a handy little feature in WebSphere Application Server V6.1: "My Tasks" in the console. In a nutshell, it allows you to quickly customize your console navigation to only include the navigation options that you care about. You start by selecting "My Tasks" as your view:









Assuming you've never been here before, it prompts you to add your first task. Clicking that options gives you a lit of navigation options. You can either choose an entire category (like "Applications") or a sub-category (like "Secure administration, applications, and infrastructure"):



















After clicking Apply, voila! You now have a customized navigation that only shows what you care about.

It's a Dessert Topping AND a Floor Wax

There has been some recent blogging about general confusion on whether or not SCA constitutes a new programming model or not; for instance Dave Chappell blogs here, Mike Rowley of BEA here, and Sanjay Patil of SAP here.

Of course SCA defines a new programming model, however, it also specifically defines an invocation model, a component model, and an SOA assembly model which embraces other, non-SCA programming models. Blur in the fact that the term "programming model" has specific language connotations (at least in my mind), while SCA and its cousin SDO were designed to be specifically language neutral.

What we need for building SOA applications is a contract to describe dependencies, policies and implementation with as little knowledge of or need to impact existing business logic. It needs to lift us out of the computer science goo and into building business logic that is meaningful to the business.

The fact that one can or cannot use SCA with or without another container, or as a client with any at all is less important in my mind as the importance of its design points of separation of concerns and insulating the business logic from specific protocol and data bindings which lead to fragile, inflexible applications.

Steve Kinder

IBM WSRP Producer for IBM WebSphere Application Server

Recently, I heard from my colleagues Richard Jacob and Joachim Loeffel that the IBM WSRP 1.0 Producer for IBM WebSphere Application Server they have been working on has now been published to the WebSphere Portal Catalog, enabling WAS 6.1 to make JSR 168 portlets running on it available as WSRP services.

The IBM WSRP Producer for WAS is a light weight WSRP producer which can expose JSR168 portlets deployed on IBM WebSphere Application Server Version 6.1 as WSRP services. These services can be integrated into any spec-conformant WSRP Consumer like IBM WebSphere Portal Version 6, IBM WebSphere Portal Version 5.1, as well as portal products by other vendors. The WSRP Producer for IBM WebSphere Application Server is stateless (with the exception of session data) and pushes portlet customization to the WSRP Consumer (client).

The code can be downloaded from http://catalog.lotus.com/portal?NavCode=1WP1001BA

More information on WSRP can be found at http://www.oasis-open.org/committees/wsrp/

Just for Terry

Since you are both a user experience guy... and a self-denying Microsoft watch dog... I thought you might find this video "What if Microsoft designed the Ipod?" entertaining. I did.

Certainly, we Webspherian's can learn a few lessons. Einstein is attributed to say, " Everything should be made as simple as possible, but not simpler. "


Steve Kinder

It really is Christmas Early... or is that Holiday Season?

Hot off the presses, a refresh of the latest externally available beta drop of the SOA Feature Pack for WebSphere V6.1 is available here. This feature pack leverages the Apache Tuscany open source technology from the Apache Incubator project to provide an implementation of the published Service Component Architecture (SCA) and Service Data Object (SDO) specifications implemented at by the OSOA Collaboration of vendors.
If you haven't heard of SCA and SDO, where have you been? :-) We are very interested in getting feedback on what we are doing right, but especially what we are doing wrong with these new SOA related programming and assembly model concepts.

Happy Coding...

Steve Kinder

p.s. I forgot to mention that the SOA Feature Pack installation also installs the Web Service Feature Pack, as we base our Web Service support on the new AXIS-2 runtime. If you happen to download the SOA Feature Pack, you get both feature packs.