Problem definition
A few weeks ago i started a thread on the Appcelerator development network about remote routes. The thread got a bit of attention and ultimately meant different things to different people.
web 1.0 transformations
When I get in front of customers today that have an existing web solution in place, they tend to ask some simple questions:
- What do I have to do to implement a service in <backend framework>?
- I’ve already got a bunch of web services, can I use them as is?
- My website has a traditional web 1.0 implementation, will i have to throw away and start over?
Primary focus: cost to implement seems to be the main chasm for them to hurdle.
REST zealots
A bunch of the developers out there are jazzed about building RESTfull services to remotely expose an endpoint for integration. Re-using these endpoints is a natural fit for them and paramount to their needs.
Primary focus: A clean single place to define their services.
back end framework architects
Then there are the framework guys that are out there that have the need to add Appcelerator to extend their portfolio. Recently I helped out with implementing an Appcelerator service for grails. To facilitate the framework integration I write a similar service broker in grails much akin to what we have done for the other platforms. The controller would discover the Appcelerator services written in grails and then invoke them directly. The downside is that:
- grails developers like to integrate at the controller level and not the service level
- grails itself makes responding to and rendering JSON very easy
- grails already has routing and discovery built into the framework
Primary focus: not duplicating existing framework functionality in a way that is consistent with their architecture
Previous approaches
In the past I’ve prescribed a 4-tiered strategy for those that are out there that are interested in integrating their existing application using Appcelerator;
- create new Appcelerator-specific remote services that reuse existing code inline if possible
- use an ESB to route to your existing services
- use the app:http written by Mr. Hashemi as mash-up in the client
- do not use remote services, but allow Appcelerator to add richness to your application locally in the browser
Solution
Instead of writing remote services that are Appcelerator specific and restrictive, an implicit contract is adhered to. This means that back end services can be written in any language or platform so long as they are able to consume and render in an approved format (for example ‘application/json’).
Traditional
Here is a simple example for a traditional service.
class MyService < Appcelerator::Service
Service 'order.create.request', :create_order, 'order.create.response'
def create_order
order = Order.new(params["amount"])
order.save
{'success'=>true, 'id'=>order.id}
end
endUsing remote routes
And now we make use of controllers as well as remote routes. Here is the controller
class OrderController < ApplicationController
def create
order = Order.new(params["amount"])
order.save
respond_to do |format|
format.json { render :json => {:success => true, :id => order.id} }
end
end
endAnd now in the client we include the following in our javascript (there are a ton of ways to implement this, but here is an example for now)
$MQR('r:create.order.request','/order/create','post',
'r:create.order.response');trade offs
| Item |
Remote Routes |
Appcelerator Service |
app:http |
| Web controllers |
Yes |
No, must be appcelerator services. |
Yes |
| Message Mapping |
Yes, client side as javascript to define routes. Concise and not too terribly tedious and can be done in exactly one place. |
Server side using annotations to map methods to message types. |
Yes, client side widget declarations per message type. |
| Message Multiplexing |
One-2-One: a given request message is associated with a single response message and are processed one at a time. |
Many-2-Many: this is a big upside for the existing service brokers is that groups of messages can be delivered to the back end at a given time and different types of messages can respond to them |
One-2-One: a given request message is associated with a single response message and are processed one at a time. |
| Service Endpoints |
Multiple can be supported, the target url is an aspect of the message mapping |
Fixed, all requests go through specifically one exposed endpoint (service broker) |
Multiple can be supported, the target url is an aspect of the message mapping |
| External Services |
Yes |
No |
Yes |
| Serialization |
Up to back end service to implementor |
Appcelerator remote service takes care of it for you |
Up to back end service to implementor |
Wrap up
Understanding the trade-offs for the different service routing opportunities should be considered when you architect your solution. At the core of it, Appcelerator provides you with options and leaves that decision up to you, empowering you to make that choice for yourself.
this blog has beeen cross-posted at http://www.appcelerant.com/appcelerator-remote-routes-for-service-integration.html
Technorati Tags: appcelerator, json, ria, soa
