At work we have both a legacy web app (a decade or so) as well as a new web application (< 6 months), both developed in Java. At the moment, both are running on different versions of JBoss AS (legacy app is currently using Spring 2, if I'm not mistaken, newer app built on Seam 2).
We're looking to create a section where users can view relevant information from both sources in the form of portlets (as well as potentially other compatible portlets).
I've never used portlets before and was wondering what technologies I should be looking at and how I should approach this task?
Is it possible to integrate the host portlet section in the first application or would we need a new deployment?
I've just gone through a portal selection process where I work and we've found several ways to approach this-
You can purchase a high-end portal product such as WebSphere Portal Server or Oracle's portal product (whatever it's called this week), you can go Liferay community or Enterprise (the enterprise version comes with support and gets new features earlier than community), or you can go purely opensource with Apache Pluto. All of those will give you real, JSR compliant, portlet containers. If you decide to go that route (as apposed to using apache tiles to aggregate at the glass and avoid the hassle of a portal or going to a non-portal technology such as Adobe Flex & Mosaic) you then get to choose how you access the legacy applications:
Using the portlet-servlet bridge, if your portal server has one;
Try and link the truly legacy applications with an IFrame portlet.
Re-implement the user interface functionality (you were using the MVC(s) pattern, right?) as portlets.
I'd guess that the older application that you mentioned is probably not designed for the UI to be replaced and you'd be best served using options 1 or 2, but I can't say for sure without seeing the app itself.
I think you may also want to look at using a portal bridge implementation.
Check out:
http://portals.apache.org/bridges/
http://myfaces.apache.org/portlet-bridge/index.html (for JSF)
Related
I made a GAE-Project with JPA2 for db access. I store some Strings which are more than 500 Characters, so I use com.google.appengine.api.datastore.Text.
I got an interface Script.java which defines the value as String, and an ScriptImpl.java which has internally a Text member, and converts for getting and setting.
Because one requirement of the project is, that it is still able tu run on an simple tomcat with a database behind. So it must be possible to run inside and outside the google environment.
Is there some realistic way to implement my application so I can switch to a normal tomcat environment (e.g. via a spring configuration to use different beans...).
What else do I have to pay attention to to make this work in both environments and how do I take care of the parts that are seamed thight to GAE?
Update: So far I found the following critic issues: Google User Service & Login Process, Text Class in Domain Models, Wicket-GAE-Initializer (since I use Wicket)
GAE has it's own proprietary API. If you wrote application using this API then if you want to move off of the GAE you have two options:
Rewrite your code, obviously.
Use a API wrapper that implements GAE API but runs on other platforms. An example of such wrappers are AppScale and CapeDwarf. AppScale is older and probably more mature and supports both Java and Python. Also it supports more platforms (private servers + clouds). OTOH, CapeDwarf is targeted at JBossAS7, so it's probably better fit if you use that server (or OpenShift cloud). Also I guess you can expect better support from a mature open-source leader such as RedHat.
While in theory it might be possible to wrap GAE functionality and then delegate it to either app engine or your "normal" environment it's probably a lot of effort.
Possibly another approach would be easier. Are you aware of CapeDwarf?
JBoss CapeDwarf
Deploy and run your Java App Engine applications on your own private
JBoss Application Server (AS7) cluster or on RedHat’s OpenShift cloud.
JBoss CapeDwarf is an implementation of the Google App Engine API,
which allows applications to be deployed on JBoss Application Servers
without modification. Behind the scenes, CapeDwarf uses existing JBoss
APIs such as Infinispan, JGroups, PicketLink, HornetQ and others.
If it really needs to be "simple tomcat with a database" then more information or constraints will be helpful to know.
I am looking at the Java Portlet API for the first time and trying to decide on whether or not to consider using it.
From the look of things, it looks like a technology that might be considered old school because i seem not to see very current references of its usages.
My question is, would you consider using the Java Portlet API, more so when you are planning to develop an integrated web application consisting of modules that may themselves be separate applications of their own.
Yes
Normally we go for a Portal application (using Portal API) in scenarios like this:
Multiple application(Portlets) in same page.
Multiple applications in separate pages but uses same Login(or User credentials).
Multiple applications which communicate to each other in same page or in different page.
These are just highlevel thoughts. Based on the application and available server stack, the Portal server can be chosen IBM Websphere Portal / Liferay / Weblogic Portal.
Portals are good at providing a common set of services, such as security and UI, to wrap around several applications that have a need to either pass information between them, or a need to be utilized as part of a similar process.
It's worth noting that there is also the JBoss Portal Platform, in addition to those above.
Also, there is a new version of the Portlet specification currently in development: http://jcp.org/en/jsr/detail?id=362
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 much 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
I'm looking at a solution to manage my content between a website & intranet and was playing with Hippo CMS in combination with Jetspeed. It looks good, bus does anybody have any experience with this combination? And where do you shop for more portlets?
I have some experience with this solution. Hippo introduced a completely rewritten version of their CMS beginning this year. This new version 7 eventually will get all features available in the previous version, but currently that is not the case (yet). However, the rewrite also made the CMS much more flexible and extensible.
They provide a toolkit for developing websites using the Hippo CMS as backend. This toolkit (called HST2) produces fairly generic components, since they can easily be converted to portlets which can be deployed on a Jetspeed portal (in fact, you only have to change one build parameter to get this working). Hippo also has an integrated solution in their product line-up called Hippo Portal. However, this is based on an old version of Hippo CMS and Jetspeed and will eventually be deprecated (I suppose).
Jetspeed is a nice portal. Recently version 2.2.0 was released. This version implements the Portal 2.0 spec, and as such can run all portlets which are conforming to this spec. There is no one location where you can get Jetspeed-specific portlets, but searching on the internet will probably give you some results (as said, Portlets doesn't have to be Jetspeed specific, if they implement the Portlet 2.0 spec (JSR-286) they will run on Jetspeed).
It is also pretty easy to create your own portlets. We use Spring Portlet MVC for this task, making the development of a portlet almost as easy as developing a generic Spring MVC app.
It's been suggested that this might be a reasonable approach, in order to minimize changes to an existing server configurations, but is it actually valid/supported? I've not been able to find anything specific either way.
In practice, with a JBoss Portal V2.4.2 server, there appears to be some class-loading issues, so things such as the downloadable Stripes example or a standard Wicket quickstart app don't run, but I'm not sure if the problem there is a server-specific one or a generic one - Anyone?
Note: This isn't about displaying/moving an existing web-app into a portal, simply if a Portal Server should also be a valid AppServer?
JSR 286 (Portlet 2.0) spec:
PLT.2.7
Relationship with Java 2
Platform, Standard and Enterprise
Edition
The Portlet API v2.0 is based on the
Java Platform, Standard Edition 5.0
and Enterprise Edition v1.4. Portlet
containers should at least meet the
requirements, described in v 1.4 of
the J2EE Specification, for executing
in a J2EE environment.
It is therefore not unreasonable to expect standard app-server applications to work under a portal.
However, by definition, a portal is going to include more libraries in the global class space. Adding libraries to the container always introduces the risk of incompatibility and the need to manage what classes/resources are exposed to your application and how (application-first class-loading, etcetera). I've had problems in the past with third part libraries whose dependencies conflicted with a version that shipped with the portal. I wouldn't expect dependency management to get any easier.
Write once, test everywhere, as they say.
From my experience that is a valid suggestion. Portlet Apps are often also Webapps (they might contain a servlet for example to allow access to application logic also by links to be rendered in one of the portlets), so they contain both portlet.xml and web.xml and need j2ee classes and jsr168 classes. The WSRP standard also contains resource link type with is supposed to represent a normal appserver for the remote server.
Websphere portal server is also an app server.
I have mixed servlets and portlets in a single web application using JBoss Portal, BEA WebLogic Portal and Apache Jetspeed 2.
However, converting a servlet to a portlet can be difficult. Using bridging technology such as Portals Bridges do exist but I have been lucky enough to avoid having to do such a conversion and have no direct experience other than playing with the tutorials.
Hmm... but can it /exclusively/ contain servlets, or in other words, does an app need to have at least 1 portlet? (I don't have/want to serve a portlet, just a servlet, but I've only got a Portal Server!)
Even if the application contains a portlet, nothing says you need to expose that portlet on a page somewhere. If you write such an application, simply author as many servlets as you wish, link to them directly and not place any dummy/default portlet on any page anywhere.
I wrote a JSR-168 compliant app with an empty portlet and a servlet that was used to retrieve some XML stock price data. For several months all that was ever invoked was the servlet, the portlet was never visible anywhere on the site. Later I added a portlet which provided some additional data from the XML feed.
The answer is that yes, it is valid, but the specific JBoss Portal V2.4.* versions appear to have class-loader issues such that only the more basic web-apps will run correctly.
I assume that the question has to do whether a standard web application can be rendered as a portlet from a Portlet container. This is not possible. The portlets need to be based on the GenericPortlet class and have special deployment descriptors. There is the JSR-168 standard, which specifies the requirements for the portal. The JSR-286 specification is on the way.
The only thing you could do is to create a portlet that will serve your existing application through an iframe, but this is of course ugly.
There is a free book for portlets called "Portlets and Apache Portals", which could be useful. Consult also the specification. This blog spot is interesting.