Summary
To do rich apps well, we need the right app model and we need a cross-platform ubiquitous client. I've written about the former, a declarative model for building service-oriented rich apps, called Flex. Now I'll mention a new product aimed at the latter: An evolution of the ubiquitous Flash VM that transcends the browser and runs in the desktop.
Advertisement
On Central and Rich Client Containers
Richness within a web browser is important, but it doesn't satisfy a couple of important requirements of data-rich and behaviorally-rich applications: inside a browser, it's difficult to develop sophisticated apps that can function as well offline as they can while connected, and it's difficult to develop true push-based and other more sophisticated message-oriented applications.
It is also difficult to aggregate data from one web app or service with that of another, as the decisions about what data can be aggregated are more or less locked into little web app black boxes on the server. There is no client-side OLE-like facility for web apps and web services, as data aggregation decisions are made by the web app and service developers. Even if you want to do something as simple as send a song name returned by Google to an Amazon or iTunes search input, forms-based cut-and-paste is involved; and that simple example doesn't touch on more useful automatic combinations of metadata through different service inputs and outputs. There are also not enough smarts, or basic server-side functionality in the client, to do much interaction with services on other clients (as opposed to servers hosting web apps).
Macromedia Central, which is a Flash desktop player and an application container atop that player, begins to address some of these issues.
Developers can create Central applications and Macromedia will use its distribution mechanisms (similar to the mechanism we used to deploy the Flash player to the world) to get those applications to users everywhere. By way of a single-click installation, end users can add applications and agents to their Central installations. Developers can create agents that run in the background while Central is operating, can bind agents to remote web services, can store data in one of two different local storage facilities, and more. Central also provides a try/buy mechanism and provides a payment facility, so that developers can decide to charge for their apps and provide trials -- using a simple XML declaration in the Central app descriptor -- and Macromedia handles the details.
Central can help aggregate and unite disparate data sources, allowing users to essentially cut-and-paste the data output by one app or service into the input of another, making it possible to create powerful service workflows and client-side portals. Users can send data from one application to another using Central's "Blast" feature, which behind the scenes generates and sends Schema-compliant XML from one app to another. The possibilities are encouraging, particularly (in my opinion) in intranet and extranet scenarios, where there is a hunger for smarter portals.
As a quick personal aside, it is written mostly in C++ like all the Flash players, and while I initially enjoyed working in C++ again after about four months I remembered why I stopped working in C++ in the first place. Looks like my next project will take me into C# land, a change I personally will welcome. My admiration for those who will continue to work on the C++ Flash codebase going forward is very high indeed, yet I also suspect a certain degree of masochism is intermixed with their undeniable brilliance.
One very powerful part of Central came from one of our partners rather than us: America Online is onboard and is planning to provide a Central API that allows developers to build apps that use AOL Instant Messaging. While yet another chat application is probably not what the world needs, treating IM as an embedded feature of applications has still not been fully exploited. Even more interesting to me is exploring IM networks as conduits for real-time data transfer rather than just for person-to-person messaging. This is a 1.0 release, but I'd expect similarly encouraging developments to follow.
You can read more about Central from Kevin Lynch, the keeper of the Central vision: Central Whitepaper (308 KB, PDF format), and you can grab the software itself from the Central page on macromedia.com.
On App Models and Ubiquitous Clients: Flex and Central Together
Many smart folks have tackled rich application issues, and most have come to the conclusion that creating the technology isn't enough to make it a broad reality. To make rich internet apps real requires both (a) a rich application development model that is fairly simple, standards-based and familiar to all the parties involved in building, testing, and managing web and service apps today; and (b) a ubiquitous cross-platform runtime which can host the rich client applications.
I see Flex as the former and Central as the latter. Others may make cases that other technologies meet the same requirements, but while there are folks who can craft strong application development models (Microsoft's XAML, for instance) I think the latter requirement, the ubiquitous cross-platform runtime for rich apps, is darn near impossible to find.
I realize there are those in the DHTML world who would argue that the browser itself is a ubiquitous runtime, but in practice I have found that assertion to be false where rich apps are concerned, as even if browser inconsistencies are dismissed and even if the winner of the browser war does change course and does announce a future for the primary DHTML runtime (two very big 'ifs'), DHTML in browsers alone does not provide the data richness that I seek: namely, sophisticated offline storage and synchronization facilities, support for local service interaction as well as peer-based services and remote services, support for push models, etc.
So powerful possibilities, post-1.0 for both Central and Flex, comes from uniting these two in deeper ways.
After researching Macromedia Central a little more, I have to disagree that Central will become (or is a good candidate for) the ubiquitous runtime container for rich client applications. The primary problem being that distributing applications which use Central as a container requires developers to enter into a commercial distribution agreement with Macromedia. IMHO, this choke-point will discourage developers, and preclude Central becoming a ubiquitous platform for rich client apps. In addition, even developing for Central is hobbled by the need to have a special ID for each app. Since only one ID is available to developers, the ability even to develop and test (never mind distribute) Central-hosted applications is severely limited. You'd better not have more than one idea at a time! And you'd better not even think about developing a set of cooperating applications. And you'd better not be an independent software developer, because you won't be able to afford the price of entry.
The unfortunate thing here is that the problem is not the technology, but the business model. It makes no allowance for grass-roots development efforts, small ISVs, etc. There has to be a better way than this, or I fear Central will become one of those promising technologies that couldn't get off the ground because of lack of developer commitment.
BTW, to lighten it up a little, I really do like the idea of Flex. It is--or at least it sounds like--what many of our developers have been waiting for (getting ahold of the Flex beta is not as easy as just asking, so it may be a long time before I can say for certain). I wish you luck with the Flex effort.
Your comments are good to hear, but I think we're speaking slightly different things. To fully confess, I am really envisioning a version of Central that's set up a little differently from the current macromedia.com-hosted installation, and instead seeing the install made available from an intranet-hosted server within an organization. In-house developers would be able to use Flex to write portlets and other apps for Central without entering into the sort of agreement you mention. Organizations would control the distribution channel for these applications, and Macromedia would not, so therefore there'd be no need to compensate Macromedia for distributing your commercial application. The business model would involve some sort of licensing of the provisioning server, maybe even as part of Flex, and the Central installation could be controlled by corporate IT.
However, for non-corporate commercial apps that make use of the macromedia.com-hosted Central, perhaps there is some sort of business model for simplifying or even eliminating the ID requirement when Flex is used. I think the business imperative is to find a modest means of generating revenue from the Flash VM itself (which is free) and from Macromedia's ability to distribute your apps to a broad audience, but if the revenue comes from Flex rather than commercial Central applications in Flex-Central situations, perhaps it will be possible to forego parts of the current Central distribution agreement for Internet apps as well as for corporate apps? There's value in the fact that Macromedia is using its distribution channels to push your commercial Central applications out to end users on the Internet, and some form of compensation for that value (when your app is commercial rather than free) seems reasonable to me, but perhaps it can be more reasonably found in other places?
I am quickly becoming a fan, and completely agree with your focus points on the Flex and Central projects. I am sure you were frustrated that you could not speak about Flex and Central during your interview on TheServerSide; they would have been perfect for that discussion.
Bravo on Flex - great job. And I think that central makes a ton of sense as well. I am not as excited by it as I am by Flex, but that reality has a lot more to do with how excited I am about Flex. I do have a couple of questions about both technologies and would appreciate any thoughts you may have.
I am the Enterprise Architect for a mid sized financial services company. We do a lot of our development in house, and J2EE is our primary development platform. I was brought in as an EA because the company I worked for recognized an immaturity in their application infrastructure, and making a componentized architecture based upon business domain models is my number one priority. The business tier architecture is pretty standard stuff, and the integration tier is still being designed (really I am waiting for a compelling BPEL implementation). Until I met Flex, I was planning on using custom JSF components at the presentation tier. What is attractive to me about that is that I can then design discreet components that cover the entire J2EE stack - Faces components could be build ready to go with JSF event handlers would call the service orchestration scripts and business services. Under that model, my developers only need to interact with the custom tag in a JSP page and set it's attributes, and they are abstracted from the complicated stuff. And because the JSF components are self-contained and activate event handlers to perform processing, my developers can place a component in a JSP and not have to change page processing logic or config files. After reading the white paper, my guess is that Flex provides a similar solution, but I wanted to be sure: can I write custom Flex components that developers can call with and MXML tag and customize by setting attributes? Can these components be aggregations of other components? And if you have a library of components with a collection of input fields, how is page flow and layout handled if you are just listing the components declaratively in MXML? That last one is pretty detailed; you can tell me to wait for the user docs if you want (I requested the beta, but haven't heard back yet).
Does Flex have the capability for local storage and working offline, or is that strictly Central? And are agents specific to Central, or is there analogous technology for Flex?
You guys are recommending an ActionScript MVC framework running in an agent for Central apps. Is there any reason that the Controller can't be generic? Are you building one? How should I feel about having my presentation tier model build on ActionScript? I love 2.0 and it's migration to true object orientation. But I have been in JavaScript hell enough times that I am... cautious about recommending that our presentation tier model and controller logic is build on ActionScript. Please dispel my fears or affirm my hesitancy.
Can I use flex to declare and/or build Central-Specific mechanisms such as Agents? You mentioned that I need to be careful because some Flex components weren't supported by central yet. Is this also true the other way around? Are there things that central requires that can only be done in the Flash tool, or can I build central apps using only Flex as long as I exclude the Flex components that Central doesn't support?
That's a lot of questions. Again, great work. I am looking forward to further developments.
These are really great questions. I've done my best to provide answers below:
> I am quickly becoming a fan, and completely agree with > your focus points on the Flex and Central projects. I am > sure you were frustrated that you could not speak about > Flex and Central during your interview on TheServerSide; > they would have been perfect for that discussion.
Yes, I did feel as if I were doing some evangelist-like handwaving when I would rather have been speaking of engineering specifics. On the other hand, Flex and Central were not quite mature enough to warrant discussion at that time.
> The business tier architecture is pretty > standard stuff, and the integration tier is still being > designed (really I am waiting for a compelling BPEL > implementation).
This is perhaps a quick tangent, but if you are using J2EE it might be that in lieu of BPEL you could build atop the WorkManager and Service Data Objects technologies becoming available in WebLogic and WebSphere. These pieces are a conceptual layer lower than a full BPEL4WS implementation, but they will likely become a Java standard in some form, and are necessary building blocks for BPEL. These specs have recently become a hot topic because IBM and BEA jointly developed them outside the confines of the JCP. Just tossing it out there in case you're operating on WebSphere (which seems to be the platform of choice in most of the financial services companies I've visited) or on WebLogic today.
> I wanted to be sure: can I write custom Flex components > that developers can call with an MXML tag and customize > by setting attributes?
Yes you can. If you have a visual control defined in the class named "SuperTextField," its properties and metadata can be exposed to MXML as attributes:
<SuperTextField prop1="val1" prop2="val2" />
Further, you can bind those properties to a DataModel to enforce a separation between Model and View:
Or you can bind your component's properties to a WebService, remote JavaBean or Java object, or remote XML document. Here's a (probably unnecessarily) more complex example with both a web service binding and a Struts JavaBean binding in the MXML document:
<!-- Here's a SOAP web service --> <mx:WebService id="StockService" wsdl="http://foo/baz?wsdl"> <!-- declare which operations in the WSDL are exposed to this client, and add bindings to parameters if you like --> <mx:operation name="getQuote"> <mx:request> <!-- Binding the input parameter for this operation to a UI component's property --> <symbol>{inputField.selectedSymbol}</symbol> </mx:request> </mx:operation> </mx:WebService>
<!-- Here's a JavaBean that in this example is stateful to this session --> <mx:RemoteObject id="StrutsModelBean" src="fooCompany.model.PortfolioBean"> <mx:method name="getTickerSymbols" /> </mx:Remote>
<!-- UI component that displays a list of stock symbols in the current user's portfolio --> <SuperTextField id="inputField" onLoad="StrutsModelBean.getTickerSymbols()" text="{StrutsModelBean.getTickerSymbols.result}" />
<!-- UI component that displays the most recent quote for the selected stock symbol --> <SuperTextField id="outputField" text="{StockService.getQuote.result}" />
Or for the strictest degree of separation between models, views, and services, you can declare a data model and bind its properties to service parameters and bind UI components to the data model's properties. This last option adds complexity, but the benefit to sophisticated apps is that services, data models, and UI components can be modified more easily as they are very loosely coupled. In simple applications, it may suffice to bind UI component properties directly to JavaBean methods or to a web service operation's inputs and outputs.
In addition to declaratively setting properties and handling data bindings, you can drop script in the document if you like. While it's usually better to keep your MXML clean and keep your code in separate source files, you can write script inline as CDATA enclosed in a <script> tag.
I haven't really mentioned anything particularly flashy about these components, so I'll quickly point out that MXML allows declaratively adding effects to controls. So if I wanted a slight fade-in effect to my text field to draw attention to it when its data content arrives, I might add such an effect like so:
> Can these components be > aggregations of other components?
Yes, you can encapsulate a group of components beneath a new tag, give that tag an id, and then refer to the that tag by its identified name as a new composite component. You can also subclass existing components using script rather than XML if you like, and craft new components that can be referenced in MXML in that manner. Animations work in a similar manner: You can group a set of animated effects, declare whether you want them run in parallel or in sequence, and then refer to the composite effect by its id name.
> And if you have a > library of components with a collection of input fields, > how is page flow and layout handled if you are just > listing the components declaratively in MXML?
The MXML View paradigm is basically this: The developer declares a "container" that is responsible for holding visual "controls." Specific containers enforce specific layout policies. So you may choose a Form container, for example, or a Grid container, and then proceed to nest controls -- images, buttons, data grids, etc, -- beneath the container. It is the container that provides the layout. At the moment we're looking at containers for absolute layout, flow layout, grid layout, text layout, forms layout and the like. In terms of style: You can declare CSS styles encapsulated in a <style> element either in the MXML document or in a separate file and apply them to any of these controls.
> (I requested the beta, but haven't heard back yet).
Thanks for letting me know. This is out of my control so I can't promise anything, but I have sent a note to the folks capable of investigating. I hope you'll get the beta bits, I'd really be interested in your feedback.
> Does Flex have the capability for local storage and > and working offline, or is that strictly Central?
The Flash player provides something called SharedObjects, a small local object store on the client. Flex can use components that target this, and you can craft components that use it in domain-specific ways if you like. At this time, however, there is no declarative control over client-side storage in the MXML syntax. This is something that's really important to us and we want to get it right; but it's not certain that we'll nail it in 1.0, and if we don't then we won't clutter the 1.0 syntax with something sub-par. In other words, declarative control over local storage may not be in Flex 1.0, though you can still programmatically exert control over local storage using ActionScript or through component crafted by those using Flash MX.
> And are agents specific to Central, or is there analogous > technology for Flex?
Agents are specific to Central. Flex is targeting the Flash 7 player, which doesn't include the Agents infrastructure we developed for Central. When we get Flex targeting Central, however, I'd expect to see declarative MXML syntax for managing agents.
> You guys are recommending an ActionScript MVC > MVC framework running in an agent for Central apps. Is > there any reason that the Controller can't be generic? > Are you building one?
On the client side, we're continuing to evolve the data provider mechanism in Central to serve as a default Controller, or Application Mediator, for interaction between view components and remote domain models. I like to refer to this is an Application Mediator because rather than sending Data Transfer Objects from a server-side domain model over to a thin client, in many cases we're talking about distributing the domain model so that it can partially reside on the client, with asynchronous messaging between the tiers for synchronization of the various concerns; this is the right way to achieve rich offline and occasionally-connected behaviors.
On the server side, Flex includes a Front Controller to handle all MXML requests and a web service proxy for managing web service invocations from Flash. It is possible, though, to drop our Front Controller and use MXML directly in JSP through a taglib shim which Flex provides.
> How should I feel about having my > presentation tier model build on ActionScript? I love > 2.0 and it's migration to true object orientation. But I > have been in JavaScript hell enough times that I am... > cautious about recommending that our presentation tier > model and controller logic is build on ActionScript. > Please dispel my fears or affirm my hesitancy. >
Man, do I hear you. It is my belief that AS 2.0 does allow developers to conquer many of the classic problems that occur when dynamically-typed languages are used in complex situations. I think it stands up to the demands of the presentation tier, and offers some advantages -- particularly with regard to the glue code that is often needed in the presentation tier -- over strongly-typed languages. I don't know that I personally would be comfortable with using it to code business processes and transactional service logic, but that's not exactly what we're talking about: we're really focused on the presentation tier. In addition to building the product we have been working with teams building large-scale applications employing Flex, and we're learning whether our assertions are true, and where they may need to be scaled back. My belief is that MXML coupled with ActionScript makes for a clean and simple development model for the presentation tier, and interacts well with services and processes that should still be coded in Java (or C#, etc.).
> Can I use flex to declare and/or build > ild Central-Specific mechanisms such as Agents? You > mentioned that I need to be careful because some Flex > components weren't supported by central yet. Is this also > true the other way around? Are there things that central > requires that can only be done in the Flash tool, or can I > build central apps using only Flex as long as I exclude > the Flex components that Central doesn't support?
In the current Flex beta and Central 1.0 release, targeting Central from Flex is not possible. When using Flex 1.0, you will initially be targeting Flash player 7. When using Central 1.0, you will initially be a Flash designer working in Flash MX. This is largely due to Flex's dependence on Flash Player 7 and Central's foundation on Flash Player 6. While it wouldn't be professional of me to provide details or to suggest a timeframe, I will say we're taking steps to move these products closer together very quickly.
> That's a lot of questions. Again, great work. I am > looking forward to further developments.
Holy moly, I just realized that the forum format really crushed the quick sample code into something barely legible. That'll teach me to rush a response, eh?
When I follow-up next week with a smarter walkthrough I'll try to accomodate the format that these forums use, sorry about that.
"I think the latter requirement, the ubiquitous cross-platform runtime for rich apps, is darn near impossible to find."
Does anybody know of runtime revolution (http://runrev.com), which seems to do exactly this (and has existed for more than 3 years)? You can have easy access to various web protocols, you can even include a browser window within any application (with a plugin to purchase separately). Developers are not bound to the company in any way, they are free to do whatever they want with the compiled application produced with this rapid development environment.
The text below was found on: http://revolution.lexicall.org/wiki/tiki-index.php?page=revolution4Education. I am not linked to the company in any way, I am only a very happy user of this software, which should, in my view really gain to be know. Unfortunately, their company doesn't have the advertising power of macromedia.
Some of you may remember Hypercard, an application program and a simple program development environment produced by Apple Computer. Hypercard was graphical, very flexible and trivially easy to modify. It was often used for rapid application development, with the reputation to let ordinary people create their own software without having to conform to the strict rules of a formal programming language.
The metaphor in use for application development is the one of a 'stack' of cards. A 'stack' is a series of cards presented in a window. Interface elements, from buttons and text fields to graphics, movie objects (linked to QuickTime? movies), image areas (for bitmapped graphics) and more are added by drag-and-drop from a tools palette.
In sharp contrast with web-based documents, it is very easy to bring the application to life. Simple actions can be assigned to any of those elements with Revolution's Transcript language.
On the surface, it may seem that Revolution works much like the easy-to-use interface builder that HyperCard? was. It is very similar. In fact, Revolution can import your old HyperCard? and SuperCard? stacks, so if you're an ex-HyperCard developer, you are free to build on your previous work and port your old stacks and apps to modern Operating Platforms (OSX, Linux, Windows XP).
However, Revolution goes far further than the good-old hypercard stacks. Runtime Revolution's Dreamcard is a software creation tool that lets you make your own software and run it on almost any modern desktop operating system, with each operating system's native look and feel, featuring menus, multiple windows, and drawers (on mac OS). That's a simple statement, but what it means is quite extraordinary. You could even start making shareware applications that not only run in the Mac OS, but also in Windows, IRIX, Solaris, and more. And in case you prefer to impose your own style rather than follow the OS native ones, you are free to create Windows of any size and shape or create widget-like application with a translucent background.
Simultaneously, it provides you with functions that give you formatted display of HTML or RTF content; spreadsheet/table fields; MIDI music file creation and playing; New sound-recording architecture; support for the parsing and creation of XML documents; Unicode text entry and text manipulation; instant access to web protocols like HTTP or FTP, and TCP sockets; almost instant access to SQL databases; calls to the system shell. For instance, reading a web document within revolution doesn't require more than a line of code like get url "google.com".
And all this come into a write-once, run-anywhere format. For a price of under $100, users can distribute their application in a format that requires a player. However this player comes for free and exists for any of the most common Operating Systems (OS9, OSX). For a heavier price tag, you can compile your stack and transform it into a native application that runs on OS X, OS 9 and earlier, Windows, Linux, and several flavors of Unix. All you need is a license that allows you to compile for the appropriate OS. In other word, the potential audience for any of your application can be almost infinitely expanded, literally at the click of a button.
I'm not so much expert in Runtime Revolution (but I'm studying now and I bought a licence). But in the past, I used Asymetrix Toolbook, an incredible tool based on the same RunRev concepts (metacard-like applications).
I think it is a great tool, more oriented to rich client applications than to simply multimedia browser-based systems.
Distributing files is quite easy but, furthermore, you can access to low level functions in the local PC (great functionality if you use it to realize rich-client tools inside a company).
You can use https connections, integrate with multimedia, use the concept of the book (simply wonderful).
I'm an expert Delphi user (and about other 15 programming languages) but I think RunRev is the best tool to create rich-clients, multimedia, multiplatform applications.
Previous Topic
