计算机系-Java-EE-外文翻译-外文文献-英文文献.doc

外文科技资料翻译
英文原文
The Java EE Platform is the leading enterprise web server. The Adobe Flash Platform is the leader in the rich Internet application space. Using both, developers can deliver compelling, data-centric applications that leverage the benefits of an enterprise back-end solution and a great user experience.
In this article, you learn about the architecture of applications built using Flex and Java including:
(1) An overview of the client/server architecture.
(2) The different ways the client and server can communicate.
(3) An introduction to Flash Remoting and why and how you use it.
(4) How to integrate a Flex application with your security framework.
(5) An overview of how to build Flex applications using events, states, MXML components, and modules.
(6) An introduction to developing a Flex application with real-time server data push.
(7) How to boost productivity developing data-intensive applications using the Data Management service in LiveCycle Data Services.
(8) An overview of model driven development using Flash Builder and LiveCycle Data Services to generate client and server-side code.
(9) How to deploy a Flex application on a portal server.
(10) Be sure to also watch the video Introduction to Flex 4 and Java integration.
(11) To learn more about the technologies used to build these applications, read The technologies for building Flex and Java applications article.
Client/server architecture
Flex and Java applications use a multi-tier architecture where the presentation tier is the Flex application, the business or application tier is the Java EE server and code, and the data tier is the database. You can write the back-end code just as you normally would for a Java application, modeling your objects, defining your database, using an object-relational framework such as Hibernate or EJB 3, and writing the business logic to query and manipulate these objects. The business tier must be exposed for access via HTTP from the Flex application and will be used to move the data between the presentation and data tiers.
Typical HTML applications consist of multiple pages and as a user navigates between them, the application data must be passed along so the application itself (the collection of pages and functionality it consists of) can maintain state. In contrast, Flex applications, by nature, are stateful. A Flex application is embedded in a single HTML page that the user does not leave and is rendered by Flash Player. The Flex application can dynamically change views and send and retrieve data asynchronously to the server in the background, updating but never leaving the single application interface (see Figure 1) similar to the functionality provided by the XMLHttpRequest API with JavaScript.)

Figure 1. The client/server architecture.
Client/server communication
Flex applications can communicate with back-end servers using either direct socket connections or more commonly, through HTTP. The Flex framework has three remote procedure call APIs that communicate with a server over HTTP: HTTPService, WebService, and RemoteObject. All three wrap Flash Player's HTTP connectivity, which in turn, uses the browser's HTTP library. Flex applications cannot connect directly to a remote database.
You use HTTPService to make HTTP requests to JSP or XML files, to RESTful web services, or to other server files that return text over HTTP. You specify the endpoint URL, listener functions (the callback functions to be invoked when the HTTPService request returns a successful or unsuccessful response), and a data type for the returned data (what type of data structure it should be translated into once received in the Flex application). You can specify the data to be handled as raw text and assigned to a String variable or converted to XML, E4X, or plain old ActionScript objects. If you get back JSON, you can use the Adobe Flex corelib package of classes to deserialize the JSON objects into ActionScript objects. To make calls to SOAP based web services, you can use the HTTPService API or the more specialized WebService API, which automatically handles the serialization and deserialization of SOAP formatted text to ActionScript data types and vice versa.
The third option for making remote procedure calls is to use the RemoteObject API. It makes a Flash Remoting request to a method of a server-side Java class that returns binary Action Message Format over HTTP. When possible, use Flash Remoting whose binary data transfer format enables applications to load data up to 10 times faster than with the more verbose, text-based formats such as XML, JSON, or SOAP (see Figure 2). To see a comparison of AMF to other text-based serialization technologies, see James Ward's Census RIA Benchmark application.

Figure 2. Methods for connecting Flex and Java.
Flash Remoting
Flash Remoting is a combination of client and server-side functionality that together provides a call-and-response model for accessing server-side objects from Flash Platform applications as if they were local objects. It provides transparent data transfer between ActionScript and server-side data types, handling the serialization into Action Message Format (AMF), deserialization, and data marshaling between the client and the server.
Flash Remoting uses client-side functionality built in to Flash Player and server-side functionality that is built in to some servers (like ColdFusion and Zend) but must be installed on other servers (as BlazeDS or LiveCycle Data Services on Java EE servers, WebORB or FluorineFX on .NET servers, the Zend framework or amfphp on PHP servers, and more). See the technologies for building Flex and Java applications article for more details about BlazeDS and LiveCycle Data Services.
BlazeDS and LiveCycle Data Services use a message-based framework to send data back and forth between the client and server. They provide Remoting, Proxying, and Messaging services, and for LiveCycle an additional Data Management service. The Flex application sends a request to the server and the request is routed to an endpoint on the server. From the endpoint, the request is passed to the MessageBroker, the BlazeDS and LiveCycle Data Services engine that handles all the requests and routes them through a chain of Java objects to the destination, the Java class with the method to invoke (see Figure 3).

Figure 3. Flash Remoting architecture.
AMF
AMF is a binary format used to serialize ActionScript objects and facilitate data exchange between Flash Platform applications and remote services over the Internet. Adobe publishes this protocol; the latest is AMF 3 Specification for ActionScript 3. You can find tables listing the data type mappings when converting from ActionScript to Java and Java to ActionScript here.
For custom or strongly typed objects, public properties (including those defined with get and set methods) are serialized and sent from the Flex application to the server or from the server to the Flex application as properties of a general 0bject. To enable mapping between the corresponding client and server-side objects, you use the same property names in the Java and ActionScript classes and then in the ActionScript class, you use the [RemoteClass] metadata tag to create an ActionScript object that maps directly to the Java object.
Here is an example Employee ActionScript class that maps to a server-side Employee Java DTO located in the services package on the server.
package valueobjects.Employee{ [Bindable] [RemoteClass(alias="services.Employee")] public class Employee { public var id:int; public var firstName:String; public var lastName:String; (...) } }
Installing BlazeDS or LiveCycle Data Services
To use Flash Remoting with BlazeDS or LiveCycle Data Services, you need to install and configure the necessary server-side files. For BlazeDS, you can download it as a WAR file which you deploy as a web application or as a turnkey solution. The turnkey download contains a ready-to-use version of Tomcat in which the the BlazeDS WAR file has already been deployed and configured along with a variety of sample applications. Similarly, for LiveCycle Data Services, the installer lets you choose to install LiveCycle with an integrated Tomcat server or as a LiveCycle Data Services web application.
In either scenario a web application called blazeds or lcds (usually appended by a version number) is created. You can modify and build out this application with your Java code, or more typically, you can copy the JAR files and configuration files the blazeds or lcds web application contains and add them to an existing Java web application on the server (see Figure 4).

Figure 4. The required BlazeDS or LiveCycle Data Services files.
Modifying web.xml
If copying the files to a different web application, you also need to modify the web.xml file to define a session listener for HttpFlexSession and a servlet mapping for MessageBroker, which handles all the requests and passes them off to the correct server-side Java endpoints. You can copy and paste these from the original blazeds or lcds web application web.xml file.
flex.messaging.HttpFlexSession MessageBrokerServlet MessageBrokerServlet flex.messaging.MessageBrokerServlet services.configuration.file /WEB-INF/flex/services-config.xml 1 MessageBrokerServlet /messagebroker/*
Optionally, you may also want to copy and paste (and uncomment) the mapping for RDSDispatchServlet, which is used for RDS (Remote Data Service) access with the data service creation feature in Flash Builder 4 that introspects a server-side service and generates corresponding client-side code. See the model driven development section for more details.
RDSDispatchServlet RDSDispatchServlet flex.rds.server.servlet.FrontEndServlet useAppserverSecurity false 10 RDSDispatchServlet /CFIDE/main/ide.cfm
Reviewing services-config.xml
For Flash Remoting, the client sends a request to the server to be processed and the server returns a response to the client containing the results. You configure these requests by modifying the services-config.xml and remoting-config.xml files located in the /WEB-INF/flex/ folder for the web application.
The services-config.xml file defines different channels that can be used when making a request. Each channel definition specifies the network protocol and the message format to be used for a request and the endpoint to deliver the messages to on the server. The Java-based endpoints unmarshal the messages in a protocol-specific manner and then pass the messages in Java form to the MessageBroker which sends them to the appropriate service destination (you'll see how to define these next).
(...)
Defining destinations
In the remoting-config.xml file, you define the destinations (named mappings to Java classes) to which the MessageBroker passes the messages. You set the source property to the fully qualified class name of a Java POJO with a no argument constructor that is located in a source path, usually achieved by placing it in the web application's /WEBINF/classes/ directory or in a JAR file in the /WEBINF/lib/ directory. You can access EJBs and other objects stored in the Java Naming and Directory Interface (JNDI) by calling methods on a destination that is a service facade class that looks up an object in JNDI and calls its methods.
You can access stateless or stateful Java objects by setting the scope property to application, session, or request (the default). The instantiation and management of the serverside objects referenced is handled by BlazeDS or LiveCycle Data Services.
ault-channels> services.EmployeeService application
You can also specify channels for individual destinations.

Lastly, you use these destinations when defining RemoteObject instances in a Flex application.

Security
In many applications, access to some or all server-side resources must be restricted to certain users. Many Java EE applications use container managed security in which user authentication (validating a user) and user authorization (determining what the user has access to—which is often role based) are performed against the Realm, an existing store of usernames, passwords, and user roles. The Realm is configured on your Java EE server to be a relational database, an LDAP directory server, an XML document, or to use a specific authentication and authorization framework.
To integrate a Flex application with the Java EE security framework so that access to server-side resources is appropriately restricted, you add security information to the BlazeDS or LiveCycle Data Services configuration files (details follow below) and then typically in the Flex application, create a form to obtain login credentials from the user which are passed to the server to be authenticated. The user credentials are then passed to the server automatically with all subsequent requests.
Modifying services-config.xml
In the BlazeDS or LiveCycle Data Services services-config.xml file, you need to specify the "login command" for your application server in the tag. BlazeDS and LiveC