Browse Prior Art Database

On the glass collaboration framework for disparate web applications from diverse technology stacks Disclosure Number: IPCOM000221134D
Publication Date: 2012-Aug-30
Document File: 2 page(s) / 27K

Publishing Venue

The Prior Art Database


Enterprise IT infrastructure is in a continuous state of evolution. Today there exist varied and heterogenous frameworks, technology stacks, specifications etc. to develop web applications namely - J2EE, Microsoft .NET, PHP, JSR 168, JSR 286 etc. Each web application is constructed using a set of the technologies and specifications; and may be different from another web application constructed using another completely different set. This is certainly true for legacy applications and applications conforming to different types of server infrastructure. The challenge every time is how to minimize disruption, downtime and cost of adding the new capability. In a scenario where existing infrastructure is built from totally heterogenous stacks this leads to either a rip and replace kind of a strategy, or adjusting with limited capability since there is no existing mechanism which is powerful enough to not just reuse capability within the existing infrastructure, but even enhance the existing capability according to the new framework being built without modifying the existing. In all the mechanisms that currently exist, it is needed to modify the existing applications in a large way or rewrite them to enable them to 'talk to each other' or collaborate by making provisions for passing events. However, at the top level of the technology stack viz HTML as rendered in a browser, these applications follow same specifications, and should be the focus of integration patterns and frameworks. Every web application works in its own silo and functions according to its base requirements, inherently unadaptive to any new functionality that can be added without application downtime and unaware of the other contexts to which it can contribute. This proposal presents how to make this possible without modifying deployment, implementation or configuration of the existing web applications irrespective of whichever technology standard or development framework etc. they may be based on. In the case of Portals where Inter Portlet Communication plays a huge part in providing power to web applications, the current proposal is not only feasible to reuse the existing web application infrastructure as is but it is also possible to make the existing web applications talk to each other using the Inter Portlet Communication method.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 01 of 2

On the glass collaboration framework for disparate web applications from diverse technology stacks

The web applications can be enclosed inside respective portlets and the portal page provides the context to these disparate applications that have been surfaced as iframes by the portlets. This proposal provides a declarative mechanism that enables an administrator to enable an existing web application to emit events without any code change or a need to interface with a set of APIs within the application. Now all kinds (independent of implementation technology choice) of web applications can listen to client-side events inside a portlet and pass on these to another portlet which reacts but using its own event handling and data transformation routines.

So by the implementation of this concept, for example a Microsoft .NET application can send events and messages and respond to events and messages from a J2EE web application, through the Portal on the client side as well as using server side eventing of Portal.

What this does is that it allows the two web applications irrespective of the development framework used for building, type of or technology of web server or host where they are running or other specifications render inside an iframe each. By applying context defining semantics to identified markup fragments applications can be enriched to participate in user context as event sources and targets. The new component could be implemented for example through a proxy that is running which masks the details of the web applications being rendered within the iframe.

Since the web applications have a number of markup sections (e.g. widgets or controls), a mechanism is created where in the Source (or the Producer) Portlet, the administrator can for example define the control or the widget (as a specification of the said markup segment) and the specific action of the control which is trapped in order to trigger the eventing mechanism. The Target (or the Subscriber) portlet listens to th...