We are in the process of working on our second generation of our eCommerce site. The contracting firm that has been brought in is pushing for the use of WebSphere Portal vs using JSP/Spring MVC etc to build out the UI part.
Many parts of the new release will be based on Version 1.
The contracting firm is an IBM partner - so I assume that there is a conflict in interest in determining the best solution for the UI.
So, I am reaching out to the group to get a feel as to is using IBM WebSphere Portal worth the money - ROI?
Going forward we will be using an off shore company to maintain the application once it goes live - so we have to consider those skills sets.
We provide Web Sites to Consignors to allow them to sell/auction their inventory of Vehicles. The underlaying Business Logic is pretty mu开发者_开发知识库ch the same for each consignor and is handled in a separate tier. The issue is that currently we have created a core set of UI and Controllers which are then extended into a Consignors project. Each Consignor "Store Front" is a separate deployment.
Here is what I know or have been told about Portal:
IBM WebSphere Portal OTB will handle the basic security - user log in and the portlets that they can see (Spring Security can do the same thing)
IBM WebSphere Portal OTB can handle the theming or re-skinning the portlets based on what company the user is associated with. (Standard UI practices can achieve the same thing)
IBM WebSphere Portal can provide re-use of Portlets (Not sure I buy this since so far each customer has demanded their own screen layouts along with the data collected and how it is displayed)
IBM WebSphere Portal can help with time to market - That is start with a base reference implementation and then show them what can be changed in a 45 - 60 day turn around.
I am open to anyone who can also provide more benefits of its usage.
Follow on Question
In response to a statement made by @Bozho - what are the guidelines if any to determine if a portlet solution is warrantied.
IBM does not trigger any good references in terms of quality software in my head. And all points above are marketing nonsense. There are two things you need to assess:
- do you need a portlet solution. (This is regardless of the portlet implementation).
- which portlet implementation to choose
I cannot decide these for you, but I can tell you that:
- spring provides even advanced user and security handling (spring-security)
- even if you choose portlets, you can use spring. Spring has portlet support.
- if you choose portlets, make sure you choose a good implementation. As I mentioned, I wouldn't go for IBM.
It entirely depends on what your end game is.
It looks like the supplier has recommended Websphere Portal with a view to setting up a virtual Portal for each Consigner - so they can be managed separately, which make sense as you can just deploy the same portlet in each virtual portal with a bit of customization and also the consigner and user roles can be handled easily by portal out of the box.
However Portal is a pretty big piece of kit. If you want to integrate content from various sources and present the data in a standard way to the end user based on their role,etc, or it you're planning on using some of its existing functionality, i.e. dynamically updating portlets on the same page through events, Web Content library, integration with Remote Portlets, integration with collaboration tools, integration with process server/bpm tasks, blogs, wikis, etc, then it might be worth using a portal solution.
If however all you want to do is essentially create a web app, then Portal's total overkill and I'd just stick to an app server with whatever frameworks make the job easier
精彩评论