Liferay ESB Support - ServiceMix and Mule

This article will give a quick summary for the 2 open source ESBs supported by Liferay -- ServiceMix and Mule.

What is ESB? #

ESB stands for "Enterprise Service Bus". Without getting into technical jargon, an ESB is basically just a switching station between services. To use Liferay as an example, imagine that the portal needs a workflow service/component. There are several different workflow engines out there that would suit our needs, but we want to give users the flexibility to choose the one they want to use. Therefore, instead of having the portal directly access the workflow service, it will access the ESB, and the ESB will then determine which workflow component to use. No matter how many times or in what ways the workflow service changes, the portal is never directly impacted. ESBs provide a powerful mechanism to "plug in" new services/components and modify them with little or no impact to the portal configuration.

How are ServiceMix and Mule different? #

First of all, there is no way to provide an exhaustive feature-by-feature comparison of ServiceMix and Mule in this article. If you would like more information about each, please check out the following 2 links:

 http://incubator.apache.org/servicemix/home.html
 http://mule.codehaus.org/display/MULE/Home

In general, though, both are useful for the purposes described above. ServiceMix is truer to the traditional definition of an ESB (it adheres to the Java Business Integration (JBI) JSR-208 specification), whereas Mule is based on ESB (it doesn't adhere to the spec) but is more flexible. In my research, I found Mule to be a bit easier to configure and get up and running. However, ServiceMix has a smaller footprint than Mule.

ServiceMix and Mule in Action #

There are 2 sample services/components preconfigured in the ServiceMix and Mule webapps. The majority of the configurations for each are done in 2 XML files:

  • ServiceMix = web.xml and applicationContext.xml
  • Mule = web.xml and mule-config.xml

To deploy each of these webapps, just run "ant clean deploy" from their root directories. The 2 examples are described below.

Workflow Example #

By default, Liferay uses JBoss' jBPM engine for its workflow component. Both ESBs' XMLs are preconfigured to call the jbpm-web webapp to process data submitted from the "Workflow" portlet. By default, the portal is configured to use ServiceMix for the workflow component, but this can be overridden in portal.properties:

 #jbi.workflow.url=http://localhost:8080/servicemix-web/workflow
 jbi.workflow.url=http://localhost:8080/mule-web/workflow

Sample Hibernate Example #

Both ESBs can be used in conjunction with the Sample Hibernate Portlet and the XSL Content portlet to provide a highly flexible means of retrieving and displaying data from any datasource. For example, assume that you have a Liferay portal running on Tomcat that uses a MySQL database. However, also assume that you have an Oracle database that has some legacy HR data that you need to display in a report in the portal. Also, you know that in the near future, the Oracle database will be replaced with a new HR system that has its own datasource. What's the easiest way to get the current data to display in your portal now but allow for easy transition to the new system later?

  • Start by customizing the Sample Hibernate Portlet to point to your Oracle database, retrieve the necessary data, and publish it as XML.
  • Next, create an XSL file that can be used in conjunction with your published XML to format the data.
  • At this point, you could use the XSL Content portlet to directly access the Oracle data. The portlet's configuration might look something like this:
    • XML: http://localhost:8080/sample-hibernate-portlet/servlet?cmd=getFoodItemXml
    • XSL: http://localhost:8080/sample-hibernate-portlet/view.xsl
  • However, let's assume that you don't want to have to change the portlet's configuration every time the datasource changes. The solution is to use one of the ESBs as a data service broker. Use one of the following URLs for the XML parameter of the portlet:
    • http://localhost:8080/servicemix-web/sample_hibernate?cmd=getFoodItemXml
    • http://localhost:8080/mule-web/sample_hibernate?cmd=getFoodItemXml
  • Both URLs will return the same XML from the Oracle database. However, in the future when the Oracle database is replaced with a new system, you will just need to update the ESB configuration or the hibernate portlet and you will never have to touch the portal. This is the power of using ESB.
0 Allegati
41867 Visualizzazioni
Media (0 Voti)
La media del punteggio è 0.0 stelle su 5.
Commenti
Commenti Autore Data
Well this is a bit lacking in details, like the... Michael Oliver 2 dicembre 2012 14.48
Hi Oliver, did you successfully uses... lpu123 xyz 14 maggio 2013 16.55
What I was looking for, was examples of Liferay... Michael Oliver 16 marzo 2014 15.42

Well this is a bit lacking in details, like the mule configuration file for the workflow.

Essentially, Mule is an event driven workflow engine. You can route events as messages through a series of message processors that can do just about anything you need done, and if you have some specific programming you can use the Java, Groovy, or JavaScript message processors (aka Components) to do the custom programming.

Since Liferay and Liferay Portlets are also event driven, you can serve the portlet from a Mule End point such as with JMS, HTTP (SOAP OR REST) and if I have time I might post a more detailed example here, but wanted to provide a little more insight.
Inviato il 02/12/12 14.48.
Hi Oliver,
did you successfully uses ServiceMixESB with Liferay.6.1.GA2 ?
Thanks too much for some hints or url !
Inviato il 14/05/13 16.55 in risposta a Michael Oliver.
What I was looking for, was examples of Liferay Hooks and SOAP integrations with Mule. For example, I have written a series of Hooks to override the Organization and User Local Services, which simply takes the data from the override, writes it to a Mule Endpoint, and let Mule dynamically route the message and return a response. If the response is good the super is called with any modified data in mule and the process in Liferay completes. Combine that with Expando Fields and you can get very powerful integrations. We use the addOrganization(...) to trigger a sequence of processors and scripts that buy a new domain name, and forwards the www on the domain to the public site created for the new organization, all with Mule Events.

Similarly we have Mule Endpoints to output data from other systems or for final processing of a workflow that continues after the addOrganization is complete, to post to Liferay SOAP to add data back to Liferay and keep things in sync.

That's where I was going when I commented the first time, and not finding anyone having done it and documented it, I went ahead and did it myself....well my staff did most of the work.

MO
Inviato il 16/03/14 15.42.