Enterprise Integration Zone is brought to you in partnership with:

Thomas has posted 3 posts at DZone. View Full User Profile

So What Are Enterprise Portals All About?

01.20.2009
| 41203 views |
  • submit to reddit

Single Point of Entry

As we have seen, a portal framework aggregates multiple applications in a transparent way, several of those applications (if not all) will likely need a registered user to delivered a customized content.
Flexible portal frameworks will be able to adapt to any authentication method choice, while most portal will use a username and password combination, a bank will probably add a one-time-password token to it or require to have a certificate installed on the user's machine. In any case once that authentication done on the portal, the user will usually never be prompt again for the lifetime of his session even though he will transparently use several web applications during his visit.

Personalization

Personalization of the portal is a major feature of a portal framework. The portlet specification offers an API in order to adapt the content of a page based on the preferences of the user. A portlet developer could also adapt content based on the user profile or information given by the portal such as the preferred locale for the user (which could be computed from the user's browser preferences).
Some part of the portals may also be restricted to some users.

User Preferences

The portlet specification comes with an API to define user preferences, it is up to the portal framework to store those preferences. An RSS feed portlet will probably let the user define how many feeds the user want to see while the administrator will want to be able to adjust the default value for such a preference.
At the portal level, a theme engine could let the user set the theme of his choice also based on the user preferred language display content accordingly.

Sometimes a portal may also allow users to have a personal dashboard which is a place where the user can create his own pages and compose them with components of his choice.

Permissions

From the administrators point of view, they may want to restrict pages or windows to certain users or group of users, most portal framework will come with a way to restrict access wither through an API and/or GUI. It also enables to provide a personalized view depending on the user (Such as showing some customer information to a salesperson, instead of a product catalog for a customer).

Conclusion

To conclude, a portal framework exists to solve personalization, and aggregation issues so that developers don't have to reinvent the wheel. Those issues are common to all portals that want to integrate in an existing infrastructure, which have several applications to aggregate or want to provide a personalized experience to the visitor. Differences between portal frameworks comes to their ability to work in a cluster environment for fail-over and scalability, support for web frameworks but also on how they can adapt to the architect and infrastructure requirements.


Thomas Heute
JBoss Portal Lead

Published at DZone with permission of its author, Thomas Heute.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Rainer P. replied on Tue, 2009/01/20 - 6:03pm

Hello,

 in the last few years I tried to integrate portals and portlets over and over again in some intranet concepts. But it never minded customers:

If they want to use a financial software (to use your example), well they just open a new browser (tab) and click the bookmark. They are logged in automatically by using some password manager of their browser and NTLM e.g. and well that's all.
If they want to use another app, ... yes they just open a new browser tab, have the full sice of their monitor and interest before them and are auto-loggedin ...
Central rights management? No problem, there was a central AD (or any other LDAP system).
Single point of entry? Customer: "My browser and the nice bookmark menu you see here ..."
Personalization? For what? I saw many mandant systems but I've really never seen a business need for a "personalized" system (without saving preferences - which btw. is j'the job of the app itself (and not the hardest one)).

So to be true: Sounds nice, not (much) effect.
The "real" portal always was there before: Some browser windows / tabs and a simple mechanim for all intranet apps to use SSO.
No need to share lean monitor size and developer resources to integrate things which just do not need to be integrated.

IMHO portals are silly things managers buy for a lot of money (for the integration) to show "internal" success when there is no "external" ;-)

Lance Chen replied on Tue, 2009/01/20 - 8:00pm

Agree with Rainer. Portal is an information entry point only. Use RSS, Atom to publish information across system is more convenient the the "Portal framework". Portal is not a good way to integrate web application. Integrate is not to show all information in a widget (or portlet).  I don't know why manager want to purchase portal solution since almost all functions can be achieve by iFrame + cookie.

Christian Schrader replied on Tue, 2009/01/27 - 5:36am

I also have to agree with the previous posters. Actually, one of the main benefits you mentioned (personalisation) is a thing which none of the customers I met ever wanted. Even for non-portal applications, where we offer small possibilities to personalize, the customers (all financial institutions) wanted those features to be TURNED OFF! They write lots of internal documentations to make sure that their brokers know exactly what to do, if they could e.g. switch sides of the "risk vs. chance" tabs that might lead to bad results... ;) Of course, for some parts of a software it might be good to configure the screens as the individual broker likes, but that would be simple information points.

So, name me a portal where I, as a developer, before release of the software, can make sure that the arrangement of the widgets is exactly as I want and it might become interesting.

Dan Mendes replied on Sat, 2009/01/31 - 7:40pm

So how would you portal skeptical create something like a university facebook, without using some sort of portal system?

Say that you have a large organization, like a university and you want to create a web services/application mashup for each department. But each department has special needs, like: communicate using a dashboard with their students, and with other faculty members; Create assignment tasks, create content for them to see, create events, etc... However some departments use internal tools for specific task. Say one department uses the moodle LMS and others use blackboard, but there are always some features missing, so they also create a separate forum (for each department) and some department use DSpace to archive library articles, others use Fedora Repository, etc... Now your task is to unify all of these services into a manageable "web application" how would you do that, not using something like a portal, and RESTful mashup?

Simplified use case: Students can start using and contributing content to their community using that community specific components (i.e.: History Students group created a phpBB forum, a mediawiki wiki, a DSpace repository, and use Moodle - these are the application that appear in the facebook-style application menu for that particular community group; The Math Student group picked: SMF Forum, JSP Wiki (bogus reason: because it has a visual MathML editor), Fedora Repository (because it's simpler than DSpace), Blackboard (because they already used it separately and just want to migrate to the new platform without loosing 5 years of content): The Arts Student group decides to have no forum, just php Gallery with comments, and a Wiki.... as you can see there is no way to predict what combination of components each group will pick and since we don't want to force them to use any particular LMS or any other system. there may be several reasons for this. They may already have many years worth of content, or have no need for a complex solution (don't want to train their libraries to move from a DSpace to Fedora Repository, or teachers to go from Moodle to Blackboard, etc...).

The real problem is that there is no Portal software (java or otherwise) capable of offering RESTful mashup of all these components, independent of what technology is behind the components (JSP, PHP, ASP, etc...). If you are using jsp you can do this, however if you want to mix php component, they don't let you. At least i have not found one portal solution that offers this feature (ability to mash up php and jsp applications in a restful manner). Most simply create a wrapper to embed the content of the php application.

Case in point: http://www.webaps.net/liferay/web/guest/2 as you can see this is a wrapped php gallery 2, however if i wanted someone to check out this image, i would HAVE to send the following link: http://www.webaps.net/foto/main.php?g2_itemId=6948 as you can see, this sends the users to the unwrapped forum, losing all of the portal functionality. This is exactly what a RESTful portal should not do. If i want to send someone a resource, in this case a link to a picture, i need all of the portal functionality to stay intact.

For instance if i wanted to show someone a picture that is on my portal powered by php Gallary 2, i would email/send them something like this URI: http://www.webaps.net/liferay/web/guest/2/-/foto/main.php?g2_itemId=6948 and the public user would be able to see the picture integrated into my portal and if he wanted register and join the student community, contribute his portfolio for the Art Department repository.

Conceptually, what i am trying to describe is Aggregation of components using a unified graphical and functional interface. So if you look at portals as integration, and most of them are architectured like that, then i agree portals are not of much use, a simple browser tab and a cookie can do the same thin. However if you have communities and the need to cater to those communities in your organization, by providing them with aggregation of services, coupled with events, tasks, and social interaction, then portals as a concept makes allot of sense.

The closest was Liferay but they are missing the RESTful part and the ability to create php based portlets.

What i mean by RESTful mashup portal is the ability to send public resources (URIs) to users or machines (serach bots) that are viewable inside my portal, if they have interest they can then join the community and contribute stuff. If they switch departments the features available to them on the portal also change. Say that a math student, uses mediawiki to store his articles. But he decides to switch course and go for an economy course. He still uses the same portal, the same login. However his services and interface are completely different. On his dashboard: He used to have an RSS feed of math articles, now his RSS feed is all about economy. He used to have tasks sent by his math teacher and the math APs, now his dashboard has all of the tasks to be done by the Economy teacher, his application list had mediawiki, phpBB, moodle, but now it has jsp wiki, SMF, blackboard. However his friend list still keeps all of his math colegues and he can IM them using the portal (in a facebook style IM). He also still has his weather widget, google calendar widget and Battlestar Galactica widget right there where he left them the past semester.

If someone can tell me a way to do this sort of web application without using a portal system or spending two years in development to create a new platform (that will basically be some form of portal/CMS hybrid) from the ground up to be able to do this, I would really appreciate it.

Also if anyone knows of a portal system (or if you are a Portal vendor) that offers these features (RESTful mashup portal, with themes and widgets) please contact me ASAP.

Rainer P. replied on Sun, 2009/02/01 - 5:19am

Hello,

just to create it well arranged I tried to provide some very quick replies in form of "Q&A":

Q: I want to create a mashup for each department.
A: So why?
To explain it: What you say is already the execution but never the requirement. Saying "I need a portal so how could I create it without using a portal" is wrong.
Maybe you "need a mashup" because (you think) your users want to see all kind of things in one place. Aha. Do they really? I never found someone who really needed this. Some place to the find the "news": OK, but not to see your student courses, TV program, pictures of their teachers, the weather (? I never found out why someone wants to see the weather on his screen when he can look out of the window), forum entries,  all in one ... how big is your monitor? ;-)
To get news I use RSS and newsletters. It's the best way for an epoch to spread information (with a CMS in background where you can refind them later).
Do you know the Unix success secret? "One tool does one funtionaliy - but this one in a perfect way".
Combine the tools and you have your swiss army tool. And remember: a fool with a big tool ... only managers (with no clue) believe that tool no. 151 will finally save everything ...

Q: You have to create content, tasks, events, ...:
A: Use an (extendable) content managment system with good modules.

Q: You have diversity of software which must be manageable.
A: So what is "manageable": For getting a fast overview of your multiple apps and service offers, create one page with a few links on it. See http://java-source.net/
Now it is another task to make your apps "manageable" in a developers or administrators way: You have to create an architecural basis and infrastructure like LDAP for unique user management and provide technologies as common basics. E.g. provide tomcat servers with postgresql databases and create a rule "Please use JSF for maintainability reasons". Instantiate an architecture service board to provide one good software (e.g. integrated Wiki) when a department needs one.
In other words: What is the win when you just mesh all the rubbish togeher with no overall things like overall search, maintainability, rights management, look-and-feel...? Primarily the "feel" will never be the same when you mesh up all things.
Perhaps you also may want to provide some "CI" to the departments: Give them colours and header images to use. They will love it because the fewest like to create creative designs. And keep a place for the department logo in your CI ;-)
Also create rules for the feel (or same kind of user acceptance board for new software.

Q: Different software in usage everywhere; what can I do? (Your simplified case)
A: What is the "real" problem here? Different GUIs? NO!! You already said that they WANT to have their different solutions for different problems (best-of-breed) and nobody cared that the software looked in other ways, no they even like that! (You even could us the CI.)
But of course (mainatinability) you want to tidy up and use common basis infrastructure to get e.g. a common search over many modules. So the way is to tidy up and not to create now cloves for old rubbish.

Q: How do I make a restful portal over many technologies?
A: Be creative. Why not just using the databases of the different systems? Databasis are already really technology independent ant "restful" ;-)
Stop the fun. The problem is neither the portal nor the forum nor the lack of integration. The problem is that web just is not designed for such things. You like REST? Lean back for a few minutes and think about what REST is doing better than SOAP and then think about what our approach to portals is doing better hen portals ;-)

Q: How do I provide an aggregation of services?
A: Use a fitted common platform, framework, what ever you call it. but it has to be common and simply expandable to new modules ... Call it a CMS with a lot of modules (Joomla!), or call it a portal: But the way here is not th "portal" itself but the new  infrastructural basics and new APIs. If there are already many such apps around, you have to integrate them. Mostly there is no way than porting them - or leaving them as I adviced in my article above.


After all I think that if one has to create a new huge webbased infrastructure for an organisation, maybe it is a good idea to use a portal, not because the portal functionality but because it already brings many "framework" components I mentioned above with it (and so you can spare time with discussions).

So in the end our conclusion is the same ... portlets do (mostly) not help a lot.

Thomas Heute replied on Sun, 2009/02/01 - 6:00am

Rainer you are full or workarounds :) It's good to be creative.

What i find funy is how you show your hate for portlets and praise CMS components a la Joomla (Fully proprietary).

Or talk about portals make you rewrite everything (you didn't read the part about bridges did you ?)Your Joomla components suppose that everything is written in PHP against that API.

"I never found out why someone wants to see the weather on his screen when he can look out of the window), forum entries,  all in one ... how big is your monitor? ;-)" 

First, you are blaming people who want to see weather... Weather Forecast is *very* popular in many countries, some people without computers plan their day to not miss the weather forecast on TV.

It doesn't have to be in small square boxes... You made up your mind about portals long ago by going on iGoogle... What will happen is that you may have last forum entries of a forum on a page and a full page dedicated to the forum and it will all come from the *same* application. Look here you can see the "popular at Dzone", i have a 1024x768 screen and i can see this ;) Whatever you do at the end, what matters is that seperating applications doesn't *have to* mean that it is *visually* seperated.

Dan Mendes replied on Sun, 2009/02/01 - 1:27pm

reposted

Dan Mendes replied on Sun, 2009/02/01 - 1:28pm

I am actually working on a project like this, my company is building the web client, mashup technology. Other companies are handling the back-end aspects like SSO, User Managment, etc... so this is not some made up scenario.

I am seriously looking for solutions. Portals appear to be part of the solution, but what we need is for the Dreamers scenario to become a reality. The truth is: end users don't care what technology is powering their applications. It is irrelevant to the end user. They don't even care if it's all in one page or if they have to use multiple browser tabs. So it's not about the appearance, which Reiner is clearly giving to much importance.

If the client wants a dashboard you give them a dashbord. If you had the luck of never having a client/project that required you to create a dashboard, then you are a lucky. The whole concept of dashboards may not make sense to you, because you don't use them, but others do, and this client in particular has the need to aggregate multiple components into one place. So the dasboard has to be a place where you have jsp/php applications and opensocial widgets working together.

To reply to your first Q&A: The creation of a dashboard that supports aggregated information and widgets IS A requirement (what kind of widget is up to the users, i was just providing some examples. If you have a widget container you can put widgets in there, that is the point, what kind does not really matter, this is not about presentation it's about functionality: Dasboard with widget support.) So you must create a dashboard, you don't have to use any particular technology, you can do dashboards as a separate application. But if you have a portal that already has the concept of a dashboard well that simply saves time and money.

Q&A2: I really don't think you are getting the point (you are focusing to much on the details and not abstracting the process enough to see the big picture). Each department/college already uses a CMS. They just want to expose tasks/events/news to students dashboards (they want to expose CMS modules to students). A student clicks the task on his dashboard, and is taken to the CMS (using SSO, and Role Managment) that created that task for detailed information, and to sign up for the task, to submit content, assets, etc...

Q&A3: The infrastructure is already in place. Your job is to glue ti all together so that it fells like it's all the same platform. So you can't exactly say: "oh you need a wiki, use this one". If it's a new wiki you may propose that they use one of your suite/portal components, but if you are handling (so you have a set of "internal" components. But you also MUST be able to handle third party tools. If they already have a wiki with hundreds of articles, a custom theme, a template system, etc... you certainly are not going to propose that they migrate. And some can't because their is no migration path, in the set of fixed components that come with your Portal or CMS. So handling third party applications is a REQUIREMENT. (Say that someone wants to install a new word processing application, are you going to tell them, well notepad has word processing, it even can bold letters ;) Use that.?!)

SSO, rights-management, and creating a unified LnF (like on facebook) is part of the development. If you have RESTful application you can easily index resources, and have search engines easily find/index/cache resources. That is why it's important to have RESTful mashup.

They don't have to fell the same, every menu does not have to look the same, etc... again you are focusing to much on presentation. They just have to fell like a platform.

Q&A4: So how am i going to manage something if i don't know it's part of the system for that particular group of people?

Q&A5: I really don't get what you are saying here.

Q&A6: Hum... yeah, port every application. That's going to be quick and cheap... that is pretty much impossible in this scenario, and many others. Also no one should have to port anything. That is the point! Stop wasting money and time porting stuff, this is just rendered HTML, who cares what generates it?! Use bridges!!!

I have created dozens of CMS based system using Joomla, and many other Java and php based frameworks. So the challenge that i have in my hands (and that i described) is very different from what i have done in the past. It's a much more abstract project, and higher order of complexity.

Sometimes there isn't a way to Integrate!!! You MUST Aggregate, and RSS and ATOM will not be enough. You must expose modular functionality that is technology independent. That is what portals are for. unfortunately they are not very independent right now, because you can't expose modular functionality of different technologies. portlets and desklets are not technology independent.

I think the ability to do RESTful mashup applications is the only thing that will save portals in the end. If we can actually get aggregation and integration right, then there is a future for portal technology. Sadly no vendor provides a full solution, they all lack integration with php software. Or when they are able to integrate like IBM Project Zero (integration of SugarCRM), it requires that you jump a lot of hoops).

So let me put it as clear as i can make it: Your goal is to create a facebook style web application for a group of community colleges. Each college has years of legacy on their applications, like Mediawiki, Moodle, DSpace, etc... suggest that every college migrates all of their content into a new system and train people to use the new system, will get you fired. Because it's clearly a very costly process, and if you never had to train people that are not tech savvy but have dozens of years using one system and get them to move to a new system, you are seriously asking for trouble. So this is the challenge, use portals, or whatever else, but if you can come up with a solution, contact me ASAP because i have a job for you!

Don't get me wrong, if i just wanted to do integration of a fixed set of components, heck i would have it done in under a week, with Joomla! and PHP, a slick theme, a few Javascript tricks, and I would have a happy customer. If this is the kind of porject your client requires then by all means avoid portals (most companies unless they are big international or have multiple regional branches do not require portals), portals are for Very large organizations that have a dsitributed (spacial or functional) organic organization. However, other projects require a more flexible solution, and Java portals may provide part of the solution.

Bottom line: Portals are a very powerful concept, unfortunately the current implementation of portals that we have today in the java space (and any other technology) is not what people want.

What people want is the Dreamer scenario: "Dreamers see this as an off-the-shelves components that you can stick together through some kind of mashups and so on... At the end everyone agrees, portals are all about integration." I do not agree. People want integration, yes! But also powerful Aggregation, not just RSS or ATOM based. What Portal developers want is very simple to describe, very hard to implement:

1) Create a web space (implementation specific rendered HTML web page) that allows me to put(place)/mesh content/applications into sub-spaces (integrate), let users navigate their applications and create dashboards that gives them powerful concepts (example: I have a dashboard that has my opportunities by lead source dashlet (from sugarCRM php based CRM platform), my weather forecast widget from (OpenSocial widget provider) - because you have studied that when it's sunny, people tend to buy more - you have an aggregated news RSS stream (from a jsp aggregator new provider) of local news about that particular client, a google map that gives the location, an IM client that lets you chat with the client right away. The concept is that you can mash things together, and let users pick what they want to see.

2) Be able to send portal users URIs that have state information, in a RESTful way. Like send a customer an order and have him review it, change status and send it back, you can see that on your dashbord, your sales CRM widget is updated, you can see all this happen and take action (say that your Chicago sales uses sugarCRM, and your local Detroit sales guy uses Salesforce. What a portal lets you do, is to connect those two systems, and track your activities. Say that the Boston clients all canceled orders the past week... you can use your components and see that there is a news feed that says the local Chicago economy suffered greatly, so you identify that problem, create a promotion, etc... the way you work is up to you. Another salesmen may not have an RSS feed aggregator and does not identify the problem (at all or in time, he listen about it in the TV news, but by then, Smart Salesman that has a powerful portal with great components has you beat, he already sold all his cars. There are many many scenarios.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.