Comment lines: Portal patterns revisited

Even with the continued popularity of agile development methodologies, modeling continues to be a valuable practice in many organizations. Modeling helps you think through a complex design and visually share your approach. With client side or browser based development models in the mainstream, a new look at modeling was in order to ensure that the approach could keep up with evolving technology. This content is part of the IBM WebSphere Developer Technical Journal.

Share:

Anthony Bernal (abernal@us.ibm.com), Executive IT Specialist, IBM Business Consulting Services

Anthony (Joey) Bernal is the Chief Programmer for the IBM Intelligent Operations Center, a part of IBM's Smarter Cities initiative. He has an extensive background in the design and development of WebSphere and WebSphere Portal applications. He is a developerWorks Professional Author and the author or co-author of several books, including Web 2.0 and Social Networking for the Enterprise, Application Architecture for WebSphere, Programming Portlets, and several others. He is currently helping to build a smarter planet working on IBM’s Intelligent Cities Operations Center.


developerWorks Professional author
        level

15 December 2010

Also available in Portuguese

The beauty of modeling

Recently, I have been thinking about and building a lot of models. Many of you know me as a portal guy, but recently I have taken on a new role in the Software Group Industry Solutions development team, working on IBM’s Intelligent Cities initiative. The solution we are currently developing brings together some of the best products and solutions within IBM, and it’s our job to tie them together in a way that enables city executives and department managers to identify and coordinate activates and events across all the specific domains and departments that make up a city domain. As you can imagine, this is quite a task and the only way to wrap your head around the complexity of this type of environment is through the use of modeling.

Why do we use models? I think we use models primarily because they are quicker and cheaper than trying to build the final solution right away. With a model, you can think about the solution and evolve it without coding yourself into a corner, which can often happen in large projects. In 2002 and 2003, I wrote a series of articles on Modeling WebSphere® Portal portlets with UML. At the time, there was very little information in this area and the challenge for many people in the field was to come up with reusable patterns for portlet developers. Fortunately, we were able to leverage experience in the field to develop portal applications. This led to successful attempts to formalize our approach in a reusable way -- which has always been the goal:

  • Form a set of reusable patterns, whether using models, design patterns, or even code encapsulated within an API.
  • Learn from your experiences, don’t reinvent the wheel, and shorten your development time and effort as much as possible.

At the time they were written, those original articles on JSP technology and server side processing provided the preferred approach: Use a JSP file to generate HTML and send it down to the browser. Most all interactions were performed on the server with very little client side code, except for perhaps some simple form validation or error checking. JavaScript™ had lost much of its popularity from the '90s when the browser wars wreaked havoc on many a developer's sleep cycle.


The return of client side development

Since then, client side development has returned with a vengeance. IBM has made a substantial investment in the Dojo JavaScript library and has led the way in developing specifications for iWidget technology. Server side aggregation on the portal page enables the portal to interact with the user with very few page refreshes required. Powering much of this client side interaction are numerous REST services streaming JSON and XML down to the page on demand. When implemented well, this architectural approach can provide a seamless interactive experience for the user that is both functional as well as aesthetically pleasing.

Client side modeling approach

I have to admit this has been a struggle for me. Thinking about how to extend traditional UML diagrams to include a client side paradigm just didn’t seem natural. It could be a natural bias against JavaScript as a first class language, but actually I don’t think that's the case. I think it is just the evolution that some of us always have to go through when trying to apply a new approach to existing techniques. The idea of JavaScript being a first class development platform has long since past. Libraries such as Dojo can now fully provide robust, cross-browser functionality to rival many other approaches.

The goal is to extend the models to the browser. This is especially true for UML-type models, many of which provide (on purpose) very simplistic representations from a particular viewpoint of the system. Once I began to treat the browser as another component in the system, the models seemed to fall into place. Not surprisingly, once I was looking for the right thing, I found an article by Jim Conallen on Modeling Web Application Architectures in UML that describes the same approach.

Extending sequence diagrams

With Web 2.0 applications, sequence diagrams can be one of the most important views of the system that you can provide. Web pages that perform a lot of client side processing can be very chatty as the page reaches back to the server for some bit of information. This is a very common pattern that is used to provide a sense of instant reaction to some action performed by the user. For example, filling in a search box might result in continuously updating a part of the screen in an attempt to try and identify what the user is looking for.

Dojo applications that talk to complimentary REST services need to be modeled in some detail so that developers understand what services are necessary, or perhaps what services already exist. Figure 1 illustrates how you might model that type of behavior by extending the sequence to include interaction of the Web page to existing back end services. Traditionally, you might just return the HTML to the user based on a request, but in this case -- except for the initial load -- the Web page itself initiates many of the interactions with server side components and services.

Figure 1. Sequence with client side interaction
Figure 1. Sequence with client side interaction

For all the models, it is important to make heavy use of stereotypes to ensure that you can identify components of different technologies. In fact, the use of stereotypes is what makes UML so flexible in it’s ability to stay current as technology evolves over the years (or, in this case, decades).


Web pages as classes

In the class diagram shown in Figure 2, much of the functionality that before would be in the controller or helper classes, is now being pushed down to the Web page. In this case, you can treat the Web page as a standard class object with attributes and methods similar to those of a Java class. This type of approach meshes well with JavaScript because most of the development effort is encapsulated in functions.

Figure 2. Modeling JavaScript Libraries
Figure 2. Modeling JavaScript Libraries

With the client layer now in place within the architecture, it becomes a simple step to start to include dependencies on additional client side components. JavaScript libraries, either existing or required to be developed, can be mapped out within the design. When using a framework such as Dojo, this approach can be used to show any custom widgets that might need to be created for your application.


Conclusion

Admittedly, these examples are pretty simple, but hopefully they convey the point and provide a starting point when you think about your own modeling requirements. Not all models are UML diagrams, and sometimes visuals such as a wireframe or a Visio diagram can convey more information to the reader then UML. In this case, it can be useful to have the right visual correctly capture the page interaction. Scott Wilson provides some great mashup stencils for Visio diagrams that can add some power to those types of diagrams. Hopefully these thoughts are helpful as you begin to think about how you can model your applications and portlets that focus on client side interactions.

Enjoy!

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere, Lotus
ArticleID=600214
ArticleTitle=Comment lines: Portal patterns revisited
publish-date=12152010