Sunday, December 25, 2011
Liferay Portal: Thoughts on ServiceBuilder
There are a few opportunities for improvement in the functionality of ServiceBuilder. Below are my thoughts...
1. Liferay does a good job in making itself manageable, but could take a further step in leveraging JMX to create additional visibility. Generally speaking, when you create a custom service, you may want to expose metrics such as uptime, number of invocations, etc. It should be relatively straightforward for ServiceBuilder to also create a JMX MBean that provides visibility into service operations.
Whenever a service is started, it could automatically register itself with the MBeanServer. Alternatively, you may want your MBeans to be available as soon as you deploy your application, listen for notifications from the deployment service.
2. Many enterprises want to increase the testability of applications they put into production and will naturally gravitate towards tools such as JUnit. Since Liferay creates services that can be exposed via SOAP and JSON, there is an equal opportunity to automate the creation of unit tests for these invocation methods. The ability to test JSON APIs may be best accomplished by using the JUnit extension known as HTTPUnit.
3. Liferay needs a better way to handle subtypes. A supertype/subtype design requires that some attributes be stored in the supertype, and some be stored in the subtype. The attributes for each thing in the real world are split between two tables/entities. This may be useful in a variety of scenarios where you need to store different typed attributes for a given population.
One example that comes to mind is for storing information about different types of users. Imagine a role-based portal where you have agents, employees and consumers all using the same resource. An agent may have a unique industry-provided identifier such as a professional license. An employee may have an employee ID and so on. A service that understands these relationships would be very powerful...
| | View blog reactions1. Liferay does a good job in making itself manageable, but could take a further step in leveraging JMX to create additional visibility. Generally speaking, when you create a custom service, you may want to expose metrics such as uptime, number of invocations, etc. It should be relatively straightforward for ServiceBuilder to also create a JMX MBean that provides visibility into service operations.
Whenever a service is started, it could automatically register itself with the MBeanServer. Alternatively, you may want your MBeans to be available as soon as you deploy your application, listen for notifications from the deployment service.
2. Many enterprises want to increase the testability of applications they put into production and will naturally gravitate towards tools such as JUnit. Since Liferay creates services that can be exposed via SOAP and JSON, there is an equal opportunity to automate the creation of unit tests for these invocation methods. The ability to test JSON APIs may be best accomplished by using the JUnit extension known as HTTPUnit.
3. Liferay needs a better way to handle subtypes. A supertype/subtype design requires that some attributes be stored in the supertype, and some be stored in the subtype. The attributes for each thing in the real world are split between two tables/entities. This may be useful in a variety of scenarios where you need to store different typed attributes for a given population.
One example that comes to mind is for storing information about different types of users. Imagine a role-based portal where you have agents, employees and consumers all using the same resource. An agent may have a unique industry-provided identifier such as a professional license. An employee may have an employee ID and so on. A service that understands these relationships would be very powerful...
