|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 14
Messages: 14
Messages: 14
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
JSR168 support with WSRP- good or bad?
As Portlets are coming to their full swing, people around big web-applications are discussing about porting to Portlet technology. I was recently working analysing the efforts required to port an existing web-application to a propritery portal server. Such issues are appearing in greater numbers now. One of the alternative is to rebuilt the whole applications from scratch (reusing some components if possible, which ruled out if the backend is not in Java). But one approach could be to use WSRP support to use the existing applications in portal and add over it what ever new functionality we need as portal application.
As I am not much into WSRP, I am not sure how far this idea is implementable. Secondly, Peoplesoft Portal 8.9 and Oracle Portal supports JSR168 specifications but through WSRP. Is this the right way to do so? Won't it have an affect in efficiency of the portal application? Is it not better to provide the JSR168 support as a part of developement environment (without using WSRP) as is done in IBM, BEA and open sources like eXo, Liferay etc?
Vikramark
http://www.portlets-jsr168.blogspot.com
|
|
|
Message #201113
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Easier for the enterprise
WSRP portlets tend to be much easier for an enterprise portal. You get mired in deployment issues with JSR168 portlets when you have hundreds of portlets and thousands of pages.
WSRP lets you move the development and integration issues closer to the business units involved. It also lets you share the burden of hosting and processing.
The primary purpose of a portal is to integrate.
|
|
|
Message #201121
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Apps should not be ported to a portal
I can't imagine why someone would want to port a complete web application to a portal unless it was a small application. It just doesn't seem to make sense to have to live within the confines/limitations of a portal container for a web application of any significant size. Plus, you can't deploy large applications in to a portal (if you're talking JSR-168) -- portal admins aren't going to like deploying an app that needs a lot of memory when they might have a 100+ portlet apps loaded on a decent sized portal server deployment. And even more important, that app will only run in a portal in this case. And if you try to make it both a portlet based app and a regular app then you're going to have sacrifice somewhere.
My personal preference would be to build portlets that can access certain kinds of data within your application that make sense to display in the portal -- and then if you need to go to the full web application have it take you to that web application.
This is where WSRP could come in and addresses your question somewhat. It'd be great if you could generate WSRP from a web application to show certain pages of workflows in your application within a portal. Then you can pull those exposed portlets into your portal via WSRP. Best of all, when you upgrade your web app you don't have to deploy new portlets (assuming you haven't changed your WSRP exposed services list). I'm unaware of any decent open source tools, however, that make this feasible. But I really haven't looked for these kinds of tools lately so that landscape might have changed.
And yes, WSRP will affect efficiency in one way and help in another (the portal won't be overloaded with bloated portlets). But then again, when are portals efficient when you're pulling data from so many different sources?
-Mike
|
|
|
Message #201126
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Apps should not be ported to a portal
I think you are right on, and this is why Oracle has chosen to go the WSRP route. They're all about "Enterprise Portals," i.e. portals bringing together data from large apps. Oracle sells lots of large apps, but they don't sell hardware. Thus they aren't going to advocate putting all these large apps in the same container -- enter WSRP.
That being said, I do think that a lot of your large app functionality can be exposed efficiently through a WSRP portal. I think the key is using a REST architecture for your portlet web services.
|
|
|
Message #201129
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Apps should not be ported to a portal
Mike,
I can't imagine why someone would want to port a complete web application to a portal ..
You don't / shouldn't. (At least from what I've seen to date.) But you _can_ expose pieces of applications in a portal, which is what integration is all about.
It just doesn't seem to make sense to have to live within the confines/limitations of a portal container for a web application of any significant size.
That sounds more like a problem with the container spec ;-)
[..] portal admins aren't going to like deploying an app that needs a lot of memory when they might have a 100+ portlet apps loaded on a decent sized portal server deployment.
That's why WSRP exists. I've already witnessed this exact thing. See:
http://dev2dev.bea.com/pub/a/2005/11/federated-portal-cache.html
That's from a bank that has lots of different applications that each deploy their portlets separately (different versions, different server clusters, etc.) and they tie them together via WSRP.
My personal preference would be to build portlets that can access certain kinds of data within your application that make sense to display in the portal -- and then if you need to go to the full web application have it take you to that web application. This is where WSRP could come in and addresses your question somewhat.
That's exactly right.
It'd be great if you could generate WSRP from a web application to show certain pages of workflows in your application within a portal. Then you can pull those exposed portlets into your portal via WSRP. Best of all, when you upgrade your web app you don't have to deploy new portlets (assuming you haven't changed your WSRP exposed services list). I'm unaware of any decent open source tools, however, that make this feasible.
Talk to Rickard / Senselogic.
[..] WSRP will affect efficiency in one way and help in another (the portal won't be overloaded with bloated portlets). But then again, when are portals efficient when you're pulling data from so many different sources?
Portals are inefficient. Portlets are inefficient. WSRP is inefficient. The whole stack is inefficient.
Yet they can solve some very difficult and expensive business problems better than the alternatives, so the processing inefficiencies are minor annoyances. (But they are definitely annoyances when you're deploying large portals! ;-)
Peace,
Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java
|
|
|
Message #201155
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSR168 support with WSRP- good or bad?
One of the alternative is to rebuilt the whole applications from scratch (reusing some components if possible, which ruled out if the backend is not in Java).
I would not recommend porting the entire application to a set of portlets, unless the application was already slated for an intense makeover OR if the move will benefit the application maintenance/maintanability/scalability in the future. Frankly, allowing the portal to perform the "heavy-lifting" will allow your developers to focus on the components and not the underlying mechanics.
Two options not mentioned here (I think):
- Why not create portlets that communicate to the existing application's exposed API's?
- Why not, at least in the interim, use web clipping portlets to act as the user-interface for the existing application? We have several customers doing this already during migration phases, with existing Coldfusion, PHP, etc... apps. ie, http://www.portletbridge.org/
Secondly, Peoplesoft Portal 8.9 and Oracle Portal supports JSR168 specifications but through WSRP. Is this the right way to do so?
Right/Wrong is subjective. Since those Portals existed before the Portlet Spec, it may explain why they took that approach. Sounds like a hackjob to me, but who am I to say, really? ;-)
Won't it have an affect in efficiency of the portal application?
*Maybe*, but since they price you per-cpu licensing bla bla bla, the inefficiency is *really* in *your* wallet and/or decision makers. ;-)
STAY METAL!
Roy Russo
http://jboss.org/jbossBlog/blog/rrusso/
|
|
|
Message #201187
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
it does make sense to build apps for portal only
I think it makes perfect sense to build applications in portal if portal is your main platform. I don't see why any application should be ruled out based on it's 'size'.
you can't deploy large applications in to a portal (if you're talking JSR-168) -- portal admins aren't going to like deploying an app that needs a lot of memory when they might have a 100+ portlet apps loaded on a decent sized portal server deployment.
I guest you are talking about 'putting it al in one war file'. Creating an application that consumes a large amount of memory is bad in any way. Not only within a portal. If you cut it up in pieces (Session beans for the backend that can be put elswhere) you can scale the application. If it is not scalable you have a point, but then you have created a bad design, and you should fix that first.
that app will only run in a portal in this case. And if you try to make it both a portlet based app and a regular app then you're going to have sacrifice somewhere.
I seem to miss the point of sacrificing. I find the portlet API (jsr168) a clean API. It does not limit you more than a regular servlet API or HTTP in general (in fact it helps you with the clean separation between action and render phases). You only have to take in account the name spacing, but the rest of the view/controller layer is handled crystal clear.
Just put your model behind stateless session beans, keep a strong hold on what you get from the model and where and how you cache, and you can built heap friendly apps without any problem.
It only gets cumbersome once you start combining struts or JSF in the portal. Have not had good experiences with those technologies within the portal. The state pattern is an excellent replacement for these technologies.
So in general, if you app leans to heavy on the heap, fix the application. Don't 'blame' the portal for your bad design.
If you have build a 'bad' application, and you are unable to fix it, why not have it run on a separate portal instance, so you can control the resources used? There is nothing wrong with running an extra portal within the same environment. Also WSRP could solve the problem you have with memory consumption, by running it remotely.
Imho, once you picked the portal as your platform, run all you have on it. It makes integration so easy. Portal as a platform does NOT limit you (more than HTTP does for anybody). If your app is a heap killer, fix it, or run it (or parts of it) remote/separately.
|
|
|
Message #201188
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSR168 support with WSRP- good or bad?
We are doing quite a lot of integration of existing apps in our portal, and so far we have mainly used two techniques: either a generic simple iframe-portlet with additional functionality to handle SSO with the integrated app, or a generic proxy portlet a la portletbridge.org (actually, portletbridge.org is based on a code donation I made of our own proxy code). The iframe variant works with any application, whereas the proxy variant works with most applications that don't do any funky stuff with frames and/or CSS and/or JavaScript and such. For most smaller apps it works quite well, and provides a good end-user experience. We've even had customers write PHP-apps specifically intended for consumption by the proxy portlet, which is very neat and tidy, and the customer gets to develop his app in any way he sees fit.
For our own stuff, we have about 60 different portlets available in the standard product (SiteVision), and they all run as JSR168 portlets in a portlet container running in Tomcat. They range from tiny (e.g. "show this text") to reasonably large (e.g. online survey app with admin, statistics, user management). See senselogic.se/referenser for a list of reference websites that use SiteVision in a wide range of ways.
From a performance point of view we have had a Large Customer do extensive testing and benchmarks, and their new portal-based website with everything dynamic beat their old static Apache+DreamWeaver site in terms of performance and scalability. With realistic usecases we could handle 400k hits/machine/hour with subsecond responses, using a relatively plain Dell/Suse 8 machine (which is way way way cheaper than their old solution). So IMO to say that JSR168 portals are inherently slow is incorrect.
The long term goals we have for integration is indeed to use WSRP to integrate with all apps. As has been mentioned previously on this forum, I started working on a WSRP implementation with a producer that used proxy techniques a la portletbridge.org to expose a webapp. In other words, it should be possible to take any webapp (within the limits of what is technically possible) and expose it with WSRP by using this producer as a proxy. This minimizes the work required by the app implementor, and also gives them an easy way to validate that what they produce can be integrated in a portal setting. IMO the rule of thumb for when a portal integration should be done is when you have more than one webapp. I.e. it might be a good idea to think about it sooner rather than later. The main reason this isn't happening is (IMO) mainly because of licensing and usability issues with existing offerings, but that is in no way an inherent problem. It's fixable.
Anywho, just a couple of thoughts on the subject...
|
|
|
Message #201197
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSR168 support with WSRP- good or bad?
Hey Rickard,
how do you integrate with non markup features of WSRP like user identity and personalization ? does your application integration needs to implement an SPI that would integrate it in the producer ?
|
|
|
Message #201202
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSR168 support with WSRP- good or bad?
Disclaimer - I'm the author of the PortletBridge project:
While I can't speak for the efficiency of using WSRP, one of the options available right now for hosting existing web applications as JSR 168 portlets is the PortletBridge (www.portletbridge.org) project.
Built on top of code that Rickard has kindly donated, the PortletBridge project can handle most downstream sites and includes configuration options for complex javascript and css rewriting, authentication, proxy support, etc.
PortletBridge has been tested in JBoss Portal, Liferay, Gridsphere, uPortal and Pluto and has been seen to work in Weblogic and JetSpeed.
Jamie McCrindle.
|
|
|
Message #201213
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSR168 support with WSRP- good or bad?
Hey Rickard,how do you integrate with non markup features of WSRP like user identity and personalization ? does your application integration needs to implement an SPI that would integrate it in the producer ? Well, the WSRP proxy stuff isn't written yet, but our own internal proxy code can do either BASIC auth, or submit login forms and such (which is BY FAR the most common scenario, as most apps are written be relatively clueless developers). It should be relatively easy to make that part pluggable in the WSRP producer proxy. In other words, there is no SPI since most of those things can be done using standard protocols. See Jamie's post about how PortletBridge works, and look at that code. I'm very impressed with what he's done with it!
|
|
|
Message #201250
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
PortletBridge packaging
With PortletBridge available I think it would be interesting to see application vendors simply package their existing functionality in pre-configured PortletBridge portlets. I.e. instead of each user having to download PB and configure it to work with an app, the creator of that app could make pre-packaged configurations that has been tested and verified.
This will make it easy for app vendors to add the "JSR168" checkbox, and also makes it easier for users of JSR168 containers who want to integrate apps.
This is similar to the idea I had about wrapping existing apps with a WSRP proxy producer, except that it is a Java-only variant, which has its perks (performance being one of them).
I mean, why don't folks like Atlassian make portlets for Jira and Confluence available which simple contains PortletBridge with some pre-configuration done. It'd make it trivial to add those apps to a standard portal without much fuss. I think that would be a good way to bootstrap the whole portlet market.
Which is, concidentally, why I suggested that something like PortletBridge should be done in the first place...
|
|
|
Message #201271
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
PortletBridge packaging
+1.
The JBoss Portal team has worked with Jamie, originally, and are impressed with what you both have done with PortletBridge. It is being considered for inclusion in the default distro for 2.4, to introduce developers/enterprises to the concept and hopefully add support for the PortletBridge project.
|
|
|
Message #201276
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
PortletBridge packaging
That gives me an idea. Currently PortletBridge uses HttpClient to make downstream calls but it could use a RequestDispatcher (or PortletRequestDispatcher) if it's deployed as part of a web application.
If anyone wants to use PortletBridge to bootstrap their application like Rickard describes, let me know (dkfn at users.sourceforge.net).
|
|
|
Message #201291
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Apps should not be ported to a portal
I am not opposing the points of apps not to be ported on poral,but my concern is that if u are building a portal application,its better that all the preexisting apps should be aggregated on ur portal.The basic idea behind portal is 'aggregation'.If we take an example of a company's intranet ,we will try to collaborate all the new and the old aplication in one place of access.
Now as far as the effort is concern to change a web-app to a portal app that to jsr168,it depends upon how big-small-clean the application is..More the number of JSP's more the time will take to change as per the portlet.
--lokesh
http://lokeshpant.blogspot.com
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
