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
end

Using 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
end

And 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

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 article cross posted at http://blog.zuerchtech.com/2008/10/05/appcelerator-remote-routes-for-service-integration/

ShareThis

We have recently committed the first stab at a google-gears enabled Appcelerator SDK. Google Gears (now just called “Gears”) is a really awesome browser plugin that gives you some out-of-process Javascript capabilities like offline and multithreading via worker pools.

With the next release of the SDK, Appcelerator’s javascript servicebroker will now automagically (and transparently) switch to using a Gears-enabled servicebroker when talking to your service-backend. That means your application will perform faster because the AJAX communication between client and server (especially for apps using fast polling) will be out-of-process using Gears’ worker pool.

You have to do nothing to enable this in your application. When you Appcelerator application loads, a small piece of code will check to see if Gears is enabled and will dynamically load the gears-enabled servicebroker code.

ShareThis

We know you’re excited about Google’s App Engine. How can you help it? If the opportunity to run your apps on a 20,000 terabyte per day cloud computer isn’t enough, certainly the ability to run Python on that cloud must be!

We were excited too, we admit. So yesterday we started porting our existing python server-side code to the App Engine, and today we’re releasing it through our developer network. This afternoon we ported Tejus’s appTunes demo to the App Engine and deployed it at http://apptunes.appspot.com.

So, how can you be incredibly hip too?

First, download and install Python 2.5, the App Engine SDK, and the Appcelerator SDK.

Now, make yourself a project and launch it locally (replacing myapp with your project’s name)

1
2
3

app create:project . myapp appengine
cd myapp
app run:project

If this is your first time on the developer network, you’ll need to enter your login.

If everything installed correctly you will see a bunch of logging info ending with:

1

Running application myapp on port 8080: http://localhost:8080

Like the other Appcelerator backends, you can find your message handlers in app/services/. So, go digest the App Engine documentation and write something great. Once you’re ready to send your app to the cloud just run:

1

app deploy:project

This will ask you for your App Engine account info, and then upload your project.

We’re putting together a screencast of this, and now that I’ve finished futzing with Windows command-line problems for this integration, maybe I’ll get some time to learn the Datastore API.

And now, a message from our sponsors:

In the spirit of open source and shared learning, we’d like to acknowledge a few key pieces that we put together to make this demo application that Tejus built happen:

• Doug McCune for his super bad ass CoverFlow Flex Component. We’ve used the Appcelerator Widget API to widgetize this flex widget and allow it to be both declaratively added to markup and the power of Appcelerator’s Web Expression Language to add remoting capabilities for data binding. This also shows off the power of using Appcelerator + Adobe’s Flex bridge to get the best of both worlds.
• JS Sound Kit for the streaming audio for playing the MP3s. Again, we built this as a reusable widget.
• Jamendo and the independent artists for the awesome, DRM-free music and cool looking coverart.

Tech Tags: appcelerator ajax flex appengine google ria javascript opensource

ShareThis

So we managed to sneak one additional feature into the upcoming Appcelerator 2.1 release. Those of you developing for the iPhone will be pleased to know that we added a new condition – ‘orientationchange’ – so you can handle the origintationchanged event on the iPhone in an on-expression. How cool is that? Very. So throw this onto the pile with the new build process, project command line tools, the eclipse plugin/ide (written by Mark Luffel), the developer network (it’s slick — just wait’ll you see it), and a ton of little features and fixes all over the place. Not to mention improvements to a bunch of the widgets (like the datatable which now supports custom formatter functions, sticky sort, etc.).

ShareThis

We’ve made another update to the RIA Developer product and beta 2 is now available. The official release number is 0.9.1 and it’s available from our Eclipse update site at http://updates.appcelerator.org.

We’ve made 2 small fixes in this release worth noting:

• Fixed a bug that would prevent downloading on windows (due to a missing win32 jar)
• Fixed a bug in the 2.0.2 SDK (project creation would always hang)

However, this release also contains one major change: licensing. We’ve decided going forward that the RIA Developer product will be licensed under the GNU Public License (GPL), version 3.0 or later.

It also worth noting that we’ve updated some minor text to come into full compliance with our license agreement with Aptana. If you don’t know, RIA Developer is “Powered by Aptana”. Aptana is a great product.

What’s up next?

We’re going to be finalizing the product as we ready the 2.1 release that’s under final development testing. We also will be incorporating the new capability in 2.1 that will allow us to incorporate full round-trip debugging in Eclipse. This will allow you to create applications, make changes in either your HTML or in your services, and then step through server code real-time.

We hope to complete our initial release for RIA Developer by the end of the month.

ShareThis

The 2.0.2 maintenance release is now available at: http://www.appcelerator.org

You can find the full release notes for changes at:
http://www.appcelerator.org/release_notes_2.0.2.html

Summary of new features:

1. Panel Widget

Allows you to easily create pre-styled panels. This widget has
several options:
- display a header with a title
- display a close button
- display a shading button (hide/show the panel content)
- use rounded corners
- display as a quote box
- display with no header (just a plain panel)

2. Http Widget

This is a powerful widget that allows you to access server resources
by URI. You can access third-party APIs like Google and Yahoo or
access your existing services. This widget effectively allows you to
use the Appcelerator RIA SDK without using Appcelerator Services. It
also allows you to easily create composite applications (i.e., an app
that pulls data from multiple sources).

3. Box Widget

This is a layout widget that allows you to layout elements
horizontally or vertically.

4. Button Widget

Allows you to easily create pre-styled buttons. The Button widget
also supports a hover mode and a disabled mode.

5. Search Widget

Allows you to have a “search-as-you-type” style combo box.

6. if Widget

Allows you to add conditional logic to your applications. This is
particularly useful when used in conjunction with the iterator widget
when you need to conditionally display row data.

7. Progress Bar Widget

This widget was contributed by Martin Robinson (thanks Martin!). I
think the name of this widget adequately describes its function.

8. Resizable Attribute

Add resizable=”true” to images and DIVs to make them resizable.

9. Ruby Improvements

Method signatures are no longer required for service methods. Added the
ability to add logic that gets executed before and after each service
call. See the Ruby Getting Started docs for more information.

10. .NET Logging Improvements

Added support for multiple logging levels and a auto-flush buffer.
These can be configured via the appcelerator-config.xml file. See
the .NET Getting Started docs for more information.

We will now begin work on Release 2.1 with a target release date of
1/25/2008. If you would like to see any specific items addressed or
features considered, please let us know. You can also directly open
issues or feature requests by visiting http://jira.appcelerator.org.

ShareThis

The 2.0.1 maintenance release is now available at http://www.appcelerator.org/download.html.

You can find the full release notes for changes at
http://www.appcelerator.org/release_notes_2.0.1.html

The main summary of new features are:

- .NET service support
- Python service support
- PHP service support expanded to support PHP4
- New widgets: calendar and pagination
- Reimplemented modules to better utilizes direct function calling vs. building via strings

We also have fixed numerous bugs and made of improvements.

With this release, we will begin working on 2.0.2 with a target release date of 12/14/2007. I will post more information about what we are targeting for this release in the next week. If you would like to see any specific items addressed or features considered, please let us know. You can also directly open issues or feature requests by visiting http://jira.appcelerator.org.

ShareThis