Extending the Leap

As I mentioned in my prior post, we are using the Spring Framework for Orange Leap. One of the biggest advantages to a dependency injection framework like Spring is that it is easy to extend with your own functionality. In the current implementation, all the services, entities and data access objects are defined with Java interfaces and then implemented with internal classes. What this means for our partners is that existing functionality can be easily extended by either extending the internal classes to add the desired behavior, or by directly implementing the interfaces with a custom implementation.

While this makes sense for a few small changes, it can quickly become overwhelming if a partner wants to add significant functionality. Rather than require developers to delve into re-implementing the base interfaces, we are taking advantage of Spring Integration to allow partners to easily hook in to life cycle events and add their own functionality.

Spring Integration is an extension to the Spring Framework which provides a messaging bus for applications. In the default implementation, messages are passed via internal queues which publish messages to other beans in the application asynchronously. Spring Integration can also push messages via an external message queue like Active MQ, which is our preferred implementation. Spring Integration allows for an asynchronous event-based architecture. For example, the current payment processing logic is tied to a Spring Integration queue which passes the gift information to a Drools rules flow. This all takes place on a separate thread from the HTTP caller, thus the rules engine and subsequent calls to a payment gateway do not block the web client.

We are planning on exposing all the significant lifecycle events for Orange Leap through Spring Integration so that partners can easily hang new logic off of the existing classes without having to override any of the existing classes or implement their own versions of the interfaces. For example, via the messaging, a partner could catch the “new gift” event and push it to a separate reporting database without interrupting the existing process flow.

This all sounds good for onsite implementations of Orange Leap, but I’m sure people are interested in how they can extend the hosted solution too. The current hosted solution allows custom field definitions, but some client are going to want to go beyond that. This is where Spring Dynamic Modules (DM) comes in to play. Spring DM is an OSGi container for hosting components. It provides full lifecycle management for components (beans) within a server instance, including hot deployment of new functionality. Our goal is to move Orange Leap to Spring DM later this year so that new functionality can be added to the hosted environment without disrupting the server. Partners would be able to write their own Spring DM modules which will receive messages from Spring Integration and provide custom logic.

Orange Leap isn’t to Spring DM yet, but it is on our road map. We intend to make Orange Leap the most developer-friendly constituent management platform on the market.

Explore posts in the same categories: Orange Leap Developer Network

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: