Level: Introductory Velda Bartek (bartekva@us.ibm.com), Senior User Experience Designer, IBM
Keith Purcell (kpurcell@us.ibm.com), developerWorks Architect, IBM
04 Dec 2003 Today developerWorks unveils its new look -- a series of enhancements to the design and navigation of the site based largely on input from readers like you. But it's not just our look that's changed. Under the surface, our infrastructure has changed to integrate and take advantage of WebSphere Portal. With one DNS change, developerWorks has moved from using WebSphere Application Server 4.0.6 in a single Web site model to using WebSphere Portal 4.1.4 in an aggregated Web site model. Portlets and Web services let us pull together content and applications and present that content and those applications to you through our single portal-based interface. This article summarizes how -- and why -- we did it.
Introduction
With the new developerWorks site, launched today, we've strived to address user feedback, enhance navigation, and otherwise improve the user experience. We offer our sincere thanks to the many readers who've contributed to our new look (through comments in our prototype forums, e-mail suggestions and feedback, and participation in surveys). And we thank also the dedicated team of developerWorks designers, architects, programmers, editors, usability experts, project managers, and others for the many long days, nights, and weekends they spent crafting the improved site.
We also thank our IBM colleagues at WebSphere, whose software plays a key role in the enhanced developerWorks site and underscores the breadth and depth of the redesign, which involves not only a new interface but also a new underlying foundation.
We've redesigned developerWorks to provide you with a more cohesive, unified experience navigating our rich collection of technical resources. We want to make your job easier by providing quick and easy access to information, tools, technologies, and products that matter to you. For example, the navigation remains the same throughout the site, so that you can always move to important developerWorks sections in one click from any page. To make the site easier to use, we are moving toward a consistent look and feel across the product and technology sections -- and we will be asking for even more feedback from you as we continue this effort. Furthermore, we created pages focused on newcomers to help you get started with IBM products or technologies.
We've consolidated technical solution content and access to IBM developer resources for building, testing, and evaluating your applications in one place. You'll also notice that we've recently added additional search scopes. You can now search all of developerWorks, a specific product area, a technology area, dW forums, or content available through our CD and download subscription -- from every developerWorks page. We continue to add even more product content to our search index.
The developerWorks site -- which serves millions of developers and technical practitioners each month -- now also showcases the capabilities of WebSphere Portal, using portlets and Web services running on WebSphere Portal 4.1.4. Integrating WebSphere Portal into our site lets us build dynamic pages with reusable portlets, rather than static content with hardcoded links. Content owned by our team and by other content providers can now be served by either the WebSphere Application Server or the WebSphere Portal servers, and aggregated into the portal pages of developerWorks. It's all available at your fingertips.
Advantages of the change
You, our audience, can access all technology and IBM developer content from one URL, http://www-136.ibm.com/developerworks. You'll notice as you access content that there's a consistent interaction and aggregation point. You'll also see a running e-business on demand showcase environment in which content from different sources, through many different protocols, is aggregated into a single site and single integration point -- our developerWorks portal.
The developerWorks team can now aggregate the disparate information sources that comprise the developerWorks content into a single site. By using portlets to display the information from these sources, it is easier to update the site appearance by changing the site theme and skins, and update site content, by pointing to a different back-end server or pointing to a different Web service. We are also set up for integration of Web services applications, and are consolidating our hosting environment. In deploying this environment, we are able to improve our cost-to-service ratio, and that's better business.
For the IBM WebSphere Portal development team, the developerWorks portal site represents a real-world test environment in which real users (that's you) interact with a production environment portal. developerWorks is a high-traffic, 24/7 site. This sort of testing and production validation cannot be duplicated in a development lab. We're sharing our "real-world" deployment experience with the WebSphere Portal development team to continue the improvements and function delivered in future WebSphere Portal releases.
developerWorks components before WebSphere Portal integration
Figure 1 shows the components of developerWorks before we integrated WebSphere Portal into our site.
Figure 1. Components of developerWorks before WebSphere Portal integration
On one side, readers accessed the data or content layer by making requests for information. The content, which content and application providers fed into the content and data stores, was located and retrieved through the support in the application layer.
As a reader, you are likely most familiar with our customer interface, the site itself. Until recently, the state of the art for providing you access to our content was by using several protocols (HTTP, FTP, RSS, WAP, and more) with the HTTP protocol as the main focus of distribution and publication. When you requested (by clicking on a link) an article or tutorial, the application server obtained and returned the content you wanted.
In our old model, the application layer supported content distribution for the site's technology sections, such as XML and Java, and for the product sections, such as WebSphere and DB2. The application layer also provided interactive showcase demonstrations that supported the site's content. In this layer, applications running on WebSphere Application Server provided search, meta view lists (the sortable lists of articles you see when you select the Articles link, for example), and forums. We used Java and XML extensively in this layer to make the applications work.
The content and data layer contained the meta content data (in a DB2 database) and application-specific data provided by the site's content and application providers; developerWorks staff and contributing authors, application administrators, and application programmers. These providers created and used the content stored in the databases. The front end to the content management system was the provider interface.
The new environment
We knew we wanted to integrate portal technology into the developerWorks infrastructure. But we didn't want to completely redesign that infrastructure (nor did we have the resources or time a from-scratch solution would have required). Our goals were:
- Maintaining the existing process and procedures of the content and application providers.
- Reusing the elements of the existing infrastructure.
- Aggregating all content in a single place.
These goals support integration, which is a key attribute of an on demand environment. WebSphere Portal simplifies integration by supporting Web services. WebSphere Portal also lets legacy systems and applications continue to interact dynamically with each other without having to be re-engineered or rewritten.
The developerWorks team rethought the process by which the site content is accessed and aggregated, then implemented the change through technology. With one DNS change, developerWorks moved from using Application Server 4.0.6 in a single Web site model to using WebSphere Portal 4.1.4 in an aggregated Web site model. You can continue to go to the site and read articles, download samples, and chat with other developers on the forums. Content providers and application providers continue to post information into the databases as they did before the change to WebSphere Portal.
Benefits
So what's new? Let's look at the benefits of the change, starting with Figure 2 below.
Figure 2. Components of the new e-business on demand developerWorks
Now, portlets point to the content, which still resides in the same databases as in the past. The existing infrastructure continues without change. New capability, such as a portlet that shows recently updated forums without you requesting an update to see the latest information, can be deployed. With WebSphere Portal, we can aggregate (or consolidate) content that exists on other portal servers and present it within a developerWorks page.
Fragmentation between the application layer and the content and data layer has been removed. Hosts are consolidated. Applications and components of the applications reside in either a WebSphere Portal cluster or a WebSphere Application Server cluster. The location of the components is dependent on performance requirements, such as the type of resources needed and the time required to complete tasks.
On the new developerWorks site, visual and customer interface components of the application such as portlets and JSP files are now contained in a WebSphere Portal cluster. Applications pull data from different locations and feed the visual and customer interface component. Distributing the components of the site across the different layers lets us optimize performance to the customer interface.
Components such as static HTML pages and library views continue to reside on the WebSphere Application Server cluster and are aggregated by the WebSphere Portal cluster and presented to readers through the customer interface component.
Web services client applications reside in either type of cluster, depending on performance requirements. The Application Server clusters provide input to cache on the portal clusters or real-time feeds, depending on the Web services client application requirements. Other channeling interfaces, such as RSS and FTP, are also provided in this layer to avoid performance degradation from the customer interface.
Following the e-business on demand roadmap
Before moving to this new environment, developerWorks team members looked hard at the way we were doing business. We studied how each of IBM's developer sites presented content, and where the sites (and the infrastructure behind those sites) were located. We decided to focus on how to pull together, or aggregate, the content from each of these sites into one place (the reader layer) because we wanted to present a unified site to our readers with minimal impact to our existing procedures and infrastructure and to those of each of the developer sites. We identified common application requirements, such as the search function. We found that the infrastructure of the existing sites could continue without change. The new portlets, grouped on portal pages, would link to these existing sites.
Team members reviewed and identified the data sources that would be used within the new environment, which consists of:
- WebSphere Portal portlets with intense processes shared by means of Web services (RPWS).
- Application Server front ends for the on demand processes of Java Database Connectivity (JDBC) and Web service connectivity.
- Data source services performed by Web services and JDBC.
Our architects designed the site so that data sources for access, such as Web services interfaces, Web services gateways, and JDBC data sources, reside on the application layer. We identified e-business on demand services for designated application interfaces and the content and data layers. We implemented resources from which the reader interface could now be aggregated.
This brings us to the e-business on demand showcase environment that you see today, which was accomplished by setting up the architecture for communications between applications, data sources, and the customer interface layer. Data from the identification and categorization processes along the way has led us to use our services more effectively.
Finishing the roadmap
The combination of the application layer and the content and data layer is still evolving to better provide readers with the right content at the right time in the right place.
We need to continue looking at our processes so that we can apply (and reap the benefits of) new technologies. We also need to adapt the technology infrastructure so that it is fully equipped to support future changes. For example, with WebSphere Portal managing the aggregation of content on the site, we can switch out the back-end hosting environment. Data and applications could be stored in a grid environment, with Web services providing an entry when you request information.
We also continue to look for ways to better the cost-to-service ratios for our hosting environment. We look to use e-business on demand services for future applications and data sources when the costs of such enhancements to the site would be achieved for less than our current environment models.
Appendix: Including developerWorks highlights in your portal
If you want to include developerWorks highlights on your portal site, our RDF Site Summary (RSS) formatted files contain data feed information on the latest developerWorks content that you can use. The various developerWorks RSS files contain the titles, abstracts, and links to recent content published on our site. Our RSS files are at the RSS 0.91 level.
Here's where to find the developerWorks RSS files:
WebSphere Portal provides a sample news aggregator portlet, RSS Portlet, to be used with RSS formatted files. You can download a copy of this generic portlet to integrate the developerWorks RSS information in your portal rather than write your own portlet. You can download the RSS Portlet from the
WebSphere Portal Catalog and download.
To use the RSS Portlet to host our RSS content on your portal, you need to update the predefined URLs in the portlet to the URLs that point to the developerWorks RSS files. To do this, modify the parameters of the RSS Portlet using the Manage Portlet capability of portal administration.
Resources
About the authors  | | |
Velda Bartek is a human computer interaction specialist for IBM. She works with customers and product designers developing WebSphere products to ensure the products are easy to use. You can contact Velda at bartekva@us.ibm.com.
|
| | |
Keith Purcell is the developerWorks Software Architect. He holds U.S. patents in various technologies from JDBC to grid. You can contact Keith at kpurcell@us.ibm.com. |
Rate this page
| 
