A web portal is a site that provides, for example, a single function via a web page or site. Web portals often function as a point of access to information on the World Wide Web. Portals present information from diverse sources in a unified way. Additionally, web portals allow, e.g., partners, employees and customers to chose their user experience, with personalized applications based on role, context, actions, location, preferences and/or team collaboration needs. The present invention uses a more narrow definition of web portal, in that it refers to Web servers that support the portlets technology.
Portlets are pluggable user interface components that are managed and displayed in a web portal. The latest portlets definition was done by the Java Specification Request (JSR) 168. Portlets produce fragments of markup code that are aggregated into a portal page. Typically, following the desktop metaphor, a portal page is displayed as a collection of non-overlapping portlet windows, where each portlet window displays a portlet. Hence a portlet (or collection of portlets) resembles a web-based application that is hosted in a portal. Some examples of portlet applications are email, weather reports, discussion forums, and news.
Portal servers are becoming more and more popular in hosted multi-tenant systems. A tenant is a subscriber to the web hosting environment and utilizes a web portal. For example, the tenant may be an enterprise which purchases information technology (IT) infrastructure, e.g., an organization. Moreover, it should be understood that the tenant is not the user of the web portal. Rather, it is the end-user (or client), e.g., a member of the organization, who utilizes the web portal. Multi-tenancy refers to the architectural principle, where, for example, a single instance of software runs on a software-as-a-service (SaaS) vendor's servers, serving multiple tenants, e.g., organizations.
With a multi-tenant architecture, a software application may be designed to virtually partition its data and configuration so that each client organization works with a customized virtual application instance or virtual portal. That is, virtual portals are logical portals that share, for example, the same hardware and software installation. A virtual portal server, for example, an IBM® WebSphere® Portal server, allows the creation and management of multiple virtual portals. (IBM and WebSphere are trademarks of International Business Machines Corporation in the United States, other countries, or both.) Other portal servers have similar functionality with different names, such as, for example, Sharepoint® portal SiteArea, and eXo. (Sharepoint is a registered trademark of Microsoft Corporation in the United States and other countries.) The virtual portals may be established by partitioning a single installation into independent, logical servers. End users are unable to distinguish whether their request is served by a full portal installation or by a virtual portal, which has been defined within the shared environment. Virtual portals simplify administration, for example, by reducing the number of parallel installations, and they help avoid the requirement for redundant hardware.
Tenants may be charged a fee for usage of the web portal server, e.g., for a portlet application. The amount of the fee may be determined with usage metering of, e.g., a portal server and/or a portlet application. However, in multi-tenant systems, for example, the same server and in some cases the same portal applications may be shared between several tenants. Within this context, the portlet application's usage continues to require usage metering information for input to the tenant's remuneration determination. Therefore, the usage metering information needs to be associated with the corresponding tenant.
There are several methods for associating usage metering data with a corresponding tenant. Some of these methods include authentication-based mapping, general HTTP or SOAP request parameter-based mapping, and application separation. However, these approaches have various disadvantages. For example, authentication-based mapping assumes access to a common authentication database. However, in many cases the authentication may be done by a third party component without access to the common authorization database. Thus, with this scenario, the third party component cannot perform the authentication-based mapping. Furthermore, the addition of HTTP or SOAP request parameters has the drawback of requiring changes in the Web Service stack or application level code changes. Additionally, application separation prevents application/middleware sharing and, thus, limits the multi-tenancy options.
USPTO Backgrounds
USPTO Backgrounds