Avoiding Coupling in Your Portal Implementation
Robert Bogue
2/22/2006
Printer Friendly Version
Software development has for a long time sought to reduce the amount of coupling between various components of the system. The goal was creating systems where parts could be replaced without requiring massive amounts of rework — or simply replacing the whole system.
Portals, which are necessarily at the heart of an ever-changing array of programs and solutions within the organization are especially vulnerable to coupling. It starts out simple at first: the special notice that one application needs, and before long your portal projects are caught behind the schedule of a dozen other applications — and a dozen different projects are waiting on your portal project to be revised before they can put changes into their products
No matter how careful you are, there will be some coupling to other systems that cannot be avoided. However, taking a stand against allowing your portal to become coupled to other systems can make it easier to continue to update and revise your portal.
Coupling Defined
One definition of coupling is "to link together." In other words, one thing cannot move or change without the other thing moving or changing. This is bad for a portal that can have connections to dozens of applications within your organization. Because of the large number of connections, even a small number of them becoming coupled create a real challenge.
In portal terms, coupling occurs when actions in the portal require another system or when the portal's upgrade cycle must be tied to the upgrade cycle of an application because the interface is coupled — rather than connected. The word connected means "to become joined or united." While substantially similar to being coupled, there is a subtle difference. Connections provide a union but they are not a burden forcing the two systems to operate in lock step.
The trick with portal development is to provide the connection to reach all of the other applications without creating a coupling that will constrain the forward progress of either the portal or the other application.
Event Coupling
Coupling frequently happens to portals when there is a need to notify other applications during an event — such as the creation of a new user, or during user login. Connected implementations send off messages to the other systems in a "fire and forget" sort of way, where the process of creating the user or logging in is not dependent upon the results of the notification; the event is simply fired off during the process. This model allows for the portal to continue its business whether the systems consuming the events are available or not.
However, coupling occurs when the event firing is placed in-line with the code necessary to create the user or get the user logged into the system. This creates a coupling where, at the very least, the performance of the portal is tied to the performance of the external systems that are consuming the login events. At the worst, the coupling prevents your system from being functional anytime one of the event consuming applications is unavailable.
The net result is that your downtime is compounded by the downtime of every system that events must be executed against. Your completion time must include time to perform each of the steps necessary before returning control to the user. Depending upon the number of systems that need to know about the event and their time to respond, it's very possible to create situations where the system performs unacceptably slow.
One of the challenges with the fire and forget model is sometimes you want or need to know something from the other system. You're using the fact that the user has been established in the other system in order to get the user information you need to pass to that system. However, a slight shift in approach can free you from this reason to create coupling in the system.
Creating Handoff Points
One of the common arguments for coupling is that the portal needs to know something about the user from that other system to know where to send the user for a handoff. In other words, the portal must hand off the user to the correct spot in the other application. Because of this, a portal page contains several coupled portlets or Web parts going out and making inquiries of other systems — again slowing performance and making the portal itself coupled to the performance and availability of the other application.
The alternative to this model of relying on the other system to provide some information that will be necessary for the handoff is to create a local hand-off point that will gather the information necessary and redirect the user once the necessary information has been assembled. This local handoff point is where all of the links point to, and since no information needs to be passed to the local handoff point (since it will fetch the information itself) there's no performance hit on the portal page.
The trade-off, however, is that following the link to the other system will be slightly slower because the handoff point will be looking up information and there will be another redirect for the browser. However, handing off the user to any specific application happens rather infrequently — at least infrequently when compared to the number of times that the typical portal page is rendered. So taken as a whole, this approach decreases system load, improves overall (but not specific) performance, and keeps the connection between the application and the portal very centralized to one piece of code, which can easily be maintained.
One of the other benefits of the handoff point approach is that it wouldn't require that you setup a user in the system they are going to until the user actually tries to go to that system. Instead of being forced to create the account when the user is created or when the user logs in, you simply create them before handing them off to the other system.
User Profile
Another common sticking point with coupling is the user's profile information. With several different systems, each of which needs some parts of the user's information, it is quickly possible to create a nightmare out of storing information about the user. The basic information, such as their name and address, is relatively simple to manage, all things being equal. Those are the kinds of fields that are well known and easy to anticipate.
The challenge involves a new field that is initially necessary for one of the point applications, but eventually needs to find its way into the portal. Without a unified profile system, the users' information will need to be retrieved from the other system or synchronized with the other system. Neither approach is particularly appealing and both require some level of coupling.
Even with a centralized profile system it's easy to get caught up in the idea of creating explicit fields for every property. However, this only leads to a situation where the next application comes out and adds a new property to the profile so the code is changed and the class exposes a new property. Now every other application that uses the profile classes must suddenly be updated — not something that is very appealing to most organizations.
The alternative is to use loose binding of the variables and leverage a property cache. This technique allows for an unspecified number of properties that are referenced via a string that can quickly and easily be changed instead of a hard-coded property on the class. This loose binding is not without its own issues, however. It eliminates the hard bindings, which will make it impossible to rapidly develop your portal.
Conclusion
Coupling is insidious. It hides in every connection that the portal makes, and most portals make many connections. You must be on constant guard to prevent a connection to another system from becoming a coupling to another system. Couplings are links... and links make chains.
Printer Friendly Version
Images
[
Home | Discussion Forum | How Do I... |
Lotus Notes Intranets |
Microsoft SharePoint |
Products |
Shopping
]
