Enterprise Architecture: Portal Aggregation and Integration
Prakash Malani's Blog |
May 20, 2005 1:56 PM
|
Comments (7)
Where does a portal make sense? Where does it fit? When should you use a portal? I am sure you know these answers already. In fact our marketing friends have done a pretty good job of answering these questions. Let us take a look at them from another perspective -- an enterprise architecture perspective.
Let me first describe a perfect and ideal use-case for a portal. My organization has a multitude of applications to process orders, check inventory, ship products, etc. These web-applications work great! They are functional and lots of effort (requirements, design, development, test, etc., -- the usual stuff) has been put into making them work well.
Ah! This is a perfect situation to introduce a portal. A portal to these different applications. A portal is a single gateway or door to these different applications. Critical information, in summarized form, from all the various applications is available in the single place within this portal. The portal is the default page that users get a snapshot of the status and tasks that are part of all these different applications. Whether these applications are themselves created using a portal framework, and the pros and cons of the approach, is a topic for another blog!
Let us look at a real-world and very familiar example: Google. Google has various applications such as search, email, maps, etc. This is a perfect situation to introduce a portal. That is exactly what Google has done! To tie these applications together coherently Google, has just released their portal: Personalized Google Homepage.
So, we would like to create a portal into various different applications. How do we aggregate and integrate information from all the different applications and their datasources? Well, it is not hard. We use the traditional mechanisms such as shared databases (tables, views, etc.), web-services, messaging, etc.
Additionally, there are few clever portal-specific ways to aggregate and integrate these different applications. I plan to elaborate on those in my up coming entries.
In the meantime, drop me a note and let me know what is driving your enterprise architecture portal strategy, specifically regarding aggregation and integration,
+prakash
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
Is it true that portal is a memory hog? Will it help to retain web applications ( as opposed to migrating to portal app)at times?
Posted by: srinivasjaini on May 25, 2005 at 11:02 AM
-
Portal is big and extensive. Portal has lots of features like content management, entitlements, portal presentation framework, etc. In that sense portal is a memory hog. Additionally, in order to develop with portal, you will definitely need use WebLogic Workshop (WLW), which is another big application.
The short answer to your second question is YES! In this blog entry I assumed that you already have pre-existing web-applications. But, what if we are developing a new application from scratch. Should that application be done in using the portal framework? The long answer is "it depends...". If you plan to take advantage of features and power that portal offers, then yes. With the power and flexibility comes cost and complexity. Therefore, just plain old web application (POWA) is sufficient in many cases. My advice is to take a hard-look at what portal offers when making this decision. This topic is near and dear to my heart. So, stay tuned for further blog entries where I discuss this in more detail.
The next question is how do we integrate and aggregate this new (and even preexisting) applications into an enterprise portal? Stay tuned for further entries that elaborate on this issue in detail.
In the meantime, if you have any questions, please don't hesitate to ask,
+prakash
Posted by: pmalani on May 26, 2005 at 8:07 AM
-
I like portal as it gives a lot of power for personalizing(entitlements) the content. But the biggest complaint I have is with it's speed when we compare with any typical POWA. I can understand that to minimize the user's work, portal runs a lot of framework files and backing files for each request. This is good from a developer's perspective.
But our user's want a fast application. It will be great if that portal was a bit faster. Any performance improvements in 9.0?
Thanks,
Raghu
Posted by: movvaraghu on May 31, 2005 at 4:27 PM
-
I have spent a number of years developing portals and web applications. There are times when POWA makes sense; however, too many times individuals just build silo applications and then it requires a user to know how to utilize each of these applications. It makes sense to provide one
Posted by: sherwood.zern@bea.com on June 3, 2005 at 5:53 PM
-
I have spent a number of years developing portals and web applications. There are times when POWA makes sense; however, too many times individuals just build silo applications and then it requires a user to know how to utilize each of these applications. It makes sense to provide one look-and-feel, navigation, etc.
Unfortunately, many organizations along with their developers just decide to create silo applications. They create their own infrastructure frameworks such as entitlements, cacheing, presentation frameworks, etc. These components get developed over and over again. A portal with its accompanying portlets would provide "windows" into these silo applications. The user only needs to learn one navigation, the look-and-feel is identical (if desired), a user has the ability to customize their pages and portlets, provide their own themes to specified components, and portals provide a more positive experience for the user.
The problem with portals is not necessarily with the product, but with the developers. A portal requires a good architecture, design, and developers with good OO development skills. Why you ask? Because a portal has for more moving parts and the developer needs to be aware that potentially many applications are being integrated into the application. Unfortunately, this is not taken into account. Organizations and in particular the IT organization does not take this into account. They assume they are building just another POWA. This leads to performance problems, memory problems, and overall a bad application.
As for the cost, I'm not sure this is an apples to apples comparison. How much does it cost an organization to maintain the many infrastructure frameworks that are built? If one would look at this closely they will see it is not cheap.
With the releae of 9.0 one should be able to do their Portal development work with the eclipse plugin.
Posted by: sherwood.zern@bea.com on June 3, 2005 at 6:12 PM
-
I like the example of Google for portal. How many portal server instances do you think Google might require if they go with WebLogic portal? ( well, it will typically be a cluster, but how many server instances roughly?)
Posted by: srinivasjaini on June 9, 2005 at 12:28 AM
-
Unfortunately, I don't have an exact number. But, I think it would be large based on their customer base. On the other hand, compared with current infrastructure, it would be small, because the applications probably will be continue to be hosted on the current infrastructure. In Google's case they are only adding a portal (i.e., gateway) into their applications such as search, mail, etc. From the outside, they are doing truly doing portal aggregation as explain in this blog. In other words, their cost of additional portal infrastructure is small compared with their pre-existing infrastructure.
If you are a capacity planning expert, this might be an interesting exercise:)
Best regards,
+prakash
Posted by: pmalani on June 9, 2005 at 3:31 PM
|
