计算机系 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 communicationflex 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 players http connectivity, which in turn, uses the browsers 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 wards 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.amfamf 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 servicesto 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.xmlif 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.xmlfor 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 (youll see how to define these next). (.) defining destinationsin 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 applications /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 server-side objects referenced is handled by blazeds or livecycle data services. 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 towhich 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.xmlin 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 livecycle data services supply the following login commands: tomcatlogincommand (for both tomcat and jboss), jrunlogincommand, weblogiclogincommand, webspherelogincommand, oraclelogincommand. these are all defined in the xml file and you just need to uncomment the appropriate one. you also need to define a security constraint that you specify to use either basic or custom authentication and if desired, one or more roles. to do custom authentication with tomat or jboss, you also need to add some extra classes to the web application for integrating with the security framework used by the jave ee application server and modify a couple of configuration files. mode details can be found here. false custom employees managers . modifying remoting-config.xmlnext, in your destination definition, you need to reference the security constraint: services.employeeservice you can also define default security constraints for all destinations and/or restrict access to only specific methods that can use different security constraints.the default channel, my-amf, uses http. you can change one or more of the destinations to use the my-secure-amf channel that uses https: . where my-secure-amf is defined in the services-config.xml file: adding code to the flex applicationthat covers the server-side setup. now, if you are using custom authentication, you need to create a form in the flex application to retrieve a username and password from the user and then pass these credentials to the server by calling the channelset.login() method and then listening for its result and fault events. a result event indicates that the login (the authentication) occurred successfully, and a fault event indicates the login failed. the credentials are applied to all services connected over the same channelset. for basic authentication, you dont have to add anything to your flex application. the browser opens a login dialog box when the application first attempts to connect to a destination. your application can now make flash remoting requests to server destinations just as before, but now the user credentials are automatically sent with every request (for both custom and basic authentication). if the destination or methods of the destination have authorization roles specified which are not met by the logged in user, the call will return a