Farata Systems      

Here is my prediction for the “Killer App” for 2008. Ok, I am cheating here a little bit – some things are happening now, but are not exposed by the media. You know, the best investments are the one it is almost impossible to get into, unless you build them yourself.

On average, I am working with technologies that are from 2 to 4 years ahead of mass adoption. With that in mind I think 2008 will be the year we start the “personal assistant” war. The short term goal of the game is to make people heavily dependent on the simple and convenient services provided by slightly upgraded gadgets.

The first grand frontier (2008-2009) will be the battle for your cell telephone. 2007 was year of IP telephony making into the masses. Skype was good example of building proprietary platform and luring a lot of people in it. There were bunch of companies that make Skype look like Scrooge – offering similar services at fraction of the Skype’s price. My favorite scheme is MagicJack – for $20 bucks a year you can have unlimited phone service in the US or anywhere on the planet for that matter – while robbing AT&T and other telecoms. There is a number of products coming to market that are going to be just as good for you and just as bad for telecoms. Obviously, it will be followed with legal changes in the next few years that will change the way we pay for regular phones. Second, we will stop using old phones altogether.

It is not too futuristic, and Google and cable/media companies are in the midst of taking over the telecommunications as we know it. It will be replaced with DVRs with VoIP servers in them.
To see it, just look what happens around you. GSM is moving in, with a lot of upgraded infrastructure. I travel a lot, and in my experience I get much better 3G speed/coverage on AT&T then on Sprint or Verizon. With that also comes freedom – unlocked phones, different OS, ability to choose from the much wider range of product. In US the “main” operating systems – Windows, RIM and Apple have 90% of the PDA market. Worldwide, they are less then 20% combined – about as much as Linux ones.

My cell phone is Linux smartphone with a touch screen and VoIP/802.11g. It is in a regular candy bar format, with a normal phone keyboard I can use while driving. It is a bit smaller then iPhone and fits into the same holder. When I am at work or home, calls are automatically routed to VoIP providing better call quality and extra features like unified messaging to boot. When I am on the go or outside of the 3G/WiFi coverage – I have a cell port on the VoIP appliance – so all my calls are routed for free as well. There is no comparison to the Blackberry or Windows devices – at about 50% of the cost with the plan. I would estimate that move to “aggressive” VoIP saves me personally about $1000 in telecom charges – and about as much per telecommuting employee for the company.

Google is about half way there in terms of service offering with GrandCentral VoIP solution. It needs just enough bandwidth – either on its own or with cable/media companies – to offer Gizmo ( standards based/open source Skype alternative) like service in well rounded package for the mass adoption – with “free” adapters converging your phones and PCs into “gvoice” service. If played well, Skype would either have to give in its “lock”/switch to VoIP or face massive drop out rate in the phone area – the main source of their income.

With “always on” network devices in our pockets we are looking at almost unlimited set of applications – personal automated voice driven assistants that would help you to choose (from the “advertisers and rating lists”) all the services and products based on location, preferences and “history” that you might have for better or worth. And believe me, these are very addictive – more then music or video on the go. That means more c/java me for selected few and a lot of Flex apps for convergence UI for the rest of us.

Happy New Year!

Sincerely,

Anatole

Š

This started as a Skype chat room conversation between my colleague Anatole Tartakovsky and myself, and I though that it would be a good idea to invite more Flex developers to this discussion.

Having said this, I’d like to make it clear that over my career, I’ve been developing frameworks myself and truly respect people who are capable of creating frameworks and Anatole has huge experience in this area as well. Here we’re just questioning the need to create frameworks not for a general purpose language like Java, but for a domain-specific framework like Flex.

This is our dialog with minor editing. Your input and feedback are greatly appreciated.

Yakov. Why people design Flex frameworks as opposed to reusable components? One of the framework is called Cairngorm, the other one is called PureMVC. I’m sure there is more. It seems to me that such frameworks is unnecessary overhead over well designed Flex framework. Are there any benefits here? Why bother creating all these singleton-based bottlenecks?

Anatole. First of all, PureMVC seems to be more of an ActionScript Framework. It is not specifically Flex framework and concentrates on the task of creating generic a framework for low-level AS objects. Flex comes with “pre-built suggestions” of how a model/view controller might work – and it offers lots of hooks throughout the data and UI classes that help implementing MVC.
PureMVC is also “server-agnostic”. Flex made very efficient Java implementation of distributed Model that can provide dynamics to the distributed Web applications.
PureMVC is more about making apps in more traditional way.
Cairngorm was started as “Micro – Architecture” – a set of patterns that allowed solving certain problems in the application design – like Model Locator or Commands – and certain applications. It never appealed to me as it had a number of assumptions that required more coding. At best you would use one or two patterns implementation from Cairngorm, but it’s much easier to rip out the part you need and adjust it to your liking.

Yakov. I can appreciate the fact that design patterns are useful in general, because they may help developers in dealing with repeating patterns in software construction such as Singleton, Mediator, Model-View-Controller and the like. But when I look at some of the third-party frameworks built on top of Flex, I keep asking myself the same question, “Why build a framework on top of framework? Are there any benefits to introducing a middleman between an application’s views and already existing Flex framework?

Anatole. It depends on the application you are building. Frameworks provide higher level of automation and abstraction for specific tasks and with various coding and performance costs. Fo example, Flex framework has Data Management Services for distributed Web applications. However, this model has limited applicability for simple Web applications working with HTTP forms-based backend API. You’d need a symmetrical MVC API on the client side. You can also have a client-side only text editor application, for example, that is completely “out of scope” for Flex framework but would benefit from implementing a Command pattern. The real question is to identify the functionality you need, and then to see how it is implemented in the appropriate framework

Yakov. I looked at the Cairngorm’s design, and having hard times figuring out why would I need something like this? Ok, you may say that it helps to organize your project better. What else? Without any disrespect to creators of Cairngorm, I can’t find a justification to recommending it to my clients. One of them has invited me to lead an ongoing Flex project, which is being developed by a large team of developers. The project uses Cairngorm, and at the same time it consists of a number of modules. After reviewing the project, I’ve recommended to stop using Cairngorm. Without going into details, these are some of my concerns in this case:
The client wants to use modules, which are can be loadable/unloadable. But since you are forced to use Cairngorm’s singleton model locator, it’ll keep the hard references to the modules (event listeners), which won’t allow you unloading modules. So, on top of Flex modules’ memory leaking (yes, they leak), we’d introduce another memory issue.

Anatole. In many cases, a detailed look at the implementation will either get you on board or will remove the framework as not applicable implementation. In later releases of Cairngorm you can have weak references – so it works – at least theoretically. However, with modules there are quite a few places when unloading will become impossible due to legitimate code generated by framework. In general, if you are going with modules, you need multi-layered framework and intelligent registration services that are written specifically for the task.

Yakov. As far as I know, the use of Cairngorm was never approved by Adobe Flex team, but I might be wrong here. Flex framework is built on a nice distributed event-driven architecture, but Cairngorm is forcing your events to go through another singleton – event dispatcher. Why is that? Why every view has to register event listener in the central place? Now developers on a large project have to acquire additional skills in proper usage of this framework.

Anatole. The reason for use of global event listeners registration are derived from the size / type of applications the framework developers worked with. It “simplifies” the project management by providing structure and separating developers responsible for model, view and controller into separate entities. All these singletons and managers are a way to establish a non-UI but business communication between parts.

Yakov. Do we really need global areas? Why not doing it locally when needed?

Anatole. First, you need to look at the events. In most cases, these are not UI or input events but rather some application/state changes that need processing. The model is global, and the application events are defined on the global level.
I think most of the seasoned developers with UI background are uncomfortable with this approach. You might want to consider Joe Berkovitz MVCS approach as a middle ground between Cairngorm and our component-based approach that might work better for medium to large size teams that would have no access to code generators and data driven/factories-based architecture.

I recall two framework-related sessions at MAX’07, where approximately the same number of people were asked the question: how many of you have looked at Cairngorm? 70% -80% raised their hands during the Flex frameworks BOF session and 90% on the Best Practices session. During the Flex framework session people were asked a second question,“ How many of you would use or actively oppose Caingorm?“ This time they’ve got a 50/50 split.

Yakov. I hope to be able to attend MAX 2008. So all these people came to the Best Practices session to get reassured that they are doing the right thing? But I’d really want to see some concrete examples where using these frameworks would bring technical benefits. I want to stress, I’m not talking about self-contained components that would automate some tedious job but a framework on top of Flex Framework.

Anatole. I think the main benefit of any pattern library will be based on its applicability to your application. There are quite a few applications – including infamous “shopping cart” ones – that can be coded quite efficiently with any of these frameworks. On the other hand, the extra setup code provided for “flexibility” is ironically the least flexible part of it.

As far as benefit ratio between an architectural framework and smart components, I think you might want to try a little test. Ask any developer if she wants an architectural framework that still would require her to implement a DataGrid componment (she would be allowed to use Grid component or some other low level controls as a superclass). On the other hand, offer her a DataGrid component without any framework. I think this developer would recognize the importance of smart objects and go with a DataGrid. Take it a level deeper and you will see an “extra” code in a DataGrid , and we’ve successfully have overridden it in our own DataForm, SuperGrid and controls.

Yakov. Do not forget though, that we are enterprise developers and are mostly concerned with a boring thingy called data processing. There are legions of Flex developers who do not care about the DataGrid. They are into creation of cool visual components. But these guys do not need any frameworks either.

Here’s another strong statement from the PureMVC framework, “The PureMVC framework has a very narrow goal. That is to help you separate your application’s coding concerns into three discrete tiers; Model View Controller”.

But isn’t this goal already achieved in Flex Framework? Wouldn’t a simple separating views, controllers and models into different folders of your project suffice? In many cases the role of Controller in Flex is kind of blended into model itself (bindable data collections can emit and listen to events caused by some data changes). In some cases, if your application’s views have reusable business logic (i.e. validation or connection to specific back end data feed) you may create separate controller classes that may be shared by more than one view. But this should be done on the case-by-case basis, and not as a must for the entire application.

Here’s another statement from a well-written PureMVC documentation: “Making separation of Model, View and Controller interests eliminates the most harmful responsibility misplacement issues that hamper scalability and maintainability“. My English is not good enough to understand this phrase in its entirety, so can you play the PureMVC advocate and suggest, how PureMVC would improve Flex scalability and maintainability?

Anatole. Well, there is an old saying that life is a play, written by God, and directed by Devil. By making the process more formal you can build a lot smaller chunks, communicating and specific way, and in your mind the more formal process will yield better maintainability. On the other hand, it will create more parts to maintain and less flexibility to do so.

Yakov. PureMVC uses mediators, which is a very applicable pattern for the software that produces UI. But would it be that difficult for developers or project architects apply Mediator pattern while designing their business applications as opposed to relying on a framework that implements Mediator globally? Check out this blog on using the mediator. Is it that difficult so it has to be hidden into a framework?

Anatole. ActionScript 3 makes a lot of patterns excessive. A lot of things can be done by using events or dynamic code without really breaching good programming practices. One-liners work for me as long as they are simple and concise.

The main question remains, “Do you want to use intelligent objects that encapsulate most of the framework functionality or if you prefer to deal with simple objecst and do explicit coding for each instance?”

Yakov. I prefer using self-contained loosely-coupled objects.

Anatole. So, coming back to your question of system-wide singletons… I do not see any reason for creating global objects – they are really bad for both application development process and maintenance in the long run. You can have a singleton pattern inside the models themselves or bind location services with module loaders depending on the architecture of your application.

I have seen these frameworks being used mostly as means to provide project manager/architect with ability to separate areas for developers, quantify functions and make project more manageable. The effect for the resulting application most likely to be negative, but it is very straightforward approach to build systems.

Yakov. So you are saying that utilizing a framework on a project allows create and enforce a nice looking project plan that reads, “Mary will create 10 model objects by February 1, and John will be done with his views a week before?”

Anatole. Yes, and then we will have all the commands coded a week after that and then we will think about fitting it all together, essentially moving real architectural and design questions toward the end of the project. If you answer the question “How?” first, people tend not to ask “Why?” for quite some time. On the flip side, you will have people doing their parts rather quickly thus producing enormous amount of code to fix when the design problems become evident. The problem with formal coding techniques is the human generated code (thus cut/paste errors) without the ultimate understanding how it will be used and very little testing done while writing the code.

Yakov. In the USA, we are already accustomed to protective medicine, when the main goal is to ensure that the patient won’t sue you. So when a guy with a headache shows up in an emergency room, they start with sending him to an MRI and making tons of other not too necessary tests. But, it’s better to be safe then sorry… The same rationale here – it’s easier to CYA with a nice project plan (see www.acronymfinder.com for the definition of CYA).

Anatole. The problem starts MUCH later – at some point of the project the spec changes – business analyst realizes that mistakes were made, process changes, the other department needs some of your functionality or another line of business has to be handled. There is no time compression or shortcuts available there – commands need to be amended and re-coded, views redesigned, events integrated with a different workflow. You are now thinking to yourself, “Why, oh why, did not I go with an application framework instead of the architectural one?”

The application framework goal is a way to get you through the “implementation” part faster while giving you maximum flexibility on design and functionality part. If you do not have 80% of application built in 20% of the time, you will be late with the last 20%.

Flex itself is more of an application framework. It is not a library of patterns but rather a set of objects that are built to communicate and react. Flex uses code generators and other behind-the-scene techniques to achieve that. The key here is automation of implementation tasks by minimizing the amount of code while behaving predictably. That is done by explicitly checking the “related” objects for specific interfaces. By not adhering to the implementation of these interfaces, the external frameworks require serious application development effort to support them.

MVC principals are also questionable in the Web2.0 world. The concept of fine granularity and validation on the client has serious security implications. You go to any AJAX show and you see one or two sessions with security specialists, cracking AJAX sites, getting free airline tickets, buying things for one penny, etc. It seems that every serious organization should be more interested in distributed model rather then pure client side solution. In that case most of the benefits of global MVC go out of the window.

Yakov. So far we have just a couple of the third-party Flex frameworks, but creation of the new ones is a viral thing, and the last thing I want to see in Flex community is more than a hundred of frameworks that do the same thing. We already see it in the Ajax world.
Anatole, it’s not easy to quarrel when both parties share the same views. We really need other people’s opinions to better represent Flex developers who may see benefits of using frameworks.

OK, your Flex application is already deployed in production. How are you planning to deploy patches to your code? I mean bug fixes or enhancements to specific MXML components or ActionScript classes? Of course, you can recompile the entire application with hundreds of classes just to deploy a new version of the class MyGreatCreation.as. Let’s see if there is a way to deploy just MyGreatCreation leaving the rest of your application intact.

In Java world, the solution to this issue is pretty simple. A typical Java application consists of a number of .jar files (think libraries or swc) and there is a concept of a class path. If a program needs to use a class MyGreatCreation, the Java class loader tries to find it based on the classes or jars listed in the classpath. If there is more than one version of this class in the path, the class loader will grab the first one. This greatly simplifies deploying any patches in Java production applications. Just make changes to your class and place it in the jar that is listed first in the classpath. Then deploy just this jar in production, and the loader will be happy to pick up the brand new version of MyGreatCreation.

Luckily, we can use the same techniques in Flex, which also has concepts of classpath, class loaders and libraries.

Go to the Properties window of your Flex Builder project and check the build path of your application. At a minimum, you’ll find there a number of libraries (compiled swc files) that represent the Flex framework itself. The chances are that you’ve added more swc’s there that contain your application-specific code.

In any event, create a new Flex Library project called patches or something of this nature. To be able to compile this project into an swc, add an empty ActionScript class there. We’ll be using the patches.swc as a first item in the build path of our main project.
Importantly, we’ll link this library to the main project as a Resource Shared Library (RSL), which means that the objects from patches,swc will not be merged into the code of the main application, but will be loaded during the run time. Add the compiler option -debug=false to your library project to avoid these annoying Flash Player’s messages asking where the debugger for this RSL is located.

Now go to the build path of the main Flex project and add patches.swc to the top of the list. Select the RSL linkage type as shown below (TestPatch there is the name of the main Flex project).

Go again to the properties of your main Flex project and add the library patches project in the list of your project’s references.

Run your main project – you should not see any differences because patches.swc does not contain any useful code yet.

Then, copy one of your classes from the main application it to the patches library project, modify it there and rebuild the patches.swc. Now we have two versions of this class – the new one in the patches.swc and the old one in the main application.

Re-run the main application. You’ll see that the new version of the modified class is being used. The class loader picked the new version since patches.swc is located at the top of the classpath of your application. That’s all there is to it.

Every time you need to make minor changes in your production application, just put them in patches.swc and upload it to the production machine.

Happy New Year!
Yakov Fain

The problem

Just two of the text fields on your Flex window have to support the mouse wheel. The user turns the wheel, the numeric field in these fields is incremented or decremented

The solution

As per the Flex manual, there is a MouseEvent.MOUSE_WHEEL event, just listen to it. So far so good. On the creationComplete event adding the one liner:

systemManager.addEventListener(MouseEvent.MOUSE_WHEEL, onMouseWheel)

The onMouseWheel event handler gets the MouseEvent, but the problem is that we have more than one field that needs to support the wheel. Which one to increment? The currentTarget of the MouseEvent does not report which text field has the focus. The currentTarget contains a reference to SystemManager.

Fine, let’s see if the FocusManager can help:

public function onMouseWheel (evt:MouseEvent): void {

var compAtFocus: IFocusManagerComponent = focusManager.getFocus();
// no wheel support unless it’s a TextInput field
if (compAtFocus is TextInput){
var theValue:Number=Number(compAtFocus["text"]);
theValue += evt.delta;
compAtFocus["text"]=”"+theValue;
}

And it works fine, see for yourself (right click to see the source code): http://www.myflex.org/codesamples/mousewheel/MouseWheel.html

In this sample application I’ve created two text inputs that have to support the wheel, and one text area that should not. Hence, first thing I do in the code above is checking the type of the object that has the focus. If this was a text input, get its text property and add the value of delta that comes with event. This delta is default increment that you can configure for your mouse outside of the application. For example, in Windows, go to Control Panel and set the Mouse wheel increment to your liking. Just keep in mind, that support of the mouse wheel depends on the mouse driver that you use, and if something does not work, do not blame Flex.

If you do not want to link the increment/decrement amount to your  mouse system settings, just do not use the delta property that comes with the MouseEvent and add/subtract any arbitrary value that meets your application’s needs.

The homework

1. Modify the above code to ensure that the numbers in your text field do not go to the negative territory.
2. Modify the above code so it’ll support just one of the TextInput boxes.

Regards,
Yakov Fain

Release of BlazeDS is a great help from the Flex enterprise adoption perspective. The high licensing costs of the server side components has been a major obstacle for Flex adoption for some of our clients over the last 2 years. As most solution providers, we had to roll out third-party replacements of Adobe’s AMF implementation – mostly built around openAMF and other open source products. With BlazeDS available within few month, the performance, support and the future of the codebase is no longer a concern, and should greatly simplify Flex adoption by enterprises.

On the technical side, BlazeDS provides a lightweight replacement for LiveCycle Data Services ES. The remoting part seems to be identical to the LCDS offering. If you just use BlazeDS WAR, just roll out a regular “LCDS-like” deployment, and the chances are it will work without the need to do any changes. For the messaging and data management services, however, there are significant differences. You might want to analyze those before plunging into either product.

The client-side of the messaging stays very much the same – you use the same Producers and Consumers, so there are virtually no changes in the client code. The BlazeDS is packaged with a pre-configured Tomcat server with messaging built-in (an open source ActiveMQ), greatly reducing the complexity of the initial setup.

The implementation of the server piece is very different though. Unlike LCDS that launches an independent Java socket server within each application, BlazeDS uses the regular Web server sockets. LCDS uses non-blocking IO that offers better scalability (we had it @ 10000 users / CPU till we maxed out on the outgoing bandwidth). With LCDS, you need either a separate port or an IP address to handle the data stream. BlazeDS does not use non-blocking IO – so you can not expect to have more than a few hundreds users per CPU at best. On the positive side, it makes the process of application development a bit simpler as the session context becomes available.

With BlazeDS going open source and abundance of Java expertise in the market place you can expect non-blocking I/O offerings from third parties shortly after the BlazeDS release. It would also mean faster recoverability of the connections that is important for the real-time applications.

The Data Management Services interface is COMPLETELY omitted from the current BlazeDS offering. This SUCKS. While it is understandable from the marketing standpoint, it will hurt Adobe in the long run. Some trivial, non-functional classes have to be included in both client and server version of BlazeDS libraries. All datatypes that go over the wire and allow users to maintain compatibility between BlazeDS and LCDS are desperately needed. A short list would include ChangeObject interface, DataSyncException and such that are used in the custom server and client code.

I could care less about a Hibernate Assembler and implementation classes but high-level WIRE PROTOCOL has to be the same. As a solution provider, I have to go with the lowest denominator of what is available across platforms, and lack of common classes interfaces hurts the code portability. Given the current license restrictions on the “mx” and “flex” namespaces in the current open source sdk it makes impossible to provide such solution in the nearest future.

Other thing people often forget about the PDF support in LCDS, which won’t be available in BlazeDS. The printing support in Flex is very light, and PDF generation is often a preferred solution for printable documents. Fortunately, you can split your application deployment now and have dedicated “print server” with LCDS or any other Adobe enterprise product that includes that capability.

Sincerely,
Anatole Tartakovsky

Last weekend we’ve conducted a two-day public training on Adobe Flex in Edison, New Jersey. The room was packed and we’ve received a really nice feedback from many attendees. Inspired by a success of this training, we’ve decided to repeat it in several cities across the USA.
This is how it works: we inject a solution of basic Adobe Flex techniques, design patterns, custom components and examples from the real-world projects. The procedure lasts 2×7 hours, the price of this weekend injection is $399 USD, which is cheaper than Botox and effect stays longer.
We are planning to run one such event a month and these are the first cities on our list are: Boston, San Francisco, Chicago and Philly.
If you believe that there might be an interest to such event in other cities, we’ll gladly consider your suggestions.

Thanks,
Yakov Fain, Adobe Certified Flex Instructor

I know, it is not supposed to be out till late next year. But I can’t wait, so in the next couple of months or so I will try to whip up a perfect phone for myself from the available components.

Recently we’ve got a number of calls from both startups and established IP telephony companies looking to put RIA into work for the phone market. The telephone industry is going through a major shift in the next year. 3G becomes a standard feature of the cell phones, very much like cameras 3-4 years ago. Combined with GPS and phone service, and upcoming voice/text automation it becomes a very powerful device.

I will run this project as a research one, to see the problems and opportunities. My initial set of “phones” will include a reasonably small set, but I welcome any suggestions of what will get us close to the perfect phone. I will run the “mini” review, pros and cons, what works (for me), designs, etc.

Here is the initial set:

AT&T Tilt Windows smartphone

Sprint Blackberry – current “business phone”
E28 Linux Smartphone

Nokia tablet

iPhone – UI design concept

Also will see what can be done with personal gateway – basically will use SIP Asterisk PBX connected with cell gateway as an application platform for SIP/Telephone integration

I will start sharing my initial thoughts on the perfect business cell phone and home automation this week.

Hope it will be fun

Anatole

Once you developed and tested Flex application locally you need to move it to the secured hosting environment to share it with the world. Usually, for simplicity/performance enterprises deploy J2EE servers behind standalone SSL accelerators/load balancers/proxies. It means that client sends data via SSL channel to SSL appliance, which in turn calls your server on the  intranet via unsecured HTTP to minimize the processing cost.
You can configure the channel/endpoint in services-config.xml, but it would mean separate build for deployment. Here is an alternative “runtime” approach:

import mx.messaging.config.ServerConfig;
 
private function preinitializeApplication() : void {
   const reUrl:RegExp  = /(http|https):\/\/(([^:]+)(:([^@]+))?@)?([^:\/]+)(:([0-9]{2,5}))?(\/([\w#!:.?+=&%@!\-\/]+))?/;
   const appUrl:String = Application.application.url;
   const parts:Array   = reUrl.exec(appUrl);
   if (!parts)
      throw new Error("Invalid URL: " + appUrl);
      /*
      ("Protocol:" + parts[1]);
      ("User: "    + parts[3]);
      ("Pass: "    + parts[5]);
      ("Host: "    + parts[6]);
      ("Port: "    + parts[8]);
      ("Path: "    + parts[10]);
      */
      if (parts[1] == "https" ) {
         const channels:XMLList  = ServerConfig.xml..channels.channel;
         for (var channel:String in channels) {
            if (channels[channel].@type=="mx.messaging.channels.AMFChannel") {
            channels[channel].@type="mx.messaging.channels.SecureAMFChannel"
            var endpoint : XML = channels[channel].endpoint[0];
            var uri:String = endpoint.@uri
            uri = uri.replace( /^http:/, "https:" );
            uri = uri.replace( /\{server.port\}/, "443" );
            endpoint.@uri = uri;
         }
      }
   }
}

As you can see, we check if the application is deployed over https and redirect regular remoting requests to https thus modifying deployment descriptors in the runtime.

Enjoy,

Anatole Tartakovsky

In my opinion this is THE biggest announcement that I’ve heard from Adobe after release Flex 2 in the Summer of 2006. This is bigger than open sourcing Flex. This is bigger than AIR. Here’s the news: Adobe is open sourcing AMF protocol and messaging under LGPL V3. Christophe Coenraets, a Senior Flex Evangelist from Adobe told me about this new free product called BlazeDS.

While many people are using Flex for creating cool widgets that can make your Web page prettier, enterprise Flex developers have to deal with such boring things as bringing data to the client. And they want to do this as fast as possible. AMF3 protocol allows your Web application to send the data over the wire at lease ten times faster than a regular HTTP.

Basically, Adobe extracted the libraries that supported AMF protocol from LiveCycle Data Services ES and gave it to us for free. On top of that, BlazeDS introduces a new channel for messaging: DHTTPStreaming that will support messaging on top of HTTP. In this mode the Web browser keeps the connection open. RTMP protocol will not be open-sourced at this time.

Like the news? I know. And here’s something for dessert. Adobe is publishing a full specification of the AMF3 protocol, which will allow anyone to implement Flex remoting for any server-side programming language.

Based on my experience, the price tag of LCDS licenses was too hefty for many small and mid-size businesses. They’d love to have faster communication with POJO , but purchasing just the communication piece was not available. Now you’ll get it for free.
For those who are afraid of jumping into open source waters and want a product that is backed up by a large company, Adobe will maintain LiveCycle Data Services Community Edition, which is BlazeDS certified by Adobe. in the diagram below, LCDS components that won’t be included in BlazeDS are shown in gray.

The product will stay in Beta for a couple of months, but since it’s a pretty stable software, the GA release will follow up shortly. Visit http://labs.adobe.com/technologies/blazeds for more details.

Now, why this announcement is important for the company I work for:

1. Now we’ll have a lot more consulting requests.
2. Our firm will start selling more of our software components, namely ClearBI and Clear Data Builder. We can just say to our customers that other than our licenses, there’s nothing else to purchase.
3. We’ll have more training requests since Flex will be used by a lot more organizations since BlazeDS will definitely open many enterprise doors to Flex development.

Overall, Adobe made a very smart move, which on the long run will lead to more sales of LCDS too. But for now let’s enjoy free BlazeDS.

The year of 2007 was a good one. The IT job market was stable. The mankind got an iPhone. While there were no any revolutionary changes in the ways software was developed, I believe that this was a year of rich Internet applications and Web 2.0. Youtube became a part of life of millions of people around the world. A large portion of the population visits use myface and facebook daily. What’s next? What language/tool/technique to learn? What’s the next big thing in IT? In my opinion…

1. Java will remain strong in large enterprises, but will it’ll continue losing grounds as a development platform for small businesses. J2EE is way too heavy, and scripting languages and frameworks offer an alternative and productive way of software development when cost of development is more important than performance and scalability. LAMP platform will remain a preferable way to develop applications for small to medium businesses.

2. AJAX popularity may go downhill. Since the first day this acronym was created I’ve been writing that it’ not a good choice for developing enterprise applications. But the vast majority of software world was (and still is) marching the AJAX way. This time it’s more of a hope than a prediction that in 2008 people will realize that AJAX should serve the same goal as JavaScript – making your Web pages a little prettier. Expect to see re-branding of some of the AJAX frameworks into RIA or Web 2.0 solutions.

3. Speaking of Web 2.0… Even though Web 2.0 was not officially defined, I think it’s all about giving more control to the users of the Web sites. The more interactive is a Web site, the higher number people will put in front of the zero – 3.0, 4.0 and so on. Some people say that Web 3.0 is about semantic Web. If you bought a grill on Amazon.com they can guess with a high probability that you might be shopping for rib eye steaks. Let’s show it to you next time you visit the site. It’s all about control. From the user’s side and from the vendor’s site. We’ll see more and more interactive sites next years. While some people are planning to write a next generation sophisticated software, others will come up with a very simple, easy to implement but appealing business idea, and the next 20-year billionaire is born.

4. Flash Player. It will remain the best deployment platform for rich Internet applications. While Microsoft is trying to come up with a competitive delivering platform for RIA, it’s not going to happen in 2008. Silverlight 1.0 is a good start, the next version (1.1) will be even better, but it’ll take time to release a product that can do more than streaming multimedia.

5. Ruby on Rails will take a small share of the market of small non-mission Web applications. Convention over configuration. Speed of development over performance. While Ruby on Rails will not become a framework of choice, it has achieved a very positive result – people started to realize that not every project has to be developed in either Java or .Net. Besides, RoR is a well designed framework that will become a good design sample for the new frameworks of the future.

6. Internet video. This will be booming and I’m not talking about youtube. The Internet Video will start being a part of a number of enterprise applications. This process won’t be fast, and you have an opportunity to be among the early adopters in this sector.

7. Outsourcing will be gaining more and more grounds despite the fact that it’s very expensive and the project failure rate is high. The reason is that the USA almost stopped producing software engineers. It’s just the matter of time for everyone to get used to the fact that business software is made in India just like we all know that all toys (with or without lead) are made in China. But innovation in software will still be happening in America. I guess, there’s something in the air here. Re-read an old but valid article by Paul Graham about why the Silicon Valley can’t be exported.

8. Apple. Next year I’ll finally purchase a MacBook Pro for myself… if my Sony Vaio will die. Even if it won’t die, having a two year old machine is a good excuse for submitting a purchase order to my wife for an approval. Peer pressure, cool design and ability to run Windows (plan B), will force me to ignore the high price.

9. Adobe Flex and AIR. Flex will become the #1 tool for developing enterprise rich Internet application, and I’ll be seeing less that 10% of the raised hands when asking an audience, “Raise your hand if you dor not know what Flex is?” Adobe AIR’s adoption will be slow though. Or course, the shops that are already sold on Flex will use it, and some AJAX developers will realize that it may become a life saver for their applications, but that’s about it. While being a well designed and very promising technology (Flex, Flash Player, HTML, JavaScript, PDF, SQLLite DBMS, an ability to work in a disconnected mode, and full access to your PC’s resources), it may be perceived as yet another Web browser, which is a tough sell in the enterprises. At least, become an early adopter. I will.

10. Telephony. If 2007 was a year of Skype, we’ll see some interesting development in this area. Skype is a great product, but it requires you to download and install software. In the era of RIA things can be done without it. Watch the Ribbit phone software that will allow you to make calls and receive emails just from your Web browser.

11. IT job market in the USA. While we’ve enjoyed a stable demand in the IT professionals in 2007, it won’t last and next year we’ll see project freezes and even layoffs. The reason is the burst of the real estate bubble. And this will affect not only those simple people who were brainwashed and decided that they could have afforded an American dream. CEOs of the major Wall Street corporation are being fired after drowning their companies by getting into bad mortgage debt. Among other things, the IT budget will be severely cut. And as you know, today’s on Wall Street, tomorrow’s on Main street. Use the training budget of your employer now if it’s not too late. Keep your skills up to date.

12. The hottest IT skills of 2008. When the job market is tight, recruiters immediately increase the list of skill requirements for job opennings. You’ll see job posting that expect you to know a number of programming languages ranging from Cobol to C++. Knowing just one hot tool does not cut it anymore. But if you have limited time and need money, start with investing in learning tools for developing rich Internet applications. A skill set -of a high-paid Web developer at a minimum has to include the following skills:
HTML,CSS, JavaScript, J2EE or.NET, Flex or Silverlight, AJAX, and good communication skills. You do not have to really learn AJAX, but must add AJAX keyword to your resume, otherwise you may not even get a job interview.

13. The next big thing. The in software development will change to wider use of code generators. Forget about heavy frameworks regardless of what programming language you use. In a simple case, use some XML style sheets combined with the metadata that describe your application objects to automatically generate the code for these objects. On the larger scale, the entire application may be described using metadata and the XML, and an appropriate code generator will do the job. So programming will change from writing a tedious code that requires lots of coders to describing the metadata and writing custom code generators.

Happy New Year!

Yakov Fain