Expose Alfresco service bean with Spring remote

[pcuvecle]

Hi,

I'm trying to find a solution to build a new webapp next to the Alfresco one (or even on another server) and I was wondering if someone already tried to expose the alfresco service beans via the Spring RMI remoting feature. Indeed, for me those beans are the most interesting ones because they are at the top of the feature capabilities list (since not all services are exposed in the webservices and even less via JCR). Also, I could call the webservices from my second webapp but I guess that RMI calls would be quicker than going through all the webservice layers.

Does anybody already tried this and if yes is there any issue (transactional, securtity, other) ?

Thanks for your feedback

[macberger]

I was thinking about it too - has anyone done it? Is it faster?

[rdanner]

I was thinking about it too - has anyone done it? Is it faster?

Guys this is tricky business.  When you make calls to the APIs you need to make sure they are sound both transactional and from a security perspective.  Alfresco uses libraries for security that place items in the thread which gets crazy with RMI because on each request RMI will potentially serve you a different thread.



That said, I think I would keep an eye on the RESTFUL APIs.  They are not as clunky as the big web services.  I guess it depends on your performance needs.  I have the tendency to think "that won't perform" but that tendency is better answered with trials rather than self FUD.  Using the REST api is much more scalable than hitting an in process repository so you have to ask yourself what scalability means in your topology – what part is most likely to represent the bottleneck?  RMI also has the firewall and serialization stigmas that the other remote API’s don’t. 

Take it from a guy who has been up and down the RMI path with this project – consider your alternative options closely before you decide to go this route.


If you need local access to alfresco but simply want to access it from another web app there is an option but it involves a bit of work:

Create a new interface with the functionality we want from alfresco (it could even look remarkably like the alfresco interface) … place that interface in the common class loader.  It has to go in the common class loader because two applications with the same JAR files in their own class loaders will view those classes as distinct (IE if you got a reference from one application and shared it with the other – you would have class cast exceptions galore)

Create an adapter class: alfresco service to your new interface

Create a bean that can put export you adapter (which implements your interface) in to JNDI

Now on the client create a bean that implements the interface and can pull the object out of JNDI.

At that point you have an interface in your remote app that gives you access to Alfresco which you can consume from other applications.  You wont want to don't put the real Alfresco interfaces in the common classloader because A: they are packaged with the Impls and B: because the footprint is too big and it's best (I think) to share in the common class loader as little as possible to avoid JAR hell.

This gives you direct access to the alfresco object with only the overhead of the adapter – it is a local reference.


It's an ok solution but it's only good if you know you are not going to need to scale out alfresco independently of you application or you are commited to scaling out the application at the same rate as you are scaling out alfresco.  I'd think price and complexity here…