Nayan Ambali

Two simple hacks for Weebly to get two pro features at free

2010-06-27T05:17:00.000-07:00

Want to remove this from footer

Click on Design - Edit HTML / CSS and add below script after body end tag

&gt script type="text/javascript" &lt

document.getElementById('footer-contents').style.visibility = 'hidden';
&gt /script &lt

Want to have Favicon to your site

Generate Favicon using http://www.favicon.cc/

Go to Design - Click Files - upload Favicon and get the path of the file - Click HTML and below lines

&gt link rel="shortcut icon" href="/uploads/5/5/5/5/7592/custom_themes/919/files/favicon.ico" type="image/x-icon" /&lt

Meeting with Matt Duncan, Director of Market Development MIFOS

2010-03-18T06:05:00.000-07:00

13 March 2010 morning 11 am, got call from Matt, he said "we are in 10th main, and I will pass the mobile to driver's hand", I asked driver do you know Kannada, he said yes, I replied him saying "innu swalpa munde banni [come little bit further...]"

11.00Am ...
[Matt Duncan] I am Matt,
[Nayan]: 'Nayan :)', and we stepped into 2nd floor, our "Hackers Garage"
[Matt Duncan] :After looking into office " Cool place .. !!"
[Nayan] : Introduced Ashok to Matt, started with our teams future plans and present work, that is Customizing MIFOS for Nirantara and modifying MIFOS for multi-tenant SaaS architecture
[Matt Duncan] :How did you got Nirantara requirements ?
[Nayan] : I had visited Niratara, and understood their operations, field work and backend office work. And also looked into present MIS.
[Matt Duncan] : Why Nirantara is moving to MIFOS from present MIS
[Nayan]: Standalone , ownership cost for each branch office , branch office data consolidation.
[Matt Duncan]: It is very tedious to consolidate data from branches !! , Ketan stepped into office, had introduction with Ketan(was working on Data mapping). And dicussed with Ketan on data mapping activity. And suggested that need to cut down Migration activity time.
[Nayan]: We have developed MS-XL utility for data migration
[Matt Duncan]: Cool !! Do you expect any help from our side.
[Ashok]: MIfos release plans and stable code to be made available
[Nayan]: And standers collaborative platform for all Mifos developer across the world, and to avoid redundant work !! And Updated user manuals before new version is launched
[Viswas]: Joined us bit late, and introduce himself to Matt
[Matt Duncan]: Sure.. We are doing ..
[Nayan]: Showed our Mifos customization, Organization announcements, ToDo , Today's activity , performance index, Today's repayment and disbursement dashboard.

1.00 PM ...
[Matt Duncan]: Do you have any thing more to show in computer
[Nayan]: We do not anything more ..!!
[Matt Duncan]: I will buy a lunch for all of you lets go !
[Ketan]: Sip and Dine will be good place have lunch, all moved to ..
[Matt Duncan]: Can we have detailed introduction.
[Ashok]: Talked about his education and work and some talk about cloud and open source !!
[Ketan]: How to connect skilled labors from rural India to market and how MFI can play a role in this.
[Matt Duncan]: I agree, it is great. And if MFI start marketing who will own the risk ? ....
[Matt Duncan]: Shared his experience in CHINA, about having dinner with community, and most of the you do not get know what they are talking, but need to respond to it . :) :)
And Chinese guys carry highend mobiles and women to have mobile phones but not high end
[Matt Duncan]: And talked about Philippines SHG/MFI and mobile trends in Philippines.
was telling out 25 women group 20 to 22 were having mobile phone.
And explained about how one of the MFI adopted Mifos hosted on EC2. And also explained about Mifos hosted service.

Same time had cool lunch .. (I hope Matt liked Indian breads and veg side dish)

Matt dropped us back to Office, And took foto of us (hope he will share those pics with us :)

Liferay - SOA in Three Steps

2009-04-30T22:05:00.000-07:00

The Liferay portal comes packaged with a powerful tool known as ServiceBuilder to helps developers quickly implement a Service-Oriented Architecture (SOA). Most technologies needed for SOA (Web Services, Spring, Hibernate, etc.) require a tremendous amount of files to be written and configured. For any developer, this can quickly become tedious and nurture an environment of copy-and-paste purgatory.

Liferay's ServiceBuilder automates most of this so that you, the developer, can focus your energy on your project's business logic. It only takes three steps to implement a powerful SOA in Liferay.

1. Define a Data Model

All you need to do is write an XML file called service.xml, based on a DTD provided by Liferay. The file should specify all necessary fields, keys and finder methods. Run ServiceBuilder using Ant, and you are done!

Over a dozen files were generated for you for each table you specified. This includes the following types of files:

Spring configuration files and Stubbed Remote/Local service classes
SOAP and Tunnel classes; WSDL files and Javascript Web Services methods
Data Model classes
Hibernate classes and configuration files
SQL create and index scripts

2. Declare Business Methods

Empty Remote and Local service classes have been stubbed out for your by ServiceBuilder. All you have to do is declare the methods you want and run the ServiceBuilder task in Ant again, and you are done!

Any business methods declared in the Remote service classes will be propagated into the SOAP and Tunnel classes, WSDL files and added into the list of Javascript Web Services methods. Like the definition of the data model, any subsequent changes should be followed by a run of the ServiceBuilder and the methods will be appropriately propagated.

3. Implement Business Logic

Like any other J2EE application, the Remote implementation class should do any security and permission checks that you may need; the Local implementation class should contain the business logic that you allow trusted sources to invoke. After you are done, compile your code and you now have a SOA!

Liferay's ServiceBuilder has created all the necessary files you need for a Service-Oriented Architecture. Rather than hours and hours of tedious copy and pasting, the ServiceBuilder automates all of this in a matter of seconds. You can now spend all that time saved on the place where your expertise should be focused: on the business logic.

Liferay - Hope of Ray for Open Source Enterprise portal

2009-04-25T22:05:00.000-07:00

Liferay is designed to deploy portlets that adhere to the Portlet API (JSR-168 / 286). Many useful portlets are bundled with the portal (Mail, Document Library, Team Calendar, Social Office , Wikis , Blogs , Activity tracking , Message Boards, to name a few) and can be used as examples for adding your own custom portlets.

Over View of Architecture

Users can access the portal from traditional and wireless devices. Developers can access the portal from the exposed APIs via SOAP, RMI, and our custom tunneling classes

Portlet API (JSR-168 , JSR - 286)

JSR 168's goals are the following:

Define the runtime environment, or the portlet container, for portlets
Define the API between portlet container and portlets
Provide mechanisms to store transient and persistent data for portlets
Provide a mechanism that allows portlets to include servlets and JSP (JavaServer Pages)
Define a packaging of portlets to allow easy deployment
Allow binary portlet portability among JSR 168 portals
Run JSR 168 portlets as remote portlets using the Web Services for Remote Portlets (WSRP) protocol

Struts and Tiles

All HTTP and WAP requests go through MainServlet which extends the basic Struts ActionServlet. MainServlet processes all requests and ensures that each request is routed to the proper PortletAction. Refer to Struts for a better understanding of how the portal's web framework functions.

Layout information for the portal is managed with customizable templates. Refer to articles about Tiles to get a better understanding of how Tiles works as a layout manager.

Session EJBs, Spring, and Hibernate

Liferay is no longer dependent on EJBs and can be deployed on a standalone servlet container. All business logic is concentrated inside POJO implementations that are looked up and instantiated by Spring. These implementations can be modified or enhanced via Spring's AOP and IOC capabilities.

The enterprise release of the portal wraps the POJO implementations with Session EJBs to provide heavy scaling and transaction support required by large sites. The professional release of the portal calls the POJO implementations directly to provide a light weight facade.

All data is persisted using Hibernate and is called through the POJO implementations. Liferay used to rely on CMP technology to achieve persistence, but switched over to Hibernate because of its raw speed and flexibility. Liferay is database agnostic and can run on a variety of popular databases.

Liferay uses JAAS Web security so that when a user logs in, their principal is propogated to the Servlet and EJB tiers. Remote Session EJBs can take advantage of this by checking security and permissions at the EJB level so it does not have be duplicated else where. Local Session EJBs exposes business logic to other Session EJBs and does not specifically check for security since they cannot be called remotely. Principals are also propagated to POJO implementations that are the base classes for Remote Session EJBs.

The enterprise release uses Session EJBs which allows the deployer to separate the Web server, EJB server, and database server to achieve clustering at three levels. This is true n-tier deploying because no one is forced to cluster at any single layer and allows the most flexibility for large companies.

Most of our EJBs, HBMs, and Models are generated through the ant task build-service which reads the file service.xml in /portal-ejb. Each portlet that persist data has its own service.xml (do a search in /portal-ejb and you will get a list back). We copy this file to /portal-ejb when we want to generate the persistence classes for that portlet. This is an internal tool that is built on top of the XDoclet engine.

For example, upon reading service.xml found in the Bookmarks portlet, the following model classes are generated. Each model class reflects a table in the database. Never edit BookmarksEntryModel. Do edit BookmarksEntry to add hand massaged code. BookmarksEntry is generated once and extends BookmarksEntryModel. This allows us the ease of generated code and flexibility of hand massaged code.

com.liferay.portlet.bookmarks.model.BookmarksEntry
com.liferay.portlet.bookmarks.model.BookmarksEntryModel
com.liferay.portlet.bookmarks.model.BookmarksFolder
com.liferay.portlet.bookmarks.model.BookmarksFolderModel

Hibernate classes are generated that map to the model classes. This allows for an n-tier architecture for cases where your model classes are marshalled across the wire and your Hibernate classes are not.

com.liferay.portlet.bookmarks.service.persistence.BookmarksEntryHBM
com.liferay.portlet.bookmarks.service.persistence.BookmarksFolderHBM

Persistence methods to add, update, delete, find, remove, and count the Hibernate entries are generated as the default persistence mechaninsm.

com.liferay.portlet.bookmarks.service.persistence.BookmarksEntryPersistence
com.liferay.portlet.bookmarks.service.persistence.BookmarksFolderPersistence

Helper classes are generated that call the persistence methods. By default, the helper classes call the Hibernate persistence methods to update the database. You can override this in portal.properties and set your own persistence class as long as it extends the default persistence class. This means you can customize where you store your data. It can be a traditional database, a LDAP server, or even something else.

com.liferay.portlet.bookmarks.service.persistence.BookmarksEntryUtil
com.liferay.portlet.bookmarks.service.persistence.BookmarksFolderUtil

Pooling classes are also created to minimize object creation. Behavior can be modified in portal.properties.

com.liferay.portlet.bookmarks.service.persistence.BookmarksEntryPool
com.liferay.portlet.bookmarks.service.persistence.BookmarksFolderPool

POJO implementations that extend PrincipalBean are generated to hold business logic that check the caller principal and can be called remotely. Calling getUserId() returns the user id of the current user. Calling getUser() returns the User model that represents the current user. The Session EJB that extends the POJO implementation implements PrincipalSessionBean.

For example, these classes allow you to delete a bookmark entry or folder if and only if you are the creator of that entry or folder.

These classes are only generated once if they do not already exist.

com.liferay.portlet.bookmarks.service.impl.BookmarksEntryServiceImpl
com.liferay.portlet.bookmarks.service.impl.BookmarksFolderServiceImpl

Helper classes are generated based on the POJO implementations. They help save developer time and prevent polluted code. Instead of writing many lines of code just to look up the appropriate Session EJB wrapper or POJO implementation, you simply call BookmarksEntryServiceUtil.addEntry to call the equivalent method in BookmarksEntryServiceImpl.addEntry.

BookmarksEntryServiceUtil calls BookmarksFolderServiceFactory to look up the class that implements BookmarksEntryService. BookmarksFolderServiceFactory defers to Spring and settings in portal.properties on whether to load the Session EJB wrapper or the plain POJO implementation. The Session EJB extends the POJO implementation.

com.liferay.portlet.bookmarks.service.ejb.BookmarksEntryServiceEJB
com.liferay.portlet.bookmarks.service.ejb.BookmarksEntryServiceEJBImpl
com.liferay.portlet.bookmarks.service.ejb.BookmarksEntryServiceHome

com.liferay.portlet.bookmarks.service.spring.BookmarksEntryService
com.liferay.portlet.bookmarks.service.spring.BookmarksEntryServiceFactory
com.liferay.portlet.bookmarks.service.spring.BookmarksEntryServiceUtil

com.liferay.portlet.bookmarks.service.ejb.BookmarksFolderServiceEJB
com.liferay.portlet.bookmarks.service.ejb.BookmarksFolderServiceEJBImpl
com.liferay.portlet.bookmarks.service.ejb.BookmarksFolderServiceHome

com.liferay.portlet.bookmarks.service.spring.BookmarksFolderService
com.liferay.portlet.bookmarks.service.spring.BookmarksFolderServiceFactory
com.liferay.portlet.bookmarks.service.spring.BookmarksFolderServiceUtil

Tunneling classes are generated so that developers can call the POJO implementations over port 80. An example of this given in the section V of this document.

com.liferay.portlet.bookmarks.service.http.BookmarksEntryServiceHttp
com.liferay.portlet.bookmarks.service.http.BookmarksFolderServiceHttp

Soap classes are generated so that developers can call the POJO implementations over port 80. Soap is slower than tunneling because tunneling streams requests in binary format. Soap is more flexible than tunneling because the client classes are not limited to Java.

com.liferay.portlet.bookmarks.service.http.BookmarksEntryServiceSoap
com.liferay.portlet.bookmarks.service.http.BookmarksFolderServiceSoap

POJO implementations classes that do not extend PrincipalBean are generated to hold business logic that do not check the caller principal and can be called locally. These classes exist so that business logic can be easily integrated with other projects.

These classes are only generated once if they do not already exist.

com.liferay.portlet.bookmarks.service.impl.BookmarksEntryLocalServiceImpl
com.liferay.portlet.bookmarks.service.impl.BookmarksFolderLocalServiceImpl

Helper classes are also generated.

com.liferay.portlet.bookmarks.service.ejb.BookmarksEntryLocalServiceEJB
com.liferay.portlet.bookmarks.service.ejb.BookmarksEntryLocalServiceEJBImpl
com.liferay.portlet.bookmarks.service.ejb.BookmarksEntryLocalServiceHome

com.liferay.portlet.bookmarks.service.spring.BookmarksEntryLocalService
com.liferay.portlet.bookmarks.service.spring.BookmarksEntryLocalServiceFactory
com.liferay.portlet.bookmarks.service.spring.BookmarksEntryLocalServiceUtil

com.liferay.portlet.bookmarks.service.ejb.BookmarksFolderLocalServiceEJB
com.liferay.portlet.bookmarks.service.ejb.BookmarksFolderLocalServiceEJBImpl
com.liferay.portlet.bookmarks.service.ejb.BookmarksFolderLocalServiceHome

com.liferay.portlet.bookmarks.service.spring.BookmarksFolderLocalService
com.liferay.portlet.bookmarks.service.spring.BookmarksFolderLocalServiceFactory
com.liferay.portlet.bookmarks.service.spring.BookmarksFolderLocalServiceUtil

Some of our users needed to call the Local Service classes remotely, so Remote Service classes that parallel their Local counterparts are also generated.

com.liferay.portlet.bookmarks.service.ejb.BookmarksEntryRemoteServiceEJB
com.liferay.portlet.bookmarks.service.ejb.BookmarksEntryRemoteServiceEJBImpl
com.liferay.portlet.bookmarks.service.ejb.BookmarksEntryRemoteServiceHome

com.liferay.portlet.bookmarks.service.spring.BookmarksEntryRemoteService
com.liferay.portlet.bookmarks.service.spring.BookmarksEntryRemoteServiceFactory
com.liferay.portlet.bookmarks.service.spring.BookmarksEntryRemoteServiceUtil

com.liferay.portlet.bookmarks.service.ejb.BookmarksFolderRemoteServiceEJB
com.liferay.portlet.bookmarks.service.ejb.BookmarksFolderRemoteServiceEJBImpl
com.liferay.portlet.bookmarks.service.ejb.BookmarksFolderRemoteServiceHome

com.liferay.portlet.bookmarks.service.spring.BookmarksFolderRemoteService
com.liferay.portlet.bookmarks.service.spring.BookmarksFolderRemoteServiceFactory
com.liferay.portlet.bookmarks.service.spring.BookmarksFolderRemoteServiceUtil

A lot of people stay away from Session EJBs because they are heavy and require a lot of coding. Our build scripts show that you can leverage the advantages of Session EJBs while minimizing repetitive labor so that you can strike a good balance between effort and results.

Spring gives Liferay additional flexibility. Developers can test their POJO implementations with Liferay Portal Professional in a servlet container and deploy to production with Liferay Portal Enterprise in an application server.

SOAP, RMI, and Tunneling

All of our remote POJO implementations are exposed to the external world via SOAP, RMI, and our custom tunneling classes.

We do not do this simply because Web services is a buzz word, but because we find it extremely useful for integration. The following is an example of a company that leverages these resources.

3sixteen is a t-shirt company that needed to get up and running fast. In the fashion industry that relies on cutting-edge appearance and presentation, 3sixteen needed to keep its Flash MX front-end "brochure" website that would not be used to sell clothing but to offer an experience through the music, graphics, and articles. Due to the static nature of Flash, the brochure site was not an e-commerce solution because products would need to be added, removed, and updated on a constant basis. To solve this problem, they decided to separate their web presence into two sites: a brochure site and shopping site.

www.3sixteen.com became the graphic oriented site built in Flash and my.3sixteen.com became the shopping site using the vanilla Liferay distribution. These two sites are hosted on two different Linux machines, and for all intents and purposes could have resided on different continents.

They also needed to build a mailing list to collect email addresses for all their interested customers. To accomplish this, they added a JSP pop up box on their Flash site that would tell the portal server to add the email address to a contact in the Address Book portlet.

The following is a JSP snippet that shows how the guys at 3sixteen leveraged ABContactServiceHttp to add a contact.

String URL = "http://my.3sixteen.com";

HttpPrincipal httpPrincipal = new HttpPrincipal(URL, "joe_bloggs", "password");

ABContactServiceHttp.addContact(httpPrincipal, firstName, lastName, emailAddress);

ABContactServiceHttp invoked addContact in ABContactServiceUtil. The invocation was sent over port 80 and received by http://my.3sixteen.com/tunnel/servlet/AuthTunnelServlet. The application server made sure the authentication matched and then processed ABContactServiceUtil as if the user with the id joe_bloggs was calling addContact. ABContactServiceUtil then called ABContactServiceImpl to do the actual work. You can trace the logic of this by viewing the source included in the generated JavaDocs.

Now Joe Bloggs can log into the portal and look in his Address Book portlet to see that he has a new contact. All of the included portlets have this capability because these helper classses are generated. This means you can write applets or any other Java application to access the Session EJBs that contain your business logic. This can be a security hazard if someone had your password, so you can configure to limit the Tunnel Servlet to only listen on certain ports by editing portal.properties.

You can also access the Session EJBs over SOAP and RMI. We will post more examples of that shortly.

Application Service Provider

Liferay was built from the ground up to be used by application service providers. The following is a sample list of portals running off of one portal instance hitting one database and shows the capabilities of Liferay.

http://demo.liferay.net
http://my.ccuc.net
http://www.gatewayfriends.org
http://www.hope-harvest.org

Users in each of these portals have no information about the other portals. They are separated by domain and each portal exists in its own space based on the company's id.

See Multiple Portals for detailed informaton on how to set up multiple instances of Liferay on one machine.