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!