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.
As many of you know, Universal Mind grew from the ashes of Macromedia Consulting. At the time, there was no talk of Web 2.0, Flex, or anything like that. We grew our business on ColdFusion. ColdFusion is in our DNA. It's always been a part of what we do, but lately I've heard rumblings from the community that Universal Mind has abandoned ColdFusion. Nothing could be further from the truth.
While people have been saying that Universal Mind has left ColdFusion behind, we have been quietly building up our ColdFusion talent with some of the strongest people in the community. Some are names you know, some are names you do not. Chris Scott, Dan Wilson, Laura Arguello, and Dan Skaggs are just a few of the great ColdFusion developers we have working with us.
Yes, we build RIAs. That includes Flex, AJAX, Silverlight, and the technologies that power them, including ColdFusion and Java. We've got some of the best Java talent around too, but that's a post for another day. This all means that we can build not only your RIA, but the complete solution from back to front. When it comes to building ColdFusion back-ends for your Flex application, nobody has more experience than Universal Mind.
So despite rumors to the contrary, our ColdFusion practice is very much alive and kicking. What do we build? Enterprise Class Rich Internet Applications, including those powered by ColdFusion. After all, ColdFusion is in our DNA.
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.
This month's issue of ComputerWorld contains a cover story titled: "Can Web 2.0 Save BI?". SpatialKey is featured on the cover of the issue as part of the article! The article goes into depth about how the Ogden Police Department is using Web 2.0 (SpatialKey Law Enforcement, in particular) to analyze data in seconds, rather than days. Doug and Ben go into this article in a bit more detail if you want to learn more about it.
Previously, the UM Blog Aggregator had been an experiment in combining Hibernate and ColdFusion with Mach-II. This, over time, proved to be a bit unstable, to say the least. About a month ago, I took on the initiative to re-write the entire aggregator using Java. Under the hood, we're still using Hibernate, but we're also using Spring and SpringMVC to manage the transactions and Hibernate sessions a bit better. One thing you'll probably not notice, but is the coolest to me, is that the post search is now powered by Hibernate Search. What does this mean? Well, every time a new post is aggregated and persisted, Hibernate transparently indexes the object and makes it searchable. It's powerful stuff.
Anyway, I hope you enjoy the site and please give us some feedback.
I have had a Sprint Mobile Broadband card for a long time. I love it. It gets me online wherever I am and whenever I need it. One thing i noticed about it when I bought it was that it has a GPS receiver in it. Up until now, Sprint has not been very forthcoming in how to get to the GPS to use it. Well, it turns out you need to use their Activation & Location Tool. This app must be running if you want access to the serial port that provides the GPS data (as NMEA sentences). While in this mode, you can also use the device as a GPS inside of Google Earth. Sounds like this little piece of hardware would be a good candidate for Merapi......
So, first there was GPS. Then, there was Growl integration. The next progression is to see what we can do with other hardware. There is a great site called Phidgets that contains a bunch of different input devices and controllers that you can hook up to your computer. The best part of their selection is that they offer a NATIVE Java API. So leveraging this API, we can use Merapi to broadcast RFID events into AIR. Pretty cool stuff, if I do say so myself. This screencast is just demo of watching for events when a RFID tag enters the sensor area and exits the sensor area, but it conveys the general point. Enjoy and, as always, comments are welcome!
The other day, I showed you how to talk to a Garmin GPS with Flex (AIR), Java, and Merapi. Well, today I'm back to talk to you about how to leverage the Java APIs to the growl notification service via Merapi and Flex. Growl is a notification service for OS X that a lot of applications are starting to make use of these days. They have a SDK which includes Java libraries. Using Merapi, you can leverage these libraries and send true Growl notifications directly from AIR applications. Enjoy the screencast below and feel free to drop me a line in the comments if you have any questions.
So, my co-worked Adam Flater started up the Merapi Project a while back and asked me to contribute. Up until now, the only thing I've had time to contribute was the name. Well, after seeing the cool stuff that he and Jordan were doing at 360|Flex, I decided it was time to step up to the plate, get my shit together, and produce my own kick-ass Merapi demo.
Anyone who has been following the blogs knows that we at UM are real big into GIS and data visualization. Don't believe me? Take a look at SpatialKey to see what we can do with it.
I recorded a screencast where I walk you through the setups and the code of the application:
Everything Girl