In a project I’m currently working on we’re using LiveCycle Data Services to expose Java back-end services to a Flex client application. The back-end is structured in several layers using some flavors of Spring “glue”. You can see below the basic building blocks of the back-end :
As you can see, the architecture is quite simple. We have a layer of service API which is implemented by another layer, a LCDS-based implementation which, in turn, uses an implementation of a DAO layer. In the diagram, I grayed out the DAO layers because they are of no interest to our current subject.
Briefly, the service API only contains the interfaces of the services along with related objects : exceptions and DTOs.
We use our custom business exceptions to signal to service clients any issues encountered during service operations. Each custom exception has a public code which indicates its nature and meaning.
Simple exception mechanism
At first, we decided to simply throw business exceptions from the service implementations. This meant that the Flex client application would receive a fault event, which it had to strip to get to the actual exception.
Here is the Java service exception and method :
public class InvalidCriteriaException extends Exception { ... public String getCode() { return ExceptionCode.INVALID_CRITERIA.toString(); } } public SearchResultDto searchById(SearchCriteriaDto criteria) throws InvalidCriteriaException { try { // do some processing, use the DAO layer ... } catch (SomeDaoException e) { // convert the DAO exception into a service exception and then throw the new exception ... } catch (Throwable e) { // any unexpected exception is caught and a new service exception is created and thrown further ... } }
And the corresponding Flex code :
private function handleException(event:FaultEvent) : void { var errorMessage:ErrorMessage = event.message as ErrorMessage; Alert.show(errorMessage.rootCause.code); }
As you can see, the Java service code is cluttered within a try..catch block, which also contains the details on converting possible exceptions to service exceptions. On top of this, the client-side code is not very clean either, because it uses an untyped object ( rootCause ) on which we make assumptions and assumptions are generally a bad thing to do in your code. The right solution on the client-side would be to take advantage of the properties of the ErrorMessage object.
A better exception mechanism
In order to leverage the properties of the Flex class ErrorMessage, we decided to only throw instances of flex.messaging.MessageException, which is shipped in LCDS (and BlazeDS). To do this in an easy way, we proceeded in making sure that each of our custom exception would inherit MessageException :
public class InvalidCriteriaException extends MessageException { ... }
The service layer would now throw only MessageException-derived exceptions, which get deserialized on the client-side as instances of ErrorMessage. The Java exception has a field called code, who is translated in the Flex class as the field faultCode. So the only thing left to do is make sure that the code field is set to a proper value on the server side.
Using Spring BlazeDS Integration and a custom exception translator
The solution described in the previous paragraph still comes with some flaws. First of all, we didn’t get rid of the try..catch block in the service code. Uh, ugly.
Second, there is a design issue : the service API layer is exposing the service interfaces along with the exceptions, which are now derived from a LCDS exception. This makes the service API layer dependent on LCDS, which is not what we want. The service API should be clean and free of any implementation-specific dependencies.
These flaws were removed once we switched to using the Spring BlazeDS Integration to expose our Spring-based services as LCDS destinations. Along with other great features, Spring BlazeDS Integration comes with the notion of custom exception translators. The translator makes sure that exceptions thrown from the Spring-exposed LCDS destinations are converted to meaningful exceptions for the client, all of this far away from the service code which will be far more simple and clean.
First of all, we create our own exception translator :
public class ExceptionTranslatorImpl implements ExceptionTranslator { public boolean handles(final Class<?> clazz) { return Boolean.TRUE; } public MessageException translate(final Throwable throwable) { final MessageException exception = new MessageException(); exception.setCode(ExceptionCode.SYSTEM.name()); if (throwable != null) { if (throwable instanceof BaseCustomException) { exception.setCode(((BaseCustomException) throwable).getCode().name()); } exception.setRootCause(throwable); exception.setMessage(throwable.getMessage()); } return exception; } }
Then we need to register it in the application context :
<bean id="allExceptionTranslator" class="com.adobe.myproject.exception.ExceptionTranslatorImpl" /> <flex:message-broker services-config-path="/WEB-INF/flex/services-config.xml" > <flex:exception-translator ref="allExceptionTranslator"/> <flex:message-service/> <flex:secured /> </flex:message-broker>
We can now remove all the exception conversion logic from the service code and let the exception translator handle all of these ugly details for us. Much better, isn’t it ?
Very useful, thanks for that!
In former projects (with plain blazeDS) we used AspectJ to do the similar thing, but this is much easier…
Yes it’s much easier, I think it brings a needed separation between your business exceptions and the exceptions you expose publicly.
Hi, thanks for that article.
I’m currently wondering where the ExceptionCode class is coming from. You do not use import statements, so I’m struggling where to get those classes from. Is it a spring framework flex class or something implemented on your own?
–
exception.setCode(ExceptionCode.SYSTEM.name());
–
Regards
Ingo
The ExceptionCode is just a custom enum that I created, containing error codes which are relevant to the Flex client application. When the client application makes a remote call and the remoting service throws an exception, the client application can read the code of the exception and determine the action to take based on the code.
Does it make sense ?
Hi,
normally I’m used to let client’s be as dumb as I could. If I can handle something in the backend, e.g. localized error messages, I do it there and let the client only read the string via getMessage. But if you have more than one ways to query with a client, like Rest, remote or webservice, it is more likely to have a error code set and let the client decide what to do with the error (just show or fetch internally something else).
So, it depends
I usually let the client applications worry about user messages and localization. I pass them an error code and let them handle it as they see fit. There’s no universally good approach. Both approaches are good, like you said it all depends on the context.
Hi,
We have our application in Spring and LCDS. Now we have to use MessageInterceptor for which SpringBlazeDS integration should be implmented. Can we use SpringBlazeDS integration with LCDS, because we get lot of errors which says ‘cannot make instance of _messageBorkerHandlerMapping’?
I’ve used Spring BlazeDS Integration with LCDS, but not out of the box. Due to its current lack of support for LCDS, I’ve had to write a small extension for Spring-Flex which makes it possible to use LCDS and also expose data management assemblers via annotations.
If you’re interested in this, give me an e-mail.
Hey, I would be interested in the extension
Can you email me back with details.
Cheers
Anuj
An useful post, Thanks for it.
There is One thing different from me, I normally don’t throw a business exception from DAO/Repository, for instance – InvalidCriteriaException. searchById() will just return a null and a business exception will be thrown in service layer. It is a personal preference.
Appreciate the post,
Cheers,
Cheng
Thanks margelatu!
Very useful post! I really enjoy to read it!
I suscribre to your RSS
See ya
“In former projects (with plain blazeDS) we used AspectJ to do the similar thing, but this is much easier”
this is much easier than AspectJ …this goes to my personal preference.
Interesting post, I like to see how other people handle things. Your code looks very professional and clean.
The codes is very complicated to me. I have programming. But I know this is very useful information!! I want to try to analyze those codes. Thanks for sharing your knowledge.
Great post. I agree with natasha it is very complicated but you did it. Good job! Thanks for sharing