Today's Portals "Inadequate" for Web Services?
A stunning report from web services analysts Zapthink for portal developers recently predicted that today's web-based portals will prove "wholly inadequate" for loosely coupled, distributed web applications. Read why the solution may be "rich clients," of all things. And why such an approach could save devs lots of time -- and headaches.
A stunning report from web services analysts Zapthink predicts that today's web-based portals, even those that use Java rather than Open Source technologies, will prove "wholly inadequate" to meet the needs of emerging standards-based, loosely coupled, distributed applications.
The solution, Zapthink's research says, will come from "rich clients" that will allow portal users to customize their UIs and even their workflow and application access.
Bottom Line: The key to effectively upgrading today's portal technology is to let all this user customization happen at the front end -- without requiring any server side developers to change a thing at their end, Zapthink thinks. And today's portals just aren't there yet.
The Problem with Portals
"What we've realized is that the portal as the primary interface to complex applications in the enterprise will become more and more obsolete," said Ronald Schmelzer, senior analyst with ZapThink of Waltham, Mass. told IDN. "It sounds a bit like heresy, but the web-based portal does not really make a very effective interface to functionality that resides in many systems"
Schmelzer cites a number of innovative rich client approaches that he says will hold promise for improving client interaction with portals, including Macromedia's Flash, and start-ups such as Nexaweb, with its client plug-in called Avalon. I can imagine a corporate desktop that has a graphical widget thing (Flash or Avalon based, I want my inventory stuff here and I drag in to a quandrant. Just like a regular UI, but the difference is those are web services and the other key difference is that you can take it offline.
Even good-ol' Microsoft Excel provides benefits, Schmelzer said. "Believe it or not, there is no better 'rich client' interface for web portals like Google and Amazon than using Excel because it lets me get data, sort my data and manipulate it." Aside from the desktop, Schmelzer also said the increasing adoption of sometimes-connected devices, mobile computing, asynchronous computing, and e-Forms will mandate widespread and rapid adoption of rich clients.
But, Schmelzer suggests that the definitive rich client will come with the rollout of Microsoft longhorn, now slated for 2006/7. Whatever the final ship date for Longhorn, its release will cause "the window of opportunity for new entrants in the rich client market [to] start to wane," he said.
Why Developers Need 'Rich Clients'
Zapthink lists several key reasons why portals -- and Java and Open Source portal developers -- will all benefit from deployment of rich clients on top of (or in) browsers. The key, Zapthink says, is that users can change their look-and-feel, the way they trigger events or work with business rules and data -- all without requiring major customization programs at the backend.
Here are some cases in point for you to consider.
One of the biggest benefits that a rich client should provide is the ability for end users to create and modify rich client presentation and user interface functionality without having to modify any server-side business logic. Similarly, developers of a server-side application shouldn't have to make any changes to rich client functionality to make sure that the two sides can communicate. The rich client, like the standards-based Web thin client, can be truly loosely coupled and thus enable independent innovation of the business logic and the user interface to that business logic.
Users demand the versatility and low cost of thin clients but the richness of interaction that thick clients provide. These rich clients must be able to provide windowing features and data navigation controls including buttons, check boxes, radio buttons, toggles, windows, palettes, dialogs, menus, hierarchical menus, popup menus, lists, outlines, tables, expand and collapse lists, sliders, scroll bars, progress bars, edit fields, tabs, and scrolling borders. These clients should also provide powerful rich-media component objects like animated sprites, multi-track sound, and movies that are rendered using the latest technologies.
Rich clients must also be able to integrate local and remote sources of data and business logic to provide the most productive user environment. Typical thin clients are not easily able to integrate local information, and thick clients have traditionally not been able to handle disparate, heterogeneous information in the enterprise. The rich client can take advantage of standards-based, Service-oriented (SO) approaches to integrate all the content, communications, and application interfaces it can physically access. Rich clients must provide seamless integration for all data sources, messaging technologies, and types of interaction.
Commensurate with the ability to use a wide range of protocols is the ability to provide for distributed computing interaction whether or not the client is physically connected to the network. Users require the ability to interact with applications while they are offline on occasionally connected devices such as mobile phones, laptops, and personal digital assistants (PDAs). Similarly, users want to be able to take advantage of their network connections through two-way, event-driven, and notification-based communications. Rich clients enable online, offline, and sometimes-connected modes of interaction through client-side caching mechanisms, support for asynchronous protocols, and stateful interaction with servers.