Showing posts with label WSRP. Show all posts
Showing posts with label WSRP. Show all posts

Federated Portal Vs Enterprise Portal

What is a federated portal?
 A federated portal is a portal that consumes resources such as remote portlets, books, and pages. These remote resources are collected and brought together at run time to a portal application called a consumer, which presents the federated portal to end users. So in federated portal, portal application and portlets will be running in different containers where as in local portal, both will be running in a single portal container.

A federated portal reflects a true Service Oriented Architecture(SOA). These individual remote parts basically called producers of a federated portal that can be maintained, updated, and released independently without redeploying the consumer portal in which they are surfaced. Lets say your organization has depts like sales, marketing, human resources and finance. Every department has its own budget, needs and resources. Sales dept doesn't need to worry about how finance portlets will look like though both portlets will be running under a portal consumer. Instead of building all portlets into a single portal applications, you can develop portlets for each dept separately and deploy portlets as seperate web applications running on remote servers while portal consumes them using WSRP. You can have producer for each department if you want to which will be easy to maintain. Federated portal uses WSRP(Web Services for Remote Portlets (WSRP) for decoupling portlets from portal.

Enterprise or (Local) portals are the one where all portlets will be developed, maintained and deployed in a single container. So small changes to the portal, you need to perform whole life cycle - design, development, testing, deployment and propagation to development to staging to production. This may be OK for small sized portal but as the portal grows maintenance becomes very difficult. For many organizations, the cost of such maintenance is significant and can include portal downtime. Federation simplifies portal maintenance.

P.S: All WebLogic Portal applications are, by default, both consumers and producers. This means that every WebLogic Portal application is capable of hosting remote portlets and consuming them. With a federated portal architecture, separate development teams, perhaps in separate business units, operating in different geographical locations, can focus on and develop their respective portlets. These development teams can update, test, and release their portlets independently from one another. You do not need to redeploy a federated portal every time a portlet deployed in aproducer changes. When a remote portlet is updated in a producer, all of the consumers of that portlet receive the change immediately and automatically.

How to Integrate web applications into Weblogic Portal

If you are a portal developer or portal architect working at client site for providing portal solutions, you will come across these questions. How will I integrate my existing web applications into portal? Or How do I bring all web applications into single user interface? How to provide a single point of access to existing applications so user just login only once? Well, there are many ways to do that. Lets take the simple approach first.

1. Links
Links portlets are one of the quickest ways to integrate with existing applications, though providing just links is not actual integration. Trust me, we have developed many links portlets for integration as it is quick to develop and not much coding is needed. But there is some disadvantage too as we are making users to jump into another applications.

2.IFrame portlet
Believe me we have developed iframe portlets as well. This is second most common way to quickly integrate an application into a portal. By using <iframe> html tag in a portlet we can reference the application. When we do so, application will be displayed under portal with portal banner and portal navigation. But there are some downsides to it too. Timesouts can be tricky because either the Iframes or portal can timeout before the other. There could be an issue with look-and-feel as well. The iframe tag can introduce scroll bars.

3. Web clipper portlets:
This is another option for integrating any web application with portal. Web Clipping enables the clipping of an entire web page or a portion of it and reusing it as a portlet. Basic and HTML-form-based sites may be clipped. Use web clipping when you want to copy content from an existing web page and expose it in your portal application as a portlet.

4. WSRP portlets:
Another approach is using WSRP - Web Services for Remote portlets. These portlets provide both presentation and business logic which is slightly different than standard web service which provides only business logic no presentation so every client had to implement on their own. To understand better, compare with HTTP where user interacts with remote servers by using browser and doing operation like form submitting. He gets his response as HTML in the browser. WSRP is a similar protocol between server and client. In WSRP terminology, the server is called a producer. It hosts services, typically portlets, that clients, or consumers, communicate with. Consumers uses WSRP which defines a common, well defined interface that defines how a portal(consumer) should interact with producer. WSRP is built upon existing Web services standards like SOAP, WSDL, and UDD. WSRP can aggregate portlets from more than one producers into single page and can apply consumer specific look-and-feel to that page.

5. Struts portlets:
Lets say you have existing struts application up and running some where obviously outside portal and you would like to host in the portal. Weblogic portal provides struts portlets by which you can integrate with existing struts applications.