Spicefactory – Part 1: Spice IT up, with Parsley, Cinnamon and Pimento

08 Dec, 2008

In my article on InfoQ I’ve looked into how Grails and Flex can be combined to create a rapid application development platform. I think this is one of the most promising combinations for RIA development at the moment. The Flex space is very happening and there are many initiatives going on. A few days ago I encountered this one on the web: Apart from the funny name, I think it is a very interesting initiative, because it brings some new concepts to the Flex remoting mix.

This is an IOC implementation inspired by Spring framework. On the official site, it is compared with Cairngorm. Without even trying it, I think I already like it better to Cairngorm. For me, Cairngorm is a bunch of very good ideas, with hardly any implementation to support it. Parsley, like Spring, seems more a lot of good ideas with some implementation to support it. Testing how this actually works is high on my todo list.
This is a remoting framework, that is completely based on AS3 and Java. No Flex classes are used. It does use AMF, the fast serialization technology for AS objects. Furthermore it uses a Servlet to communicate with the server-side. While reading the documentation I started to wonder why this would be better than using Flex’ remoting service. I guess when you are using SWF without flex, this is a suitable choice.
Nevertheless I tried to expose my Grails services using this framework. This should be possible by using a custom configuration processor. While implementing this, I ran into the problem that Cinnamon requires your service to implement an interface. Since Grails services only have implementation, this is where my attempt failed.
Now this is something completely different: Pimento offers to use the JPA EntityManager from the client-side code directly. So, from within your flex application, you can load, query and manipulate data from the database using JPA. To me this sounds… interesting.
When configured correctly to work together with Grails, which I’ll cover in the next blog, an application to manipulate data with Flex becomes quite trivial. Let’s say we have the following domain class is Grails:

import org.spicefactory.pimento.config.Operation;
class Person {
	def String name;
	def int age;

This is a fairly normal Grails domain class, except that it has an annotation, that configures pimento to allow data manipulation on this class.
This class is mirrored in the client-side code like this:

	public class Person
		public var id:Number = 0;
		public var version:Number;
		public var name:String;
		public var age:Number;

Duplicating this class is still necessary. It should be rather easy to generate this class from Groovy code. Notice how the fields id and version that are automagically added by Grails are copied to the ActionScript class as well.
The rest of the client side might look something like this:

private function initEntityManager () : void {
  var config:PimentoConfig = new PimentoConfig();
  config.serviceUrl = getWebContextRoot(application.url) + "service";
  trace('url: ' + config.serviceUrl)
  config.defaultTimeout = 5000;
  entityManager = config.entityManager;
private var entityManager:EntityManager;
private var people:ArrayCollection;
private function refreshPersons () : void {
  var q:Query = entityManager.createQuery("from Person where age between :minAge and :maxAge");
  q.setNamedParameter("minAge", uint(ageFilter.values[0]));
  q.setNamedParameter("maxAge", uint(ageFilter.values[1]));
private function onRefresh (result:Array) : void {
  this.people = new ArrayCollection(result);

See how the client directly loads the data from the EntityManager! Similarly the client can update and delete data directly.
Now what do you think of this approach?
On the PRO side:

  1. Writing a lot less code: No DAO required. No service layer that just delegates to the DAOs.
  2. No lazy-loading issues: The client is in control and can load what is necessary.
  3. Better feature packing: All (or most) code that is required for a feature is in client code.

On the CON side:

  1. Very crude access control: Operations can be allowed/disallowed per entity.
  2. Data access code (although EJBQL) scattered through (client) code.
  3. No clear separation of concerns: Very data centered and data driven application.

Any thoughts?

Newest Most Voted
Inline Feedbacks
View all comments
Shrikant Vashishtha
13 years ago

Hi Maarten,
Did you get a chance to look at prana framework which provides Spring like IOC implementation?
It works well with Cairngorm and removes some of its problems (singleton, writing front-controllers and other dependencies related problems) To me it looks similar to Parsley.

Jens Halm
Jens Halm
13 years ago

Hi Maarten,
as the Spicefactory lead developer I’d like to comment on some of the issues you mentioned.
Regarding Pimento: Yes, the approach that you describe has pros and cons. That’s the reason why Pimento actually supports two programming models, as described in the manual here:
There may be use cases where using the AS3 EntityMangager might not be the best approach, for security reasons for example. In this case you can use the other programming model based on custom services and still benefit from some of Pimento’s data management features (like the client cache or sending only change sets when updating entities for example).
The existence of this second programming model is also the reason for the access control. Not sure why you find that crude, but the idea was, that you simply disallow queries on certain types of entities if you want to make sure that they can only be loaded through one of your custom services.
As for exposing Grails services for Cinnamon: It probably requires a custom ServiceFactory implementation. If you are interested in making this work, I’d be happy to assist. I’d need your help though as I don’t know Grails (yet).

Maarten Winkels
13 years ago

Hi Jens,
Thanks for your message.
I find the AS3 EntityManager approach very interesting. I think it will allow for very fast development, although I haven’t experimented with it enough to support this claim. To make it usable in a larger project, I think a lot of logic will have to be build into interceptors to implement standard JEE features such as security or application specific features such as audit trails. The framework seems to provide these plug-in points.
If I understand it correctly, the other approach will not work for Grails services, since they don’t have an interface as I explained in the blog. By quickly looking into the API documentation it seems like the SpringServiceFactory should be usable with Grails, since all Grails services are spring beans. The problem arises when creating a ServiceConfig object, which requires an interface constructor parameter and also checks that it is in fact an interface. Would it be possible to relax this requirement? I assume that the interface is used to create a proxy for the service. If so, maybe CGLib can be used to create proxies from concrete classes. This is the same approach that Spring uses.
Thanks for developing this interesting framework! I’m looking forward to the 1.0 release.
-Maarten Winkels

Jens Halm
Jens Halm
13 years ago

The interface was only a requirement because it is needed if you use Cinnamon’s Java Client. It will then dynamically create the remote stub from the interface. For the server side an interface is indeed not required, as Cinnamon uses plain method invocation via reflection with its default service factories. So it was quite easy to relax that requirement, I had to change about 5 classes. As I don’t know Grails I tested it with a Java Spring Bean that does not implement any interfaces. In this case Cinnamon now expects that either the annotations are on the implementation class or the exposed methods are declared in XML.
To try it out you have to build the Cinnamon jar from SVN. I also changed the XML Schema, making service-interface an optional attribute. You should now point the schemaLocation to Let me know if that works for you.
Regarding the access control: I probably should improve the docs to make it clearer. It’s not our goal to include a full blown security framework. Rather we would start to integrate with existing solutions like Spring Security with upcoming releases. The global switches that were irritating for you were only introduced to offer some kind of easy base configuration. So if you know that you would not want to allow clients to freely build JPAQL queries in AS3, you could simply disallow some or all operations of the AS3 EntityManager and then use standard Spring Security Aspects on the custom services that you use to read and write these entities.
If you DO want to use the AS3 EntityManager, you are right, you don’t get much options for declarative security now and would have to write some interceptors. I’ll evaluate (for Pimento 1.1) whether there is an elegant path to also integrate the AS3 EntityManager with something like Spring Security. Method level security wouldn’t make sense in this case though, so I’d have to look at their ACL stuff, with which I haven’t worked yet.
Btw.: If you don’t mind I would like to link to Part 2 of your blog post from the Pimento documentation for users who want to integrate Grails.

Jeremy Flowers
12 years ago

One thing I couldn’t ascertain when I read the Pimento + Cinnamon docs was how you’d be able to deal with things like validation – tackling the GORM constraints with a Flex front end. I think the Grails GraniteDS guys wrote their own templates and kept this stuff client-side – sounded half finished work from plug-in wiki too.
I posted a message on Jans forum…

Explore related posts