MetroSphere is an online technical community and information marketplace built with WebSphere Portal. When it's complete, MetroSphere will allow consultants, programmers, and technical writers to gather and share information, tips, and techniques, while at the same time providing a customized portal to information of their choice. MetroSphere will be a place where individuals and companies sell and barter technical content and services, as well as enable better collaboration and workflow on new and existing projects. In this series of articles, tutorials, and tips from Studio B, we share our experiences as we build the MetroSphere portal.
I never thought much about patterns in software development until about mid-way through my career as an instructor, when I noticed that no matter what programming language I was teaching, students always asked how to build the same types of functionality. And why shouldn't they? While there are certainly innovations that are wildly different from anything that have come before, they're few and far between; most of us are writing applications to solve problems that someone somewhere has already solved. That's not to say, of course, that you could just take their program and use it, even if they'd let you. Every situation carries unique, specific requirements, and individual environments vary. But wouldn't it be nice if you could use the pent-up wisdom of all of that previous development?
In many ways, that's the idea behind the IBM Patterns for e-business initiative.You may be familiar with Design patterns, which take a particular software development situation and explain the best way to solve it. Patterns for e-business takes this idea one step further, opening up to the business issues that ultimately influence those software designs. A system architect can take the problem at hand, determine the Business pattern (or patterns) that applies, and then look at the Application patterns that can be used to implement a solution. In some situations, Application patterns are further broken down into Runtime patterns, which apply to specific products and architectures and can even provide sample code.
Of course, we already know that we're building the MetroSphere Web site on WebSphere Portal, so why should we even worry about these patterns? Simple. I hate reinventing the wheel. If somebody's already thought about what I'm doing, what does it hurt for me to see what conclusions they ultimately came to? What's a couple of hours reading about patterns compared to days of flailing uselessly?
As it turned out, the time was well spent. While we already had a good idea of how we wanted to build the site, the patterns pointed out alternative architectures we hadn't considered and showed how we might later integrate other functionality so we could keep it in the back of our heads while we built Phase 1. It also helped to validate some of the architectural choices we had already made.
To start the process, we looked at the basic Business patterns.
As discussed in Part 2 of this series, the heart of any Web site is the business issue it is supposed to solve, so it made sense to look at different Business patterns that frequently emerge in the building of a Web site. Currently, the Patterns for e-business site documents four different Business patterns:
Self-Service: The Self-Service pattern is perhaps the most general, consisting of any situation in which a user needs to interact with enterprise data. For example, any site that enables you to see your account information, make a request, or even look something up uses this pattern. It's also known as the User-to-Business (U2B) pattern.
Collaboration: The Collaboration pattern describes situations in which groups of users have to interact with each other, usually (but not necessarily) to achieve a common goal. For example, instant messaging, newsgroups, and e-mail discussion lists fall into this category. It's also known as the User-to-User (U2U) pattern.
Information Aggregation: Information Aggregation involves gathering information from different sources, such as multiple databases, and making it available to users. For example, sites such as Blogdex, which gathers statistics for different weblogs, or News Is Free, which gathers RSS feeds from thousands of sites, use this pattern (for more on these sites, see Resources). It's also known as the User-to-Data (U2D) pattern.
Extended Enterprise: The Extended Enterprise pattern isn't normally seen on the public Web because it concerns situations in which one company's systems must interface with another company's systems. For example, a company that interfaces with supplies to implement Just-In-Time delivery would use this pattern. It's also known as the Business-to-Business (B2B) pattern.
For now, we know that MetroSphere will be concentrating on collaboration between users, so the Collaboration pattern is probably going to be a good fit. Ultimately, though, we know that at the very least, we'll probably be using Information Aggregation as well, and possibly Self-Service and even Extended Enterprise. Fortunately, we're not limited to a single pattern; they're used together. In fact, they're so frequently combined that certain common integration points often emerge, and, in fact, two Integration patterns have been documented.
The Patterns for e-business site (see Resources) currently documents two main integration patterns, dealing with the front-end of the application and the back-end of the application:
Access Integration: The Access Integration pattern covers situations in which users are coming in using different devices, such as browsers vs. mobile phones, but it also covers situations in which information from different applications has to be presented using a single user interface. For example, Yahoo! provides information from its search engine along with news and other information on its home page, but it's visually consistent. It's also available in alternate forms for alternate devices.
Application Integration: Application Integration is one step beyond Access Integration in terms of complexity. While Access Integration covers a situation in which information is returned to a user from different sources, Application Integration looks at situations in which information from different sources is combined to create a new source. For example, Mockerybird takes the list of books cited by onfocus.com's Book Watch and searches for information on the book using Amazon's Web services, then links it up to news items and Web sites using the Google API (for more on these sites, see Resources). On a more enterprise-related level, a Customer Relationship Management tool that pulls information from several databases uses this pattern.
I'd come to the Integration patterns section of the Patterns for e-business site (see Resources) looking for a solution similar to the Application Integration pattern, even though we're unlikely to need it during Phase 1 of the MetroSphere project. The Access Integration pattern, however, looks useful right now; we do need to accommodate different types of devices and to keep various functionalities looking more-or-less the same.
It certainly bears further investigation, just as the Collaboration pattern does. But before we get to that point, we had to answer one question: could we use these two patterns together without increasing complexity?
As it turns out, certain patterns are combined so frequently that the combination itself becomes a pattern. The Patterns for e-business site documents four such combinations, or Composite patterns:
Electronic Commerce: This is actually a pretty broad category, covering situations as simple as a user who logs into a system (using Self-Service) to get information (Information Aggregation) from a particular application (Application Integration) to a system that enables a company to integrate its systems with business partners using the Extended Enterprise pattern. Other patterns can also be added to the mix, if necessary.
e-marketplace: An e-marketplace system is specifically designed to make it possible for multiple trading partners to interact in order to buy and sell goods and/or services.
Portals: Portals typically provide access to information gathered through Information Aggregation, but officially, the Portals composite pattern consists of the Access Integration pattern plus one other Business pattern. For example, in the case of MetroSphere, a portal would consist of Access Integration and Collaboration.
Account Access: A system that falls under the Account Access composite pattern is one that enables a user to access an account and gather information or make changes. This access could be personal, such as a user who checks bank or stock portfolio information, or it could be indirect, such as access through a customer service representative.
Looking at the extended view, we know that MetroSphere will make use of at least three of these patterns. In addition to the Portals pattern, future plans for users to sell and buy content will require the e-marketplace pattern, and users will want to control their own account information using the Account Access pattern.
For now, though, we know that we'll need to concentrate on implementing the Portals composite pattern.
The Portals composite pattern, as shown in Figure 1 from the IBM Patterns for e-business site, makes it clear that in order to combine different Business patterns, you must implement the Access Integration pattern. This makes sense, considering that when users are presented with different types of information, it's necessary to provide consistent presentation in order to prevent confusion.
Figure 1. The Portals pattern
Looking at this pattern, it's reassuring to realize that we should have no trouble later integrating the other Business patterns into our plans using the Portals composite pattern.
Now that we had the lay of the land, we were ready to look at the specifics of the two patterns we'll be implementing.
The Collaboration business pattern
The Collaboration business pattern should be a familiar one at heart. It encompasses applications such as email, discussion groups, and instant messaging -- any situation in which one user needs to share information with another, for any reason. Of course, that's a pretty broad range of situations, so there are actually four different Application patterns related to the Collaboration business pattern:
Point-to-Point (a.k.a U2U Topology 1)
The Point-to-Point application pattern centers on a synchronous peer-to-peer architecture. There is no centralized server, so each user must know the IP address of anyone he or she wants to talk to. The other person must also be present and logged in at the time. One example of this method would be the use of Microsoft NetMeeting. It's only feasible in situations where the number of users is fairly small, and their network locations fairly static. Some commercial tools are available, but in many situations solutions are coded from scratch, which can be a problem because it requires knowledge of low-level networking protocols. There can also be great difficulty scaling up the number of users, though it's interesting to note that the file sharing system Gnutella falls into this category. It also has the limitation of requiring both users in a conversation to be present and logged in at the same time.
Store and Retrieve (a.k.a U2U Topology 2)
Much simpler than the Point-to-Point solution, Store and Retrieve involves a situation in which the user sends the information to a centralized server, and the recipient logs into the server to pick it up. It's important to note that in addition to the obvious case of discussion groups, this pattern also applies to email and to Internet Relay Chat (IRC) clients. The advantages of this pattern include wide availability of commercial software, in many cases -- though not in ours -- eliminating the need to write custom code, and the fact that the IP address of the receiver does not have to be known. The receiver is also freed from the need to be online at the same time as the sender. This method also enables one-to-many or many-to-many communication, but has a major limitation when it comes to time. While Point-to-Point is synchronous, Store and Retrieve can be asynchronous, and thus may not be a good solution for situations in which the sender needs immediate action.
Directed Collaboration (a.k.a U2U Topology 3)
The Directed Collaboration pattern, in many ways, borrows the best of the Point-to-Point and the Store and Retrieve patterns. Users can communicate directly, but this pattern requires a central server that all users must log into, so the sender of a message doesn't have to know the IP address of the receiver. (Usually, however, the sender has a list of potential receivers stored in the client. By contacting the server, the client can then determine the current IP address of those receivers.) One widely recognized example of this pattern would be instant messaging. The basic limitation of this pattern is the need to provide the central server. Also, both parties in a communication must be online at the same time.
Managed Collaboration (a.k.a U2U Topology 4)
This pattern is basically a more complex version of Directed Collaboration. Rather than simply collaborating with each other, users in this solution go through some sort of workflow system. For example, a call center might direct the user to a specific customer service representative based on information provided before and during the conversation.
Our early plans fall pretty clearly within the Store and Retrieve pattern, but looking at this list does two things for us. First, it points out that the Store and Retrieve pattern can be implemented in a number of different ways. For example, we've been so focused on using a discussion group-type system, we hadn't given much thought to adding e-mail or other methods to the system. Second, we are getting an idea of other potential ways for users to collaborate with each other, which we'll keep in mind for future phases of the MetroSphere project.
Now, in an ideal situation, we would follow the next step and look at Runtime patterns, or sample applications that we could use in our own environment. Unfortunately, at the moment, the Collaboration pattern is only documented to the Application patterns level, so we're on our own. It's hardly a catastrophe, though; we'd been planning to build this part of the system from scratch anyway, and at least we've gotten some ideas about the benefits and limitations of this strategy.
The Access Integration pattern
Access Integration actually applies to two different situations. First, it encompasses a situation in which users must access information from different devices, such as browsers, mobile phones, and PDAs. Second, it deals with a situation in which a single site must give a user access to many different types of information, typically from different applications. The purpose of Access Integration is to provide a single, unified, adaptable presentation to the user. You can perform this task through several different Application patterns:
This pattern adds a new tier to the application itself, as shown in Figure 2. The Pervasive Device Access Tier includes information about potential clients and style sheets that enable it to take the HTML provided by the application and transcode it into the appropriate markup.
Figure 2. Caption for sample figure
Fortunately, WebSphere Portal has a built-in Transcoding Server, so we won't have to build this tier ourselves.
Single Sign-On creates a system in which the user simply logs into the overall system, and if any of the underlying applications need authentication information, the new Single Sign-On tier provides it. This pattern actually comes in two different varieties. Figure 3 shows the simpler version, in which applications simply accept the authentication information and move on.
Figure 3. Single Sign-On
In some cases, however, an application can't be so easily integrated, either because it's a legacy application that requires different authentication, or because of a high-security or non-refutation requirement. In this case, the architecture may look more like Figure 4.
Figure 4. Extended Single Sign-On
Personalized Delivery takes information about the user and uses it to determine the information that will be shown to the user. In MetroSphere, we'll be using several types of profiling and personalization. We'll explicitly ask users what topics they're interested in, but we'll also compare the items that they view with the items that others view in order to make inferences about their preferences and provide appropriate material. WebSphere Portal provides a personalization engine that will enable us to create rules that govern these interactions, as well as provide the pattern recognition necessary for implicit personalization. In addition, we'll be creating some personalization from scratch within our portlet applications.
In the MetroSphere project, we're actually going to need all of these patterns, in one way or another. Access Integration is also documented to the Runtime patterns level, providing examples of how to implement these patterns in various environments. But we're fortunate to find that much of this functionality is, as I said, built right into WebSphere Portal.
Even though we didn't get any sample code from the Patterns for e-business, we still got a lot out of the process. First, it forced us to define exactly what it was we wanted to accomplish. Second, it provided us with the wisdom of others who had gone before us, listing benefits and limitations of each approach. Third, it provided us with ideas we hadn't necessarily considered that we can use as we go forward. We also discovered that much of the functionality we're going to need is already included in WebSphere Portal.
Our work centered on three patterns: Collaboration, Access Integration, and Portals. We'll keep track of developments in these and other patterns as time goes on by subscribing to the Patterns for e-business mailing list.
The next article in this series, written by the project system administrator, Tom Syroid, will discuss the process of setting up and properly securing a WebSphere Portal - Express server.
- Stay up-to-date with the MetroSphere Project by visiting the overview page.
- Take this tutorial from the MetroSphere team to learn how to install WebSphere Portal - Express.
- Download and try the latest version of WebSphere Application Developer.
- For more integration solutions, visit the Integration patterns section of the Patterns for e-business Web site.
- See the different Business patterns to decide which best fits your project.
- For more resources on integration and e-business solutions, visit the IBM developerWorks On demand site.
- Read about the Collaboration, Access Integration, and Portals patterns.
- For a look at the entire Patterns for e-business landscape, read about the IBM Patterns for e-business Initiative or pick up Patterns for e-business: A Strategy for Reuse (MC Press, 2002).
- Read about Pervasive Computing and the Patterns for e-business, by Leo Marland (January, 2001).
- Read John Lord's whitepaper, "Facilitating the application development process using the IBM Patterns for e-business" (IBM, August 2001).
- Read the Bloor report, Patterns of Experience: A Review of IBM's Patterns for e-business Initiative (June 2001).
- Sign up for the Portals for e-Business mailing list to keep track of changes and additions to the pattern.
- Visit the WebSphere Portal Server product site, which includes the InfoCenter.
About the author: Nicholas Chase, a Studio B author, has been involved in Web site development for companies such as Lucent Technologies, Sun Microsystems, Oracle, and the Tampa Bay Buccaneers. Nick has been a high school physics teacher, a low-level radioactive waste facility manager, an online science fiction magazine editor, a multimedia engineer, and an Oracle instructor. More recently, he was the Chief Technology Officer of Site Dynamics Interactive Communications in Clearwater, Florida, and is the author of four books on Web development, including XML Primer Plus (Sams).
Comments (Undergoing maintenance)
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags