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

this article cross-posted at http://blog.zuerchtech.com/2008/08/29/soap-orchestration-with-javaaxis2/

Popularity: 3% [?]

It’s the GUI stupid!

Many years ago, I consulted for a large semi-conductor company during the early stages of a software project. They had a highly detailed and fairly rigid process for software projects that started with a complete requirements document based on an extremely verbose and granular template. As the project progressed and I saw the size of the document balloon from 50 pages to more than 200 pages, I had the realization that this document would never be read by ANYONE from beginning to end. The business owners who were responsible for ensuring that the requirements fit their actual business needs were completely overwhelmed by the document’s size and complexity. Six months later the business users were given their shiny new software and they were disappointed that the software didn’t match their expectations.

In reality, the software was a very solid effort that met all of the requirements specified in the document. However, business users had no ability to read the requirements document and imagine what the user interface might look like for the requirements provided. I remember feeling that the business owners didn’t know what they really wanted and feeling resentful of that fact. In retrospect, I realize that almost nobody knows exactly what they want, until they see it. Why? Because to a user, the interface IS the software. Concepts like data models, middleware, rules engines, LDAP, and SSL have no real meaning outside of us techies.

So how do we avoid this? Is Agile Development the answer? Agile is definitely a step in the right direction. It codifies the practices that had evolved in the most successful and most productive software development teams of the 1990s. However, we need more. We need to enable our development teams to prototype the user interface quickly and easily so that users can actually see (better yet, use) the software EARLY in the process. In web 1.0 this was a fairly straightforward effort of building static HTML wireframes. The problem was that this work was largely throwaway b/c they had to be rebuilt as servlets, JSPs, ASPs, PHPs, etc.

As our web applications become more sophisticated this approach starts to break down even further. Today, rich internet applications include syndicated content, widgets, DOM manipulation, Ajax calls, and often a substantial amount of JavaScript. Static wireframes just cannot easily emulate this kind of rich user experience accurately.

What If?

What if you could build the user interface prototype in a matter of days or weeks without a single line of server-side code or even a datamodel? What if the business owner could not only play with this prototype, but also provide context specific feedback seamlessly while exploring the prototype? Finally, what if the prototype wasn’t a prototype at all, but was the actual user-interface of the final product (zero throwaway code)… even if you haven’t decided which server-side technology you want to use (Java, .Net, Ruby, PHP, Python, Perl)?

This is exactly how we develop software for our consulting customers today using the Appcelerator platform. We’ve been doing this for over a year now, but we haven’t really given it a name until recently. We call it “Interactive Use-Cases”. Essentially, we skip the entire functional requirements definition phase and move directly from use-cases to working prototype! This is only possible because of the advantages that the Appcelerator platform provides us. Let me explain.

Technological Enablers

First, Appcelerator’s widget library, web expression language, and message-oriented architecture were designed to enable web developers to build UIs with the minimal amount of code (read: JavaScript) possible. As an example, Ajaxian’s Dion Almaer posted a small interactive web page on his blog and invited people to port it to their favorite JavaScript framework. Compare the ViewSource of the Appcelerator version to those of the other frameworks. More app + less code = better productivity.

Second, the fact that you are not generating your HTML from server-side scripts frees you from the wasted effort associated with building throwaway static wireframes. Build applications as Ajax enabled .html files which dynamically pull data/content from the server and (re)render those sections of the page accordingly.

Third, our message-oriented architecture is ideal when prototyping because message subscribers in the browser do not care about the source of their messages (that’s the point of publish/subscribe architectures). So build the entire user interface with the exact messaging code that they will need for production use. But instead of building a datamodel, DAO objects, DTOs, business logic, and such to provide the actual service implementations, just add a single line to your webapp to include a single JavaScript file containing mock implementations of these backend services. In 90% of the cases you can mock that service with a couple lines of JavaScript that generates a JSON message with a mock payload.

My favorite part about this approach is that once you have gotten sign-off from the business owners, you can remove a single line from the application and all of the mock services have now been turned off. And the server-side programmers have a complete contract of every service which needs to be developed along with test data. Even better, they can choose to implement those services in any language they prefer because the UI is just producing/consuming JSON.

Fourth, thanks to a recent enhancement by Andrew Zuercher, we can easily collect user feedback on our user interface prototype by passing an additional URL parameter which highlights the border of any HTML control on mouseOver. By CTRL-clicking on any highlighted element a feedback dialog box appears that includes the specific page and HTML control being commented on. Users can see other users comments so that feedback effort isn’t duplicated. UI elements that already have comments are indicated with red borders.

Everyone knows that prototyping is a valuable exercise that improves the likelihood that the business users will be satisfied with the end-product. However, the limitations of web technology have made it prohibitively expensive and time consuming for all but the most critical web projects…… until now.

Popularity: 4% [?]

I love my Google Reader (especially the VI hotkey navigation). I really love the fact that I can take my RSS feeds offline with me when I’m about to jump on a plane. However, what happens when the concept of being disconnected from the Internet disappears?

I tend to be a ridiculously early adopter of technology and therefore end up with hopelessly outdated technology that costs 5x more than it should. I have always thought that connectivity should be independent of wires & location. From OmniSky (for my Palm Pilot in 1999) to Intel Anypoint (1.5 mbps baby) to digital phone cards (PocketPC) to EvDO cards… there’s almost never a reason not to have an IP address except on an airplane, a submarine, in a faraday cage, or in deep space. Since I’m unlikely to encounter three of those situations it’s really about the ability to access the net at altitudes of 30,000ft.

I just read today that Delta has announced it is going to provide WiFi on all domestic flights. And it seems JetBlue has been offering limited access since 2007.

As competition forces the cost of mobile connectivity to decline, offline may be a stop-gap solution that eventually becomes a solution in search of a problem. Now this doesn’t mean that some of the advancements that have been associated with offline will also disappear (local data storage, desktop integration, etc.).  They will continue to advance the ability of browser-based applications regardless of connectivity.  However, the idea that my user interface needs to be stored locally will soon seem quaint.

note: cross-posted at my personal blog

Popularity: 6% [?]