Along with SOA,BPM the other buzz word with regards to J2EE Application development in Java community now-a-days is about Rich Internet Applications-RIA.
Personally I do think strategically this is the most important aspect that needs to be covered or looked into by a seasoned Java/J2EE Architect ,that how best he can improve the usability and appearance of the corporate applications he is working on, because ultimately what matters to the users is better,scalable and enhanced GUI.Along with Web Services(SOA),Mobile Computing,BPM(Business Process Management),this is one area where Iam really focussed and I suggest every Senior Java/J2EE guys to consider having a look at.To start with,I guess every Java person ,who is interested in GUI development does try to acquaint himself with technologies with HTML,DHTML,CSS,JavaScript,Java AWT,Swing ,XHTML etc....And there is ever growing interest in building AJAX style web applications using different frameworks and technologies which I will harbor upon in this article down the line.So what is this RIA is all about?
To start with the basic definition of RIA is ,Rich Internet applications (RIA) are web applications that have the features and functionality of traditional desktop applications. RIAs typically transfer the processing necessary for the user interface to the web client but keep the bulk of the data (i.e., maintaining the state of the program, the data etc) back on the application server.
RIAs typically:
* run in a web browser, or do not require software installation
* run locally in a secure environment called a sandbox
Compared to RIAs,traditional web applications centered all activity around a client-server architecture with a thin client. Under this system all processing is done on the server, and the client is only used to display static (in this case HTML) content. The biggest drawback with this system is that all interaction with the application must pass through the server, which requires data to be sent to the server, the server to respond, and the page to be reloaded on the client with the response. By using a client side technology which can execute instructions on the client's computer, RIAs can circumvent this slow and synchronous loop for many user interactions.
All RIAs share one characteristic: they introduce an intermediate layer of code, often called a client engine, between the user and the server. This client engine is usually downloaded at the beginning of the application, and may be supplemented by further code downloads as the application progresses. The client engine acts as an extension of the browser, and usually takes over responsibility for rendering the application's user interface and for server communication.
Benefits
Because RIAs employ a client engine to interact with the user, they are:
* Richer. They can offer user-interface behaviors not obtainable using only the HTML widgets available to standard browser-based Web applications. This richer functionality may include anything that can be implemented in the technology being used on the client side, including drag and drop, using a slider to change data, calculations performed only by the client and which do not need to be sent back to the server, for example, a mortgage calculator.
* More responsive. The interface behaviors are typically much more responsive than those of a standard Web browser that must always interact with a remote server.
The most sophisticated examples of RIAs exhibit a look and feel approaching that of a desktop environment. Using a client engine can also produce other performance benefits:
* Client/Server balance. The demand for client and server computing resources is better balanced, so that the Web server need not be the workhorse that it is with a traditional Web application. This frees server resources, allowing the same server hardware to handle more client sessions concurrently.
* Asynchronous communication. The client engine can interact with the server without waiting for the user to perform an interface action such as clicking on a button or link. This allows the user to view and interact with the page asynchronously from the client engine's communication with the server. This option allows RIA designers to move data between the client and the server without making the user wait. Perhaps the most common application of this is prefetching, in which an application anticipates a future need for certain data, and downloads it to the client before the user requests it, thereby speeding up a subsequent response. Google Maps uses this technique to move adjacent map segments to the client before the user scrolls their view.
* Network efficiency. The network traffic may also be significantly reduced because an application-specific client engine can be more intelligent than a standard Web browser when deciding what data needs to be exchanged with servers. This can speed up individual requests or responses because less data is being transferred for each interaction, and overall network load is reduced. However, use of asynchronous prefetching techniques can neutralize or even reverse this potential benefit. Because the code cannot anticipate exactly what every user will do next, it is common for such techniques to download extra data, not all of which is actually needed, to many or all clients.
Shortcomings and restrictions
Shortcomings and restrictions associated with RIAs are:
* Sandbox. Because RIAs run within a sandbox, they have restricted access to system resources. If assumptions about access to resources are incorrect, RIAs may fail to operate correctly.
* Disabled scripting. JavaScript or another scripting language is often required. If the user has disabled active scripting in their browser, the RIA may not function properly, if at all.
* Client processing speed. To achieve platform independence, some RIAs use client-side scripts written in interpreted languages such as JavaScript, with a consequential loss of performance. This is not an issue with compiled client languages such as Java, where performance is comparable to that of traditional compiled languages, or with Flash movies, in which the bulk of the operations are performed by the native code of the Flash player.
* Script download time. Although it does not have to be installed, the additional client-side intelligence (or client engine) of RIA applications needs to be delivered by the server to the client. While much of this is usually automatically cached it needs to be transferred at least once. Depending on the size and type of delivery, script download time may be unpleasantly long. RIA developers can lessen the impact of this delay by compressing the scripts, and by staging their delivery over multiple pages of an application.
* Loss of integrity. If the application-base is X/HTML, conflicts arise between the goal of an application (which naturally wants to be in control of its presentation and behaviour) and the goals of X/HTML (which naturally wants to give away control). The DOM interface for X/HTML makes it possible to create RIAs, but by doing so makes it impossible to guarantee correct function. Because an RIA client can modify the RIA's basic structure and override presentation and behaviour, it can cause failure of the application to work properly on the client side. Eventually, this problem could be solved by new client-side mechanisms that granted an RIA client more limited permission to modify only those resources within the scope of its application. (Standard software running natively does not have this problem because by definition a program automatically possesses all rights to all its allocated resources).
* Loss of visibility to search engines. Search engines may not be able to index the text content of the application.
* Dependence on an Internet connection. While the ideal network-enabled replacement for a desktop application would allow users to be "occasionally connected" wandering in and out of hot-spots or from office to office, today the typical RIA requires network connectivity.And I think this year will decide whether RIA are here to stay or it goes off like smoke without fire.
Ok enough of talking about RIA,its benefits and shortcomings.Lets talk about what we are really concerned about, which framework or technology is the best for RIA,I think that should be the primary focus now rather than considering the potential or growth of RIA.There are many choices for us and they are:Adobe Flex/Flash,Ajax,JSF(yes it can also be used),JavaFX,Dojo,Swing,Google Web Toolkit,Google Gears,Eclipse RIA & Microsoft Silverlight.I guess with so many choices,the obvious question will be which one is the most efficient and best one for RIA.
Personally I do like Adobe Flex,The Flex SDK comes with a set of user interface components including buttons, list boxes, trees, data grids, several text controls, and various layout containers. Charts and graphs are available as an add-on. Other features like web services, drag and drop, modal dialogs, animation effects, application states, form validation, and other interactions round out the application framework.I do go through its documentation like Flex 2 Developers Guide,Building & Deploying Flex 2 applications,I must say this tool is here to stay.
There are, however, more specific and compelling reasons to adopt Flex. Flex builds on the advances made in the Java/J2EE community over the last decade. New Java converts to the Flex programming model will find the framework, language, and tools easy to learn, as there is a familiarity in the Flex IDE and the language structures, like the Flex Collections API. The Flex development tools offer the clearest link for current Java developers. The Flex IDE is built on Eclipse, which can be used as the stand-alone Flex Builder product or as an Eclipse plug-in. Virtually all Java developers have had some exposure to the Eclipse development environment. This is a huge benefit that speeds and enhances the learning process.
In addition to the IDE, Flex also has Ant Tasks for automated builds of Flex applications, whether they are integrated with a Java application or stand-alone. Once again, Ant is a technology Java developers have all been exposed to in the Java community. With Adobe's comprehensive suite of tools, integrating Flex into your skill set is natural and enjoyable.
In a multi-tiered model, Flex applications serve as the presentation tier. Unlike page-based HTML applications, Flex applications provide a stateful client where significant changes to the view don't require loading a new page. Similarly, Flex and Flash Player provide many useful ways to send and load data to and from server-side components without requiring the client to reload the view. Though this functionality offered advantages over HTML and JavaScript development in the past, the increased support for XMLHttpRequest in major browsers has made asynchronous data loading a common practice in HTML-based development too.
There are frameworks ranging from testing to MVC in Adobe Flex. A good example of this is the Cairngorm MVC framework. Cairngorm is written in ActionScript 3.0 and follows many of the Core J2EE patterns. It provides Flex developers with an MVC framework for structuring their Flex presentation code and the interactions with the business services. Flex also provides API's for multiple methods of integrating with backend services, including LiveCycle Data Services ES (Data Services), Web Services, and HTTP.
LiveCycle Data Services ES deploys in a Servlet/J2EE container and provides significant server-side infrastructure to Flex applications. Data Services offers a number of features, including remoting, publish/subscribe messaging, and data management (client-server synchronization, paging, notification, Hibernate adapter, etc). The simplest use allows a Java developer to expose Plain Old Java Objects (POJO's) as back-end services via a simple configuration. Objects are transferred to the client in a compact binary format called AMF3 and converted to ActionScript 3.0 classes, which is far more efficient in the transferring and rendering time than other implementations, like XML. Combining Data Services with the popular Java POJO-based frameworks, like Hibernate and Spring, creates a truly powerful combination for building enterprise applications.
Things you need to get started with Adobe Flex
Flex Builder 2
Flex Builder 2 is the new development tool that (although it is not necessary for Flex development because any text editor can be used) offers the most complete development environment for rapidly creating Flex applications. Because Flex Builder 2 has been built on top of the mature Eclipse IDE, it will be very familiar to developers who have already been developing software in other languages using Eclipse as their tool of choice. Eclipse is a development environment that was built with extendability in mind, and this can also work to the benefit of Flex developers because it can be customized to suit the needs of the Flex developer. Chapter 2 provides a more comprehensive look into Flex Builder 2.
Flex Free SDK 2
The Flex Software Development Kit (SDK) is a free download from Adobe and includes the Flex framework (component class library), compiler, and debugger. Using the text editor of your choice, you can create the ActionScript and MXML files for your application, and then compile to SWF using the SDK. The SDK allows for data communication via Web services, HTTP services, and Flash remoting with ColdFusion as the back-end server.
Flex Data Services (FDS)
FDS is the server version of Flex that must be installed under any Java 2 Enterprise Edition (J2EE) server. FDS is essentially the next generation of Flex 1.5, which was sold only as a server.
As well as a full commercial edition, the FDS server is available in an Express edition, which is free and available for commercial use (but is limited to one CPU without clustering).
FDS is made up of several components and capabilities, including the following:
Flex Messaging Services (FMS)
Publish-subscribe messaging
Data push
RPC services
Flex Messaging Services
FMS is one of the pieces that make up FDS, and it allows for the creation of applications that support real-time messaging, as well as collaboration. The messaging service has support for Java Message Service (JMS), as well as other existing messaging services, allowing for the creation of cross-platform chat applications.
Publish-Subscribe Messaging
FMS uses the producer/consumer publish-subscribe metaphor, which allows for the creation of co-browsing applications. To understand what is meant by a co-browser application, imagine a company’s customer service representative being able to make edits to a form on the user’s screen in real time while the user watches.
Data Push
Data push is the capability for the server to push data changes to the client without any user interaction or polling of the servers. This can be critical when an application has hundreds or thousands of users connected, and they can all see changes to business-critical data in real time. This is a feature that is available only when using the FDS server.
RPC Services
Remote procedure call (RPC) services are the suite of services used to connect to external data. They include the following:
WebService - The WebService component can be used to access any Web service that complies with the WSDL 1.1 standard and returns data formatted as Simple Object Access Protocol (SOAP) messages over HTTP.
HTTPService - The HTTPService component can send HTTP GET, POST, HEAD, OPTIONS, PUT, TRACE, or DELETE requests. It does not support multipart requests.
RemoteObjects - The RemoteObject component uses Action Message Format (AMF) to transfer data that is a binary format and is the fastest of the RPC services. It is an ideal way to interact with server-side Java objects that are within the FDS server’s source path. It can also be used to connect to local or even remote ColdFusion servers. Both Java objects and ColdFusion components can be mapped to ActionScript objects, allowing for seamless integration between the server-side and client-side objects.
The WebService and HTTPService components are included for free with the Flex SDK, whereas the RemoteObject component is available only for use with the FDS server (Commercial or Free Express Edition) or ColdFusion 7.02.
Flex Charting
The Flex charting components are a set of rich charting components that enable easy development of professional dashboard and business intelligence (BI) systems. The charting components are sold as a stand-alone product or bundled with Flex Builder 2
Flex 2 Programming Model
The Flex 2 Programming Model consists of MXML, ActionScript, and the Flex class library. To build a full-fledged application, you must have a good knowledge of all these technologies. To start off, you are introduced to the basics of MXML. Then you are shown how ActionScript and MXML work together to create powerful, rich user interfaces.
The third element of the programming model is the Flex 2 Framework, which contains Flex components, managers, and behaviors. This component-based development model allows developers to incorporate pre-built components, extend the component library by creating new components, or combine pre-built components to create composite components.
MXML
The first element of the programming model, MXML, is an XML language that defines the user interface for an application. MXML is also used to define non-visual aspects such as server-side data sources and bindings between the user interface and the server side.
To write a Flex application, you must be able to write MXML and ActionScript. As mentioned earlier, MXML is an XML language that is used to lay out your user interface.
MXML is very similar to HTML in that it provides tags for user interface elements. If you have worked with HTML, then MXML should be very familiar to you. MXML has a much broader tag set than HTML, and defines visual components such as data grids, buttons, combo boxes, trees, tab navigators, and menus, as well as non-visual components, Web service connections, data binding, and effects.
The biggest difference between HTML and MXML is the MXML-defined file that is compiled into a Shockwave file (SWF) and rendered by the Flash Player. MXML can be written in a single file or in multiple files. MXML requires that you close off every tag that you declare in your Flex application. Otherwise, the Flex compiler will throw an error.
The
ActionScript
The second element of the programming model, ActionScript, extends the functionality of a Flex application. ActionScript provides control and object-manipulation features that are not available in strict MXML.
The ActionScript programming language is used in Adobe’s Flash Player. Included are built-in objects and functions that allow you to create your own objects and functions like many object-oriented programming (OOP) languages.
ActionScript 3.0 offers a robust programming model that is more familiar to developers with basic knowledge of OOP. ActionScript is executed by the ActionScript Virtual Machine (AVM), which is part of the Flash Player. The code is compiled into a bytecode format by the compiler, such as the one built into Flex Builder 2.
ActionScript and JavaScript are very similar, so being familiar with JavaScript will make your life easier when using ActionScript. JavaScript is derived from The European Computers Manufacturers Association (ECMA) document ECMA-262, which is the international standard for the JavaScript language. ActionScript is based upon the ECMA-262 Edition 4 specification, so this is where the similarities come in between the two languages.
ActionScript 3.0 contains a lot of new features, such as run-time exceptions, run-time types, sealed classes, method closures, ECMAScript for XML (E4X), regular expressions, namespaces, and new primitive types. All these new features allow the developer to speed up the development process.
One important point to note is that Flex Builder 2 converts all MXML files into ActionScript before the code is compiled into bytecode for use with the AVM.
ActionScript in MXML
Flex developers will find that ActionScript extends the capabilities of Flex when developing applications. In ActionScript, you can define event listeners, create new classes, handle callback functions, and define getters and setters, packages, and components.
Following are some of the ways that ActionScript can be used in Flex applications:
ActionScript is inserted between the
Create new components in ActionScript.
Create new components and compile into SWC files (which are external components compiled to be reused in many applications).
Extend existing components with ActionScript classes.
Take advantage of ActionScript support for OOP concepts such as code reuse, inheritance, encapsulation, and polymorphism.
Use global ActionScript functions that are available in any part of an SWF file where ActionScript is used, or in any user-defined class.
Use the standard Flex components that comprise the Flex Class Libraries. All the components and libraries are written in ActionScript.
Overview of ActionScript Compilation Process
A Flex application can consist of MXML files, ActionScript classes, SWF files, and SWC files.
The Flex compiler transforms the main MXML file and its children into a single ActionScript class linking in all the reference-imported classes. Once the transformation is complete, the end result is a single SWF file that can be deployed on the server.
Every time you make changes to your application, a new SWF file is generated. You may find it more convenient to remove the reusable components and compile those into SWC files, which can be included in a library path for your application.
Statements and expressions must be wrapped in functions; otherwise, you will receive a compiler error. Also, you cannot define classes or interfaces in the
You may have noticed the odd CDATA construct. This is used to tell the compiler not to interpret the script block as XML, but rather as ActionScript. The
In MXML, you can use ActionScript to refer to visual or non-visual components. You do this by specifying the id property of the component in MXML. Then you use id to refer to the component in ActionScript.
If you want to access the
var str:String = lbl1.text;
The code gets the value from the Label control named lbl1.
Import and Include
There is a noticeable difference between the terms “importing” and “including” in reference to ActionScript. Importing is adding a reference to a class file or package so that you can access the objects and properties of the external classes, as shown in the following example:
import mx.controls.TextInput;
Including ActionScript is copying the lines of code of an external ActionScript file into another. This can either be done in the
Introduction to ActionScript Components
This section provides a brief overview of how to create reusable components using ActionScript. Later in this book, you will build more complex components using MXML and ActionScript.
Custom components can contain graphical elements, define some kind of business logic, or extend existing components in the Flex framework. Defining your own components in ActionScript has several advantages:
Divide your application into individual models that can be developed and maintained separately.
Implement commonly used logic within the components.
Build a collection of components that can be reused among all your Flex applications.
When creating custom components, you may find it useful to extend the component from the Flex class hierarchy. This allows you to inherit functionality already built into the Flex components.
As shown in the following example, you can define a custom TextInput and derive it from the Flex TextInput control:
package myComponents
{
public class MyTextInput extends TextInput
{
public function MyTextInput()
{
...
}
...
}
}
The filename of the control MyTextInput must be in a filename called MyTextInput.as and stored at the root of your Flex application in a subdirectory name myComponents. As you may have already picked up, the package name reflects the location of the component, myComponents.
Flex Class Library
The Flex 2 Framework contains Flex managers, components, and behaviors. The component-based model allows developers to incorporate pre-built components, create new ones, or combine components into composite components.
The following lists some of the common packages that you will use in your Flex application:
mx.controls - Flex user interface controls
mx.collections - Flex collection components
mx.charts - Flex charting components
mx.utils - Flex utility classes
flash.events - Flex event classes
flash.net - Flex classes for sending and receiving from the network, such as URL downloading and Flash Remoting
Just have a look at the Adobe Developer Connection,http://www.adobe.com/devnet/ria/ and you will surely agree that it is the most useful tool and for samples visit here,http://www.adobe.com/devnet/flex/index.html?tab:samples=1
Tuesday, January 15, 2008
Rich Internet Applications - One more Buzz word (Adobe Flex)
digg
reddit
del.icio.us
Subscribe to:
Post Comments (Atom)
0 comments:
Post a Comment