Meet the Author - Shashank Tiwari on BlazeDS, Flex & Java Integration
DZone this week released the exclusive Getting Started with BlazeDS Refcard, authored by Shashank Tiwari, a New York-based Flex consultant and author of the recently published book Professional Blaze DS (Wiley, Oct 2009).
The Refcard walks you through BlazeDS installation and configuration and examines the three, pull-based communication and data interchange mechanisms within Flex: 1) HTTP Request-Response; 2) Web services; 3) RPC calls as well as real-time communication within Flex. Shashank also covers Flex Integration with Spring (via Spring BlazeDS), how to extend BlazeDS via its Java API, and shows you techniques for scaling your BlazeDS applications.
In this interview, conducted at the recent Adobe MAX conference in Los Angeles, Shashank talks about the evolution of the BlazeDS project, how it compares to Adobe's LiveCycle Data Services platform, and describes some of the advantages of integrating Flex and Java for enterprise RIA development.
"I think Flex is a natural extension for Java developers. If you combine both [Flex and Java], it’s a pretty interesting proposition," says Tiwari.
The complete transcript of the interview has been provided below:
DZone: We are sitting today with Shashank Tiwari, author of the recently released book Professional BlazeDS by Wiley/Wrox. Shashank it's a real pleasure to have you with us today. Can you tell us a little bit about some of the work you're currently doing?
Shashank: Well, thank you. Thanks for having me here. Well as you know, as you just introduced, I most recently authored the book on BlazeDS which is out now and available. But, of course, that's not my day job. That doesn't pay all my bills so I do run a concern, a company, which largely focuses on helping clients build Rich Internet Applications and enterprise grade applications that need leverage for both the client and the server side. That company is called, Treasury of Ideas and it's based out of New York. We, of course, tend to work with a lot of companies which are very New York centric which essentially ends up becoming a financial service area, or the media companies. Besides, of course, I spend quite a bit of time with the community either contributing to open-source projects, writing up things, speaking at conferences, or speaking with you. You know, things of that nature.
DZone: How was the book authoring experience for you?
Shashank: Very tiring. Which, I think, is pretty much every authors experience but extremely exciting also. It also gave me an opportunity to learn at the same time I was teaching because it's an evolving technology. It's an open-source project. It's a pretty vibrant community and I certainly addressed a lot of points in the book which are about extending the essential core product. I think it was exciting, in general.
DZone: As a server-side Java developer what do I gain by using the Flex platform?
That also happens to be the market where most Java server-side developers seem to work. I mean, they typically end up building more enterprise friendly, robust, large applications. So I think Flex is a sort of natural extension for them because most of the applications that would get reinvented to become rears and leverage big server sides would essentially be something that would be Java centric, at least on the server.
Since Flex is a great choice, combining the two is just sort of an optimal stack, if you may. It brings the best of the client side and the best of the server side together. So I think what you were saying essentially is what is it for the Java developer? I think if you combine both it's a pretty interesting proposition.
DZone: Java Web developers today have a very rich array of JSF-based Ajax component libraries that they can choose from to build their RIA apps. Does Flex provide a comparable alternative?
Shashank: Sure, absolutely. That is certainly one of the value propositions. Apart from that, you also need to realize that comparing Ajax and Flex is probably not that appropriate. For the simple reason that Ajax, at the end of the day, gets constrained by what's there in the browser because finally the run time for it or the virtual machine, if you may, is the browser and there are a ton of browsing incompatibilities. The browser is meant to be more of a content-centric run time and not so much of an application-centric run time so there are sort of constraints which still exist whereas the Flash player is really a rich media run time. So, yeah, if you said whether it's the choice between JVM in a sense of swing applets in the past and maybe JavaFX right now versus the player, the Flash player then, yeah, that's a more appropriate comparison. When you consider the two, I think, Flex certainly and Flash applications certainly are... it's easier to make them. There are a ton of off-the-shelf or out-of-the-box features which some of the older frameworks tend to lack in the Java world. It just seems to be more enterprise ready in terms of being a slightly more mature product or something that has a developer community behind it today; something that is well understood and well documented. So from that standpoint I think it's certainly the choice, there's no two ways on that.
DZone: You've spent the better part of the last year writing about BlazeDS. Can you give our audience some background around the BlazeDS project?
Shashank: Sure, so BlazeDS actually is a product which was extracted out of an existing Adobe product which was earlier called Flex Data Services and then it was renamed Lifecycle Data Services. Now, Lifecycle Data Services is really part of a large suite of server-side, server-centric, products from Adobe, which tends to get into things like remoting, integrating with wire messages to your server side, the whole document management, including PDF generation, work flow, and a ton of other things out there. So a small part of that is specially catered to the fundamental two interaction models of remoting, which is essentially talking between your client-side objects and your server-side objects. And then message-based integration was taken out of that project and open sourced under the name of BlazeDS. So that's really the genesis, or the history, of BlazeDS.
Of course, what also happened is that the AMF specification, which is an important format, that makes remoting so effective, was an open specification, open sourced, if you may, at the same time. That went hand in hand and that was brought into BlazeDS. That's basically what the product is.
DZone: Is BlazeDS really just a "sandbox" version of Lifecycle Data Services? Can you actually do some serious commercial work with it?
Shashank: That's a good question. That's actually a very interesting question. Now, the question can be answered in a straight, simple manner, by saying that no it is a pretty robust product in its own right and it can certainly do a lot of tasks that it's supposed to do. But having said that, there are a few things in BlazeDS which fall short as compared to what Lifecycle offers. Especially around scalability, around streaming and real-time messaging, where Lifecycle certainly seems to be superior to BlazeDS. Part of that reason also is until they... A bunch of that post streaming protocol was closed source, a closed product around RTMP. That was never open sourced from Broadlink to BlazeDS. That was perhaps one reason why we did not see some of the nice things that we saw in LCDS comes to BlazeDS.
Besides, LCDS, because it's a commercial product, and that's something that Adobe takes to market, has certainly been built to be more scalable, as such. More energy, more effort, more money has gone behind that product, so that it's enterprise-ready.
A lot of the newer things like Java Neo, as a case in point, which provides you more robust connections, has been leveraged there, as opposed to in BlazeDS. But I think all those features will possibly flow in back into BlazeDS, either from Adobe or from the open source community. It's a matter of time.
DZone: There's also a Spring-specific version of BlazeDS that's out there. How does that differ from BlazeDS?
Shashank: The Java world has a whole bunch of people who swear by Spring, as you probably already know. When these developers started using BlazeDS for their applications, which combined Spring server-sides and Flex client-sides. They were faced with a couple of challenges.
Namely, one, well, I've got my Spring Beans which is within my Spring container within a Spring idiom. BlazeDS has its own model of configuration, its own way of setting up. So how do I get the two together? That was a challenge that everybody was, pretty much, fighting with.
The second bit was that Spring has so many nice things, including Spring security, the DI implementation, dependency-injecting implementation. A lot of templating, like the JMS template, as a case in point, which could be leveraged.
Which was difficult to use with plain vanilla, out of the box, BlazeDS. Now people had, the community had, certain workarounds for it. There were a whole bunch of hacks and sophisticated workarounds which had emerged over the last couple of years. Which ended making BlazeDS, as is, work within the whole Spring structure.
But I think, about six to eight months back, Adobe and SpringSource perhaps realized that it would be in their favor, and in the community's favor, to perhaps have an official project. Where all of that is brought in into the Spring umbrella and done in a manner that's more Spring-friendly. That's where the Spring BlazeDS project has come about, which is really an extension project within the SpringSource umbrella and supported by Adobe.
So, yeah, it's a very valuable, project that I assume that would keep in sync with the core BlazeDS product and would see a very healthy adoption. Because the Spring community loves it and you'll probably see more and more stuff coming in that bundle, especially from the Spring side.
DZone: What advice would you give to people looking to start using BlazeDS? Where can they learn more about it?
Shashank: Well, read my book. Sure, but there are a ton of sources for BlazeDS. One of the most obvious ones is the Open Source Website. If you go to opensource.adobe.com and then browse up to the BlazeDS-specific Website. You will see a whole bunch of documentation there. Which, of course, if more along the lines of reference documentation as it typically is. A lot of API documentation. Plus there is also the BlazeDS Developer Guide, which is officially published as a part of the other developer guides that Adobe publishes. So those exist. Apart from that, there are a ton of articles, actually, online from various sources. There are some on DZone, which people can certainly go and read. There are a bunch of them on the Adobe Developer Connection. There are some on InfoQ. If people just Google for it, they will find a whole bunch of it.
DZone: There's also the BlazeDS Refcard, which people can download from DZone as well.
Shashank: Absolutely. I think that will be a very valuable piece, because it will give snapshot, quick overview, of some of the features that people might want to get familiar with, right up front. I think it will have same advantage that any other ref card has, actually, which is a very convenient, quick, reference.
DZone: Shashank, we look forward to working with you to publish more content around BlazeDS and the Flex Platform. I want to thank you, on behalf of DZone, for your time today.
Shashank: Well, thank you. Thank you for having me here. I hope that a lot of developers and users continue to use this product and the community grows. There's a lot more that DZone also contributes, in terms of really good content, in the space.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)