We have some portlets which are JSR 286 complaint. We sell those portlets with a liferay-server to our customers. One customer asked if it's possible to use those with Drupal instead of Liferay.
I can not find any information that Drupal supports jsr-286-portlets. So its not possible to use the liferay-portlets with Drupal, correct?
I think you may have the following options:
Web Service for Remote Portlets 2.0 (WSRP)
Quoting from WSRP specification:
The Web Services for Remote Portlets specification defines a web
service interface for accessing and interacting with interactive
presentation-oriented web services.
Basically you need a running instance of Liferay exposing your portlets as presentation-oriented web service to Drupal that will consume them and send back to the client.
The good news is that Drupal seems to support it. You need to enable Drupal as a consumer of WSRP, see that Drupal page, and Liferay as a producer, see here.
Using IFrame
Similar to first solution but with less integration and more work to do about security because the client will contact directly the Liferay server, so you'll need to expose it as a public server (if not in a Intranet scenario) and you'll probably need a Single Sign On solution for authentication.
I suggest to take a look at that document about Liferay Application Integration Strategies because recap very well several integration strategies with pros and cons (including the two I cited).
Related
I have written many services resources on the DRUPAL, "n" number of API hit comes to the DRUPAL CMS and access the data in the DRUPAL database.
My question is, when I hit service, Is DRUPAL CMS calling the bootstrap and verify every modules is loaded or not ?
Because I am wondering, there are nearly 100 web services, no more DRUPAL UI is consumed in this project.
So web service will eat site performance ?
Each request to one of your services will bootstrap Drupal in order to be able to reliably uses its APIs. And yes, this is a performances hit since bootstrapping Drupal is not lightweight.
In addition, depending on how the services are build, they may not provide any kind of caching, unlike traditional pages. Also a Web Services driven page will probably require more than one request, increasing the load on the server.
So yes, Web Services may eat your site performances.
The project has a situation which can be described as: a portal application has to be built. This is expected to be home for many existing non portlet applications (some are Java EE based and some not).
Obviously, portal will provide SSO. Options of rendering a non portlet application to portal seem to be using either an iFrame or a URL redirect. In either case, it looks like the request has to pass through the portal server (??).
What are the challenges that this solution face? Best practices to get this implemented?
This is what a Portal solution has been meant to provide: central point of access to applications, services, people, processes...
There is also the third option for integrating legacy web applications (I assume you are asking about WebSphere Portal Server) and that would be "Web Application Integrator". You can find some info on it here
Challenges with this solution would be related to:
1. SSO - there could be some complications with this, depending on infrastructure.
2. Look and feel uniformity - Portal themes should be appropriate for web applications to be integrated.
3. In some cases Web applications will need to be changed in order for integration to be possible.
Yes, each request will need to pass through Portal Server.
Hope this helps..
I'm looking to make a RESTful API on ASP.NET for a website. My problem is that I need it to be integrated into the website and not as a separate project.
I understand that WCF makes this really easy and its the ideal way to do it, but I don't think you can combine a WCF Service Project and a ASP.Net Website, Is this correct?
Is there a way we can do this using a webservice (asmx) file (since I know that asmx services use SOAP no?)
The reason I need this to be in the same project is that the customer will be able to purchase ssl for their domain (which the website is going to use) and I need to make the API secure as well, but the customer should not be asked to purchase two ssl or even a wildcard one.
Knowing this, is there a better easier way of doing this using WCF?
Take a look at the new MVC4 Beta, it's set to go live sometime between March and April this year and should be able to accommodate your requirement to build a RESTful web service alongside a web application. I haven't spent too much time with MVC4 to go into the details, but it's definitely worth a look. Links: Get MVC4; MVC4 and WebAPI blog.
Hope this helps!
You can use ASPNET MVC to build an API along with your website.
See How can I implement a site with ASP.NET MVC without using Visual Studio? for some details on building a basic MVC site.
ASPNET MVC services can respond in JSON or XML, or both.
There will be no special requirement for two SSL certs.
I have an ASP.NET MVC 3 application that exposes both WCF REST services. I'm using .NET 4. You'll have to pay attention to how you configure your routing. For example, my WCF services are prefixed with something like "api/v1/" while all other requests are handled by ASP.NET MVC 3.
I had a problem because IIS refused to serve some "localhost" requests (like when your MVC 3 controllers try to consume your WCF rest services). That was solved by adding an entry to my hosts file. Also be aware of this when implementing an OAuth 2.0 Resource Server or Authorization Server.
Using WCF for REST services works ok in .NET 4, but the JSON serialization sucks big time. There are issues with default dates and it is rather slow. You may want to look at using a different serializer. With WCF you sacrifice some flexibility for some features you get for free.
ASP.NET MVC 4 (and the WEBAPI) is still in BETA, so I'd avoid that for a project with a short term release date.
I'd actually use NancyFX. Setting up routes is super-easy, and it comes with built in XML and JSON serializers that act based on the data in the headers.
I have a custom web "portal" that is essentially a webapp built primarily using JSP/Tiles, Spring/MVC, and Hibernate. It runs on an Apache/Tomcat, MySQL stack. I have the portal within quotes because this is not truly a portal in the same sense as a Liferay, Glassfish or whatever portal server. But essentially what looks like a portal to a business user and one that pulls in data from several 3rd party systems through custom system integration.
I am now looking to add a community module to this "portal". A key piece of this requirement is to federate identity between this "portal" and the community server. Further, to facilitate a seamless single sign-on from the "portal" to the community. My preference is to keep the choice of community software to java-based and open source. Liferay is one example of it. JForum is another though it is limited to just discussion forums and not other modalities such as blogs and wikis.
Presently, the custom "portal' provides its own authentication/authorization mechanism based on user information in the MySQL database. It appears that for a scalable and flexible account provisioning across multiple systems, I am better of refactoring this to be based on a CAS-based authentication supported by a directory server such as OpenLDAP. It seems like with this approach I might be able to integrate with a community server such as Liferay.
If I extend my choice of community server to a PHP-based solution such as Drupal, can I accomplish the same result through a CAS-based approach? Any recommendations on how to federate identity (and enable SSO) between a custom Java webapp and Drupal? Entry point (login) for a user to the community will only be through the custom "portal".
CAS is a very popular method. Here is a Drupal module to support SSO into a Drupal installation.
Are both completely different concepts? Or is there an overlap in their meaning?
Would it be correct to say that a Web Framework is used for the creation of a front-end, while a CMS is used for the back-end?
If yes, then should the Web Framework use the same technology as the CMS? For example could Ruby on Rails be used in combination with Drupal? Or doesn't that make any sense at all?
Are both completely different concepts? Or is their an overlap in their meaning?
A web (application) framework is a lower level, generic toolkit for the development of web applications. That could be any type of system managing and processing data while exposing it's data and services to human users(via web browsers and other interactive clients) as well as machines via the http protocol.
A CMS is one type of such applications: a system to manage content shown in websites. Usually/historically, this mainly means managing (pieces of) text of "pages" shown in a web site, and useres that have different levels of access to manage this content. That's where the C and the M come from.
With a CMS, you can manage web content. With a Web framework, you build web applications.
Would it be correct to say that a Web Framework is used for the creation of a front-end, while a CMS is used for the back-end?
No. It would be correct to say that a web framework can be used to create a CMS.
Both contain parts that work on the backend as well as on the front end.
Often, a CMS is based on a web framework - sometimes CMS developers build there own web framework, and sometimes they even expose the API of this framework, so a developer can create extensions to the CMS in a way as if he would develop an application with a web framework. Drupal really does this, so you can create real web applications based on the integrated framework - with the upside that they will also be easily to integrate into the CMS.
But that(exposing the API of a web framework) is no necessary criteria for being called a CMS.
If yes, then should the Web Framework use the same technology as the CMS? For example could Ruby on Rails be used in combination with Drupal? Or doesn't that make any sense at all?
It's be possible to combine two existing systems build with these two, (e.g. because you want to show some data in a web site managed by drupal, that already exists in a Rails-based system).
But as Drupal also provides you some of the genric functionality of it's underlying web framework, it might not be necessary. You would have to manage and learn two very different systems and handle all the problems with there interoperation. So, I'd try to build a Website with only one of these if possible and only combine them if theres a good reason to.
They're different concepts. A CMS can be built on top of a web-app framework, but a web-app framework has no direct relationship to a CMS. Its at a lower level, providing a platform for any type of web-app to be built on top of it, of which a CMS is an example.
Drupal runs on php and Ruby on rails runs on, well, Ruby, so they wouldn't play together.
Just to muddy the waters a bit, Drupal describes itself as a content managment framework which is essentially a content management system with hooks to extend it. Which does create an overlap. The drupal overview describes this better than I could.
Would it be correct to say that a Web Framework is used for the creation of a front-end, while a CMS is used for the back-end?
It's not "correct" but it's not wrong, either. A web framework is a general concept -- many things count. A CMS is a specific concept, often built within a web framework. Sometimes CMS's are stand-alone web applications. More often, however a CMS is a back-end things that require a customized presentation front-end.
Should the Web Framework use the same technology as the CMS?
Shouldn't matter. At the end of the API definition, the Framework and CMS can have any implementation at all.
Web App Frameworks -- generally -- must either serve HTTP requests or plug into something like Apache.
A CMS is a glorified database, and any sensible API is good. Most often, however, they're also using HTTP as their interface protocol.
Could Ruby on Rails be used in combination with Drupal?
Sure. Purists will object, but there's no technical reason why they can't cooperate.