Could you tell me the difference between website/portal and a web application?
As i understand a website is one which is deployed on webserver machine & serves request by giving response which is static web page. while a web application is also deployed on a web/application server machine & processes the request & gives response which is dynamic, one that is computed at runtime(based on user data recieved).
A website is simply an application deployed to a web server. Perhaps a Servlet/JSP application has some level of interaction with the client that makes the experience interactive.
A portal on the other hand builds heavily upon the dynamic nature of a normal website. Furthermore, a portal has built in user functions, and the ability for the user to customize their own experience.
Furthermore, portals help with content management features. Portals significantly build upon a normal Servlet/JSP website.
Enterprise development is hard. That�s why we need J2EE. J2EE provides a strong foundation upon which we can build our enterprise applications. Important services, such as database pooling and security, are implemented by those clever spuds who design the application server�enterprise architects and developers are then allowed to concentrate on the business logic needed to get their applications up and running.
Unfortunately, J2EE isn�t a panacea in itself. The developer is still burdened with a significant amount of work if they want to get their applications working properly. A J2EE application server will take care of transactions and object distribution, but it won�t help your notoriously lazy Java developers with common tasks such as internationalization or error handling; addressing these tedious tasks still falls into the domain of the developer.
Of course, we do have a variety of open source projects that help address such issues. Apache frameworks such as Struts and Cocoon further simplify J2EE development by providing a common framework that does input validation, error handling, and internationalization; however, this simply isn�t enough. Effectively managing and maintaining a vast enterprise environment is simply far too complex to be addressed by a simple combination of J2EE and open source projects. This is where the portal comes in.
Where does WebSphere Portal fit into the whole WebSphere world?
The WebSphere Portal Server is an extension to the WebSphere Application Server. The portal runs on top of the WebSphere Application Server � it does not replace it.
WebSphere Portal takes advantage of all of the fundamental J2EE services and components such as naming, security, EJBs, Servlets and JSPs. By doing so in a fabulously creative and inventive manner, the portal provides a boatload of functionality over and above what someone would expect from a basic J2EE environment.
Why is the portal so hot?
The portal is a complete environment for managing and integrating a large number diverse applications and user repositories across an enterprise wide system.
A single administrative interface makes it possible to manage users, applications, content, look, feel and navigation of an entire website. Centralized administration of a huge web based infrastructure is probably the most compelling reason for adopting the portal.
How does a portal facilitate application development?
Rather than developing Servlets, as one would do if they were putting together a typical J2EE application, a portal developer develops something called a portlet. A portlet is similar in many ways to a Servlet. A portlet handles a request and must subsequently figure out how to respond. However, the big difference between a portlet and a Servlet is the fact that a portlet is responsible for rendering only a small portion of the web page that is returned to a client. Because the page that is sent back to a client is actually a combination of the output from many portlets, along with the inclusion of skins and a theme, the response a portal sends back to a client is usually referred to as a portal page. A portlet is given a small square on the overall page that is sent back to the client. The final page that gets aggregated and sent back to the client can be made up of many different and diverse portlets, some which might be completely independent, while others might actually interact with each other. The portal provides a very pluggable environment. What is the benefit of developing portlets instead of Servlets? By only being responsible for a very small slice of real estate on the portal page, a portlet is forced to be highly focused and very specific in nature. Creating portlets is simplified by the fact that their purpose is very clear, and unlikely to be the victim of feature creep. Furthermore, with a portlet, the developer can be very focused on business logic and functionality and avoid many of the frustrations associated with generating a handsome looking page. The job of creating a handsome overall look and feel for a portal page is delegated to graphic designers and html experts who put together special portal components called skins and themes. Portal embraces an MVC framework, and abstracts the view portion out to a much higher level than typical Servlet-JSP applications do.
So you made a portal in time and started grabbing people. This tiny ad thinks that's rude: