Liferay Portal With Mule Esb

  • Uploaded by: Pawan
  • 0
  • 0
  • May 2020
  • PDF

This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA


Overview

Download & View Liferay Portal With Mule Esb as PDF for free.

More details

  • Words: 922
  • Pages: 29
LIFERAY PORTAL-MULE ESB Pawan Modi Senior R&D Engineer

Agenda

      

Scope Objective ESB Case Study Topologies Accomplishment Investigation

Scope Scope of this demo project is to assemble the information from multiple sources & represent it on common interface. LifeRay is a portal offers many good features & it also meets our requirements. Following are the modules expected in LifeRay Demo.     

Single Sigh-on. Role Management. ESB. Auditing. Jasper Reports.

Objective Objective is to achieve communication between extremely different applications & information source. Application Integration is the biggest challenge for many enterprises. ESB is probably the quickest and most cost-effective way to address this challenge.

Goal is to innovate platform that integrate different applications & provide simple communication & data exchange between them. Multiple technologies are available in market.  Rest  ESB

Rest REST is a simple interface transmits domain-specific data over HTTP without an additional messaging layer such as SOAP or session tracking via HTTP cookies. Multiple REST framework are available in market  WebDAV  Restlet Team decided to explore Restlet framework.

Rest Conti.. After going ahead with Rest, team found following limitations with Rest. 



All critical resources in an application should be exposed as URIs. Very much applicable for GET requests but unproven for other state operations like complex operation eg PUT, DELETE.

Decided to go for ESB instead of Rest.

ESB Enterprise service bus provides foundational services for more complex architectures via an event-driven and standardsbased messaging engine. ESB enables the software connection running in parallel on different platforms, written in different programming languages and using different programming models.

ESB Conti..

ESB Conti.. Multiple ESB frameworks are available in market.  Mule  Service Mix  WSO2  IBM WebSphere Decided to explore Servicemix & Mule ESB.

ServiceMix ServiceMix combines the functionality of a Service Oriented Architecture (SOA) and an Event Driven Architecture (EDA) to create an agile & enterprise ESB. Following are the features of ServiceMix    

Completely based on JBI (Java Business Integration standard) Normalized messages based on XML. Best suited for working with BPEL, WSDL etc. Lacks security and breadth of connectivity.

ServiceMix Conti..

ServiceMix Limitations Decided not to explore further on ServiceMix due to following limitations. Only support Xml messages.  Lack of security.  ServiceMix is not light-weight framework. 

Need to be explored more towards ServiceMix.

Mule 



Mule is a light-weight messaging framework that contains a distributable object broker for managing communication between applications. Mule can communicate over a whole range of communication channels whereas ESB standardizes on the notion of a message bus.

Why Mule?? Mule got following advantages on other ESBs.  Scalable messaging framework that should handle most of the complexities of system integration. 



Mule server can operate over complex topologies. Flexible configuration that should be easy to manage over a distributed environment.

Mule Architecture

Mule Architecture Conti..

Case Study Following are the main objectives 

Integrate Mule with LifeRay portal. 



Deploy LR-Mule on single common server.

All communication must be redirected only via Mule server. 

Above requirement is important because communication via Mule server aid in implementing single sign-on & monitoring security threats.

Mule is tried & tested in N-N, Bus & Star topology Following slides share experience about N-N, Bus & Star topologies.

N-N Topology 



In N-N topology, all nodes need to implement Mule for communication. All node / application communicate with each other via underlying Mule.

N-N Limitations 

N-N topology is not feasible to implement.



Replication of Mule configuration in to multiple nodes is not advisable.

N-N Topology Conti..

Node1

Node2

Node3

Mule

Mule

Mule

All network nodes need to implement Mule

Bus Topology Bus topology is not meeting our 2nd objective. In Bus topology, communication among network applications is not necessarily be via Mule server.  Direct access make it difficult to implement single signon.  Direct access may also compromises with network security. 

Bus Topology Conti.. Node1

Node3

Node2

Mule Server

Node1/Node2/Node3 can access services from Node1/Node2/Node3 without going via Mule Server.

Star Topology Mule is integrated in liferay portal & tested successfully in star topology. Centralised LR-Mule server is functioning well. Single sign-on & centralised security server via Mule is yet to be tried out. Following slides shows Mule deployment in various star topologies.

Star Topology Conti.. Mule Client1

Communication among client1,client2, client3 is via Mule server.

LifeRay-Mule Server

Mule Client2

Mule Client3

Centralised LifeRay-Mule Server

Star Topology Conti.. AA A

LR-Mule2 LR-Mule1

BB B

C

Two LifeRay-Mule network applications communicating with each other.

CC

Accomplishments 

Mule is successfully integrated & tested in LifeRay portal.



LifeRay-Mule server is tested & working fine in star topologies.











LifeRay-Mule server with multiple applications like JSP, portlets is tested & working fine. Two LifeRay-Mule server networks, each with multiple applications are tested & working fine. File transfer from Mule server to clients in star topology is tested successfully. Accessing information among multiple nodes in star topologies is tested & achieved successfully. Redirection via mule server is functioning well in star topologies.

Investigation 





Single sign-on via Mule server is still in investigation. Mule security & authentication feature need to be further explored. File transfer between mule-clients via mule server is not yet achieved.

Centralised Setup App1

LDAP CAS MULE

App2

App3

Single Sign-on & Centralised Security Implementation

Questions ? Kindly send all your queries at the following id. [email protected]

Thank you!

Related Documents

Mule Mihir
May 2020 7
Esb Presentation
November 2019 14
A Mule
May 2020 2
Portal
October 2019 54

More Documents from ""