In my last post, I talked about Service-Oriented User Interfaces (or SOUIs). In this post, I want to get more specific about what that means from a development perspective. In practical terms, a SOUI is nothing more than a composition of Service-Oriented Components.

A Service-Oriented Component is a component whose behavior and visual appearance is driven by a message and optionally some data in that message. In Appcelerator, we turn standard HTML elements into Service-Oriented Components. Let’s look at some examples:

Example 1: Progress indicator

1
2
3
4

<div on="r:login.request then show or r:login.response then hide" 
     style="display:none">
        <img src="images/progress.gif"/> Processing Login....
</div>

In Example 1, the display of a standard HTML <div> is controlled by two separate messages. The login.request message triggers the <div> to show and the login.response message will trigger the <div> to hide.

Note: Appcelerator Client messages are always prefixed with either an l: or an r:. The former tells Appcelerator that the message should only be sent locally (i.e., within the browser). The latter will result in the message being sent both locally and to a service.

Example 2: Submitting a form

1
2
3
4
5
6

<div>Username:</div>
<input type="text" id="username" fieldset="login"/>
<div>Password:</div>
<input type="password" id="password" fieldset="login"/>
<input type="button" value="Login" fieldset="login" 
     on="click then r:login.request"/>

In Example 2, when the user clicks the “Login” button, a request will be sent to a service that subscribes to the login.request message. The message’s data payload will contain two name/value pairs: ‘username’ with the value of the username input field and ‘password’ with the value of the password input field.

These two simple examples demonstrate both the power and simplicity of Service-Oriented Components. In Appcelerator, Service-Oriented Components are possible because of Appcelerator’s integrated Message-Oriented Architecture. This architecture binds user interface elements to services via a lightweight message contract. Appcelerator Message Contracts have two parts:

• message name (e.g., “login.request”)
• message data payload (i.e., one or more name/value pairs)

In Example 2, the “Login” form and the “Login” service share a message-based contract. This contract has a message name: login.request and two name/value pairs: username and password.

Service-Oriented Components can also take action based on the combination of a message and its data payload. Let’s look at some examples:

Example 3: Show an element based on message data

1
2
3
4

<div on="r:user.registration.response[success=true] then show"
   style="display:none">
   Your registration was successful as far as you know...
</div>

In Example 3, the registration message will only be shown if the r:user.registration.response message contains the name/value pair ’success’=true.

Example 4: Set styles and element values based on message data

1
2
3
4

<div on="r:login.response[gender=male] then set[border='1px solid blue'] 
     else set[border='1px solid pink']"  style="display:none" >
     Welcome back, <span on="r:login.response then value[name]"></span>
</div>

In Example 4, several user interface actions occur based on the message login.response and its data payload:

• The border of the <div> is set to blue if ‘gender’ is ‘male’, otherwise its set to pink
• The value of the <span> is set to the user’s name in order to complete the “welcome” message

These examples provide just a glimpse of the power of Service-Oriented Components. I’ve been developing applications this way for over a year, and I believe the benefits are enormous. Here are just a few:

• You get more functionality with significantly less code, or as we like to say: “More App. Less Code.”
• You can easily Ajax and DHTML-enable standard HTML elements without writing any Javascript
• You can create mock service handlers on the client - the result is a fully functional client prototype that is 100% resusable
• You get a very clean separation between the client and its services.

Now that I’ve set a new world record for using the phrase “Service-Oriented Component” in a blog post, my work here is done, plus you need to get back to work - your boss is standing right behind you.

Popularity: 6% [?]