文章 - 17 评论 - 30 收藏 - 1 粉丝 - 6 访问量 - 38275

1 Preamble

System integration is playing a more and more important role in the informationization construction progress of mechanical product R&D and Manufacturing Enterprises. As a global framework, portal technology has been used to handle many integration issues like system management, user and role management, multi-system display and multidisciplinary collaboration etc. Project overview in a R&D institute including project background and user requirements will be first introduced in this paper and after a brief comparison between different portal productions, Liferay will be introduced to build the whole R&D platform as the portal solution. In the forth part of the article, system architecture will be described to explain how Liferay is used to handle the integration problems and some high lights will also be bringing forthed. Main efforts of the project will be discussed in the fifth part, our works in system design and implementation step will be explained in detail to show how Liferay is working together with other systems. Simple system demonstrations will be given in the sixth part. Some experiences and works have to be finished in the future are discussed in the last section as the conclusion of the paper.

2 Project overview

AAA institute is a high-tech mechanical product R&D enterprise mainly focuses on products’ whole life cycle research and development, including design of products’ three-dimensional model, simulation and testing of products’ performance. One main goal of the project is to build a platform that can integrate all resources such as work flow, data, information, human and software systems(including in-house software ) in the enterprise(in this paper ,we mainly discuss human and software systems ).

The contextual analysis of institute’s organization can be seen in the below table:

Table 1 Contextual analysis of institute’s organization

No.

Department

Duty

1

Chief Engineer Office

chief engineer

vice chief engineer

2

Information Center

chief of engineer

team leader

engineer

3

General Design Office

chief of engineer

team leader

design expert

engineer

4

Structure Design Office

chief of engineer

team leader

engineer

5

Strength Analysis Office

chief of engineer

team leader

engineer

6

……

……

We can analysis from the table above that the institute has many different kinds of departments, each people in the department has his own unique duty, subsequently people has different role and hierarchical authority access to a special system.

Software systems existed in the institute have to be integrated in the platform are also concluded as table bellow (for security reasons, some system’s name is replaced by system+No.):

Table 2 Software systems in the platform

No.

Name

Function

System Technology

Application Server

1

Workflow

workflow management

J2EE, Struts+spring+hibernate

Oracle

JBOSS

2

DataMan

data management

ASP.NET

DB2

IIS

3

ProjectMan

project management

J2EE, Struts+spring+hibernate

Oracle

Tomcat

4

SystemMan

system management

J2EE, Struts

Oracle

WebLogic

5

SoftwareMan

software management

J2EE, Struts

Oracle

Tomcat

6

System5

model design

J2EE, Struts

Oracle

JBOSS

7

System6

model design

J2EE, JSP

Oracle

Tomcat

8

System7

product simulation

PHP

MYSQL

 

9

System8

product simulation

PHP

MYSQL

 

 

As we get from the table, these systems are based on different architectures and were developed by using various technologies (languages, databases etc.), meanwhile, people in each system has a role that has special access control authority to the object and operating resources. The user, role and authority information are stored in respective database.

User requirements from the institute were concluded as follows:

  • User information only stores in one place and can got from LDAP system of the institute
  • SSO requirement: Single Sign-on
  • User has his own workbench can easily access to any desired resource
  • Customizable and localizable web interface
  • Single view of & access to capabilities
  • Internationalization support
  • Can easily integrate with other systems in the institute such as PDM etc.
  • ……

3 Introduction of Liferay

A stable, flexible and extendable framework is essential to the R&D platform that can fulfill the user requirements. So a mature portal product should be adopted to handle this issue. We can classify portal products into two types as commercial portal and open source portal. Bellow table shows the comparisons between commercial and open source portal.

Table 3 Comparisons between commercial and open source portal

             Products

Item

Open source portal product

Commercial portal product

Documents and services

most open source products are lack documents and services

mature services support

Technology

relatively more new and advanced

relatively more mature technologies

Product stability

there are some unpredictable product defects

persistent testing of systems and modifying

Scale of product line

such as AM and IDM

need developing or third party software

adequate peripheral systems

Code

whole open source code

no codes provided, only APIs

Easy to learn and use

relatively easy to learn and use

system is complex, relatively hard to learn

Communities and resources

lots of communities and communication resources

lots of communities

Investment

low cost

invested cost is high

After analysis the table above, some determining factors make us decide to choose open source portal are as follows:

  • Scale of the product: Ordinary, commercial portals are too large, that not only means big installers of the production (hundreds of megabytes and even kilomegas), but also lots of unnecessary functions of the portal. Meanwhile, open source portals are often light weighted.
  • Ability of re-develop and modification: Because codes can totally controlled by adopting open source products, portal can easily be modified and redeveloped, subsequently, the whole project’s risks are decreased.
  • Investment of the Product: A common commercial portal product (its licenses) plugs some additional modules often costs millions of YUAN. On the contrast, an open source portal has the same functionality nearly cost 0 YUAN.
  • But there are still some doubts made us hesitate to adopt an open source portal product:
  • Product stability: Because open source portal were often designed and developed by some individuals or some teams, product’s stability and quality are hard to guarantee.
  • Easy to deploy and develop: There are should some plug-ins and toolkits can support the development of portlets, and in the develop process those portlets can easily be deployed without shutting down the application server (hot deploy).
  • Training Services and Learning resource: For a fresh, it’s hard to master a new portal’s development and manage, and it’s a key element to accomplish the project in a relatively short time.

We have studied some main open source portal solutions nowadays, the information are navigated by “link”. See the table bellow:

Table 4 main open source portal solutions

n    JBoss Portal

Home page: http://www.jboss.com/products/jbossportal

Documentation: http://www.jboss.com/products/jbossportal#docs

Community: http://www.jboss.com/index.html?module=bb&op=viewforum&f=205

n    Jetspeed 2

Home page: http://portals.apache.org/jetspeed-2/

Documentation: http://wiki.apache.org/portals/Jetspeed2

Community: http://portals.apache.org/jetspeed-2/mail-lists.html

n    Liferay Portal

Home page: http://www.liferay.com/home/index.jsp

Documentation: http://www.liferay.com/documentation/architecture/index.jsp

Community: http://forums.liferay.com/

n    The Exo Platform

Home page: http://www.exoplatform.org/

Community:http://www.exoplatform.com/portal/faces/public/exo/home/community

n    uPortal

Home page: http://www.uportal.org/

Documentation: http://www.uportal.org/docs.html

Community: http://www.uportal.org/getinv.html

n    Gridsphere

Home page: http://www.gridsphere.org/gridsphere/gridsphere

Documentation:http://www.gridsphere.org/gridsphere/gridsphere?cid=docs

Fortunately, finally we found that as an excellent open source portal solution, Liferay can fulfill most of our requirements (sounds like an advertisement, but it’s the truth). Liferay is the “world's leading portal and social collaboration software” and InfoWorld calls the “Best Open Source Portal” on the market. An aggregation of features makes it different from other portals:

  • Out-of-the-box Tools: Liferay Portal provides more out of the box portlets than any other portal on the market—Choose from over 60 to customize work environment.
  • Single-Click Configuration: A fast, responsive interface makes Liferay Portal extremely easy and enjoyable to use for everyone in an organization. Typically time-consuming tasks such as altering a page layout, adding new applications and content, and changing look and feel can all be done in a couple of clicks without ever refreshing the page.
  • Secure Single Sign-On (SSO): Aggregate and access content and applications in one place. Liferay Portal can pull all different systems together and make them available by logging in just once via the secure SSO.
  • SOA Framework: Liferay Portal is developed using an open SOA strategy that makes it the choice of enterprises worldwide for enterprise application integration. Integrate users’ existing HR, Accounting or Sales systems and any other sources of important data.
  • Granular, Role-Based Authorizations: To ensure that the right people control the right information, portal administrators can assign individual users or groups of users different "roles" that grant varying levels of access and editing rights to specific communities, files, applications and tools. For example, a "Sales Director" can view and edit all sales documents but a "Sales Assistant" can only view them.
  • Communities & Organizations: Liferay users can be intuitively grouped into a hierarchy of "organizations" or cross-organizational "communities," providing flexibility and ease of administration.
  • Dynamic Drag & Drop: Liferay Portal was the first portal to offer this feature, allowing users to move different elements around in the portal by simply dragging and dropping them into place.
  • Personal User Pages: All users get a personal space that can be made public (published as a website with a unique friendly URL) or kept private. Users can customize how the space looks, what tools and applications are included, what goes into the document library and who can see and access it all.
  • Multi-language Support: International or multi-lingual organizations get out of the box support for 22 languages. Users can toggle between different language settings with just one click. You can also easily add other languages.
  • Multiple bundles of installers: Liferay supports many different combinations of applications, databases and operating systems. Runs on all major application servers & servlet containers, databases, and operating systems with over 700 deployment combinations .Users can download their own special bundle of installer.

In the next section we’ll build the platform with helps of these features of Liferay by describing a system’s architecture in detail.

4 Platform construction and architecture

4.1 Platform construction

After analyzing user requirements in the institute, we get relationships between business system and internal systems. For example, Department of Chief Engineer Office and Information Center mainly use Portal Administration System and it was constituted by internal systems named SystemMan and ProjectMan, corresponding user roles are chief engineer, vice chief engineer, chief of engineer, team leader and engineer in information center. Detailed information is described in table 5.

Table 5 Relationships between business systems and internal systems

No.

Business System

Department

Roles

Internal Systems

1

Portal Administration System

Chief Engineer Office

chief engineer

vice chief engineer

SystemMan

ProjectMan

2

Portal Administration System

Information Center

chief of engineer

team leader

engineer

SystemMan

3

General Design System

General Design Office

chief of engineer

team leader

design expert

engineer

Workflow

DataMan

System4

System5

System6

4

Structure Design System

Structure Design Office

chief of engineer

team leader

engineer

Workflow

DataMan

System5

System6

5

Strength Analysis

System

Strength Analysis Office

chief of engineer

team leader

engineer

Workflow

DataMan

System7

System8

6

 

……

……

 

We can see form table 5 that one department is corresponding to a business system and it’s constituted by several internal systems like Workflow and DataMan etc. One group of role can has the specific view of internal systems, we use the “Community” in Liferay to form business systems, and each tab in top of the general page is corresponding to an internal system or module.

4.2 System architecture

The whole architecture is described by the figure bellow. As we see in the platform architecture, portal framework (Liferay Portal) is the core module of the system. Basic functionally such as portal management (platform management), theme setting, layout modification, single sign on, portlets and adapters are provided by Liferay or by self-development.

Figure 1 System architecture

We will describe the platform in detail by explaining each module in the architecture, four big parts relate to the platform are as follows:

  • External Systems: Systems such as PDM (Product Management System) and CRM (Customer Relationship Management) are classified as the external systems, these system have the business relationships with the R&D platform.
  • Enterprise Integration Framework (EIF): EIF is the central bus integrates all the systems in the institute.
  • R&D Platform: Core part of the whole system, we’ll fatherly explain it later on.
  • Lightweight Directory Access Protocol (LDAP): It’s an application protocol for querying and modifying directory services running over in the whole institute. Uniform user information like user ID, password and E-mail address are all rooted in LDAP.

We’ll introduce there key modules in the platform, those are Portal Framework, CAS Server and Internal Software systems.

4.2.1 Portal Framework

Liferay Portal has been adopted as our Portal Framework solution. In order to realize platform’s functions, basic portlets and function modules of Liferay were used to make the portal more useful, stable and flexible, see the below correspondent table:

Table 6 Correspondent of platform and Liferay

Functions of the platform

Modules or portlets of Liferay

Portal management

System admin

Admin

portlet

Enterprise Admin

portlet

Location Admin

portlet

Organization Admin

portlet

Plugin Installer

portlet

Tags Admin

portlet

Update Manager

portlet

Theme setting

Theme Management

Basic Function

Layout setting

Layout Management

Basic Function

Collaboration

Calendar

portlet

Chat

portlet

Mail

portlet

Message Boards

portlet

Adapters

Single sign on

Single Sign-on

portlet

LDAP

Enterprise Admin

portlet

User information synchronization

Self-developed

Portlets

(for personal workbench)

My Task Guide

Self-developed

Task Summary

Self-developed

My Data

Self-developed

Software List

Self-developed

……

Self-developed

As we see from the table above, some functionalities of the platform are based on Liferay’s Portlets or basic function modules, while other functions like “User information synchronization” and “Task Summary” should be developed by ourselves based on Liferay’s develop environment.

4.2.2 CAS Server

Single sign-on is a method of access control that enables a user to log in once and gain access to the resources of multiple software systems in the platform without being prompted to log in again. CAS is an authentication system originally created by Yale University to provide a trusted way for an application to authenticate a user. By integrating Liferay Portal with CAS Server, the platform can easily realize single sign on (SSO) between Liferay and existing web applications (software systems).

4.2.3 Internal Software systems

We can get form table 2 that all the internal software systems are web-based systems based on different architectures and were developed by using various technologies. Two high lights should be taking into account by integrating these somerous systems:

  • The CAS provides a wide range of clients for different architectures, including ASP.NET, ASP, PHP and spring. This functionality can strongly supports SSO for different web applications.
  • When referring to personal workbench, because of this somerous reasons, web services method should be used for portlets development and deployment.

5 Main works

Our main works in the project focus on integration of all the systems involved, single sign-on from portal, the uniform theme and layout, setting of personal workbench etc. Detailed information is described as follows.

5.1 Single Sign-On Setting

5.1.1 Architecture

Figure 2 SSO integration of the platform

5.1.2 Process

(1) Setting up CAS server

We will begin with setting up JA-SIG CAS server on the application server (For example: Tomcat 5.x.x.) Drop the cas-web.war file into Tomcat's webapps dir. We'll need to edit the server.xml file in tomcat and uncomment the SSL section to open up port 8443.

<!-- Define a SSL HTTP/1.1 Connector on port 8443 -->

 <Connector port="8443" maxHttpHeaderSize="8192"

 maxThreads="150" minSpareThreads="25" maxSpareThreads="75"

 enableLookups="false" disableUploadTimeout="true"

 acceptCount="100" scheme="https" secure="true"

 clientAuth="false" sslProtocol="TLS" />

(2) Generate the SSL cert with Java keytool

We use the follow three command lines to generate SSL and import/export certificate files.

keytool -genkey -alias tomcat -keystore c:\.keystore  -dname "CN=localhost, OU=localhost, O=localhost, L=SH, ST=SH, C=CN" -keypass changeit -storepass changeit

 

keytool -export -trustcacerts -alias tomcat -keystore c:\.keystore -file c:\mycerts.cer -storepass changeit

 

keytool -import -trustcacerts -alias tomcat -keystore "%J**A_HOME%/JRE/LIB/SECURITY/CACERTS" -file c:\mycerts.cer -storepass changeit

After importing the cert into Java's keystore, web.xml file in CAS Server conf folder should be set to fit the cert. Detailed segment of web.xml file as follows:

<Connector port="8443" keystorePass="changeit" keystoreFile=" c:\.keystore "

maxThreads="150" minSpareThreads="25" maxSpareThreads="75"

enableLookups="false" disableUploadTimeout="true"

acceptCount="100" debug="0" scheme="https" secure="true"

clientAuth="false" sslProtocol="TLS" />

Readers can get further information by visiting address: http://www.liferay.com/web/guest/community/wiki/-/wiki/Main/Single+SignOn+-+Integrating+Liferay+With+CAS+Server

(3) Setting up Liferay Portal

In Liferay version 5.1 we can easily add bellow information segment in the Liferay “webapps\ROOT\WEB-INF\classes” portal-ext.properties. Liferay can automatically reload this   CAS configuration information when startup. The “server_name” is machine name where CAS Server was installed.

## cas config

cas.auth.enabled=true

company.security.auth.type=userId

cas.login.url=https://server_name:8443/cas/login

cas.logout.url=https:// server_name:8443/cas/logout

cas.service.url=http:// server_name:8080/c/portal/login

cas.validate.url=https:// server_name:8443/cas/proxyValidate

(4) Setting up the CAS client

Internal systems such as workflow and dataman are all CAS clients, because each system has specific technology architecture, so we need different methods to realize SSO by CAS for each system. In this part we use system “workflow” for example to illustrate how it is integrated with the CAS server. As we know, it was developed by using “Struts+spring+hibernate” architecture and adopt Oracle as the Database system and JBOSS as the application server. The detailed process is as follows:

              1) Add path filter for CAS

Add bellow information segment to workflow web.xml file in “webapps\ROOT\WEB-INF\”folder. The “server_name” is CAS server’s name, “client_name” is the machine name where workflow is running and port is the application’s port. The url-pattern “/*” represent all the path in the program will be filtered by CAS.

<filter>

              <filter-name>cas-filter</filter-name>

              <filter-class>cas.CASFilter</filter-class>

              <init-param>

                     <param-name>

                            edu.yale.its.tp.cas.client.filter.loginUrl

                     </param-name>

                     <param-value>

                            https:// server_name:8443/cas/login

                     </param-value>

              </init-param>

              <init-param>

                     <param-name>

                            edu.yale.its.tp.cas.client.filter.validateUrl

                     </param-name>

                     <param-value>

                            https://server_name:8443/cas/serviceValidate

                     </param-value>

              </init-param>

              <init-param>

                     <param-name>

                            edu.yale.its.tp.cas.client.filter.serverName

                     </param-name>

                     <param-value>client_name:port</param-value>

              </init-param>

       </filter>

       <filter-mapping>

              <filter-name>cas-filter</filter-name>

              <url-pattern>/*</url-pattern>

       </filter-mapping>

              2) Modify the login module of workflow

Find out the loginAction in workflow system and then modify the loginId(login account) formally getting from the loginForm in login.jsp to getting form CASFILTER:

HttpSession session = this.getSession();

loginId = (String) session.getAttribute(CASFilter.CAS_FILTER_USER);

Commonly it’s no longer need not to validate user password by using CAS in the client side program.

3) Import cert for client

If CAS sever and workflow server are not in the same machine, the cert file (mycerts.cer) generated in the CAS server has to be exported to the client side. We can use the bellow command line to realize this functionality.

keytool -import -trustcacerts -alias tomcat -keystore "%J**A_HOME%/JRE/LIB/SECURITY/CACERTS" -file c:\mycerts.cer -storepass changeit

4) Add casclient-2.1.1.jar

Drop the casclient-2.1.1.jar to folder “/WEB-INFO/lib” in workflow system.

For other kinds of client such as phpCAS and ASP.NET, readers can get more detailed   information from: http://www.jasig.org/cas/client-integration/other-clients

5.2 Portlets development

Liferay provides two methods to develop portlets: plug-ins and ext environment method. In this section we mainly illustrate how to develop a “software list” portlet by using plug-in method.

5.2.1 Description of “software list” portlet

 “Software list” is a portlet that can display software’s information in the personal workbench of the platform. Users have the authority can view the software list and check out the detailed information of a specific item. All these software information resources come from software management system. Table 5 shows in the software information list in detail.

Table 7 Software information list

No.

Item

Data Type

Description

1

softwareId

String

Unique identifier

2

softwareName

String

 

3

softwareType

String

 

4

softwareVersion

String

 

5

totalLicenseNo

Integer

Total number of Licenses that a software can assign

6

currentLicenseNo

Integer

Current number of Licenses that a software can assign

5.2.2 Method and Process to develop the portlet

In order to lower the degree of coupling, we develop the program interface based on SOA model. Bellow figure shows how we develop and integrate portlets based on web services method.


Figure 3 Portlets develop and deployment method based on SOA

In the server side (Workflow, DataMan and SoftwareMan system etc.), we develop the web services based on the standard interface, these web services are provided by wsdl format. In the client side these service should be invoked and packaged to a portlet.

Bellow shows a common process to develop and deploy a portlet by using “software list” as an example.

(1) Setting develop and deploy environment

The Plugins SDK is a simple environment for the development of Liferay hot deployable plugins portlet, theme and layout. Because plugins can be added which enhance its functionality for Liferay and portlets, we deiced to use eclipse as the basic develop tool. In this section we will not illustrate the basic steps of how to setting up develop and deploy environment. Any reader takes interested in this part can get information from: http://wiki.liferay.com

(2) Develop web service in the softwareMan system (server side)

Developing web service in the server side according to the pre-defined interface by the help of Xfire.

(3) Invoke web service in Liferay (client side)

We’ll explain how to encapsulate the interface and develop a portlet in this part. Bellow figure shows the protlet skeleton automatically generated with the Plugins SDK.


Figure 4 Portlet skeleton automatically generated with the Plugins SDK

Next step we’ll add codes to this portlet skeleton to realize the functionality of “show software list”. Figure 5 shows the class diagram of the client program.


Figure 5 Class diagram of the client program

(4) Add software list portlet to personal workbench

In develop process, we modify the liferay-display.xml, and change the place where the “software list portlet” displays, bellow codes show the modifications.

<display>

       <category name="category.workbench">

              <portlet id="software_list"></portlet>

       </category>

</display>

After deployment, we can simply drag the portlet to user personal workbench from the slide window on the left. Certainly we can change the layout it displays optionally by the functionality provided by Liferay. See the bellow figure.

Figure 6 Add software list portlet page

5.3 User information synchronization

In order to fulfill the SSO and user management requirement, when adding a new user to Liferay, the same user account must be built in the sub-systems that user can access to. The user information including username, password and Email address etc. We should modify the program based on Liferay and add some user information synchronization adapters to revolve this problem. When adding, deleting, modifying and activing a user in the portal, program synchronously invoke the operations in the web service provided by the related internal system. See the directory structure and class diagram respective in figure 7 and figure 8.


Figure 7 Directory structure of the information synchronization program


Figure 8 Class diagram the User information synchronization program

Description:

  • Class: EditUserAction:Realize the functionality of Add a user to the portal;
  • Class: SynchronizedUser:Mainly finish the work of invoke the operations in web service client;
  • Class: Dom4jXml:Class reading the configuration files;
  • Class: SynchronizedUserClient:Generated according to the webservice URL in the configuration file;
  • Class: Implement of SynchronizedUserPortType;
  • Interface: SynchronizedUserPortType:Webservice interface provided by the internal system.

5.4 Theme modification

Thanks to Liferay’s theme strategy that majority of the themed elements share properties, making the styling process very quickly. Developing and deploying a theme by using the Plugins SDK and ViewDesigner Dreamweaver Plugin is as easily as writing “ABC”. And also, we can set each business system has a theme of each own. Bellow figure shows several themes we have developed for the platform.


Figure 9 Themes available in the portal

5.5 Portal optimization

5.5.1 “Dieting” of Portal

The propose of “dieting” the portal is clipping some unnecessary components and services and reserve some basic and essential ones, which can make the system more slim and faster.

(1) Reserve basic components of Liferay

Liferay provides some basic components, theses components do not belong to the whole portal framework, but the portal services are based on these components. Table 8 shows the basic components should be reserved in Liferay.

 

Table 8 Basic components should be reserved in Liferay

Structure of package

Description

com.liferay.counter

Provides primary key operation services

com.liferay.filters

Provides basic filters based on servlet filter

com.liferay.taglib

Provides basic web display labels

com.liferay.util

Provides some public components

com.liferay.wsrp

Provides web services

(2) Reserve basic services of Liferay

Basic services of Liferay are based on com.liferay.portal, sub packages in this package should all be reserved. See detailed information in the Table bellow:

Table 9 Basic services

Structure of package

Description

com.liferay.portal

Some exceptions relate to portal services

com.liferay.portal.action

In charge of struts action processing

com.liferay.portal.definitions

Provides some DTD file resources definition

com.liferay.portal.dependencies

In charge of some reliant resource files

com.liferay.portal.deploy

In charge of auto deploy and hot deploy

com.liferay.portal.events

Provides action processing classes

com.liferay.portal.jcr

Provides supports for JSR-170 JCR, realizes the Jackrabbit

com.liferay.portal.language

Language package

com.liferay.portal.lucene

Full text support

com.liferay.portal.model

Aggregation of some model objects

com.liferay.portal.security

 

com.liferay.portal.servlet

 

com.liferay.portal.spring

 

com.liferay.portal.struts

 

com.liferay.portal.theme

Provides supports for theme style

com.liferay.portal.tools

 

com.liferay.portal.util

 

com.liferay.portal.velocity

 

com.liferay.portal.wsrp

 

(3) Keep down unnecessary portlet appellations

Liferay provides a mass of in-house portlets, these portlets waste lots of resources and make the speed of startup slower. In fact, to ensure system’s normal running, only a few basic portlets are essential, the rest unnecessary ones can be kept down. Table 10 shows the Basic portlets that should be reserved.

Table 10 Basic portlets that should be reserved

Structure of package

Description

com.liferay.portlet

Basic classes Liferay Portlets

com.liferay.portlet.admin

Manage the portlets

com.liferay.portlet.communities

One of the most important portlets for portal

com.liferay.portlet.enterpriseadmin

 

com.liferay.portlet.language

 

com.liferay.portlet.layoutconfiguration

 

com.liferay.portlet.login

 

com.liferay.portlet.myaccount

For modification of user information

com.liferay.portlet.myplaces

For chosen of user’s personal community

com.liferay.portlet.portletconfiguration

 

com.liferay.portlet.themegallery

For change of themes

com.liferay.portlet.translator

Necessary portlet for internalization

com.liferay.portlet.wsrp

 

We’ll not go thorough the detail process of keeping down those unnecessary portlet appellations, users can take a little time to handle this issue.

(4) Keep down unnecessary portlet deployments in the configuration files

 This work focus on modifying files like portlet.xml, liferay-portlet.xml and liferay-display.xml, what we only need to do is delete portlet information in these files.

(5) Modify server configuration files

Get detailed information in the bellow table.

Table 11 Server configuration files

Structure of package

Description

/WEB-INF

Portlet description and struts configuration files

/WEB-INF/classes

system-ext.properties

portal-ext.properties

/WEB-INF/classes/META-INF

portal-spring.xml

portal-hbm.xml

portal-log4j.xml

The files “system-ext.properties” and “portal-ext.properties” are core and useful configuration files in Liferay. We can find lots of portal settings like “Single Sign-on”, “Look and Feel”, “Preferences” and “LDP” in these files. Readers can get detailed information by visiting web address:http://www.liferay.com/web/guest/community/wiki/-/wiki/Main/Portal%20Properties

5.5.2 Performance optimization

One suggestion to optimize the portal performance is to use good server machine (system memory is big enough), and meanwhile since Liferay loads a lot of jars, more specifically classes, another useful suggestion is to increase the amount of memory in startup options for Liferay server, we can change it in windows/tomcat: “catalina.bat” file. A MaxPermSize of 128m is recommended. It's also good practice to up the maximum heap size to 1024m (-Xmx1024). We can configure the file as the following JVM options control memory usage in Java:

--Xms128m (default) --Xmx512m (default)--XX:MaxPermSize=128m

6 Simple system demonstration

In this section we’ll give a simple scene of how the users login and use the platform. Three kinds of users will take part in the demonstration. See the detailed information in bellow table.

Table 12 Three kinds of users related to demonstration

No.

UserId

Business System

Roles

Internal Systems

1

Mike

Portal Administration System

chief engineer

SystemMan

2

Russ

Structure Design System

chief of engineer

Workflow

DataMan

SoftwareMan

SystemMan

3

John

Structure Design System

engineer

Workflow

DataMan

SoftwareMan

6.1 Mike constructs the Structure Design system

(1) Mike logins the Portal Administration System as the super administrator


Figure 10 Mike logins the Portal Administration System

(2) Mike’s Personal Workbench (default as Integration Management)


Figure 11 Mike’s Personal Workbench

(3) Adds a new business system: Structure Design System


Figure 12 Adds a new business system

(4) Assigns users to the Structure Design System


Figure 13 Assigns users

(5) Assigns system roles to users


Figure 14 Assigns system roles to users

6.2 Russ manages the Structure Design System

(1) Russ logins as the administrator of the Structure Design System


Figure 15 Russ logins the Structure Design System

(2) Russ sets theme for the structure design system


Figure 16 Sets theme for the structure design system

 (3) Edits pages for the Structure Design System


Figure 17 Edits pages for the Structure Design System

(4) Russ adds page component “DataMan” for the system


Figure 18 Adds page component “DataMan” for the system

6.3 John works in the Structure Design System

(1) John logins the Structure Design System


Figure 19 John logins the Structure Design System

(2) John’s default personal workbench, including personal task list, software list and template list, for some security reasons, we delete some detailed information in the page.


Figure 20 John’s personal workbench

(3) John works in the DataMan system environment.


Figure 21 DataMan system environment

(4) John works in the SoftwareMan system environment.

 

Figure 22 SoftwareMan system environment

 

7 Summary

Liferay is a very excellent open source portal product with stable infrastructure, flexible drag and drop operation method, multiple in-house applications and extensible programming functionalities which make it suitable for the basic portal framework of an enterprise’s R&D platform. This paper introduces Liferay to build a R&D platform in an institute and illustrates some main technical things in the integration process and gives a simple system demonstration of the R&D platform in the sixth part of the paper.

References

1. http://www.liferay.com/web/guest/community/wiki

2. http://hi.baidu.com/supersi%5Fpumc

3. http://www.jasig.org/cas/client-integration/other-clients

 

注:上文是本人在2009年写的一篇如何应用关于开源的Portal系统Liferay产品作为门户解决方案搭建企业的协同研发平台的技术文章。现在Liferay的版本已经升级到更高的版本,但是基本的思路和构建方法并没有改变,希望能对一些人有所帮助。另本文的pdf格式文档可以发邮件给我索取,地址是yak1982@126.com

发表于: 2011-09-07 09:32 阅读(5415) 评论(2) 收藏 好文推荐

本博客所有内容,若无特殊声明,皆为博主原创作品,未经博主授权,任何人不得复制、转载、摘编等任何方式进行使用和传播。

作者该类其他博文:

# re: Construction of a R&D platform based on Liferay
2011-09-07 10:50 | 【匿名用户】:E-works热心网友 | 1楼
哈哈,全英文的您太厉害了,可是我还是有些看不懂。
# re: Construction of a R&D platform based on Liferay
2011-09-07 11:06 | 朝阳陆 | 2楼
如果有需要可以和我邮件交流,呵呵,当时是为了和Liferay公司的人做交流写了一篇英文的。

发表评论(网友发言只代表个人观点,不代表本网站观点或立场。)

您尚未登录,请先【登录或注册