We’re pleased to announce that as of our newest 2.2.0 release (GA a couple of days ago) we’re going to be changing the licensing for the Appcelerator SDK. We now have officially moved away from the GNU Public License (GPL), version 3 to a more permissive Apache Public License, version 2. So, why the change?

1. We’ve talked and listened to the community a lot in the past 6 months to understand how people want to use Appcelerator, how they are presently using Appcelerator and what types of things they would like to do in the future. We’ve clearly heard a very resounding theme: GPL is not the right license from a community perspective because of the implications that it brings to redistribution, especially as it relates to building web applications and how they are incorporated and downloaded by a web server. While we initially considered attempting to clarify our position on the GPL as it relates to these special legal concerns — I felt like we would essentially dilute the intent of the GPL license and that would defeat it’s purpose. This was a clear indication that our license didn’t match our business and technical goals.

2. We are not pursuing a normal path like most open source companies — especially one’s before us like JBoss and MySQL. Our business model is not centered around income from a “for fee” derivative based on the “for free” version. This is a very popular OSS business model and one that has its merits in professional open source. I personally think this OSS business model makes sense for a lot of companies. However, not all open source companies are made equal and we are not going down this path. While we will continue to provide special licensing, indemnification and support as customers want it — we’re not going to ask you to buy a paid version of the SDK after you adopt the free version.

After careful consideration, we’ve decided that the Apache Public License fits the bill for us because it balances some basic legal protections (i.e. NO WARRANTY) with the ability to provide the community with a license that enables broad use of our technology. This gives everyone the ability to use it, modify it and redistribute it in every circumstance. We believe this is a good thing and will enable the community to more easily adopt Appcelerator. There’s always the danger that someone will rip it off and use it without giving back — but I believe that’s a risk we’re willing to take to enable a better outcome for everyone. Ultimately, it’s hard to anticipate what evil people might do against you. Our goal is to help make the open web world a better place and the Appcelerator SDK is the first step of many towards that.

I realize that this leaves one major question. What is your revenue model? However, that’s a post for another day and it will become clear in the future. For now, we want to focus on continuing to build on our fast community growth, continue to listen to what problems you’re facing and how Appcelerator can help you solve them, and work hard to build the best rich web platform around. We have a long way to go, and with your support, we’ll get there together. Thanks for your continued support, kind words and positive criticism. We’re listening.

Code strong!

Popularity: 2% [?]

Today we launched an interesting experiment here at Appcelerator and I’m curious to see how it plays out.

Certain technologies are such that description is a poor substitute for personal experience (think Tivo or iPod).  This is often the feedback we receive from people who decide to build something with our Appcelerator RIA + SOA platform (e.g. “wow, this is so friggin elegant!”).  But the investment that someone must make to achieve that epiphany is non-trivial because they must step back to grasp basic Appcelerator concepts like our message-oriented architecture and our web expressions (just as they would with any other framework).

To lower that barrier we have asked members of our community to submit screenshots of their most boring (yet critical) web 1.0 business application along with a description of the functionality provided.  We will select a few of the submissions and rebuild that user-interface entirely as a rich internet application based on Appcelerator.  Best of all, it’s absolutely free.  Often times what a developer needs to convince their management about the business case for RIA is a functional prototype that allows them to really experience the enhancement it can bring.  Because our technology completely decouples the user interface from the server-side infrastructure the resulting prototype can be used as the actual user-interface for their RIA upgrade if they decide to use Appcelerator.

While the contest is formally named “WebApp Facelift” we’ve been referring to it around the office as “Pimp my WebApp”!  Click here to submit your web application for consideration.

Popularity: 2% [?]

Problem Definition

Are you considering integrating a bunch of web services together but may not feel too comfortable with the vulnerabilities of a mash-up approach, the overhead of setting up and using an ESB, or writing a bunch of mind numbing spilling crushing service transformation code? If thats what you want then, yeah sure that would work for a problem definition.

How does it do it?

The java:axis2 plugin (an appcelerator plugin) installs an appcelerator command that can be run either silently or prompt for input to generate and build axis2 stubs from your WSDL url. Once the stubs have been built, the command then creates a java appceleator-based class with services for each corresponding soap endpoint. The solution makes use of code generation so that you may enhace the services should you so desire. Serialization is also taken care of by transforming to/from the JSON model to the Axis2 model so that making the changes to the service mapping is clean and simple.

How would 1 set it up?

Before you can use the plugin, you need to download axis2 and setup your path appropriately. Its pretty easy, just extract axis2 and set your AXIS2_HOME environment variable. Now you can add the plugin to your java project (named $PROJECT):

app install:plugin java:axis2
cd $PROJECT
app add:plugin java:axis2

How do I use it?

Now that you’ve added the plugin, you can now implement the service orchestration for invoking a SOAP endpoint. Lets assume that your wsdl is at http://localhost:8080/axis/services/QueryPort?wsdl. This is how it would flow for you in prompted mode

app gen:axis2
Whats the url for your wsdl?
http://LODVM1044:8080/axis/services/QueryPort?wsdl
What directory do you want to use for storing the axis stubs? [src/axissource]
src/axissource/queryport
What package name do you want to use for your axis stubs? [my.axis]
queryport.axis
What directory do you want to generate the services to? [app/services]
app/services
What package name do you want to use for your appcelerator services? [my.service]
queryport

Alternatively you could run this silently:

app gen:axis2 --axisdir=src/axissource/queryport --axispackage=queryport.axis \
--wsdl=http://localhost:8080/axis/services/QueryPort?wsdl --silent=true --appcpackage=queryport

Here is a sample snippet of the code that will be generated to map your appcelerator services to a web service call:

package cmdb.service;
 
import org.appcelerator.annotation.Service;
import org.appcelerator.messaging.Message;
 
public class QueryService {
 
	@Service(request = "graphQuery.request", response = "graphQuery.response")
	public void graphQuery(Message request, Message response) throws Exception {
		uery param = (axis.query.QueryServiceStub$Query) AxisUtil.toAxisObject(request, axis.query.QueryServiceStub$Query.class, "param");
		axis.query.QueryServiceStub$QueryResult result = new axis.query.QueryServiceStub().graphQuery(param);
		response.getData().put("result",AxisUtil.toMessageDataObject(result));
	}
}

Note that for this to work you will have to upgrade your Appcelerator installer to 1.1.20+ (next release to be out shortly), I’ve updated mine off of the svn trunk. To check your installer:

app --version

Some more details on how to test

Now the question is, how do i know how to construct my request parameters? You can use the AxisUtil class to help you out, here is a sample snippet for my parameter into the web service, the model class Query:

Query param = createQuery(); //however you want to create your model object
System.out.println(AxisUtil.toJSONObject(param).toString());

the request body will directly reflect that ex:

{"query":{"itemTemplate":[{"contentSelector":null,"id":{"value":"ALL_CI1s"},
"instanceIdConstraint":null,"recordConstraint":[],"suppressFromResult":false,
"xpathExpression":[]},{"contentSelector":null,"id":{"value":"ALL_CI2s"},"instanceIdConstraint":null,
"recordConstraint":[],"suppressFromResult":false,"xpathExpression":[]}],
"relationshipTemplate":[{"contentSelector":null,"depthLimit":null,
"id":{"value":"ALL_Relations"},"instanceIdConstraint":null,"recordConstraint":[],
"sourceTemplate":{"maximum":22,"minimum":0,"ref":{"value":"ALL_CI1s"}},
"suppressFromResult":false,"targetTemplate":{"maximum":0,"minimum":0,"ref":{"value":"ALL_CI2s"}},
"xpathExpression":[]}]}}

This utility will help you to see how the data is structured. For a more detailed example unit test check out SerializationTest.java

Wrap Up
In this post we demonstrated:

• what the plugin does and the problems it solves
• how to set it up and use it, as well as how to test

Popularity: 3% [?]