Friday, February 5, 2010

Liferay and SOA

One of the main characteristic of a portal is that the origin of the data that it holds can be initialized at any place and integration of this information is handled by the Web portal. Another important characteristic of a portal is different users who have different roles within the organisation must be able to see different views of the same web portal depending on permissions they have. The main component of the portal is the portlets which are self contained interactive elements written according to a particular standards like JSR-168, JSR-286 etc. Portlets are the components that render the markup fragment that represents the applications. Because of these characteristics of the web portal and the portlets it is possible to extend the Liferay using the Service Oriented Architecture (SOA).

All the applications that we integrate with the Liferay are portlets and since portlets are developed independent from the portal itself and loosely coupled with the portal, it is possible to use SOA. Since Liferay portal uses and open SOA framework and provides tools and framework to extend SOA to other enterprise applications, SOA can be easily implemented. The Liferay provides mechanism to the developers to quickly implement the SOA concept. The Liferay portal comes packaged with a powerful tool known as ServiceBuilder which helps to develop the SOA. There are lot of technologies needed for SOA such as Web Services, Spring and Hibernate and it is necessary to write and configure lot of files when implementing SOA. But the ServiceBuilder of Liferay automates most of these things and the only thing the developer has to do is implement the business logic which is the key aspect of the portal. So it is possible to extend the Liferay using these things to implement powerful SOA.

When implementing SOA with the Liferay the first thing we have to do is define the data model. In order to do that it is necessary to write an XML file called service.xml with all the necessary fields, keys and finder methods. After that we need to run the ServiceBuilder using Ant and number of files are generated. Among these files, Spring configuration files, SOAP and Tunnel classes, WSDL files Javascript web services methods, Data model classes, Hibernate classes, SQL create and index scripts are included.

After Defining the data model it is necessary to declare the business methods. We can declare any business methods in Remote and Local service classes. After run the ServiceBuilder task in Ant again, those methods will be propagated into the SOAP and Tunnel classes and WSDL files and Javascript Web Services methods.

The final step in implementing SOA is implementing the business logic. The remote implementation class do security and permission checks like any other J2EE application. The local implementation class contains the business logic that we allow the trusted sources to invoke. After doing all these three steps we have to compile the code and SOA is implemented.

Web Services for Remote Portlets (WSRP) is another way of implementing SOA with SDWMS. WSRP is a specification which defines the methods on how to combine SOAP based Web Services that generate mark-up fragments within a portal. The main goal of the WSRP is to bring the Web Services and the benefits of SOA to the end users. WSRP is built on top of the existing Web Services Standards such as SOAP, WSDL and UDDI.

Web Services allows to re-use the back end services and WSRP allows to reuse the user interface. As an example we can use this with Liferay as follows. If we decide to provide the users of the SDWMS to retrieve news alerts or price of stocks, we can first look whether there is already Web services which provide these functionalities. We can search in UDDI registries for web services portlets to find a web service which provides this functionality. After finding such a portlet, the process of adding it to the portal is simple. Since the portlet is being consumed through WSRP we don’t need to do any custom coding or deployment activity.

WSRP architecture defines three types of actors. They are,
  • WSRP producer – In the above example it is the web service that which offers portlets which implement the WSRP interfaces and the news alerts or stock quotes functionality.
  • WSRP portlet – This is the pluggable user interface component that runs inside the WSRP producer and it can be accessed remotely through the interface define by the producer.
  • WSRP consumer – This is the client that invokes the WSRP web services offered by the producer. In above scenario it is the SDWMS portal.
The process of Discover, publish and run the web services using WSRP is shown by the following figure.

1 comment:

  1. That was remarkable post. I like to read articles that are edifying for they enriched my mind with different knowledge that makes me a better person. These articles especially about recent events, technologies, news, tips and technical skills are the topics that I adore. Keep it up and more power to your website. I look forward for your next article.Thanks Jennifer Liferay Portal Development

    ReplyDelete