Archive for February, 2007

Grey Line

Event-driven programming model offers an excellent architecture based on loosely-coupled components consuming and throwing events. This simply means that a properly designed component knows how to perform some functionality and notifies the outside world by broadcasting one or more custom events. I need to stress, that such component does not send these events to any other component(s). It just broadcast its “exciting news” the event dispatcher. If any other component is interested in processing this event, it must register a listener for this event.

Before explaining how to create an event-driven component let’s state how we are going to use them. This is a typical scenario: MyApplication uses Component1 and Component2. Components do not know about each other. Any event-handling component should define this event inside. For example, Component1 dispatches this custom event sending out an instance of the Event object, which may or may not carry some additional component-specific data. MyApplication handles this custom event and if needed, communicates with Component2 with or without feeding it with data based on the results of the first component event.

We’ll create a “shopping cart” application that will include a main file and two components: the first a large green button, and the second one will be a red TextArea field. These components will be located in two separate directories “controls” and “cart” respectively.

To create our first MXML component in Flex Builder, select the “controls” directory and click on the menus File | New MXML Component. In the popup screen we’ll enter LargeGreenButton as a component name and we’ll pick Button from a dropdown as a base class for our component. Flex Builder will generate the following code:

<?xml version=”1.0″ encoding=”utf-8″?>
<mx:Button xmlns:mx=”http://www.adobe.com/2006/mxml“>
</mx:Button>

Next, we’ll make this button large, green and with rounded corners (just to give it a Web 2.0 look). This component will be dispatching an event named greenClickEvent. When? No rocket science here – when someone clicks on the large and green.

Custom event in MXML are annotated within the Metadata tag in order to be visible to MXML. In the listing below, in the metadata tag [Event] we declare a custom event of generic type flash.events.Event. Since the purpose of this component is to notify the sibling objects that someone has clicked on the button, we’ll define the event handler greenClickEventHandler() that will create and dispatch our custom event.
<?xml version=”1.0″ encoding=”utf-8″?>
<mx:Button xmlns:mx=”http://www.adobe.com/2006/mxml
width=”104″ height=”28″ cornerRadius=”10″ fillColors=”[#00ff00, #00B000]”
label=”Add Item” fontSize=”12″ click=”greenClickEventHandler()”>
<mx:Metadata>
[Event(name="addItemEvent", type="flash.events.Event")]
</mx:Metadata>
<mx:Script>
<![CDATA[
private function greenClickEventHandler():void{
trace("Ouch! I got clicked! Let me tell this to the world.");
dispatchEvent(new Event("addItemEvent", true));// bubble to parent
}
]]>
</mx:Script>
</mx:Button>
Listing 1. LargeGreenButton.mxml

Please note, that the LargeGreenButton component has no idea of who will process its addItemEvent. It’s none of its business: loose coupling in action!

In dynamic languages following naming conventions. Common practice while creating custom components is to add the suffix “Event” to each of the custom events you declare, and the suffix ”Handler” to each of the event handler function.

Here’s the application that will use the LargeGreenButton component:

<?xml version=”1.0″ encoding=”utf-8″?>
<mx:Application xmlns:mx=”http://www.adobe.com/2006/mxml
xmlns:ctrl=”controls.*” layout=”absolute”>
<ctrl:LargeGreenButton addItemEvent=”greenButtonHandler(event)”/>
<mx:Script>
<![CDATA[
private function greenButtonHandler(event:Event):void{
trace("Someone clicked on the Large Green Button!");
}
]]>
</mx:Script>
</mx:Application>

Listing 2. EventApplication.mxml

We have defined an extra namespace “ctrl” here to make the content of “controls” directory visible to this application. Run this application in the debug mode, and it’ll display the window below. When you click on the green button it will output on the console the following:

Ouch! I got clicked! Let me tell this to the world.
GreenApplication:Someone clicked on the Large Green Button.

While adding attributes to <ctrl:LargeGreenButton>, please note that code hints work, and Flex Builder properly displays the greenClickEvent in the list of available events of new custom component button.


Figure 1. The output of GreenApplication.xmxl

Our next component will be called BlindShoppingCart. This time we’ll create a component in the “cart” directory based on the TextArea.

<?xml version=”1.0″ encoding=”utf-8″?>
<mx:TextArea xmlns:mx=”http://www.adobe.com/2006/mxml
backgroundColor=”#ff0000″ creationComplete=”init()”>
<mx:Script>
<![CDATA[
private function init():void{
parent.addEventListener("addItemEvent",addItemToCartEventHandler);
}
private function addItemToCartEventHandler(event:Event){
this.text+="Yes! Someone has put some item inside me, but I do not know what it is. \n";
}
]]>
</mx:Script>
</mx:TextArea>

Listing 3. BlindShoppingCart.mxml
Please note, that the BlindShoppingCart component does not expose to the outside world any public properties or methods. It’s a black box. The only way for other components to add something to the cart is by dispatching the addItemEvent event. The next question is how to map this event to the function that will process it. When someone will instantiate the BlindShoppingCart, Flash Player will dispatch the creationComplete event on the component, our code calls the private method init(), which adds an event listener mapping the addItemEvent to the function addItemToCartEventHandler. This function just appends the text “Yes! Someone has put …” to its red TextArea.

The application RedAndGreenApplication uses that uses these two components LargeGreenButton and BlindShoppingCart.

<?xml version=”1.0″ encoding=”utf-8″?>
<mx:Application xmlns:mx=”http://www.adobe.com/2006/mxml” layout=”vertical”
xmlns:ctrl=”controls.*” xmlns:cart=”cart.*”>
<ctrl:LargeGreenButton addItemEvent=”greenButtonHandler(event)”/>
<cart:BlindShoppingCart width=”350″ height=”150″ fontSize=”14″/>
<mx:Script>
<![CDATA[
private function greenButtonHandler(event:Event):void{
trace("Someone clicked on the Large Green Button!");
}
]]>
</mx:Script>
</mx:Application>
Listing 4. RedAndGreenApplicatoin.mxml

Let’s go through the sequence of its events:
When the green button is clicked, the greenButtonHandler is called and it creates and dispatches the addItemEvent event on itself. The event bubbles to the parent container(s) notifying all listening parties of the event. BlindShoppingCart listens for such event and responds with adding text. Run this application, click on the button, and the window should look as follows:

Figure 2. The output of RedAndGreenApplication.mxml

And one more time: the green button component shoots the event to the outside world without knowing anything about it. That is very different from the case when we would write “glue” code like cart.addEventListener(“click”, applicationResponseMethodDoingSomethingInsideTheCart).

Sending Data Using Custom Events

To make our blind shopping cart more useful, we need to be able not only to fire a custom event, but this event should deliver description of the item that was passed to shopping cart. To do this, we’ll need to create a custom event class with an attribute that will store application-specific data.

This class has to extend flash.events.Event, override its method clone to support event bubbling, and call the constructor of the super class passing the type of the event as a parameter. The ActionScript class below defines a property itemDescription that will store the application-specific data.

package cart {
import flash.events.Event;

public class ItemAddedEvent extends Event {
var itemDescription:String; //an item to be added to the cart
public static const ITEMADDEDEVENT:String =”ItemAddedEvent”;
public function ItemAddedEvent(description:String )
{
super(ITEMADDEDEVENT,true, true); //bubble by default

itemDescription=description;
}

override public function clone():Event{
return new ItemAddedEvent(itemDescription); // bubbling support inside
} }
}
Listing 5. The custom event ItemAddedEvent

The new version of the shopping cart component is called ShoppingCart, and its event handler extracts the itemDescription from the received event and adds it to the text area.

<?xml version=”1.0″ encoding=”utf-8″?>
<mx:TextArea xmlns:mx=”http://www.adobe.com/2006/mxml
backgroundColor=”#ff0000″ creationComplete=”init()”>
<mx:Script>
<![CDATA[
private function init():void{
parent.addEventListener(ItemAddedEvent.ITEMADDEDEVENT,addItemToCartEventHandler);
}

private function addItemToCartEventHandler(event:ItemAddedEvent){
text+="Yes! Someone has put " + event.itemDescription + "\n";
}
]]>
</mx:Script>
</mx:TextArea>

Listing 6. ShoppingCart.mxml

There is a design pattern called Inversion of Control or Dependency Injection, which means that an object does not ask other objects for required values, but rather assumes that someone will provide the required values from outside. This is also known as a Hollywood principle: ”Don’t call me, I’ll call you”. Our ShoppingCart does exactly this – it waits until some unknown object will trigger event it listens to that will carry item description. Our component knows what to do with it, i.e. display in the red text area, validate against the inventory, send it over to the shipping department, and so on.

Next, we will completely rework our LargeGreenButton class into NewItem component – to include a label and a text field to enter some item description, andthe same old green button:
<?xml version=”1.0″ encoding=”utf-8″?>
<mx:HBox xmlns:mx=”http://www.adobe.com/2006/mxml” >
<mx:Metadata>
[Event(name="addItemEvent", type="flash.events.Event")]
</mx:Metadata>
<mx:Label text=”Item name:”/>
<mx:TextInput id=”enteredItem” width=”300″/>
<mx:Button
width=”104″ height=”28″ cornerRadius=”10″ fillColors=”[#00ff00, #00B000]”
label=”Add Item” fontSize=”12″ click=”greenClickEventHandler()”/>
<mx:Script>
<![CDATA[
import cart.ItemAddedEvent;
private function greenClickEventHandler():void{
trace("Ouch! I got clicked! Let me tell this to the world.");
dispatchEvent(new ItemAddedEvent(enteredItem.text));
}
]]>
</mx:Script>
</mx:HBox>

When we look at our new application with new ShoppingCart and NewItem components, it is almost indistinguishable from the original one. If we would of kept the old class names, we could of used the old application.

<?xml version=”1.0″ encoding=”utf-8″?>
<mx:Application xmlns:mx=”http://www.adobe.com/2006/mxml” layout=”vertical”
xmlns:ctrl=”controls.*” xmlns:cart=”cart.*”>
<ctrl:NewItem />
<cart:ShoppingCart width=”350″ height=”150″ fontSize=”14″/>
</mx:Application>

Listing 7. RedAndGreenApplication2.mxml

When the user enters the item description and clicks the green one, the application creates a new instance of the ItemAddedEvent, passing the entered item to its constructor, and the ShoppingCart properly properly displays selected ”New Item to Add” on the red carpet.

Figure 3. The output of the RedAndGreenApplication.mxml

Making components loosely bound simplifies development and distribution but comes at higher cost during testing/maintenance times. Depending on delivery timeline, size and lifespan of your application you would have to make a choice between loosely coupled or strongly typed components. One last note. The itemDescription in Listing 2 does not have access level qualifier. It’s so called package level protection. The ShoppingCart can access itemDescription directly, but the classes outside of “cart” package can’t.

Event-driven programming is nothing new – we routinely did it in mid-nineties in such toos as PowerBuilder or Visual Basic. In Java, it also exists as an implementation of Observer/Observable pattern. But entire Flex programming is built on events, which makes coding a lot simplier.

Yakov Fain

Comments (3)

 

Grey Line

I met with Jeff Whatcott from Adobe a couple of times, and have to admit that he’s a top-notch professional product manager. He knows how to talk the talk, and I mean it. But let me explain you what I mean. Intelligent Enterprise magazine has published an interview with Jeff on Rich Internet Applications. Of course, Jeff likes Adobe Flex technology for RIA (surprise, surprise).

The question is how do you say it properly? Especially when these journalists are asking questions like what do you think of AJAX, as if they do not understand that you are into Flex and for a good reason. Flex developers really like this product, but I’d split them into three categories based on how they’d answered the question, “What do you think of AJAX”.

Junior programmers and amateurs would simply say “AJAX sucks”. That’s why they are still junior.

Experienced Flex developers would say AJAX sucks because… and they’d give a half a dozen of valid reasons (I put myself into this category).

And the top notch professionals like Jeff, would put it right (no irony is intended here). Let’s read it, enjoy it, and most importantly learn how to talk the talk.

The journalist asks, “How would you compare Flex with alternative routes to RIAs such as Ajax, JavaScript, Active X and Microsoft’s Windows Presentation Foundation?”

This question is wrong for various reasons. First of all, you can not compare AJAX with Flex as the former is a set of techniques for creation of richer Web applications, while the latter is a product of a particular vendor – Adobe in this case.

Also, asking Adobe product manager what he thinks about AJAX or WPF, is like asking me if I like my wife better that Joe Smith’s one.

But Jeff answers the question gracefully. He says, “There are lots of ways to build RIA user experiences, but you have to use the right tool for the job. There’s no one tool that’s right for every solution. Ajax is really great for bringing incremental improvements to existing Web applications. If you have a big Web app and you want to eliminate page refreshes here and there and bring some improvements to the user experience, it’s a great fit because it follows the same [development] model. It’s relatively easy for Web application developers to understand and adopt Ajax for simple things, and that takes you pretty far.”

I’d like to emphasize this statement, “If you have a big Web app and you want to eliminate page refreshes here and there and bring some improvements to the user experience, it’s a great fit”. Absolutely. AJAX is great tool for improving an old application here and there. Three Botox shots around the mouth. What’s that under your left eye? Let me fix it real quick. Ouch!! Done. It’s still Joan Rivers, but hey…I do not mind watching her at the Red Carpet this Sunday. Sure, Melissa looks better…a little.

But let’s get back to Ajax. Jeff continues, “Ajax gets a lot more complicated and more challenging to use when you’re building full-on, large-scale rich Internet applications that are very data intensive and very graphical. A lot of Ajax frameworks are fairly lightweight and not terribly complete“.

Jeff has to be careful, so let me try to interpret this last statement. IMHO, “lightweight and not terribly complete” means scattered widgets and pieces of functionalities that are not even close to solid Flex framework offerings. Opponents of Flex often say that they do not want to commit to a proprietary technology (they refer to Flex). But they do not get it – since writing AJAX application manually is something that even AJAX proponents do not recommend- you’d have to select one of two dozen of immature AJAX frameworks and lock yourself right in this proprietary tool.

And Jeff rightly states so, “Some of the commercial-grade frameworks are more complete, but they’re often incompatible and can’t be mixed and matched. When you pick one, you are really making a long-term commitment as to how your software is going to be built, so it could be a fairly risky decision. Another problem with Ajax is that productivity tends to suffer because of the cross-browser compatibility issues that pop up when you’re dealing with very large-scale applications. It takes time to track down and fix all the bugs. Flex is most powerful in these large-scale, complex development scenarios and it solves all the issues I just mentioned. “

Since I do not work for Adobe, I have a luxury to say that Flex is not a silver bullet either, you still need to write code and deal with non-trivial tasks daily. But it is a good and extensible platform, which can bring your enterprise Web application to a different level.

The next question was, “What about Microsoft Presentation Foundation?

I do not know what Jeff was thinking about their direct competition, but he gave an open answer without burning any bridges, “That’s an incredibly powerful tool set. It’s really cool stuff and good technology, but it’s still a little early. It’s not yet widely proven in a lot of rollouts, so there may be lurking issues that we don’t know about.”

I consider this interview as a good lesson on interviewing techniques. This does not mean that I will be answering the same way, but I’m taking my hat off to Jeff for his speaking skills. I mean it.

Yakov Fain
P.S. Having said all this, I respect people who are overcoming AJAX challenges on a daily basis. I also respect people who climb Everest.

Comments (2)

 

Grey Line

How Fast is Development in Flex?

Ask me what is the easiest way to build RIA apps and you do not have to wait for the answer: it’s Flex, of course. Ask me is it fast to develop in Flex and I will say “it depends”.

First, it depends where are you coming from. Literally. I’ve seen enough places where Struts/HTML is the only known UI technology. Meanwhile the business is running a huge VB app that changed hands 6 times before last developer left during the .com days.  Now everyone wants it on the Web, but expectations of the development complexity are distorted by the culture of straw houses.

“Nevermind that legacy Client/Server system took 10 man years to build. We have never done Struts/HTML app in more then 6 months and Flex is a “better HTML” so it should take 3 months in Flex, should it not?”

This rhetorical question brings me to the second point.

What is simple and straightforward in Flex, has been often out of the question, unthinkable in Web 1.0 applications. The paradox, that I call the “Home Depot Effect”, is that once the threshold of “possible” has changed, you want it all. It is easy to put the tiles, it is easy to do the lights, it is easy to build the patio, etc. Does it mean you are going to rebuild that old house in the same time you used to paint your Struts/HTML appartment?

Now you know what I meant by “it depends”.

Victor

Comments (3)

 

Grey Line

I have finished “fixes” on some project that was developed by typical J2EE team and needed to made work before it enters official beta. It has been extremely difficult to navigate and resolve and I would like to provide a brief checklist of symptoms you might want to review to see if your project is heading for trouble:

Symptom #1. The sizable project is built very much on Flex framework without layer of UI controls for common business and UI functionality. Typical of shops that think of MXML as another xHTML.

Problem: Impossible to enforce consistent behavior across multiple screens, cumbersome user input, complicated formatting and validation, tons of “cut and paste” spaghetti code and millions of bugs.

Solution: Extend MXML controls into business controls that would make reusable UI elements with ROBUST and SIMPLE interface. Make sure that your controls are perfect to the end-users of your application. Strive for data-driven application programming.

Symptom #2. Conventional J2EE middle tier that does nothing but repackages data for DB/XML communications.

Problem: It usually does something in reality. It might prevent you from using transactional capabilities in database. It can hide errors from the back-end. It might contain bugs. Cause performance degradation and scalability issues.

Solution: Either go directly to the datasource or base your data entry systems on the model with client-centric updates. Provide direct feedback on the errors, transactional control, eliminate duplication and integration problems.

Symptom #3: Cairngorm framework for large application. I am going to get a lot of flame mail on that one.

Problem: Nevertheless, I was saying it 15 years ago, and I say it again – do not use framework unless you build application identical to the one the framework was built for. Unfortunately, RIA area is much wider than old “shopping cart/content management” Web we know of – there is slim chance that any framework will be more of help then a burden unless you indeed are building shopping cart. Framework is not a silver bullet, but rather a way to postpone design stage.

Solution: Start with class libraries. Build and verify reusable components early. You are in object-oriented, event-driven, real-world facing environment that has to be intelligent and friendly to the end-user. Break your application into libraries and modules as early as you can – it will pay off faster then you think.

Symptom 4#: Excessive use of binding.

Problem: You try to see dependencies, and it just never ends. Cycles, breaks, using binding for initialization, wrong timing – you name it. Debugging becomes time consuming and very challenging. As a result – untested code that seems to work.

Solution: Understand the difference between binding, initialization and types of the events you really want to listen to. Handle events locally in the business domain UI components. Do not force system to do more then it needs. In the event driven environment you really want to keep the noise down -especially for large applications.

Symptom 5#: No error handling, no logging statement and assertions in the code.

Problem: I can be wrong here. It is possible that the code is perfect and nothing is going to break ever. Otherwise, you are doomed. Seriously, bringing support phone into your bedroom is not thing you want to do. Postponing the problems after release date will get you in trouble.

Solution: I will blog a bit more next week and make sure we will release some of the internal tools in the circulation this month. There is no excuse not to use logging API and assertion in Flex.

Sincerely,

Anatole Tartakovsky

Comments (7)

 

Grey Line

Two conferences are running side-by-side competing for better developers. Looks like I will be staying in CA for extra day – Eclipse one is running through March 8th. It would be interesting to see what new tools will be available to Flex developers sharing Eclipse IDE with the rest of the world.

At Eclipse conference, I will be doing hands-on for a chance to “Show the light of Flex” to very advanced group of Java developers/toolmakers: http://www.eclipsecon.org/2007/index.php?not_accepted=0&page=sub/&id=4009&conference=2007 These are the people who define what next generation of Enterprise tools are going to be – with very interesting possibilities coming out of merging different technologies. Architecture of the future frameworks will depend on how well and seamlessly they would integrate with the current trends.

At 360Flex.org one I will be doing “Enterprise Applications” demo – how to build the “meat and potato” systems quickly and reliably having the resources available in the corporate world. The approach is very different, but the result is the same – the RAD development based on proven ideas of client-server programming applied to distributed/network-based topology. I’ll call the approach “getting-rich-quick” or some other name people feel good about.

It’s going to be a fun week – see you there and there.

Regards,

Anatole Tartakovsky

Š

Comments

 

Grey Line

JetBrains team is well known and respected in Java community for their excellent IDE called IntelliJIDEA. Java developers in-the-know know – Eclipse is bigger, but IDEA is better. Last year, I had to switch from IDEA to Eclipse, because I’ve been doing mixed Java/Flex development, and Eclipse was my only choice.

When JetBrains announced Ruby support in IDEA, it was clear that Ruby fans just won the lottery. The next question in my mind was, “How about supporting Adobe Flex languages – MXML and ActionScript?“ But this was the case when no new was bad news.

Today, I’ve got an email with a reference to a ticket opened by Michael Klishin in the IDEA’s bug tracking and project management database that asks for Flex support. Way to go, Mike! I’m with you.

JetBrains, go for it! Adobe Flex is here to stay, and having two Flex IDEs is better than one.

Yakov Fain

Comments (7)

 

Grey Line

We are entering an era of Rich Internet Applications (RIA), and many enterprise development managers are facing the dilemma – which way to go – remain with tried and true Java or .Net technologies or less know yet AJAX, Flex, OpenLaszlo or a number of other vendors. This article is an attempt to give a brief overview of what’s out there on the RIA market.

Historically there have been major shifts in the software industry. We moved from mainframes with dumb terminals to client/server. Users gained in convenience and productivity, and mainframe systems were patronizingly labeled as legacy. With the availability of the World Wide Web industry visionaries turned the tables: vendors and corporate IT had been eager to get rid of the complexity of client/server version management and technologists were sold on multi-tier computing. This time client/server was called legacy. Excited with server multi-threading, messaging, persistence, and similar toys, we pretend not to think that, at the end of the day, we’d have to trade user experience and productivity for the transparency of application deployment. And to make us feel better, we proudly called the new breed of applications “thin client.”

Now we are entering an era of RIA, which restores the power of desktop applications…inside downloadable Web page. RIAs run in a virtual machine (i.e., Adobe Flash Player or Java VM) and have the potential of becoming a full-featured desktop application soon. As opposed to just simply displaying Web pages delivered from some server machine, RIA really run on the client. Many of the data manipulation tasks (sorting, grouping, and filtering) are done locally like in the old client/server days. In three or four years most newly developed projects will include RIA technologies.
A rich Internet application combines the benefits of using the Web as a low-cost deployment model with a rich user experience that’s at least as good as today’s desktop applications. And, since RIAs don’t require that the entire page be refreshed to update their data, the response time is much faster and the network load much lower. Think of a globally available client/server application.

Let’s illustrate the difference between “legacy” Web and RIA with a shopping cart example. Non-RIA Web applications are page-based. Since HTTP is a stateless protocol, when the user moves from one page to another, a Web browser doesn’t “remember” the user’s actions on the previous page. As a common treatment of this “amnesia,” a user state is stored on the server side in the form of the HTTP session.
Consider the case of an online shopping session. It can go as follows:
1. The user initiates a search for an item on Web page #1.
2. The server processes this request and returns page #2 that may (or may not) contain the required item.
3. The user adds an item to a shopping cart that takes yet another trip to the server to create the shopping cart and store it on the server side. Then the server responds with page #3 so the user can either continue shopping (repeating the first three steps) or proceed to the checkout – page #4.
At the checkout the server retrieves selected items from the session object and sends page #5 to the user for shipping info. The data entered travels back to the server for storage, and the client gets back page #6 for billing information. After that page #7 will confirm the order and only then goes to the order completion page.
This simplest of online purchases consisted of seven roundtrips to the server. In striking difference to desktop applications, a few-seconds-per-page refresh is considered fast(!) for a typical Web application, and the commonly acceptable delay is up to eight seconds. Is the user motivated enough to complete the purchase? Think again, because your system gave him a chance to reconsider seven times in a row. Now assume that the network and/or server are slow…your potential customer went elsewhere.

Rich Internet applications eliminate the roundtrips and substantially improve system performance by doing a lot more of the processing on the client than a thin client Web application. Besides, RIAs are stateful: they accumulate the information right on the client! To put it simply, RIA isn’t a set of pages controlled by the server; they are actual applications running on the client’s computer and communicating with servers primarily to process and exchange data.

Both consumer-facing and enterprise applications benefit from being RIAs. It’s a well-known fact that e-commerce Web sites such as online ticket reservation systems and online retailers are losing revenues because users abandon shopping carts on non-responsive Web sites during the checkout process. Such Web sites result in lots of calls to the call center, a major operational expense in and of itself. The performance of any system operated by employees is critical to company productivity and RIAs provide a performance boost over HTML applications, while reducing operating and infrastructure costs.
RIA Platforms: The Major Choices

There’s more than one way to create RIAs that run in the client’s browser with the help of some kind of client engine. These are the most popular products or technologies:

  • A Java programmer can create Java applets. As mentioned, this solution has been available since 1995.
  • Using Adobe Flex you can create an ActionScript application for the ubiquitous Flash Player, a high-performance multimedia virtual machine that runs bytecode files in the SWF format (pronounced swif). The player’s JIT compiler converts the SWF bytecode to native machine code for fast performance. The later facility is specific to Flex 2, available since 2006. Although early versions of Flex were out in 2004, they didn’t support just-in-time compilation.
  • Microsoft Windows Presentation Foundation (WPF) was released as part of .NET 3.0 in November of 2006 and can be used to create both Internet and desktop applications (it also has the Everywhere version – WPF/E).
  • AJAX, a k a DHTML, born circa 1998. This solution was recently boosted with XMLHttpRequest API support for all major browsers. AJAX served as a wake-up call for the user and developer communities. It is often the first step on the migration path from the legacy Web to the world of RIA despite being seriously handicapped by having to support browser incompatibilities and a poor programming model.

Java

Even though the Java programming language became popular largely because of applets and the famous dancing Duke (http://java.com/en/download/help/testvm.xml ), applets haven’t become Java’s main use pattern. The main reason: the large footprint of the required JVM (currently 16MB). And there are other drawbacks. For instance, although Java Swing pushed a platform-independent look-and-feel, absent any good-looking off-the-shelf GUI widgets it was hard selling it to the public. In this regard Flash and Flex creators did a much better job with their eye-candy components. Or take audio and video integration. Today people are used to having streaming audio and video components embedded in Web pages. But the multimedia Java API remains rudimentary, to say the least.
There are some efforts to minimize the size of the JVM used by Web browsers and the Java Browser Edition project now needs “only” about 3MB to run a primitive Hello World applet. But this can’t compete with Flash Player 9, which managed to accommodate two virtual machines in a 1.2MB download that can run any RIA however complex.
Another issue with Java applets is that they don’t offer a seamless download of the proper version of the JVM along with the applet. Flash Player’s express install does precisely that.
Having said that, I must acknowledge that Java Swing is a very mature and robust technology for creating GUI applications delivered either over the Web or installed on the desktop. You can do literally anything with Java Swing – if you can afford it. No, you don’t pay licensing fees, but because of the longer development cycle and need to engage expert programmers, industrial-size Swing projects are usually quite expensive to build and maintain.

Adobe Flex 2

Flex 2 applications run cross-platform in a ubiquitous Flash Player 9 that’s a lightweight virtual machine. The platform includes:

  • an XML-based language called MXML that supports the declarative programming of GUI components targeting designers;
  • the standard object-oriented programming language, ActionScript 3.0, based on the latest ECMAScript specification;
  • server-side integration via Flex Data Services giving client applications transparent access to the world of J2EE;
  • charting components, access to multimedia controls, etc;
  • and an Eclipse-based full-featured IDE with automated deployment, debugging, and tracing facilities.

The Flex 2 platform is easily extendable and integrates well with server-side Java, ColdFusion, PHP, Ruby, ASP, and the like.The SWF file format is open, and there are third-party open source products that offer tools for creating RIAs delivered by Flash Player like OpenLaszlo from Laszlo Systems. This is what comes at no cost with Flex 2:

  • MXML – an XML-based declarative programming language for creating GUI.
  • ActionScript 3.0 – an object-oriented language similar to Java.
  • Flash Player 9 – a virtual machine with a tiny footprint that lives inside a Web browser and runs your compiled bytecode (.SWF).
  • Command-line compilers and debugger.
  • Flex Framework, which includes a library of well-designed GUI component: buttons, tab folders, data grids, tree controls, animated effects, and more.
  • Flex Data Services Express (FDS) – a template Web application deployed in a J2EE server to communicate with ActionScript client application run by Flash Player. FDS Express is limited to a single CPU, which makes it useful only for learning purposes.

The following Flex tools require a purchased license:

  • Flex Builder – the Eclipse-based IDE
  • Charting component
  • Flex Data Services Departmental, 24×7, 100 concurrent users
  • Flex Data Services Enterprise, 24×7, unlimited users

In a nutshell, the process of creating a basic Flex 2 application consists of the following steps:
1. Design application by adding MXML components like this button:
<mx:Button label=”Place Order” click=”processOrder(event)”/>
If you use Flex Builder IDE, you can apply drag-and-drop techniques. Alternatively, you can write the MXML as text.
2. Write the code in ActionScript per your functional specification, for example:
private function processOrder (event:Event):void{
//The business logic goes here
}
3. Compile the code: The Flex compiler automatically converts MXML into ActionScript and creates bytecode output in a form of an SWF file to be run in Flash Player 9 or above. You’ll enjoy a fully automatic compilation process if you use the Flex Builder IDE.
4. Deploy the SWF file and the wrapping HTML page in the Web server of your choice. The deployment process and creating the wrapped can be completely transparent if you use the Flex Builder IDE.
More advanced Flex applications can include interaction with the server-side systems through FDS, which provides remote access to server-side Java objects and Java EE components, extensive messaging support (including JMS integration), synchronization with persisted data, and integration with other persistent technologies.
WPF

Recently released Microsoft’s Windows Foundation Platform, or WPF uses an XML-based declarative programming language called XAML to create GUIs and C# as a general-purpose programming language. WPF is suitable for creating both RIA and desktop applications. XBAP stands for XAML Browser Application and it’s a WPF way of creating RIAs that runs in Internet Explorer.
Microsoft has released a Beta version called WPF/E that will run on some non-Windows platforms (this version uses substitutes C# with JavaScript). While living in a sandbox, XBAP will have access to all .NET 3.0 functionality but WPF/E won’t. Common Language Runtime (CLR) is the client’s WPF engine.
To create WPF applications, developers can use Microsoft’s Visual Studio 2005 IDE with installed .NET 3.0 extensions. The next version of this IDE, called Orcas, will include a visual GUI designer. WPF developers use the same code base for writing XBAP and desktop applications: they just enclose the code sections that aren’t allowed in XBAP into the ifdef blocks.
Microsoft XAML code looks similar to Adobe’s MXML. Even though today’s Flex 2 is a lot more mature than WPF, Microsoft has an established developer base, while Adobe traditionally catered to designers, and its main goal today is to convince enterprise developers (particularly the Java camp) that Flex can be a tool of choice for creating business RIAs.

AJAX

While the term AJAX was coined by Jesse James Garret in February of 2005 and is partly rooted in the asynchronous XmlHttpRequest implemented by Mozilla, lots of developers have used Microsoft’s version of XMLHttpRequest and alternative techniques like IFrame since 1999. These techniques facilitate synchronous and asynchronous communications between the script in a page and server-side code. The main problem with AJAX is that despite its popularity it has no technical foundation. While the other solutions we mention here are based on rock-solid virtual machines, there’s no standard VM for AJAX. Each browser implements AJAX building blocks differently. There’s a chance that deployed AJAX application will require code changes with each new browser release. Wait, let’s rephrase that: there’s a chance that a deployed AJAX apps may run as is on a new browser release. Do you want to take chances with your business?
That said, Internet giants like Google, Yahoo, and Amazon are building AJAX apps on top of their own abstraction layers such as Google Web Toolkit (GWT). Because of the immature level of the technology, these abstract layers need constant vendor attention as soon as changes appear.

AJAX Shortcomings

An ability to create flicker-free Web apps without buying more software is AJAX’s big appeal. You may have heard the chant “AJAX is free.” Here’s the simple translation: no commercial AJAX tool is worth paying for. There are hundreds of libraries, toolkits, and control sets that give you the impression that AJAX applications are cheap to develop and strategically safe since there’s no vendor lock-in. Actually, there is vendor locking because you won’t manually write JavaScript code and will have to pick an AJAX library of some vendor. Now think about it: starting from the ground up you need a communication layer, messaging and remoting mechanisms, an HTTP sniffer, a library of UI components with shared objects and event models, a visual IDE that understands these components in design time, and a debugger that accommodates all this stuff. On top of that, there’s internationalization support, accessibility for the disabled, and support for automated testing tools.
You really think you’re safe with mix-and-match from different vendors? If the answer is yes, you must be working for a software company in the RIA business. Coming to reality, long development cycle, lack of free quality GUI components, and the shortcomings listed below make AJAX less appealing and, actually, the most expensive way of creating RIAs.
These are some of AJAX’s current drawbacks:

JavaScript development tools are limited due to the dynamic nature of the language, and debugging any DHTML/JavaScript mix is a pain. Yes, Google’s GWT can spare you from writing JavaScript manually, but at the end of the day, it’s still JavaScript that has to be deployed in production. When the system isn’t working and time is limited, what are you going to use to debug it – the real page of Java mock-up?

Tons of JavaScript source code has to go over the wire to the client to be interpreted by the browser. We’re talking about business applications, not some proof-of-concept demo.

Web browsers will happily display your application even if a piece of JavaScript didn’t arrive at the client. You won’t know of a problem exists until you execute the particular use case.

A simple right-click followed by the “View Source code” menu option would reveal your business application code. Better yet, all this code resides as plain text in the browser cache on disk. Because of this, you have to drop all the code comments and use obfuscators to protect your code from being stolen.

HTML rendering is slow: think of a data grid that contains 5,000 records. How long are you ready to wait for your sales report?

Any data manipulation by JavaScript is inherently slow because JavaScript is an interpreted, not a compiled language. We’re talking thousand of times slow.

The code is more vulnerable to hacker attack, a fact that was proved recently by a worm that stole a bunch of mail addresses from Yahoo address books.

AJAX doesn’t support server push. The server-side application can’t publish the data directly to the client. AJAX applications have to poll the data from the server at specified time intervals without knowing if the data is there or not.
It’s not easy to find good AJAX programmers.

To summarize, if you’re developing a new enterprise business RIA from scratch, AJAX may not be the way to go. Choose a solid application development environment that offers a virtual machine at runtime like Flex/Flash, Java, or WPF. Any of these environments is more productive than AJAX. If you already have AJAX applications you can nicely integrate new Flex RIAs in existing AJAX applications using tools like FABridge from Adobe for communicating between AJAX and Flex.

During AJAX’s first year of life, every article or book on the subject mentioned Google Maps and Gmail, and various type-ahead samples: you enter the first zip code digit in a text field, and it suggests your possible choices based on your input without a page refresh. Today, you can read about a number of AJAX applications, including ones that work with photo images loaded from the popular flickr.com Web site.

Lastly, I’d like to make it clear that popular comparisons of Flex versus AJAX are simply wrong, since Flex is a framework and complete development platform, while AJAX is a set of techniques. To compare apples to apples, you should compare products like Flex against GWT (Google) and the like.
Other RIA Solutions

OpenLaszlo

OpenLaszlo from Laszlo Systems is an open source product that lets you create applications that can be deployed as DHTML or Flash Player files. The ability to generate DHTML code made it a good candidate for developing applications for mobile devices, and Sun Microsystems has recently partnered with Laszlo Systems to bring this technology to the Java mobile space. This is direct competition for Adobe Flash Lite.

GWT

GWT stands for Google Web Toolkit lets you write programs in Java and convert them to JavaScript so they can be delivered as AJAX Web applications.
An interesting GWT feature is that it compiles Java into various versions of JavaScript to accommodate the specific needs of different Web browsers. GWT comes with a library of extensible components. The number of these components was limited, but that will probably change soon, because it’s Google.

NexaWeb

NexaWeb offers a Java-based thin client that doesn’t require any additional installation on the user’s desktop. The application’s state is controlled by a small Java applet running on the client. This applet communicates with the NexaWeb Java EE application as needed. To avoid issues related to the version of the Java Runtime Environment installed with the Web browser, NexaWeb uses JRE 1.1 for its applet.

Some Pragmatic Flex/Java Considerations

Cool technologies come and go. Only some of them settle down in the toolbox of a professional programmer working on enterprise business applications. The technical excellence of any software is important, but it’s not the only component in its success.

The Learning Curve: Reuse of Skills and Code

One important concern of any development manager is the availability of a large pool of people who know a particular software. There are plenty of Java programmers with the skills required to develop Web applications, and the good news is that enterprise Java developers with servlet/Java EE programming skills or Java Swing experience will find the Flex path very easy.
Java and ActionScript 3 are very similar; Eclipse is a familiar environment for many Java developers. Since Flex piggybacks on Java EE and browser technologies, a server-side Java programmer should be able to correlate his current skills with the development process in Flex. Java Swing developers will instantly spot similarities to Java event and layout models. In our experience, the typical ramp-up time for motivated Java developer is two weeks. The best part is that Flex seamlessly integrates with existing Java server code of any flavor – POJO, EJB, Hibernate/Spring, or JMS, so the server-side part can literally remain unchanged.
Application Security
Another important consideration is the security of Flex/Java applications. Flex server-side security management is quite extensive, and it lets you use either container offerings or custom security providers via declarative XML binding. There are a couple of challenges since Flex supports multiple protocols, so Java EE security that relies only on HTTP sessions has to be extended, but it’s a simple and well-documented process. On the client side, it builds on Flash Player security that’s known for its lack of serious security flaws. You have a built-in security manager that has all the standard protection for cross-domain and zone access. Corporations can further restrict the code they get from third parties by wrapping the code loaders in additional security managers.
Flex GUI Performance
Java Swing is a tried and true tool for developing responsive GUIs in demanding applications like stock trading and online auctions. Flex is capable of providing near-real-time data rendering to the GUI and very high refresh rates on large data sets. Flash Player 9 is the high-performance modern virtual machine with precompiled optimized code and a just-in-time (JIT) machine code compiler.

Shorter Development Cycle
It’s very possible to build the client side of a real-time portfolio display integrated with news feeds and graphs in about 200 lines of Flex 2 code. A similar Swing program (even if it’s created with commercial IDEs) would be several times larger.
A decent Flex developer should be able to prototype (short of server processing) most of the UI for a specific trading system by the end of the first week. If you’re lucky and system integration went okay, you can add the collaboration features and multimedia – with the total client code base for the whole project coming within 1,000-1,500 lines. This is definitely not possible with Swing. Of course, some people will say modern Java IDEs generate lots of boilerplate code automatically, but this is still the code that someone has to read, understand, and fix if needs be.
Having said all this, there is a big difference between an application prototyping and delivering a final product – you still need to write code, create new components extend ActionScript classes and implement interfaces. Flex is not a magic wand.
Flex: Room for Improvement

While many programmers who dealt with previous versions of Flex are really happy now that they have a professional Eclipse-based IDE, Java programmers are spoiled by the variety of excellent and responsive IDEs. Flex Builder helps a lot in writing Flex code, but it’s not as Flex Builder helps a lot in writing Flex code, but it’s not as sofisticated and elegant as it could have been. It’s even not as good as its daddy Eclipse.

While you can use Flex just to connect to your existing applications written as JSP or any other HTTP-compatible technologies, you’ll get performance gain if you’ll use Flex remoting and messaging that is build on fast Adobe proprietary protocols called AMF3 and Real Time Messaging Protocol (RTMP). To take advantage of these benefits you have to purchase Flex Data Services licenses, while may not be affordable for small businesses.

Connection Management

Flex provides an extensive infrastructure for managing connections between the Web browser and the server. It lets you specify all the protocol details for the RTMP, HTTP, HTTPS as well as plain socket connections. You can then specify the order in which the protocols should be tried due to availability/firewall issues. You also get alternative real-time push or pull connections on additional protocols, a direct socket API, and tons of low-level hooks that let you build any protocol you want.

Flex and Agile Development

In mid-‘90s PowerBuilder and Visual Basic were the tools of choice in the client/server field. Software developers didn’t really worry about what was under the hood, but more importantly, they were business users’ best friends. They could do stuff quickly, or using the modern jargon, they were agile programmers without even knowing it. They’d ask the business user Joe, “How do you usually do your business? What would you like to have on this screen? Describe the steps of your business process.” Most likely Joe wouldn’t know all the answers, but this was okay, because developers could come back to the user the next day with a working prototype. This was easy with PowerBuilder’s DataWindow. When Joe-the-user saw the prototype, his glassy look all of a sudden would become friendly and understanding. Now Joe was back in control: “No, you did this part wrong, I wanted it different.” No problem, developers would return with the changes the next day (not next month, but the next day!).
Developers didn’t really know how DataWindow worked, but they trusted this component. PowerBuilder used event-driven programming model, which was clean and simple. Object A triggers event XYZ on object B, and this event can carry a payload – the data that object B needs to operate. Using modern jargon it’s called Inversion of Control or Dependency Injection design pattern. What’s important is that the object B doesn’t know about object A. On the same note, if object B needs to return the result of some internal function back, it would broadcast this result “to whom it may concern” by triggering one of its own events. This is loose coupling in action.
The mentality of many Java programmers was different. They’d assign lower priority to the user’s windows and spend most of their time designing a multi-tier system that didn’t depend on any specific look-and-feel and could be universal. Meetings with Joe would be rare because they couldn’t create a decent prototype fast. Fancy IDEs with GUI designers like Matisse weren’t in the picture yet and, more importantly, Java programmers were thinking big: UML, design patterns, application servers, and clustering. They enjoyed the programming process for itself. They didn’t like the mindset of old-fashioned PowerBuilder or Visual Basic programmers who were thinking windows and screens.
With Flex you started to care about the business users again. You can change the prototype twice a day, and Joe can do the same with his business requirements. No pile of project documentation is needed. The napkin is back and it works. Flex architects can give the server-side Java team the final okay only after Joe is 100% happy.
Besides, with Flex we can have the best of both worlds: the source code of the Flex framework is available, we can learn how it works inside, and override some functionality with what suits our needs better.
Working with Flex promotes agile development, where the people we build the software for are the driving force. Agile development methodology suggests minimizing each development cycle to mitigate the risk of delivering something to the users that they don’t want. Agile development encourages frequent face-to-face meetings with the end users as opposed to preparing and sending documents back and forth.

Summary

This quick overview of major RIA-enabling technologies and various approaches to making Web applications richer. It’s by no means a complete list: new commercial and open source RIA frameworks and components arise every day. Regardless of what RIA tools you are going to select, start your evaluations now to get a competitive edge.

Yakov Fain

Comments (5)

 

Grey Line

Modules or RSLs, whatever way you partition your Flex system, if you are delivering it over the public web you want to keep the size as small as possible. What are the best options?

Flex compilers support -link-report option. It let’s you produce a file of the linker dependencies found during the build of your SWF. Then there is a matching -load-externs option that let you specify the classes you do not want to link, but rather prefer to extern. Conveniently, -load-externs anticipates the input to be in exactly the same XML format as is produced by -link-report.

Speaking of modules and applications – just as an example case – this pair of options enables you to extern for the module everything, that will be loaded by the application. You build your application producing -link-report, then apply it for the module (see Flex docs for exact details). However, if you plan to ever reuse the same module for the different hosting application, this technique is not applicable. You’d need to rebuild the module.

There is an opposite way of using -link-report option. If you use compiler’s option –include you can have application merge-in all classes required by your libraries .

In this scenario, you run -link-report on the module and instead of optimizing the module, you optimize the application. No need to rebuild your modules to satisfy every individual application – they stay 100% reusable. Instead you tune your applications.

And, speaking of size, do not forget the -debug option. By turning it to false you may strip up to 30% of size taken by debugging information. By the same token, you may want to recompile framework.swf from Adobe Flex Framework source files to take it’s size down in the first place, prior to resorting to –include.

Keep it small.

Victor

Comments (1)

 

Grey Line

In XML, namespaces are used to avoid potential naming conflicts with other components having the same names. Since Flex lets you program in MXML and in ActionScript 3, I’ll go over the syntax of namespaces in both of them. Familiarity with Soprano family is a pre-requisite for reading this article.

Namespaces in MXML

MXML applications start with the <mx:Application> tag that includes xmlns property:

<mx:Application xmlns:mx=”http://www.adobe.com/2006/mxml” layout=”absolute”>

The namespace mx:xmlns refers to the URI http://www.adobe.com/2006/mxml that lists valid MXML tags. Open the file flex-config.xml, and you’ll find there an XML element that links this URI to the file mxml-manifest.mxl, which list all MXML components. Here’s an extract from this manifest file:

<component id=”ButtonBar” class=”mx.controls.ButtonBar”/>
<component id=”Canvas” class=”mx.containers.Canvas”/>
<component id=”CheckBox” class=”mx.controls.CheckBox”/>
<component id=”ColorPicker” class=”mx.controls.ColorPicker”/>
<component id=”ComboBox” class=”mx.controls.ComboBox”/>

If you want to use one of the standard MXML components, specify the prefix mx for each of them. For example, to use MXML Label, you write the following:

<mx:Label x=”111″ y=”81″ text=”Hello World”/>

If you are going to create custom Flex components, keep them in a separate namespace to avoid naming conflicts. For example, if you are going to develop a custom Tree component, introduce another namespace, for example with the URI com.enron.controls.* as shown below:

<mx:Application xmlns:mx=”http://www.adobe.com/2006/mxml”
xmlns:lib=”com.enron.controls.*” >

<lib:Tree id=”tree” width=”50%” height=”100%”…>
</lib:Tree>
</mx:Application>

This sample defines two namespaces: mx and lib. The

notation means that we are planning to use a Tree component from the namespace that we called lib. As you can guess, I assume that you are going to program this Tree component in the ActionScript’s package com.enron.controls and will have to provide either the code of our Tree component or the SWC library that includes this Tree.The namespace URI tells Flex where to look for the file implementing this component. You can either create a subdirectory com/enron/controls in the application’s directory, or preferably keep it in a separate location that is included in the classpath of your application (read about flex-config.xml file and the source-path tag in Flex documentation). Since we’ve defined two namespaces here, we can use components available in any of them.

You can also specify so-called local namespace using notations like xmlns=”*” or xmlns:mylocal=”*”, which tells Flex to look for components that are located in the same directory as MXML file or, in case of Flex Data Services, in the /WEB-INF/flex/user-classes directory.

Namespaces in ActionScript 3
Namespaces in ActionScript 3 as well as in MXML are used to control/limit the scope (visibility) of the methods, properties or constants. They are also used to avoid naming conflicts in cases if you create your own custom components that may have the same names as the Flex Framework or other vendor’s counterparts.

You can think of access control keywords public, private, protected and internal as a built-in name spaces. If a method has been declared as

protected calculateTax(){}

you can say that the method calculateTax() has a protected namespace. But AS3 allows you to define your own namespaces to be used instead of these standards language qualifiers.

To introduce your own namespace, you need to perform the following steps:

- Declare a namespace
- Apply the namespace
- Reference the namespace

Let’s write a simple program for an accountant who calculates taxes, but customers that belong to mafia should pay only half of the amount. To do this, we’ll start with declaring two namespaces called regular and soprano. This is the content of the file soprano.as

package com.enron.namespaces {
public namespace soprano=”http://www.enron.com/namespaces”;
}

Please note that the use of a URI in the namespace declaration is optional. The listing below does not use any explicit URI, but the compiler will generate one. This is how the namespace called regular may look like (it’s defined in the ActionScript file called regular.as):

package com.enron.namespaces {
public namespace regular;
}

To apply the namespaces, we’ll define a class Tax with two methods calcTax() that will differ by the namespace access attribute and by the amount of “calculated” tax. The ActionScript class Tax may look like this:

package com.enron.tax{
import com.enron.namespaces.*;
public class Tax
{
regular static function calcTax():Number{
return 3500;
}
soprano static function calcTax():Number{
return 1750;
}
}
}

The testing class TextTax looks like this:

package com.enron.test
{
import com.enron.namespaces.*;
import com.enron.tax.Tax;
import mx.controls.Alert;

use namespace regular;
// use namespace soprano;
public class TestTax
{
public static function myTax():void {
var tax:Number;
tax=Tax.calcTax();
Alert.show(“Your tax is “+ tax,”Calculation complete”);
}
}
}

Since we apply the namespace for the regular customer, s/he will have to pay the tax amount of $3500. The MXML code that uses TestTax is shown below.

<?xml version=”1.0″ encoding=”utf-8″?>
<mx:Application xmlns:mx=”http://www.adobe.com/2006/mxml”
layout=”absolute” creationComplete=”initApp();”>
<mx:Script>
<![CDATA[
import com.enron.test.TestTax;
public function initApp():void {
TestTax.myTax();
}
]]>
</mx:Script>
</mx:Application>

The output of this program looks as in a screenshot below.

Switch to another namespace by changing the use statement to look like

use namespace soprano;

and the amount of tax to pay will by substantially lower. Besides the directive use that affects the entire block of code, AS3 allows more fine grained notation to refer to a specific namespace with a name qualifier (a double colon). In our example, this may look like this:

tax = Tax.soprano::calcTax();

This is the output of the TextTax.mxml for regular customers. For obvious reasons I do not show the output of this program for Soprano family members.

Using namespaces provides additional means of the visibility control (especially if you have something to hide). The methods, class properties of the constants can be physically located in different packages, but marked with the same namespace qualifier, and a one-line namespace change can engage a completely different set of methods/properties across the entire application.

Yakov Fain

Comments

 

Grey Line

Software engineers of Farata Systems present on several conferences every year during which they enjoy learning from others and share their accomplishments. Below are our confirmed presentations for the Spring of 2007.

1. EclipseCon 2007, March 5-8, San Jose, CA.
Anatole Tartakovsky will present on Rapid Application Development of Rich Internet Applications with Eclipse plugins.

2. Flex 360, March 5-7, Santa Clara, CA.
Anatole Tartakovsky will present on Using Flex for Business Intelligence and will demo a number of Flex Builder plugins.

3. AJAXWorld 2007, March 18, New York, NY.
Yakov Fain and Victor Rasputnis will run a one-day hands-on Flex bootcamp. During this event we’ll be also paticipate in a book signing event for our new book on RIA Development with Adobe Flex and Java .

4. SOAWorld Conference, June 25-27, New York, NY.
Yakov Fain will present on “SOA, RIA and the Human Factor“.

Please feel free to contact us either before, or during the conference for any formal or informal disscussions.

Thanks,
Yakov Fain

Comments (2)

 

Grey Line

I was thinking about using the FDS Express on a small community Web site, namely Princeton Java Users Group that I run. This is 100% non-profit pretty simple Web site. It’s current version runs on Java Struts and MySQL. I’d be happy to use Flex/FDS to replace Struts, but the licensing of FDS Express may not allow me to use it in the real world scenario. Here’s the extract from the Peter Ent’s blog where he explains the limitation of this version”
“Q2: How do you quantify the limitations for Flex Data Services Express?

A: Flex Data Services Express is production software that can be deployed only on a single, non clustered CPU. The Express license does not allow (1) install, use or access of Adobe Flex Data Services Express software on more than one CPU (2) cluster any CPUs, and/or use load balancing software or hardware; and (3) can not deploy any unique application on multiple disconnected single CPUs, including kiosks and other such devices.”

This makes it literally impossible to use it on a setup where the site is hosted by an ISP, because they are running multi CPU boxes. I know that theoretically you might be able to ask your ISP to do a special setup for some kind of  a VM that is configured to use one CPU, but again, is it real?  The other choice is to find in the attic one of these old single CPU boxes and host the site on your own. But it’s a hassle.

FDS Express can be used for education (does someone who runs it on a Core 2 DUO CPU violates the license?).  I wonder if anyone can suggest the use of FDS Express for non-commercial Web sites? Can Adobe make some changes to the Licensing agreement to allow wider use of FDS Express?

Yakov Fain

Comments (5)

 

Grey Line

This year started with a surge of requests to work on Flex projects. We need to grow – we are looking for Flex developers to work on various projects. Our small company has very good reputation on Wall Street, and to maintain this status we always cherry pick people we work with. We are looking for seasoned developers. We need people who are motivated to work and master Flex.
Our requirements are pretty reasonable: you have to be smart, know how to survive in a corporate environment, deliver on time and what’s expected, and require very little supervision. Beside working knowledge of Flex 2 you should have experience developing applications using J2EE.
We can work with you either on the corp-to-corp basis, or offer full time employment. Please send your resume and salary/rate requirements at info at faratasystems dot com.
While we do not hire junior developers at this time, we will open a limited number of internship positions to talented students for the Summer of 2007. We hope that some of these interns will eventually start working for Farata Systems. Please get in touch with us early describing why you are a good candidate for being an intern. If does not matter where you live – you will telecommute – but good English and passion about developing rich Internet applications is a must.
Thank you,
Yakov Fain

Comments (6)

 

Grey Line

Last month, on my way home from my annual skiing vacation I spent a day in Zurich, Switzerland with may family and friends. This city is very nice and clean with well maintained buildings, large windows with watches, silver and gold, and people are well dressed and polite. This was during the day. But when on the evening we were walking along the central Banhofstrasse street to a famous place that sells long sausages, the street was empty. This was 7PM on Saturday! After dinner, my son with his friends decided to go to a night club. The hotel concierge said that there is not too many fun clubs in the city, but if they take a cab and go out of the city, there is a very popular place…

For some reason this reminded me of today’s Java, which is also a well established metropolis, with a multitude of different areas that are suitable to people with various tastes and needs. But…if you take a cab…there are some really fun places to be. And the names of these places are AJAX, Ruby, and Flex. Let’s not get into technical pros and cons of these three, but they are fun places to be. That’s for sure.

The Ruby crowd writes about happiness of programming. AJAX folks are routinely overcoming lots of challenges, but somehow enjoy the process anyway. Flex has a very live and vibrant online community, where almost each blog entry includes at least one occurrence of the word “Cool”. Are all these people faking orgasm? I doubt it.

After my recent talk at New York’s Java user group (this was about using Flex as a front end to Java), a guy from the audience stopped by and said, “This looks nice, but I can do all this in Java Swing”. He’s right, but how easy would it be? Do you enjoy the process of Java Swing programming? There is an old joke when a wife says to her husband, “My mother is dying, I know you did not like her that much, but it’s her last day, please do me a favor and kiss her.” The husband replied, “I’ll do it for you, but you should know that I’m not going to enjoy the funeral!”

The Java metropolis consists of three boroughs – the Server Side (sounds like an Upper East Side), Mobile, and UI. The first two areas seem to be fine. Working with Java Swing for desktop applications is not fun, but if you have enough time and money, you can create solid enterprise applications. But this is not the case when it comes to Java applets, or in other words Rich Internet Applications (RIA).

To put it simple, Web shines when you want to have seamless deployment. Initially it was just HTML, then JavaScript came in. These two exist ON ANY user’s PC, even though there are some issues with JavaScript incompatibility in different Web browsers.

Then Java was born with its concept of applets, which were the first rich Internet applications (remember the dancing Duke). But Java creators quickly decided that the development of the server side applications should be their strategic direction.
Up till now, Sun was not able to pull off an easy installation of a small footprint JVM on anyone’s client machine. This is where Flash Player shines. The fact that it exists on 98% of users PCs makes it pretty much equivalent of HTML or JavaScript when it comes to availability on the end-user machine. ITS ALREADY THERE. Do not get the right version of the Flash Player? One button click and 20 seconds later you got it. That’s why I believe that Flash Player is today’s best environment for rich Internet applications. Flash Player is a VM running compiled bytecode processed by JIT compiler.

Java is hopelessly lagging behind in the RIA field. Even Microsoft is giving up Windows-only approach with their WPF/E tool for RIA, where E stands for Everywhere. Today, they are behind Flash Player, but at least they are actively moving in this direction. Ironically, they are using competitor’s Flash Player to promote Vista as opposed to their own Windows Media Player.

But Java seems to be hopelessly losing in the RIA field. To the best of my knowledge, nothing exciting is cooking there. Yes, you can create a rich Internet application in Java, but if you take a cab…

Yakov Fain

Comments (1)