We have some portlets created by a team working on a Java EE site.
They would like to include one of these portlets within a site I manage, which is ASP.NET.
Aside from solutions like iframes, is it possible to embed a Java portlet within an ASP.NET page?
(Note: I don't have much Java/portlet experience, so please take that into consideration in your answer)
UPDATE
Is this relevant to my question?
http://download.oracle.com/docs/cd/E13174_01/alui/devdoc/docs60/Portlets/Basics/Hello_World_Portlet_NET.htm
The short answer is yes - this is technically possible.
You could expose the Java portlet using WSRP. The Java portal server will need support being a WSRP producer. The Java portlets will need to strictly adhere to the spec to avoid things like URL rewriting issues, so your Java folks will have to test the app for conformance.
I don't know much about the ASP.NET stack, but I know Sharepoint supports WSRP. If your portlet consumer isn't a Portal server, I don't know how much work would be involved in consuming the web service directly - you'd have to study the spec.
While theoretically the answer is WSRP - cross vendor WSRP has always been challenging (though Oracle Portal uses it internally for example) - especially since WSRP 1.0 omitted Authentication and other important pieces.
In my experience your best bet is either:
Uses AJAX or similar to load a full-page version of your portlet, and rely on SSO or shared secrets to handle authentication
Write a slim webpart that talks over REST/SOAP to a backend service that's shared between a portlet and webpart (e.g. exposes servlet/Webservice endpoints in the portlet webapp)
Related
I have an enterprise Java web application deployed in tomcat.
I am looking for ways to integrate a HTML & JS UI with the mid tier java code. So far, from looking around I have read that there are two ways to do this which fit my requirements :
1) DWR - Direct web remoting
2) Use REST web services.
I am not sure which approach to use.
Edit: What is the advantage of using DWR over a rest WS design?
Is there a better approach available? Some people asked me to have a look at GWT, but I am not sure if these are scalable.
Edit 2: I will most likely be using dojo for the UI development(Works well with REST/DWR??), and I want to keep the java code chages minimal. I understand that by using web services, I would have to write an additional WS client layer on top of the existing java code.
Also, the usual enterprise needs, performance, scalability, etc.
Ok so you're building a web client frontend to your java backend, there are a few ways to go about this:
You want to use java standards as much as possible, preferably living in the java EE world: JSF. You will need some knowledge of HTML, XML and perhaps even javascript (though limited). Personally I have had a pretty buggy experience with JSF+richfaces to the extent that I don't use it anymore.
You are very well acquainted with java desktop application development but don't know much about javascript: vaadin: it allows you to write plain java using desktop application terminology which will be compiled to javascript. Currently I am working on a big vaadin project and it is very nice to be working with pure java in eclipse, the downside is however that you are far removed from the actual frontend, so tweaking can be tricky. Additionally everything is stored in sessions (afaik) and scales poorly.
You are primarily a frontend person with unrivaled javascript skills: use a REST interface in java and a pure js/html/css frontend. Personally I think this is the cleanest design and I have designed a few of my own applications like this. The downside is that managing large javascript projects tends to be hard because...well...javascript sucks. The upside is that this will always be the fastest most lightweight option available to you.
Ideologically I would definitely suggest the last approach but this can be hard for large projects. If you have the hardware to throw at it, vaadin is a nice option. My JSF 2 experience was a bit disappointing due to the bugs in (necessary) third party libraries like richfaces.
PS: I have never heard of DWR but the last stable release seems 2 years old and all it seems to do is expose java code as javascript methods which can be better handled with a REST interface.
Open interface standards like REST and SOAP make it easy to build code to consume these services if you are using frameworks to build a REST Client and a SOAP client code respectively. But the point is that you need to have this client code to make calls to these services.
DWR on the other hand, generates this client code. Your java classes are ready to be called (like you would do in Java).
In JavaOne 2013 I attended a seminar on Project Nashorn. I was astonished after knowing about it. Calling Java From JavaScript and vice versa.
But one question is still unclear to me, that how can we use Nashorn in favor of Web Application Framework like JSF, ADF Faces or Wicket etc. If someone give any pointer, it would be highly appreciable.
Scripting API for Java Platform, in general, and Nashorn, in particular, open wide range of opportunities for web app development on JVM. Frameworks like node.js and vert.x solvency of JavaScript as server-side framework. Yes, we still waiting news about node.jar - mystery Oracle's project of implementing node.js API on Java platform.
In todays modern web applications we should think about server-side more as service provider (RESTful services) rather than presentation framework that generates html on the server. But even for server-generated pages you not necessarily need stick to frameworks like JSF, Wicket, ADF. With Nashorn/Rhino you can use JavaScript templates to generate html markup on the backend. LinkedIn, for instance, already described benefits of having templates written in JavaScript in both browser and on the server. In case when your browser unable to precess client-side templates you can graceful degrade and switch to server-side rendering.
If you're looking to example for to leverage JavaScript in server-side web framework you can start with Dust4j. Do not be confused by words Rhino in description. Dust4j doesn't use internal Rhino's APIs. It uses jsr223 APIs so if you run it on JDK8 or JDK7 with Nashorn backport it should work. Dust4j project shows how you can integrate scripting into you JSP/Servlet/Filter-based application.
Nashorn is a JavaScript compiler and runtime for the Java Virtual Machine. It is not a Web Application Framework in itself, but might enable one to be built on top of it.
Therefore, it isn't a replacement for JSF or ADF.
Apache Wicket provides a functionality to post javascript code against the server, now and also allow to access session / request scoped objects. It does not replace the Web Framework itself, but allows you to create a programming interface to run code on the server and modify java objects, calculate values and return the calculcation.
The documentation of Wicket's Nashorn Integration can be found here: https://github.com/wicketstuff/core/wiki/NashornIntegration
And if you fork the git repository you can run the nashorn integration examples:
https://github.com/wicketstuff/core/tree/master/nashorn-parent/nashorn-examples
One thing left to be mentioned: Because it is an arbitrary code execution this might lead to security issues, so ensure that only logged in users can access this interface.
Why would I want to use java portlets above tomcat and gwt?
Would portlets make it less- or un- necessary for me to use jsp and jsf?
Has Jboss been part of the portlet evolution culture? Does Jboss satisfy the portlet jsrs?
What portlet implementation/brand would run on gae java and gae python?
Are portlet specs due to peer pressure from php cms culture?
What are the equivalent of portlet and portlet jsr in .net?
Portlets were a well-meaning but mis-guided attempt at a reusable widget API for web applications. Think of the personalised google home page, with the portlets like weather, news, mail, etc.
Unfortunately, they made a bit of a mess of it. The Portlet API is a bit of a pig, a real barrel of not-fun, and there are very few implementations of it. The only one I've ever used is JBoss Portal, but it's a bit of a brute, and rather buggy. Liferay may also be a portlet server, but the home page is heavy on fluff and light on information, so I can't tell.
Spring provides an MVC framework for the portlet API which tries to reduce the pain, but frankly I wish they hadn't bothered, it just clutters up the documentation.
Essentially, the whole shebang looks like a solution in search of a problem.
If you happen to have a framework that you need to use, and it supports portlets, you may find then that portlets are going to be useful, since the application is built with the idea, but, as others have mentioned, if you are starting on a project, there are many other technologies that will do what you want with less effort, in a more stable environment.
For example, when I worked at the University of South Florida, the learning management system was (and is) Blackboard, and they now support portlets: http://www.ja-sig.org/wiki/display/JSG/Blackboard+Portlet. So, if the application provides an API, and expects people to use portlets, then it may make sense to look at them.
UPDATE:
After looking at the question there were a couple of things I missed.
Portlets were an attempt, it seems, to try to do as Google did on their homepage, where you could have multiple unrelated blocks of information on the webpage, so you could track your stack portfolio and your favorite hockey team, for example. I don't think it was influenced by PHP CMS as it was just an idea that was ready to come about, and if you need the server code to help pull the information, and to tie it into an application, this was one approach.
The closest thing in ASP.NET that I can think of to portlets are controls. I could have a stock portfolio control and when I include it on my page, you can set the options and it will show you your stocks and hockey team scores.
Not everyone uses JSF, for example, so controls would need to be written by hand as JSPs and servlets, with javascript.
Why would I want to use java portlets above tomcat and gwt?
These technologies are not directly comparable. Coming from regular web page development, Portlets seem like a very restrictive technology. But then the value of Portal servers is largely the control they give to administrators and users - the fact that this makes your life more difficult is irrelevant.
Would portlets make it less- or un- necessary for me to use jsp and jsf?
You can write directly to the output, just like you would in a Servlet. You probably still want a view technology (that will have to support portlets).
Do you know a technology which can provide me a portlet-like interface?
But I do not want to use JSR 168/268 portlet specifications and a portlet container.
The reason is: My web app is a product which can be installed on the client's server (it can be weblogic/websphere/tomcat).
Packing the portlets container along with my application to be installed on clients web server is just too much.
Besides, there are a lot of features this technology offers which I don't need. Actually, all I need is the porlets look and feel (dragable and customizable windows,adding and removing windows and so on).
I know there is also the possibility to do it with client technology (like jquery) and that is cool, but I would like to know if there is any kind of java technology out there which will also give me that.
So, if you know something like a struts or a spring-mvc component library which does this job or maybe a third party product, I would like to know.
If you think my whole approach is wrong I would also like to know that.
Take a look at gwtportlets. From their site;
GWT Portlets is a free open source web
framework for building GWT (Google Web
Toolkit) applications. It defines a
very simple & productive, yet powerful
programming model to build good
looking, modular GWT applications.
The programming model is somewhat
similar to writing JSR168 portlets for
a portal server (Liferay, JBoss Portal
etc.). The "portal" is your
application built using the GWT
Portlets framework as a library.
Application functionality is developed
as loosely coupled Portlets each with
an optional server side DataProvider.
Take a look at the demo here
Another suggestion would be JSF 2.0 which provide AJAX support for updating part of the HTML-page out of the box.
Have a look at this series to get an idea of the possibilities:
http://www.ibm.com/developerworks/java/library/j-jsf2fu1/index.html
Does someone know/have experience in showing Java web application generated UI in Sharepoint? We have a Java web application and are evaluating the possibilities to embed Java-generated web UI into Sharepoint. I don't think Sharepoint supports Java portlets, but it might support consuming WSRP?
As previously mentioned, the SharePoint team released the WSRP toolkit a few months back. More details available here.
If that doesn't work out for you (I've never tried it so have no experience to share) depending on the UI requirements you can always use the simple route of the Page Viewer Web Part.
This essentially creates a mini-browser (I believe it uses an iFrame) within a SharePoint page. If you're portlet is simply a data entry/display method it may work out for you and it's definitely less work.
WSRP consumer support is out of the box in SharePoint Enterprise. You can find a WSRP WebPart on your site if you've activated the Enterprise feature.
The WSRP toolkit allow SharePoint to produce WSRP compatible webpart.
SHarepoint does not support WSRP out of the box. However MS released a WSRP Toolkit.
You can find more information here
Actual link
http://sharepoint.microsoft.com/blog/Pages/BlogPost.aspx?pID=537