Hitoshi Ozawa:
That's why I recommend putting all business logic in an external application server instead of Liferay. The only problem is with the workflow.
Hi Hitoshi,
We have decided to develop several portlets with the following architecture in mind:
* presentation layer: vaadin framework; MVP/MVVM pattern
* business layer:
- business objects containing all business logic, backed by JPA persistence
- services as workflows of operations on business objects, responding to use cases or steps in a business process
- workflow framework (Activiti) in order to model some corporative business processes involving different roles and tasks
* persistence: JPA
After some google and forum research it seems to be not very easy to accomodate this into liferay: problems accessing same business logic (other than service builder provided) from different portlets, classloader issues, spring contexts...
Maybe we have missed something here (any enlightenment welcome) but as you recommended putting all business logic in an external application server... could you give us a brief description or tip about such a deployment??
To put it all on the table, our business objects/custom services might be used together with some liferay builtin services in the same workflow, and maybe we'll have to access our services within a velocity template called by web content display/asset publisher portlet.
We are using the tomcat bundle (6.1 GA2)... any issue with a liferay cluster deployment if we need more resources in the future?
(For the tempted reader... please, solutions in the direction of "don't do that! try service builder instead"... or the like, are not solutions to us...
)Thanks in advance!
ignacio garcia:
(For the tempted reader... please, solutions in the direction of "don't do that! try service builder instead"... or the like, are not solutions to us...
Sorry, couldn't help myself, but...
Here's the deal. When you deploy portlets in separate wars, they suffer from the same issues you have using separate servlets in separate wars. The application containers are designed to separate the separate wars from each other entirely, and for good reason. It ensures that some other servlet does not tinker with objects defined within your servlet. So they have separate class loaders, and more or less virtual walls between them.
The portal, on the other hand, does not like all of that separation. In a portal, there is a need to share beans, services, data, etc. We don't like to think of portlets as islands unto themselves, they are part of an overall system that we expect they should be able to play together.
But, at the end of the day, the portal is still running under an application container, so it comes with all of the same restrictions. The portlet specs do not really allow for the sharing of beans or data, the portlet spec really treats portlets as extensions of servlets, although the spec says that they run under a portal container and have some extra lifecycle stuff to them, so portlets will basically have the same walls between them (when deployed as separate war files) that servlets do.
So you face the same challenges that Liferay and many other portlet developers before you have faced... You have separate war artifacts containing portlets that you want to share code, functionality, and data.
At this point, I suggest you start googling for how to share spring beans in multiple servlets in separate wars. The best search I can recommend is googling for "sharing spring beans between wars" as this is, basically, what you'd like to do...
The top result is probably going to be Using a shared parent application context in a multi-war spring application. It's a pretty decent read, but unfortunately it doesn't make clear that all you're doing is sharing the bean definitions, but not the bean instances (two wars that use the parent context would each get their own instance of a particular bean as defined in the parent context, since there's still the class loader issue to deal with). Other solutions deal with using spring remoting (so you're basically sharing your beans/code/data via a remote invocation and suffering the marshalling/unmarshalling penalties in doing so), etc.
So, after doing all of this research, what is the end result? Can we share spring beans/code/data across separate wars? No. It's just not possible, and the app container is going to keep it that way.
So the only way to really share beans/code/data across wars is to have one war host it's stuff and provide services of some kind so other wars could invoke those services, thus giving you the beans/code/data access you're looking for...
Now you could spend some time building some sort of framework for doing this, maybe leveraging web services, maybe leveraging SOAP or JSON so you can pass objects around. You could address issues of running your framework within a cluster, and how you deal with caching of data in your cluster, etc.
Or you could go back and take another look at Service Builder (which takes care of all of these issues w/ the class loader yet does not have the marshalling/unmarshalling overhead of some remote call).
Or you can continue to snub your nose at SB and complain...
Your call...
