GB2460314A

GB2460314A - Remote dynamic portal application

Info

Publication number: GB2460314A
Application number: GB0905249A
Authority: GB
Inventors: Peter Fischer; Richard Jacob; Stephen Laertz; Andreas Nauerz
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2008-05-28
Filing date: 2009-03-27
Publication date: 2009-12-02
Anticipated expiration: 2029-03-27
Also published as: GB2460314B; GB0905249D0

Abstract

A method of operating a portal application is disclosed. In a first step a producer portal server (30) collects from an application template (38) description data describing composite applications being available at said producer portal server site using a discovery service (34). A consumer portal server (32) remote from said producer portal server requests (2) description data describing composite applications being available at said producer portal server site and issues an instantiation request (3) for a selected one of said described composite applications. The producer portal server (30) creates an application instance (4) in response to said instantiation request issued by said consumer portal server, including application components (35, 37) comprised of said template of said composite remote application. The consumer portal server (32) the creates proxy objects (33) for communicating with said components of said composite remote application wherein said proxy objects (33) include portal pages and page navigation structures. The consumer portal server (32) also creates a mapping from security roles as described in said application template (38) description to the consumer portals user security groups and roles. The final step of the method is running said remote composite application on said consumer portal server by using said proxy objects (33) for communicating with said components of said composite remote application of said portal producer server (30). The system is an implementation of a Web service remote portal (WSRP).

Description

DESCRIPTION

REMOTE DYNAMIC PORTAL APPLICATIONS

1. BACKGROUND OF THE INVENTION

1.1. FIELD OF THE INVENTION

The present invention relates to the field network computing, and in particular to the area of portal applications, and in particular to composite applications.

1.2. DESCRIPTION AND DISADVANTAGES OF PRIOR ART

In this field the term "composite application" defines an application hosted on a web portal platform which is built by combining and connecting multiple components such as portlets, wikis, document libraries and web services, for a particular purpose such as a shop or a virtual team room application. A single portal platform may host multiple instances of the same composite application, for example different team rooms for different associated user communities. Composite applications are built from a template describing the contained components and their set-up and interconnection.

Figure 1 shows the overview of the components that build up the prior art application infrastructure 11, -abbreviated herein also as Al -system architecture within an overall portal system 10. The application infrastructure comprises: -the templating application infrastructure 13 -abbreviated herein also as TAI -that handles the templates in the system and the Creation of new composite applications, -the composite application infrastructure 15 -abbreviated herein also as CAl -that handles the application instances 19 during runtime and manages connections and the data flow between the components of an application, -the component registry 27 that manages the business components installed in the system, and -the portal handler 29 which is a specific local component that manages any portal related artifacts 8 like pages or portlets for the application infrastructure in the portal, and which is used by the instantiation component 17 to create such artifacts during the creation of a new composite application.

The templating application infrastructure (TAI) component 13 manages the templates 23 in the system which contain references to instantiable components in a local list of components 27. As an example, a template for shopping applications could consist of a reference to a document library component which is used to hold the available goods and their descriptions, a shop portlet that lets clients process actual shopping transactions, an invoice business component that handles the payment process and a blogging component that allows clients to comment on their satisfaction.

The TAI component 13 also creates application instances from the templates via an instantiation component 17, which creates separate instances of the referenced business components, typically by creating or copying individual configurations for these components such that multiple application instances can be created from the same template without interfering with each other.

For the above mentioned sample template, the instantiation 17 would, among other things, create an individual storage compartment in the document library, an individual configuration of the invoice component referring to the bank account and an individual configuration for the shop portlet that is set up to display goods from the created document library and to delegate payment processing to the created invoice component instance.

In particular, the instantiation 17 needs to create the necessary portal artifacts like pages that allow to interact with the created composite application, which is typically done by employing a specific handler 29 that creates those portal artifacts 8 and links them with the business components of the application.

The created composite application instances 19 hold a context 25 that lists the component instances that make up the composite application Figure 2 shows an overview of the storage components involved in the portal architecture 10 that comprises deployment related code in a deployment component 14 and a runtime environment in one or more runtime containers 12 where the deployed components are executed.

For the composite application context deployed artifacts are: -application components stored in a component registry 18, -templates stored in a template catalog 20.

This data is then referenced by the application's instance specific data 16.

Prior art composite applications are a key concept of the prior art "Service Oriented Architecture" (SOA). They allow end-users to assemble business logic out of a set of given components without programming by simply defining some meta information, such as configuration data and application structure.

Prior art composite applications are supported for example by the prior art IBM WebSphere Portal and other known products.

With special reference now to the focus of the present invention, a typical portal provides access to user specific information, applications and processes using local and remote information sources, thus creating so-called aggregated applications. It combines the aggregated applications and provides a unified presentation layer. Most of today's portal implementations provide a component model that allows plugging components referred to as Portlets into the portal infrastructure. Portlets, as defined by the Portlet specification, are user-facing interactive web applications that render markup fragments. The content of a portlet is normally aggregated with content from other portlets to form a portal page.

In prior art, besides portlets locally executed on the Portal system another standard named WSRP (Web Services for Remote Portlets) introduced a mechanism that allows dynamic integration of portlets executed on remote portal systems so called WSRP Producers into other WSRP Consumer portals. Remote portlets also provide markup fragments that combine data and presentation logic and that can be aggregated together with local portlets to form the content of a portal page. Usually the consumer portal communicates with the WSRP remote portlets using a generic proxy portlet. Common advantages of remote portlets include aspects like integration of portlets across borders of different vendors portals independently of the technology used for the implementation and isolation of execution of alien code (portlets). Disadvantages of remote portlets are as follows: Disadvantageously, no context is shared between different remote portlets. Even though WSRP 2.0 allows sharing of rendering state information between portlets it does not allow remote portlets to share application logic, and further disadvantageously, remote portlets are unaware of the portal or the portal page they are aggregated in. Both would be in turn desirable to offer a more concise and error-redundant business logic at the consumer site.

The above mentioned Composite Applications allow the composition of applications from business components (like EJB's) with defined metadata, static content and portal artefacts such as pages and portlets used to visualize the application. That allows building of integrated applications that share information and an application context.

A composite application is defined in a template that describes the business components and the metadata needed to use these components, the portal pages that form the portal application, the portlets used to visualize the application and wire between these portlets. Furthermore the template can contain access rights and security roles understood by the application and other meta data that allows customisation of the application during the instantiation process. Composite applications are locally instantiated with its template description and all resources (portlets, EJB's etc) needed to run the application needs to be locally available to the instantiating portal system. Even though composite applications resolve some of the disadvantages of local and remote portlets by allowing to share an application context, logic and resources between components in the composite application they miss some of the advantages remote portlets have and share some of the disadvantages of local portlets such as that the execution environment is not isolated against potentially unsafe application code, and that a local instantiation of the composite application doesn't allow integration of applications running on other portal systems.

1.3. OBJECTIVES OF THE INVENTION The objective of the present invention is to provide an improved method of operating portal applications.

2. StJNNARY AND ADVANTAGES OF THE INVENTION This objective of the invention is achieved by the features stated in enclosed independent claims. Further advantageous arrangements and embodiments of the invention are set forth in the respective subclairns. Reference should now be made to the appended claims. In order to improve the understanding of the invention, the terminology of a producer and a consumer portal server as known from WSRP is used also herein.

According to the broadest aspect of the present invention, a method for operating a composite application on a portal server is disclosed, which is performed in part at a producer (also called in here "provider") portal server, and in part at a consumer portal server, and which is characterised by the steps of: a) a producer portal server collecting from an application template description data describing composite applications being available at said producer portal server site, b) a consumer portal server being located remote from said producer portal server requesting description data describing composite applications being available at said producer portal server site, and issuing an instantiation request for a selected one of said described composite applications, c) said producer portal server creating an application instance in response to said instantiation request issued by said consumer portal server, including application components (35, 37) comprised of said template of said composite remote application, and d) said consumer portal server creating proxy objects (33), communicating with said components of said composite remote application wherein said proxy objects include portal pages and page navigation structures, e) said consumer portal server creating a mapping from the security roles as described in said application template description to the consumer portals user security groups and roles, and f) running said remote composite application on said consumer portal server by using said proxy objects (33) for communicating with said components of said composite remote application of said portal producer server.

According to this basic aspect of the inventional method a producer portal server implements an inventional service which implements functionality for requesting composite applications which are available at this producer portal. Further, the portal server implements an inventional service having the functionality for performing a remote instantiation of composite applications.

At the consumer portal server side the inventional method offers functionality, for example in form of a client for requesting available remote composite applications, for example by a polling mechanism which polls through a predefined number of producer portal servers. Further, the consumer portal server implements an inventional service for creating proxy objects which implement the communication with the components of the remote composite application at the producer portal server.

The method according to the broadest aspect of the present invention provides remote dynamic portal applications that combine the functionalities of remote portlets and the functionaljties of composite portal applications. By that the inventional method provides to exploit the advantages from both

technologies, which is unknown in prior art.

Further, the inventional method allows remote portlets to share a common context at the consumer portal. A shared application context providing page awareness will allow remote portlets to generate e.g. hyperlinks to pages on the consumer portal that are also part of the application. This for example will be advantageously usable by all remote portlets of a remote application to link to a commonly used application help page.

According to a first aspect of the inventional method a remote application is provided by an application provider portal and is consumed by a consumer portal. It allows a consumer portal to dynamically instantiate and integrate composite portal applications which are executed on remote portals into the consumer portal system while keeping the application code isolated on the remote portal system. The communication between the consumer portal and the portal providing the remote portal application can for example be implemented using web services technologies for example by leveraging the extension mechanisms of the WSRP protocol.

The inventional remote dynamic portal application is a composite application that -according to its preferred embodiment -is described in an application template which in addition to the information provided by "normal" local composite portal application templates also includes information about the web services interface provided by the remote applications needed to communicate with the remote application. Similar to local composite application remote portlets are used to visualize the presentation of the application.

According to a further preferred nesting feature of the inventional method, more complex remote portal application can be built in a nested structure such that a complex application consists of one or more other remote applications.

3. BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example and is not limited by the shape of the figures of the drawings in which: Figure 1 and 2 illustrate the most basic structural components of a prior art hardware and software environment used for a

prior art method at a portal site,

Figure 3 is a schematical depiction of the main components -Provider portal and consumer portal -with the main steps of interaction when disovering and using remote composite applications according to a preferred aspect of the invention, Figures 4A and 4B illustrate the control flow of the most important steps of a preferred embodiment of the inventional method.

4. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT With general reference to the figures and with special reference now to figure 3 this figure illustrates the main components -Provider portal 30 and consumer portal 32 -with the main steps of interaction denoted 1., 2., .. to 6., when discovering and using remote composite applications according to a preferred aspect of the invention.

A provider portal server 30 is equipped according to the invention with a new remote application discovery service 34 which allows to act as producer server in the sense of WSRP. A remote application instance 36 is also provided at this producer -10 -server 30 in the course of running the inventional method.

Further, a remote application template 38 is provided also at the provider portal server 30 which includes web pages 35 and business components 37 which are used for setting up the remote composite application according to this invention.

At the consumer portal server 32 respective web pages 33 are present which are created according to the inventional method.

The usual communication interfaces are not depicted in order to improve the clarity of the drawing.

The main steps of the inventional method are as follows: Step 1 is to discover application templates.

Step 2 is to deliver these templates to a requesting consumer portal.

Step 3 is to request to instantiate an application.

Step 4 is to create an application instance.

Step 5 is to provide the application instance to the Consumer portal.

Step 6 is top use the application.

Step 7 is to destroy (i.e. to delete) the created application instances and proxy objects on the consumer portal as well as on the producer portal.

Next, reference is made to Figure 4 illustrating the control flow of the most important steps of a preferred embodiment of the inventional method.

In order to allow application consumer portals to perform the discover step the remote applications provided by other producer portals such a producer portal provides a discovery service (34 in figure 3) that allows the retrieval of all application templates provided. Then, an application is selected automatically by the Consumer portal server software or this is -11 -done manually by a respective portal administrator. Finally, the consumer portal requests for the selected composite application its templates from the Producer Portal, step 405. In a next step 410, the Producer portal sends the application templates to the Consumer portal.

Then the consumer portal decides if the needed application is found or not, see decision 415. If it is not found, step 420, the flow is finished and can be restarted with a new producer portal during a superseded search loop not indicated in figures 4A and 43.

In the Yes-case of decision 415 the consumer portal sends an instantiation request for the selected composite application including meta data which are descriptive and individual for the consumer site, step 425. These meta data information includes customization data that are understood by the remote application.

In particular, during the instantiation of a remote application the consumer portal reads the application template and creates -steps 430 and 435 -all local artefacts needed to integrate and visualize the remote composite application within the consumer portal. That includes pages and generic proxy portlets that communicate with the remote portlet provided by the remote application as well as wires to transport events between the portlets of the composite application.

Furthermore the consumer portal creates the features which are typical for a composite application, namely creating appropriate mappings between the consumer portals user group and roles and user roles known by the application and described in the application template.

-12 -Additionally the consumer portal provides the meta data understood by the application and used to customize the remote application to the requirements of the consumer portal. This meta data may include information like application title and logos displayed by the application. The portal providing the remote application also instantiates a new instance (36 in figure 3) of the provided composite application for the consumer portal based on the data received from the consumer portal.

Once the instantiation of the remote application is done and all artefacts needed to communicate with the remote portal application are created, the use of the composite application may begin, step 440, i.e., the users of the consumer portal transparently interact with the remote application in the same way they would interact with local portal applications. If required, the use can be terminated and the instance can be deleted according to prior art application instance management.

Depending on the individual use case and the level of customisation the inventional method of using a remote composite application provides that a consumer may instantiate only one instance of a remote application or an instance for each user of the consuming portal, or even more. This may be implemented by a sequence of steps 445, 450, 455: In particular, in step 445 the control logic of the inventional method or an administrator decides if a new application instance is needed f or a further user. If YES, the consumer portal requests the instantiation of a new application instance with the respective configuration data which are typical for the new user, step 450.

Then in a step 455 the producer portal creates the required application instance an returns an instance handle to the the consumer portal.

-13 -Then in a next step 460 the consumer associates this application instance with the respective user.

Then it is branched back to the No-case of decision 445, entry point 465.

Then the consumer portal's WSRP proxy portlet sends a WSRP request to the remote application producer, see step 470.

Further, the producer portal server executes the requested portlet and application logic for the application instance, step 475.

Then the consumer portal's WSRP proxy portlet receives the markup from the application portlet produced at the producer portal server and displays the markup at the consumer portal server.

After the consumer portal no longer requires a prior created application instance it deregisters the application instance at the producer portal before destroying the locally created artefacts.

The above described preferred embodiment can be varied in many aspects.

Similar to the concept of pushing the state of WSRP remote portlets to the WSRP consumer it will also be possible to push the state of the remote application including the state of the all portlets and business objects to the application consuming portal and store the application state on the consumer portal instead of storing the state on the portal that provides the remote application.

-14 -Additionally it is also possible that the producer portal provides pre-configured ready-to-use remote applications that do not require an explicit instantiation request from the consumer portal. Such pre-configured remote applications can be commonly and sharedly used by different consumer portals. Consumer portals that want to use any of these pre-configured remote portlets still need to create the local proxy objects, pages and all other artefacts needed to communicate with the remote application. Whenever a consumer portal sends a request with meta data to customize the remote application, the producer portal would implicitly create a new application instance based on the pre-configured remote application that is from now on exclusive for this consumer portal.

The invention can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements. In a preferred embodiment, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc. Furthermore, the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system.

For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.

The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid state memory, -15 -magnetic tape, a removable computer diskette, a random access memory (RAN), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk -read only memory (CD-ROM), compact disk -read/write (CD-R/W) and DVD.

A data processing system suitable for storing and/or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bus.

The memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.

Input/output or I/O devices (including but not limited to keyboards, displays, pointing devices, etc.) can be coupled to the system either directly or through intervening I/O controllers.

Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modem and Ethernet cards are just a few of the currently available types of network adapters.

References

WSRP 1.0 Specification

http; //www. oasis-open.org/committees/download.php/3343/oasis-

200304-wsrp-specification-l.0.pdf

WSRP 2.0 Specification

http://docs.oasis-open.org/wsrp/v2/wsrp-2.0-spec.pdf -16 -

JSR 168 Portlet Specification

http: //jcp.org/en/jsr/detail?id=168 WebSphere Portal Composite Applications http: //www.ibm.com/developerworks/websphere/library/techarticles /0608_stober/0609_stober html

Claims

-17 -CLAIMS1. A method for operating a composite application on a portal server, characterised by the steps of: a) a producer portal server (30) collecting from an application template (38) description data describing composite applications being available at said producer portal server site, b) a consumer portal server (32)being located remote from said producer portal server requesting description data describing composite applications being available at said producer portal server site, and issuing an instantiation request for a selected one of said described composite applications, c) said producer portal server (30) creating an application instance in response to said instantiation request issued by said consumer portal server, including application components (35, 37) comprised of said template of said composite remote application, and d) said consumer portal server (32) creating proxy objects (33), communicating with said components of said. composite remote application wherein said proxy objects (33) include portal pages and page navigation structures, e) said consumer portal server (32) creating a mapping from security roles as described in said application template (38) description to the consumer portals user security groups and roles, and f) running said remote composite application on said consumer -18 -portal server by using said proxy objects (33) for communicating with said components of said composite remote application of said producer portal server (30).
2. A method for operating a composite application on a portal server, characterised by the steps of: a) a producer portal server (30) collecting from an application template (38) description data describing composite applications being available at said producer portal server site, b) said producer portal server (30) creating an application instance (36) in response to an instantiation request issued by a consumer portal server (30), including application components (35, 37) comprised of said template (38) of said composite remote application, and c) assisting to run said remote composite application on said consumer portal server by a communication between proxy objects (33) and said components of said composite remote application of said portal producer server.
3. The method according to the preceding claim, wherein said application template (38) includes information about a web services interface provided by remote applications needed to communicate with said remote applications.
4. A method for operating a composite application on a portal server, characterised by the steps of: a) a consumer portal server (32) using a remote composite application discovery service (34) for discovering (405) from an application template (38) description data describing composite applications being available at a producer portal server (30) -19 -site, b) said consumer portal server (32) being located remote from said producer portal server (30) requesting description data describing composite applications being available at said producer portal server (32) site, and issuing (425) an instantiation request for a selected one of said described composite applications, c) in response to receiving an application instance including application components (35, 37) comprised of said template (38) of said composite remote application, said consumer portal server (32) creating (435) proxy objects (33) communicating with said components of said composite remote application, d) running (440) said remote composite application on said consumer portal server (32) by using said proxy objects (33) for communicating with said components of said composite remote application of said portal producer server (30).
5. A producer portal server (30) for operating a composite application, comprising: a) a discovery service means (34) for collecting from an application template (38) description data describing composite applications being available at said producer portal server site, b) means for creating an application instance (36) in response to an instantiation request issued by a consumer portal server (30), including application components (35, 37) comprised of said template (38) of said composite remote application, and C) a communication means communicating between proxy objects (33) and said components (35, 37) of said composite remote application of said portal producer server.

-20 -
6. A consumer portal server (32) for operating a composite application, characterised by: a) means (32) for using a remote composite application discovery service (34) for discovering (405) from an application template (38) description data describing composite applications being available at a producer portal server (30) site, b) means for requesting description data describing composite applications being available at said producer portal server (32) site, and means for issuing (425) an instantiation request for a selected one of said described composite applications, d) means for receiving an application instance including application components (35, 37) comprised of said template (38) of said composite remote application, said consumer portal server (32) creating (435) proxy objects (33) communicating with said components of said composite remote application, e) means for running (440) said remote composite application on said consumer portal server (32) by means of said proxy objects (33) for communicating with said components of said composite remote application of said portal producer server (30).
7. A computer program product for operating a composite application on a portal server, comprising a computer useable medium including a computer readable program, wherein the computer readable program includes a functional component (32) that when executed on a computer causes the computer to perform the steps of: a) a consumer portal server (32) using a remote composite application discovery service (34) for discovering (405) from an application template (38) description data describing composite applications being available at a producer portal server (30) site, -21 -b) said consumer portal server (32) being located remote from said producer portal server (30) requesting description data describing composite applications being available at said producer portal server (32) site, and issuing (425) an instantiation request for a selected one of said described composite applications, c) in response to receiving an application instance including application components (35, 37) comprised of said template (38) of said composite remote application, said consumer portal server (32) creating (435) proxy objects (33) communicating with said components of said composite remote application, d) running (440) said remote composite application on said consumer portal server (32) by using said proxy objects (33) for communicating with said components of said composite remote application of said portal producer server (30).