WebORB and FDS, friends or foes?
I keep running into the questions about WebORB and its relationship with FDS. Is WebORB a replacement for FDS? Is it an add-on? Is it a complementary technology to what Adobe is doing? I'd like to take a moment to address these and other related questions.
- First off, right from the get go we said we do not plan to add Flex integration into WebORB for Java. That edition of the product supports Ajax and Flash Remoting (AMF0) and does not offer ANY kind of Flex integration. So from the perspective of our Java offering, it should not be even on the radar for anyone developing with Flex.
- We offer Flex integration for the following platforms and development environments: .NET, PHP and Ruby on Rails. Now if you spend 2 minutes on the Adobe's website (you are welcome to take more time if you want to), it will be quite clear that Adobe's Flex offering, or to be precise Adobe's FDS product offering is available only for Java. As a result, if you are a .NET, RoR or PHP developer, the most you can do with FDS is to use WebServices or plain HTTP requests to integrate your backend code with the Flex clients.
WebORB is a technology that fills that gap. It is not a replacement, since it is physically impossible to replace void (if you figure out how to do that, you might as well claim the Nobel prize). So to put a label on it, our product complements Adobe's product offering by extending it to other platforms. Any .NET, RoR or PHP developer using WebORB can get all the benefits of Flex Remoting, Data Management and soon Messaging for their native environments. - How does WebORB integrate with Flex then? Our goal is deliver the same kind of developer experience to the .NET, PHP and Ruby developers as one would have with the Java implementation. To us Flex is a standard. Just like SOAP is with a variety of implementations from Microsoft, BEA, Sun, etc. As a result, WebORB is an implementation of such a standard. You will find the same development process, same configuration files, same APIs, same on-the-wire protocol, etc.
posted by Mark Piller at
4:38 PM
Subscribe to this blog
4 Comments:
I recognize there are not plans to support AMF3 in the Java version, but I don't understand the rationale. The gap between free and $20K per CPU begs to be filled, and is the primary reason many developers I've evangelized Flex to are sticking with AJAX.
6:39 PM
Anonymous - If you're interested in using FDS and find the $20k/cpu price a bit of a sting too far, it may be worth talking with Adobe about alternative licencing - they're interested in getting people using FDS and can work with you on a percentage point basis (i.e. %age of your sale) and other discounts - of course they're hoping you will then grow enough they'll get their 20k.
And of course it is possible to use Flex with Web Services rather than Java remoting (how many AJAX developers use remoting vs Web Services??)
5:11 AM
Ajax isn't really an alternative to FDS but I agree that the price jump is a steep one and can be a disincentive. At least FDS is optional now (unlike with Flex 1.5)
By the way I believe Adobe has a FDS Departmental Edition that "plugs the gap" between the free Express Edition and the $20k/cpu Enterprise Edition.
5:18 AM
juleslt - The point is Adobe is trying to make $20k per CPU, whether it's per CPU, as a percentage, or whatever else. My question is whether Adobe would sell more than 10x the licenses at a price point 10x below the status quo. I absolutely believe so.
Web services and HTTP requests are alternatives, but the perception this leaves is similar to bait and switch marketing. "We'll give you the basic functionality free, then knock you off your feet if you want the cool stuff." That's a horrible business model for Web 2.0.
Where would JRun or ColdFusion be today if either was $20K per CPU? Ancient history.
Re: Departmental Edition. Absolutely useless for public-facing applications, since you don't control how many users visit your app at any given moment.
11:04 PM
Post a Comment
<< Home