Andrew Powell

Every couple of years I have to stop and shake my head at how damn cyclical (and cynical) this business is.  Sometimes, I can't help but feel like Marty McFly and get the feeling like I've seen all this before.  Everyone is, quite rapidly, getting caught up in the notion of this high experience, mobile, touch-screen, multi-device world and how revolutionary it is.  

We've sung this song before though.  It's nothing new.  

It's kinda like "O Canada" and "My Country, 'Tis of Thee" being the same melody as "God Save The Queen".  We know it's the same tune, just different lyrics.  With that thought in mind, let's take a look back and figure out how we got to this point and where we are going in the future.

When I first started building software (Omnis 7 paid the bills), it was all about client-server computing.  You had to have moderately powered desktops and a beast of a database server to house all the data.  Most of the heavy lifting of the data and logic happened at the client.  The server was, basically, just a database, if not in reality, just a database.  This made updating the applications we built a total pain in the ass because we didn't have a really well built out infrastructure to push updates to our clients.  Hell, even Microsoft sent updates on CD.  I fondly remember waiting to see what was in that month's TechNet update, but I digress.

As server performance increased at a faster rate than desktop performance did, the shift was back towards a centralized-type system that was a lot like the mainframes of yesteryear.  Hell, the system we used was even called MetaFrame to harken back to the mentality that all the processing was centralized.  Metaframe was an absolute disaster, but that's a story for a few beers and another time.  At that point in time, you had all the power you needed on the server to run the app, but you were still talking to the database, which was the centralized server component.  That part didn't go away.  

Not too long after that, along came the rise of web-based UI's.  This moved pretty much solidified the move of all the processing to the massive servers that we had sitting in data centers (or server rooms).  This paradigm gave rise to the concept of a middle-tier that took requests from the client (web server), processed the incoming data, made requests to the database, then sent the results back to the client.  

This was a defining demarcation because at this point, we would never really have all the logic in one place anymore.  The client could render and process some of the data and the server would still do most of the business logic.  This worked well, especially with the introduction of client-side scripting methodologies, like JavaScript.

In the middle of the last decade, we saw the emergence of the Rich Internet Application (RIA), be it AJAX, Flash (and Flex), or whatever your tools of choice were (and maybe still are).  This, again, signaled a new era where we moved a lot of the processing back to the client and relegated a good majority of the middle-tier to things like security and data access.  A lot of business logic moved towards the client applications, again.  

Fast forward a year or two to the present day. Now, we are in the midst of a new multi-device paradigm where we have a legitimate business need to have both consistent experiences and business logic across multiple devices (Android, iPhone OS, Windows, Desktops, etc.).  So what do you do?  Do you spend the extra money to duplicate libraries of business logic across platforms and create a version for Cocoa, Android, .NET, and whatever other platforms on which you wish to deploy your applications?  

In a word, no. 

You do the smart thing and move that common business logic back to the server.  The native user interface serves the relatively simple purpose of providing the face of the application, taking input from the user, prepping it for the middle-tier, passing it to the middle-tier, then processing and rendering the results.  The real work: security, data access, and all important business rules and logic are deferred to the server, again.  

So here we are, again in the circle, moving the most intensive processing back to the middle-tier and leaving our device native code to render the user interfaces.  History would tell us that the next phase of this will probably be much more powerful devices that can handle the processing of complex business rules and crunching larger amounts of data.  Achieving this will require us to find a way to create logic libraries that are cross-device.  That will require a change in the current environment where either everyone, or a good number of vendors start playing nice.  If that does or doesn't happen, history tell us that something will trigger us towards this paradigm in the next two to three years.  Let's hang on and see what happens next.

On May 7th, Flash Camp Seattle will be held in the Adobe offices in Seattle.  One of the sessions we are working out for that event will be a panel discussing where Flash and HTML5 will both fit within the future of the web.  It's not going to be a "bash-fest" either way, but a frank, open discussion with representatives from both sides. Tickets are going fast, and registering via this link will save you 50% off the ticket price.  

Speakers Include:

• Ryan Campbell
• Ryan Stewart
• Duane Nickull
• Carl Smith
• Jeff Croft
• Christian Saylor
• Antonio Holguin
• Nate Beck
• David Kelley

A few months ago, I started a project to make a framework for ColdFusion to enable its functionality as an Enterprise Service Bus (ESB).  I kept running into roadblocks in my mind as how to structure things, but I realized something.  Everything I was trying to do to make ColdFusion an ESB was simply hindering tasks that were already easy to do.  ColdFusion, out of the box, can function as an ESB.  

It wasn't always this way, but over the years, with the addition of things like JMS gateways, .NET integration, HTTP, and FTP integration; it's easy to create workflows that receive data from an input, processes it, and sends it to another destination.  ColdFusion 9 enables this even more so with the addition of Sharepoint integration. 

Why worry about installing something like Mule?  ColdFusion already does everything you need it to do out of the box.  ESBs are the next generation in integration.  ColdFusion just makes it easier and faster than traditional Java or .NET based solutions. 

There has been some confusion as to what FlashCamp Orlando really is.  FlashCamp is the new name that Adobe wishes to use for the events formerly known as FlexCamps.  The content that you can expect for FlashCamp Orlando covers:

• UX
• AIR
• BlazeDS
• Flash Catalyst
• Flex

FlexServerLib , the extension project for BlazeDS, is a powerful library that allows you to access functionality on the server, in Flex, as easily as ColdFusion allows developers to access complex server functionality in CFML.  Imagine if sending an email was as easy as sending a message into a destination and receiving an email was as simple as subscribing to the same destination.  This is just some of the functionality FlexServerLib aims to implement.

A topic has been submitted on FlexServerLib for 360|Flex Indianapolis, but if you want to learn more, we need your vote.

Follow this link to vote

Dave Meeker, Adam Flater, and myself were interviewed a while ago about Merapi for The Flex Show.  The episode has finally posted and is available for your enjoyment.  It makes a good listen on mass transit and will have you amused and amazed.

There are tickets still available and it's dirt cheap for a day full of great content.  Head over to http://www.flexcampboston.com and register today!

Every once in a while, something happens that, for better or worse, changes your perspective on some preconceived notion that you once held. It is something so profound and momentous that it shakes you to your very core. Other events in your life can be traced back, like touchpoints, to these events, so important that you never forget when and where you were when they happen. These moments can range from something globally significant, like the Berlin Wall coming down, to something intensely personal as your child being born. Irrevocably you are changed and your preconceived notions are nothing if not shattered.

These moments are professional as well as personal. You may well remember the first time the light shined on you when you realized how much you could do with your favorite programming language, or had that first professional breakthrough moment and realized what you wanted to do with your career. The first such of these moments for me was when I was in school and realized that I could create something with a computer just by writing some code and running it. It wasn't something tangible like a vase or carving, but it was my expression of creativity. It came from my head and I was able to express in a way that I could relate to others. It sparked a passion for me to create something that only existed in my mind on the computer. With just a few lines of code, I could solve problems, transform data into real and meaningful information, and really feel like I was being challenged every day. I had a passion for the technology and what could be done with it.

Over the years, the fire inside me has been reignited with things like Java, ColdFusion, and Flex. I still have a passion for the technologies, but I have come to see that as intense and passionate as I have been about the technology, I had lost sight of the overall story I was trying to tell. I had lost a compelling way to express the passion that I had burning within myself.

A few conversations with colleagues over the past few days have illuminated the need and requirements for telling a great story with the applications we build. It has been a few days that have, to say the least, become another touchpoint.

Most of us have been focused on delivering high-end technology centric solutions. We are able to use the great techologies available to us to build the next generation of high-end rich internet applications. However though, there is a question we need to ask ourselves: Are we helping the users for whom we are building these applications tell their story in a compelling way, or are we just focusing on the technology?

I used to regard the "user experience" aspect of application development as just the graphic design. I was looking at the phrase itself. User experience is all about enabling someone to tell their story in a compelling way. It can range from simple print and digital design to application development, with the user experience at the epicenter, to industrial design (there's a reason we love the iPod). Regardless of the medium, a good UX helps us tell the compelling stories. If you do it right, you don't get mindshare, you get evoke an emotional response and you pass your passion through to the end user.

There are applications developed that are some of the most basic and rudimentary technology, relatively speaking, but they provide the user with an emotional, psychological connection that keeps them coming back for more. Take Twitter as an example. Twitter is far from the sexiest technology out there, but despite numerous fail whales, we keep coming back to it. Why? We want to know what the people we're following are doing. We want that connection with others that applications like Twitter readily provide. It may not be a great technological application, but Twitter is a great user experience.

My colleague Christian Saylor has published a document that discusses the marriage of a great brand experience and the latest cutting edge technologies. He contends that a great user experience is "a thoughtful relationship between art and science". This document is a great starting point for those who want to explore and start to get involved with the next generation of user experiences. (Read The Document Here)

I have come to realize that going forward from this day, we will not be building applications that are solely based on high-end technology. We will have to be focused on the total package. Our applications will define brands and fight for more than mindshare. We are developing applications that are contending for valuable time within our users' lives. Only by developing applications with a purpose and a total brand experience will we be able to deliver the true next generation of RIAs.

A while back, at 360|Flex San Jose, I gave a presentation titled "Implementing BlazeDS". I've been interested in BlazeDS a lot since Adobe announced it way back in early 2008. Being open-source, BlazeDS is open to extension and customization. Until now, only dpHibernate has really taken advantage of what can be done when you extend BlazeDS. At 360|Flex, Mike Nimer and I got to talking about how we could integrate some of the things we really like from ColdFusion into BlazeDS / Flex. We considered creating a Flex server that hooked into Mule, the OS ESB, but ultimately decided that Adobe's established presence in the server-side space with BlazeDS / LCDS was enough to guide us in a direction for extending the server-side capabilities of Flex. So Mike and I decided, after a bit of discussion, to create FlexServerLib.

So, what is FlexServerLib? FlexServerLib is an open-source project that aims to extend BlazeDS with custom message adapters, endpoints, and services. We will provide, in addition to each piece of server-side functionality, a corresponding SWC to implement the service on the Flex client.

We chose the name FlexServerLib because we really wanted the same mindset to FlexServerLib as there is to FlexLib. FlexLib is the goto point for AS3/MXML components and is strongly community driven. We want the same thing, the same community atmosphere for FlexServerLib. And, if you're wondering, we ran the name by Doug to get his blessing before settling on it.

Through the course of discussion at 360|Flex, we came across another collaborator: Chris Scott. Chris is really strong in the Flex to Java and Flex to ColdFusion department, plus he's released his own Flex framework: Swiz. Let's just say he knows his stuff. We are leaning on him to integrate the Spring Framework into our adapters to make them simple to use. Spring abstracts out a bunch of configuration headaches when dealing with these enterprise services, so it only makes sense to include it in our adapters. Chris is working on the Spring implementation for our first adapters, the JMSAdapter (Spring configurable), and the MailAdapter. Going forward, a lot of the work Chris is doing will set the groundwork for our pattern of how our adapters work. We're very lucky to have him on board with this project.

This announcement however, is not all fluff and no stuff. We already have something ready to give to the community. The first piece we wanted to deliver was a messaging interface for sending mail; i.e. We wanted to create the BlazeDS/Flex equivalent of CFMAIL. Well, we have a custom messaging adapter (MailAdapter) and the corresponding SWC that will let you send email from your Flex application without any additional server-side code. Now, sending a mail message from Flex is as easy as MessageSender.sendMail(messgae:MailMessage). This is only the tip of the mail iceberg, however. The plan is to evolve this custom adapter into a complete POP3/IMAP interface for Flex. The first piece though is just getting mail to send, and we have that today. We will also be breaking out a RPC component to do the sending of mail only.

So, where are we going with this? We have a few things on our radar to implement, but no real timetable to do it as we all have day jobs which require attention. First up is RTMP. We are planning on implementing RTMP (engineered from Red5's example) into the BlazeDS MessageBroker servlet (or maybe we can get Adobe to just do this and save us the pain). Like I said earlier, we also plan on fleshing out the MailAdapter to support full blown IMAP and POP3 messaging. Another big announcement is that, as a part of creating FlexServerLib, Mike is planning on rolling dpHibernate into FlexServerLib. So, right away, we'll have dpHibernate, a JMSAdapter, and a MailAdapter available as part of FlexServerLib.

I really think that BlazeDS is somewhat overlooked when it comes to building Flex applications. We are aiming to bring more functionality, relevant functionality (think porting cool ColdFusion functionality to BlazeDS), to BlazeDS and enabling powerful applications for Flex developers, while reducing the amount of server-side development. All that has to be done, server-side, for most components of FlexServerLib is to configure the adapter's settings in messaging-config.xml or remoting-config.xml, and include the relevant jars in your BlazeDS deployment. It's as easy as that.

We've already started to recruit contributors as well. Our first two contributors, outside of the core project leadership are Brian O'Connor and Ivan Latysh. Brian is another member of the Universal Mind team and brings a great deal of experience with LCDS and BlazeDS to the table. Ivan has actually contributed to BlazeDS (an EJB adapter), but that contribution has been put off a version by Adobe. I saw this as an opportunity and asked Ivan if he'd like to add his contribution to FlexServerLib. He gladly accepted our request and will be adding it to the repository soon.

What would any open-source project be without sponsorship? Well, we have two firms sponsoring the project. They are, in no particular order, Digital Primates and Universal Mind. These two firms are the only ones that are going to be able to provide you with any project-approved professional services you would need in regards to support and advanced development around FlexServerLib. We also have a third sponsor: JetBrains, the makers of IntelliJ IDEA, the absolute BEST Java (and now Flex) IDE around. JetBrains has kindly donated IntelliJ licenses to the contributors of FlexServerLib. All the more reason for you to become a contributor, a free IntelliJ license to use on your FlexServerLib work.

This project is being hosted at Google Code, and the SVN repository is already open and ready for you to take up. Feel free to drop any of emails or questions in the comments and we'll try to answer as best we can. Contributions, questions, and the like are all welcome. Feel free to sign up for one of the mailing lists, download the code, give us feedback on what we hope will be a great community resource.

Thanks to Ted for getting these posted up.  I had almost forgotten about these: