RIA Architectures: An Exclusive Interview with Adobe's Duane Nickull
DZone recently caught up with Duane Nickull, Senior Technical Evangelist at Adobe Systems and bass player with the band 22nd Century. In this interview, recorded at Adobe MAX 2009, Duane revisits the notion of 'Web 2.0', and discusses some of the new architectural and human interaction patterns that are shaping the way in which we build Web applications today. He talks about some of the new Flash authoring tools for the iPhone, the Open Screen Project, as well as the impact HTML 5 will have on Flash adoption.
The complete transcript of the interview has been provided below.
DZone: Duane, it's a real pleasure to have you here with us today. Can you tell us a little bit about what you're currently doing at Adobe?
Duane Nickull: Sure. I'm a senior technical evangelist. I guess in the shortest sense of the definition, I'm evangelical about technology. It's like technology with religion for us who are on the team. What we do is we really focus on working with architects, developers and community members. We go out, we talk, but more importantly, we like to listen to find out what's bugging them, what's on their worry list, what's going to be their biggest brain activity in the next six months. Through this, we collectively get a state of where the community is with respect to not only our products but just the industry in general.
DZone: You'd published a book earlier this year, with James Governor and Dion Hinchcliffe called "Web 2.0 Architectures, " published by O'Reilly. We've heard the term "Web 2.0" used for quite some time now, but can you give us a sense of what Web 2.0 really means today and whether it's still a relevant term to describe modern Web architecture?
Duane: Sure. It's definitely a relevant term. It means so many different things to so many different people, which is why we developed the book, and the book really examines it. I've done a lot of work in enterprise architecture, and from my standpoint, I like to take something and really look at it pragmatically. In general, there are going to be two big revolutions that have happened in the computing industry in the last decade, and one of them was the migration from a client server model to service‑oriented architecture and architecture that's geared around taking capabilities, making them available as services that could be reused by a multitude of different clients.
On the client side, there's this parallel revolution that's being enabled by this, by having more information available via services to do stuff with and being able to mix stuff together better. You've had this better user experience on the front end, and that's generally being termed as Web 2.0.
Now it's not always just stuck in the technical realm. You have things that you can do in the technical realm, but then there are companies who've taken that, and taken the service‑oriented back‑end approach and built a platform to take advantage of human needs and human patterns.
So an example of this would be YouTube. The founders of YouTube noticed a very simple pattern, which is that people who make videos generally like other people to watch their videos. They said, "Well, we're going to make a platform that helps them do that and use the Internet as the platform on which our platform will be based," and they did that quite successfully.
Another pattern that was picked up on was MySpace, and MySpace took the pattern that most musicians, such as myself, when we create music, we want other people to hear our music. It's very, very basic. They put the technology around that to help it happen.
Web 2.0, when we started to write the book, it was very difficult. It's a chicken and egg. You have to look at things that are Web 2.0 and dissect them, but how do you know what things are Web 2.0 without knowing what Web 2.0 is?
We took the things that were the least contentious. Most people agreed that eBay, and PayPal, and MySpace, Flickr, all represented a new generation of Internet‑based applications and architectures that were built from the ground up with the Internet at the core, and with the idea that we're a platform and we're going to enable people to do a lot of things.
Tim [O'Reilly's] ideas, he really summed up a lot of the general ideas of the web like architectures of participation, harnessing collective intelligence, like the Wikipedia model, which unfortunately hasn't worked out so well. We took a look at these things, and started dissecting them and saying, what are the patterns that these guys do?
The reason we wanted to do this in the book is because we wanted to isolate it from the implementation, wanted to take a pattern that was abstract of the actual thing so somebody could look at it and say, there's this thing called social networking. What is it really?
Through dissecting it and distilling out what it was away from all the other stuff, we realized that social networking isn't something that's new to Web 2.0. The social networking pattern has been around since the dawn of civilization. Ever since we've been able to communicate with one another, we've had these patterns.
What's new about Web 2.0 is we've actually decided to start declaring those for others to see. The pattern we came up with, James Governor largely has the credit for this one, is called declarative living. And Twitter is an example of declarative living. MySpace is a sub‑example of declarative living. Dopplr, when you declare where you're going to be on your trip, and on all of these other sites where you just declare something about yourself. Facebook, who are your friends? What are you doing? How do you feel right now? These types of things.
This is what we did by being able to extrapolate that out and say, OK, there's a pattern where somebody takes information about themselves and publishes it through some way, shape or form so that others can then come along and harvest that information. That's a pattern.
DZone: It's interesting because it sounds like what you're saying then is these user interaction patterns and ways of behavior are inherent in human behaviour. We've now just found a new manifestation for them through the Internet, through the Web.
Duane: Yes, it's also in the social networking context yet. But declarative living wasn't always what it is today. That's the one that's really been affected. We used to declare who our friends were, when you're mad at somebody say, "You're not my friend anymore, " when you're six years old in the sandbox. "You can't play with my toys. No, you can't." [laughs] These are the human patterns, too. Architectural patterns have many different kinds of categories of patterns. There are purely technical patterns. There are architectural patterns. An architectural pattern would be building a platform as opposed to a closed website, and the platform really is, by definition, something that supports further growth and evolution in extension by coming up, as eBay did, with a platform whereby people could become eBay developers. Now their developer conferences are huge. PayPal is the same thing. They have a big developer conference.
Then you get into the pure technical patterns such as Ajax, and Ajax looked at the model of request/response. The people who developed it, when the XML HTTP request object was put into the browser to enable somebody, instead of refreshing the whole page, to just get a smaller part.
We called it something like the atomic particle update or something, but it's really getting away from the page refresh and getting down into a more minute view. But that enabled a lot of other message exchange patterns, like subscribe, push or pulling, et cetera. These are purely technical.
Then you get these composite patterns that encompass a little bit of each, and these patterns start to get very, very complex. But the idea behind the book was that this thing called Web 2.0 is really a series of these patterns that we seem to have noticed and admired in these sites that did something new, and being able to take these patterns, and distill them down and present them in the book in a way that there's a generalized architecture, a generalized model for integration and interaction and allowing people to engage with you.
We presented them in the book in a way that somebody who may be in IT in a company can look at them and reapply them to their own company or use one of them or just take them and use part of one, part of another, et cetera.
DZone: And one of these patterns is the 'Rich Internet Application.' With the RIA pattern, as it were, it sounds like at least some level of processing is moving back to the client side.
Duane: Yes, but I could sum it up in four words. Don't piss off users. Here's a true story. I filed my taxes electronically and because of what I do and the fact that I'm a musician and I travel a lot, I had a lot of forms to fill out. So I send in maybe 25 to 50 forms to file my taxes. I don't remember the exact number because some of them are multiple pages.
Revenue Canada took the information, looked at it, and they sent me back a correction that said, "No, this was wrong." Now, let's think about that for a second. My first response is why the bleep are you asking me for this information if you already have it? Why are you forcing me to do work? If you already know the answer, don't make me guess at it and sit there studying and doing math.So here is a great user experience with Revenue Canada, aside from the fact that you're paying taxes, which isn't always an enjoyable experience. What if instead of getting a tax form that is completely blank, what if they sent a tax form that was already pre‑filled out with all the information they had. They just said, "Is this correct?" If this is correct, hit accept, electronically sign it, and then you're done. Think of the collective goodwill that would create with their users. Independent of technology, that's really a RIA. I speak at a lot of conferences. So many of the conferences when I apply, I have to go first and set up a user account. Then you get to the speaker submission form, and they start asking me for things that they already have, like my name. I'm logged in!
My bank does that, online brokerage house. You go through this real intense security. You get your user name, password, everything is encrypted. I'm in this really safe place, and then you want to do a transaction. They say name, phone number, address. If you don't know who I am by the time I'm logged in and about to do this transaction, your IT system sucks. A rich experience would be not asking for that.
DZone: Are web developers doing enough today to understand user behaviors and user experience patterns?
Duane: I don't think that that is the developer's responsibility. I think that is the architect's responsibility. I think for creating an RIA a lot of that work must be done by the architect. Let's back up a sec. RIAs, why do they exist? Any website, whether it is rich or not or interactive, is there because it is part of a process. If I am a big food company and I put up a website, I'm putting up that website because there is an information flow that is part of my process. The process may be getting a new customer. It may be getting an existing customer to place an order with me or getting somebody to place an order that is not a customer.
First doing the modeling and understanding why you have that thing in the first place, that is absolutely essential before you start to build it better and build it rich. By the time this stuff gets dumped into a developer's hand, the developer is often tasked with a very seriously scoped and constrained set of deliverables. Build a form that captures this, this, this, this, and this. Inevitably, stuff gets left out.
We're Canadians. How many times have you gone to order something, and it asks you for your zip code instead of your postal code? And it doesn't accept it because it's not five numbers.
DZone: All the time.
Duane: All the time [laughs]. So just this one pattern of understanding that Canada has a postal code instead of a zip code.
DZone: Or that Canada is a separate country. [laughter]
Duane: Well, these are very simple bits that can be done. If you're a developer working in an IT shop, a lot of times these requirements that are handed to you say to build something to make sure that they only enter a zip code. That's not the responsibility of the developer. The responsibility should be for the architect to understand the business requirements, sit down with the business owners, the LOB guys, and figure out how he is going to build something in IT that is going to be the best thing to accomplish their goals. So, IT supports business.
DZone: Are tools facilitating this? I believe Flex 4 allows designers and developers to interact with the same application in more dynamic ways than ever before possible.
Duane: It is. The specific product that you are talking about is called Adobe Catalyst. Catalyst is really something that can take a Photoshop file or an Illustrator file that a designer has done and take it an intermediate step between the designer and the developer where you can take that purely graphic file and turn a triangle or a rectangle into a user input element. Then you can pass it off with the code that can go right into the Flash Builder four product and work with the Flex four framework. That is a good start, but both the designer and the developer in that case still have to be directed by the architect at a higher level. If the architect doesn't give them sufficient instructions or clear instructions, they're going to build something that is going to be great for their set of requirements. Designers and developers rarely fail to do that. But if they have a bad set of instructions, the outcome cannot be good.
DZone: What advice would you give to architects who are building Rich Internet Applications, in terms of how they should tier their applications and spread business logic versus UI logic and flow logic? Is there any sort of general guidelines that you would give there?
Duane: Yeah, well, first of all they should buy the book, "Web 2.0 Architecture." [laughter]
Duane: A lot of it is very specific to the job at hand, but there is a pattern that we explored in the Web 2.0 book called the mashup pattern. In that pattern, you have a view presented by a client that is mashing up information from two or more sources. I guess you can't just mash up one thing. Some of it may be off the user's desktop or their own host system. Some of it may be from a bunch of services. When you start to look at building these for the enterprise, the architect's job is understand the constraints or the architectural forces working against them and the potential architectural forces working against them in a way that they can mitigate it. Sometimes the mitigation involves not building just a two‑tier mashup, so there are variations on the mashup pattern.
One is that you do all the mashing up, all the logics, on the client. Now that is great in a lot of cases, but if there is a potential for some of the service calls supporting that mashup to be 150 MB in size and all XML files, and there are 10 of those going out at once, that client is not going to be able to mash‑up that stuff very well if you put it on an phone or you put it on a Blackberry device, or some other resource‑constrained device.
And at that point, it probably makes sense to evolve to a three‑tier architecture. Now, there are models that we explored in the book, and they're basically just showing ‑ because they're abstract models, they don't have cardinality. But you can obviously have multiple integration tiers.
An example of this would be ‑ we just did a demo last week of an SAP R/3 system using the JCo architecture, which is the Java connectors to ABAP from SAP. And we built an intermediate integration tier using LiveCycle Data Services that was able to then offer the plumbing to the last mile to the client in something called AMF to client‑built using Flash Builder 4. And in that case, the middle tier has the responsibility of doing all the communications with the SAP system, which sometimes could result ‑ in this case ‑ in a lot of data coming back.
And its job is to filter out the data not needed by the client and manage the communication so that the client has very high efficiency and is perceived as being very relevant. So, these are the types of things architects need to looked at, and these are affected not just by what the user might do, but it's also constrained by what the licenses are.
In this case, the business owners have to be involved and have to look at "How many licenses of SAP will I have to buy if I do a two‑tier versus how many licenses of LiveCycle will I have to buy if I do it three‑tier," versus something else.
DZone: So Duane, the iPhone has significantly changed user interaction patterns in terms of how we interface with the Web. Yet oddly enough, Flash is still not natively supported on the iPhone yet. What are your thoughts on that front? Can we expect anything to change on this front?
Duane: Well, something did change. In the keynote here at Adobe MAX , we saw that there was an announcement of using the Flash authoring tools to be able to develop applications and then compile them to target for the iPhone as a platform. And 90% of the media understood, but there are still a couple of them out there that said, "Apple now supports Flash on the iPhone, " which is actually emphatically wrong. The correct statement would be that "Adobe's tooling can now enable you, through languages and user interfaces and tools you're already familiar with, to build iPhone apps and then submit those through to the App Store and hope they get accepted." So you know, that has changed a lot, and there are a lot of other companies doing really cool things out there with the phone and mobile space. One of them is Nitobi in Vancouver. They have a project called Phone Gap which combines APIs from three different devices and allows developers to write it once and deploy to all three.
And you know, there are people doing really exciting stuff out there. In general, I'm pretty excited about it, but there are still some hurdles the technology has to account for. People want richer and more interactive applications on mobile devices, yet they want longer battery life. Those are two diametrically opposed objectives.
One of the more exciting things that have happened in mobile space development right now is, as we saw at Adobe MAX 2009, the advent of Flash Player 10.1. So this is the full version of Flash Player going on these devices. And in order to do that, the engineers at Adobe really have pulled themselves inside out to cut down the runtime footprint of that Flash Player so that it doesn't eat the battery life. And this is not going to be something that is easily repeatable, if repeatable at all, but anytime you get a bigger set of APIs and a more robust user experience...
DZone: ...that's pretty amazing...
Duane: ...Yeah. They made it available for cheaper in this route. And now, I don't think that they're going to be able to consistently do that, but who knows, maybe something will happen. But they definitely deserve a Nobel Prize for their efforts on Flash Player 10.1. It's a fantastic thing. Adobe pioneered, with some of our partners, what's called the Open Screen Project. And you saw yesterday, Google joined, RIM joined. We've got device manufacturers like Nokia who are on board, Docomo on board. We've got the chip manufacturers, Intel ‑ like, all these people joining the Open Screen Project. So, there's a real future.
DZone: What is the Open Screen Project?
Duane: There used to be some licensing restrictions on the Flash Player where if you wanted to put it on a device, you used to have to pay some money and license it before you could. And the Open Screen Project realized that that model might have worked 10 years ago, but it's not something that works today. Times change, and we have to change with them, and we removed the licensing restrictions around the Flash Player. We also, at the same time, really opened up how the roadmap of Flash going forward is being shared. And the theme behind the Open Screen Project is that you have this one runtime which can be used across multiple screen types. So, touch screens, using it on mobile devices, PDAs, tablets, desktops, laptops ‑ you know, devices in your automobile, as we saw in the Tesla and whatnot, and the Prius.
All of the world is seeing the value in having a standardization on this one thing and having one consistent runtime for this. You know, one of the things that a lot of Ajax developers complain about is they go out, they do great work, but they don't control how the browser manufacturers may upgrade or change or patch things, and sometimes it breaks things.
If you're an Ajax developer, you have to look at the fact that if you're developing, you have to first start out asking, "Which browsers are we supporting?" And then which versions of these browsers, and which operating systems, and for how long. Any competent Ajax developer you ask, you say, , "How many of you think your apps will all be running without you touching them again two years from now on all the browsers?" They won't put up their hands, because they know.
So, this is an advantage. And this is not a diss on Ajax. Ajax is great, we love Ajax at Adobe, but when you start looking at how the single runtime across multiple screens really starts to benefit the whole ecosystem, the choice is compellingly easy to make. And seeing Internet and TV converging now with Flash on televisions, this is a big ‑ this is a huge revolution. This is going to really change our world.
DZone: You've done some work in the standards space. Can you talk little bit about that?
Duane: Actually, I've completed the work. I worked on the Web Services Architecture at the W3C and did some other work there. I'm still chairing the OASIS SOA Reference Model Technical Committee. Yes, standards are very important. The work in the United Nations CEFACT organization was very instrumental and groundbreaking for me personally just to get me thinking about things in a new way. Doing all of these standards activities really is enlightening when you see the benefits of what a standards body run properly can do.
Not all standards are run properly. There can a very difficult, painstaking, decision‑by‑committee process that takes a lot of energy out of you if you do it, but there are also a lot of instances where it really works well. It largely depends on who the people are, what the problem is they're tackling, and how easy it is to scope that problem, and then work through figuring out what the options are and choosing the best one.
With PDF as an example, Adobe made a decision a few years back that we brought PDF out, and we had always been the shepherds of PDF. At some point we realized it was an illusion that we controlled PDF, because we don't. Even though we wrote the specs for it, we didn't control it.
We couldn't do what we wanted with it because we have a larger community that would have rebelled if we did the wrong thing. The community members who are using PDF were wanting to feed the input into the future revisions of PDF, which is what we want. We want the people using PDF to help...
DZone: ...to guide the direction of PDF....
Duane: Exactly. There's no reason why we won't want that. Then the realization came. Is Adobe a standards body? We're not. We're not a standards body. We participate in standards bodies. We have a very, very good track record participating in open standards, some of the activities we've done in the last few years with open‑sourcing, with Flex SDK, and major parts of the framework for Flash and working with standards bodies on critical issues to move technology forward. It's amazing what a company of our size has been able to accomplish.
DZone: What stake does Adobe have in the HTML 5 standard? There's been some talk about HTML 5 potentially replacing Flash.
Duane: The best answer is I really don't know. We're going to have to see what HTML 5 is when it's done, and Adobe's there participating. We're monitoring, looking at it, and of course it impacts us just as much as it impacts everybody else in the world. We want that the future of IT is determined in a way that meets everybody's needs. There will always be some people who, through whatever standard, won't see that that standard meets their needs, and they will do something some other way. Even if the standard does meet their needs and they're already doing one thing, it's very unlikely they're going to drop that thing and completely retool all of their architecture for this other new thing. So by being an incumbent in the area of RIA, it's very unfathomable that HTML 5 will erase Adobe from the map.
That being said, I'm excited about HTML 5. We all are. It's the next evolution of this thing called the Internet, and it's going to be the cornerstone of the Internet. There's some really interesting activity going on with respect to bringing a much more rich multimedia effect to it.
But let's remember what HTML is. HTML is a markup language, and it's hypertext. "T" stands for text, not video, right?
Duane: If it's now growing past its scope of what it started with, we're going to see some very interesting developments. I'm personally very open to seeing what those are and seeing how they're proposing solving some of the tougher challenges. I think when you start to look at the introduction of functionality that Flash has, it will be very difficult for anybody to build a runtime, not withstanding the fact they probably will be trying to build several runtimes because every browser manufacturer will want to have their own runtime, but just build a runtime that's going to be able to deliver that in a more efficient manner than Flash. You're talking about a 10‑year‑old heritage with Flash.
DZone: Flash is quite ubiquitous.
Duane: It is. It is. There are people that don't like Flash, and that's great. They can use HTML 5 if they don't like Flash. Having choices is good, and having choices drives innovation in the industry. If there wasn't the entrance of other people into the RIA space with technologies, it might have a stifling effect on innovation to some degree. Innovation just keeps everybody on their toes.
DZone: Duane, looking forward on the horizon, how do you see the Rich Internet Application space evolving?
Duane: I don't know how the future will hold, but if I was to give advice, I would encourage people to look at the fact that an RIA is only there because it's part of a process. Whatever you're trying to accomplish with the RIA, it's likely to be only one step of some overall bigger process of a business goal or objective. Understand why you're trying to build an RIA, or any application, for that matter, and understand what its role is in the process. Understand how the process can support your developing that.
Going back to I set up an account with an online brokerage, I log in and want to do a transfer, and it asks me for my name. Can I get that name from the overall process? If the process already has access to that, let's use the process to pull something out of something else and pre‑populate that to make that user experience better.
When you start looking at Adobe LiveCycle ES, this is where we really think the future is as a company. We're already tying in the Flex front ends to the heavyweight backends, and we're doing it in a way that things can be orchestrated.
It's embracing the service‑oriented model absolutely perfectly, and the whole service container model enables us to take something that exists in an enterprise and make these available so you can reuse as many of these things as possible to help you build the best RIA. The enterprises are moving in that direction, because where there's competition...
You look at the younger crowd here. If they have five sites they can go to do something, and the first one presents them with a 100‑page long form, it's going to be hitting the back button very, very quickly.
DZone: Yes, absolutely. Duane, on behalf of the DZone community, thank you very much for your time today, and we look forward to speaking with you again really soon.
Duane: Any time.
DZone: Thank you very much.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)