After experiencing spectacular growth and acceptance in the late 1990s, portals appeared to experience a stagnant plateau. This was partly due to the dotcom bust’s fallout, which hit portal vendors particularly hard. Moreover, the economic downturn exposed the portal paradigm’s immaturity. At this time however, a new generation of portals which offer far easier integration into back-end systems and flexible interoperability is emerging.
Powered by the Organisation for the Advancement of Structured Information Standards (OASIS) (Business Process Execution Language (BPEL) and an array of new protocols such as WSRP (Web Services Remote Protocol), BPELJ (Java compatible with BPEL) and JSR-168, portals are about to have a renaissance powered by a far more fluid functionality. However, to appreciate the innovative momentum of today’s portals, one must take into account their history.
Generation 1: Point-to-point Connectivity
The portlets which populated the first generation of portals relied on crude, point-to-point connections between each application and its host portal. Rigid and inflexible, these brittle bridges between applications usually consisted of manually coded middleware, required considerable time and expense to build but only offered simplistic tools that merely routed data to its corresponding application. Since most organisations employ a large hodge-podge of commercial and in-house applications, this made portals an innovative, yet problematic concept to implement.
Consequently, whenever new applications were introduced to the portal, additional coding was required. If the application was a crucial one, developers were forced to rewrite virtually the entire portal’s middleware. This was most unfortunate as enterprise systems are an area where a high rate of innovation results in the introduction of numerous new applications or software revisions. There was a clear need for ubiquitous connectivity between applications, their host portlet, and other portals.
Manual coding’s human element required staff or subcontracted developers to create an extensive array of middleware to efficiently leverage the capabilities of a diverse set of applications. Moreover, in the implementation of hard-coded process solutions, there were invariably discrepancies between the process designed (usually by a business analyst) and the coding parameters developers faced. Hence, although second generation portal’s Business Process Management (BPM) layer was a quantum improvement over earlier point-to-point application interfaces, long, costly cycles of coding, testing, feedback, and refinement followed by further testing were still required in order to model individual process details correctly.
Fig. 1: First generation portals relied on point-to-point connectivity. Middleware was required for data translation, conversions and connectivity when different protocols or platforms were in effect. Unlike the tools found in second generation portals, middleware was usually hand-coded and often compatible only within the user’s own organisation.
Generation 2: Flexible Portals with Brittle BPM Layers
In response to these drawbacks, portal vendors created the second generation of enterprise portals: Powered by BPM, they employed an integration layer to perform translation, transform data format conversions, and connect otherwise incompatible portlets with their subsystems, which were often powered by mutually exclusive applications or platforms.
By moving away from point-to-point interaction, a portal’s component portlets used the integration layer portal to connect to a wide array of other portlets, platforms or applications without the need for customised manual coding.
Upon receiving a request for information or connectivity, the BPM layer in second generation portals transformed and routed data or requested to the application in question, before exporting to end-users through a portlet. The translation and transformation layer, actively mapped data to the appropriate back-end applications and, where necessary application adapter to enable seamless connectivity.
Although second generation portal’s BPM layer automated macro processes that spanned across a diverse multiplicity of applications, their deployment still required some fine-tuning through either manual coding individual applications or by using the proprietary tools provided by the portal supplier. Created to automate the generation of code, these tools allowed developers to focus more on designing higher level processes.
Although far less cumbersome than the long, drawn coding required by first generation portals, the proprietary solutions which managed second generation BPM layers were still restricted in the amount and types of code they could automatically generate. This in turn profoundly limited their performance, capacity to efficiently execute changes or incorporate new elements – and this at a time when enterprise systems were rapidly changing and expanding their scope of functionality.
Furthermore, in the absence of a standard BPM protocol, vendors developed their own proprietary BPM tools which were usually incompatible with those of rival portal providers. Thus, adopting the portal solution of any given vendor was always a trade-off relative to the advantages or disadvantages offered by other solution providers.
Fig. 2: A BPM layer takes the place of point-to-point connections, thereby eliminating the need to construct extensive, hand-coded middleware. Proprietary tools automate some coding but they are vendor dependent and a signifi cant amount of manual coding is still required, especially from remote sources or across different vendors or platforms.
Generation 3: Powered by BPEL
Originally designed to coordinate the interaction between web services, BPEL was created by the OASIS. Due to portal’s increasing reliance on a family of web services, leading portal suppliers including Microsoft, Oracle, IBM, Sybase and BEA are now using BPEL to design portals with interoperable BPM customisation tools.
In addition to BPEL, OASIS coordinated the design of BPEL with that of BPELJ (Business Process Execution Language for Java) and the Web Services Remote Protocol (WSRP). Collectively, this new array of standardised web services powered by Java, XML and other platforms has created the scope for designing a new, third generation of portals. These have feature platform and vendor independent BPM tools complimented by far more automated coding, freeing developers to focus more on enterprise system design.
The first versions of this new generation of portals were released in 2004 but the next two years should see considerably more innovation interoperability and BPM tools as OASIS protocols such as WSRP are expanded and extended.
Advantages of Generation 3
In practical terms, there are approximately four value-added features common to the new, emerging generation of portals. Firstly, freed from the burden of fine-tuning a portal BPM with hard coding, developers can now restructure individual business processes or just as easily re-orchestrate enterprise wide processes. Furthermore, the BPEL-compatibility of the tools accompanying new generation portals creates a cross-vendor solution that liberates developers from the lock-in and high cost of earlier BPM. Indeed, the rising ubiquity of BPEL amounts to a programmatic, standardised, and repeatable process language that enhances the capacity for developing, deploying, exporting or sharing best of breed BPM techniques. With the new generation of portals, developers can rapidly expand or collapse business process flows in response to changing enterprise demands.
For example, a large scale manufacturer’s business processes incorporates many different levels of user transactions. Elements of these transactions may include initiating an interaction, inspecting the state of process, approval of various tasks, and handling exceptions. To manage this myriad of situations, enterprises have created custom dashboards, often stand-alone applications built on a proprietary architecture that enable user interaction with business processes. With BPEL, these interfaces, applications and their host business processes can be seamlessly incorporated into an enterprise portal, offering users highly customised displays of work lists, notifications, alerts or key performance indicators.
Fig. 3: BPEL and array of other OASIS compatible web services greatly enhance portal functionality. BPEL is used to make vendor-independent, cross-platform tools to create connectivity between services and reduce manual coding to a minimum.
For example, when a manufacturer accepts orders from customers, he immediately creates an order tracking number. This mundane business process is usually a synthesis of synchronous services. Thus, using financials to look up payment terms would be a synchronous service while the subsequent submitting of a batch of orders to mainframe system would be an asynchronous activity. Third generation portal’s BPEL-based drag-and-drop paradigm allows for one-click build and deploy, enabling these processes to be easily modeled, adapted or exported.
Similarly, the creation of custom views for processes such as tracking, reporting, handling exceptions, sending notifications, and doing manual-processing steps once required manual steps. These can now be generated, accessed and executed through a combined portal and BPEL-based BPM solution.
Conclusion
Vendor’s rapid migration to BPEL as the new BPM standard will create a new, third generation of portals that will leverage the benefits of cross-vendor portal-based integration layers. In addition, emerging portal and BPM solutions provide the flexibility, interoperability, and modularity that will link multiple businesses together in a manner that creates mutual synergies. Powered by BPM, BPEL and an array of standardised web services, the emerging third generation of portals will enable business process management to more efficiently manage processes across the enterprise and, often, with external organisations.
Powering the Third Generation:
The Emerging Role of WSRP, JSR-168 and BPELJ in Enterprise Portals
WSRP leads a new array of web service standards in empowering portal functionality.
WSRP is a protocol for communication between remote portlets developed by the Organisation for the Advancement of Structured Information Standards (OASIS). Major vendors including Citrix, Oracle, Sun, Vignette, IBM, BEA, and Plumtree intend to incorporate the Web Services for Remote Portlets (WSRP) 1.0 into their upcoming portal suites. Here is a brief overview of these emerging protocols and implications for portal operability.
No Need for Vendor-specific APIs
In recent years, Web portal providers have answered the challenge of integrating disparate software services into a unified portal structure that transcends multiple operating systems, applications from different vendors and networks. Solving that challenge is a key reason for the development of the new WSRP specification.
According to OASIS:
“WSRP eliminates the need for content aggregators to choose between locally hosting a content source or writing code specific to each remote content source. Instead, WSRP allows content to be hosted in the environment most suitable for its execution while still being easily accessed by content aggregators. The standard enables content producers to maintain control over the code that formats the presentation of their content. By reducing the cost for aggregators to access their content, WSRP increases the rate at which content sources may be easily integrated into pages for end-users.”
In the case of WSRP, OASIS’s objective was to enable web service-based access capability for portal servers that are both from different vendors and separated by distance, as well as differences in hardware or software infrastructure. Previously, portals usually created new features or functionality by employing proprietary APIs or protocols that, by implication, differed from vendor to vendor. With WSRP’s standardised protocols, remotely separated portlets will be able to communicate with one another, thereby significantly extending their host portal’s core capabilities.
Furthermore, a WSRP-compliant portlet may contain fully rendered markups that can be incorporated within a portal page, with very few changes to be made by developers. This is a paradigm change over conventional portal services, where requested raw data is transmitted to a caller who then determines its usage. Hence, WSRP portals’ enhanced interoperability is complimented by the fact that they implicitly offer presentation-oriented web services.
WSRP, BPELJ, and JSR-168: A Complimentary Relationship
Both complimenting and coinciding with the release of WSRP standard, the new JSR-168 specification provides portals with a Java-based API for creating an open standards-based portlets interface. Leveraging BPELJ’s (Business Process Execution Language for Java’s) interoperability with BPEL, JSR-168 was developed at the same time as WSRP, and their respective associations cooperated to make these two standards compatible. Consequently, the augmented interoperability of this new generation of portal’s Java and XML-based elements has a synergistic effect on performance, as the portal’s versatility is enhanced by more than the sum of each protocol’s increased functionality.
WSRP’s Effect on Portal Infrastructure
Moreover, WSRP gives portals new, detailed standards for the integration of portlet services through the use of web services. Chief among these are the proprietary standards for integrating remote content. This new interface between portlets and their web services empowers developers to easily acquire portal content from a diverse variety of sources. Henceforth, hard coding the acquisition of portal content will either not require, or, at the very least, be kept to a minimum.
For example, users may select any given portlet from the list of available ones and placed it on the host portal’s page. For argument’s sake, assume this portlet obtains content from one local source and two remote ones. The local one is accessed through its JSR-168 container but remote content is ported in through the WSRP. Hence, the seamless integration of JSR-168 and WSRP functionality cooperates to create a synthesis of end-user content obtained from both local and remote sources.
WSRP’s Components
Five web service interfaces collectively make the WSRP protocol, though two of them (markup generation and interaction processing) could almost be treated as different aspects of the same general function. On neither the portlet server end nor the portal facing end users do all four of them have to be present. Below is a brief description of markup generation, interaction processing, registration, service description, portlet management and their contribution to WSRP-enabled portal’s functionality.
Service Description Interface
Before external content can be integrated into the portal’s end-user interface, the services offered by a producer must first be defined. Hence, the service description infrastructure notifies the portal’s developers and end-users about the content offered by the available portlets. In this way, service description tells us if the host portal can display a particular portlet’s markup contents, window states, modes and supported locales.
Like other WSRP infrastructure elements, the service description supports extensions consisting of an array of type objects. Needless to say, this allows both the portal and its portlet content provider to support a wide range of custom features.
At the same time it is requesting a service, the host portal has the option of providing the remote portlet server with registration credentials. However, it should be noted that a content producer could use the host portal’s disclosed credentials to modify or restrict those service list it offers in the service description.
Registration Interface
Upon registering with a remote content provider via its designated portlet, a host portal submits two sets of authentication data. Firstly, it submits registration properties required for registration as specified by the content producer's service description. Secondly, the portal provides data that describes about its modes, window states and other capabilities.
In the event registration is not supported by the content provider, then its interface will not be accessible to the portal or will only be available in an out-of-band process. However, regardless of whether registration occurs in-band or out-of-band, it will create a unique registration handle that will transmit its parameters to all other portlets that are created under it.
Portlet Management
Portlet management is an optional interface that enables the host portal to manage portlets exposed in the producer's service description – but only if the content producer uses a portlet management interface which describes those portlets that were mentioned in the service description. Provided a content provider defines his portlets in both the service description and portlet management interfaces, the host portal can then clone and customise the content provider’s portlets.
This also means that if either the host portal or remote content provider does expose all its portlets on the portlet management interface, then the type, amount and format of information provided will be restricted. In this way, both the host portal and remote content source’s capacity to import, export, duplicate and modify content can be managed.
Markup Generation & Interaction Processing
This is the interface that will be invoked the most frequently by the portal or its developers. In both markup generation and interaction processing, the host portal will send both identification and request-related details about registration data, request parameters, the host portlet state, etc. An end-user on the portal end of the transaction will usually provide standard consumer profile data including name, username, e-mail and postal addresses, age, income, etc. This is used by the content provider to personalise the content offered to the consumer at the portal end of a transaction.
Markup generation and interaction are distinguished by the fact interaction enables the portlet to update its state along with a second, revised markup generation at the end of the transaction. Hence, clicking on a portlet or interacting triggers an interaction processing and a revised, somewhat modified markup operation. On the other hand, refreshing a page merely causes each WSRP portlet to request an unmodified markup.
Another important capability is the format of the markup that is returned by these calls. The producer generally will have to encode all URLs that refer to content within the portlet so that the producer can rewrite and put them in the context of the portlet for later proxy to the producer when needed.
One of the strongest reasons for adopting the use of WSRP is that it allows portals to integrate services and content into the portal. These services and content can be exposed on just about any platform or operating system and implemented in almost any language that supports XML-based web services.
Moreover, in complex applications, there is a need for dynamic content producers. Dynamic producers offer a larger degree of flexibility and the ability to create new offerings on the fly. For example, imagine that an integration engine and application generator are exposed via WSRP, and that each newly configured integration component is then added to the service description. This provides a means for exposing any integration component directly into a portal, regardless of the integration platform, as long as it supports WSRP production.
The ability to quickly and easily add existing applications and services directly into the portal is essential for companies trying to leverage existing applications inside their enterprise portal.
What is Next?
As with the first versions of any specification, there are still a large number of features and issues that remain to be addressed. The items below are planned for inclusion in the upcoming 1.1 and 2.0 versions of WSRP. The 1.1 version is scheduled to be released by the time of this article’s publication, while version 2.0 is due to be ready in either the fourth quarter of 2005 or 2006.
Version 2.0 is expected to introduce more detailed structures and offer support for categorisation. Here is a brief summary of the leading issues that WSRP’s upcoming major release will address.
Security Issues
Security was not addressed at all in the current release, except for specifying a portlet to be marked as accepting only secure connections. Hence, at this time, individual vendors decide for themselves how to attempt to secure WSRP usage. For example, there are no conditions for passing along user tokens from an SSO system or other means of authenticating a user to the producer. OASIS intends to incorporate WS-Security along with guidelines on how it should be used within WSRP. Support for this is planned in the 2.0 version.
UDDI Support
UDDI support will allow producers to post information about their services on UDDI servers to make it easier for consumers to search for and find their offerings when the location of the server that hosts these servers is not known. Version 1.1 adds simple support of UDDI, enabling producers to describe its presence and the services it offers. This is the basically the same as data already in the service description.
Cross-portlet Communication
This ranks among the most significant enhancements that will be incorporated in version 2.0. By enabling portlets to broadcast event information to other portlets residing in producers, portlets can use shared contextual information about their interactions. They can this use this information shared in common to tailor the content that they generate or choose to export.
Conclusion
Although BPEL’s capacity to create standardised, cross-platform BPM tools and solutions is the main driver of third generation portals, WSRP, BPELJ, JSR-168 and several other protocols also play key roles. However, over the next year, it will be the upgrades and extensions to WSRP standard that will give developers and vendors the greatest scope for expanding portal functionality.
|
