外文翻译-----使用开放源码工具的专业便携式开发

Professional Portal Development with Open Source ToolsDesign Pattern Considerations in Your PortalClearly, there are many ways to implement a design that cannot be expressed adequately in this chapteralone. Hopefully, the introduction of high-level pattern constructs and brief discussion of the implementationof Java standards in this chapter can facilitate your design decisions on your portal deployments.Java language and implementation standards can also help control complexity so that consistent levels ofquality can be attained in your development activities. This in turn can lead to increased partner adoptionand portlet maintenance. Last, the adoption of design patterns should be applied so that best practices arepropagated in your portal deployment and development operations can be hastened.Much has been written during the last few years about design patterns and their use in Java development,so rather than go into great elaboration of their use, we felt that it would be more beneficial to providehigh-level concepts of patterns that might be used in your portal deployments and to encourage you toexplore them from the online Javaworld newsletter and from the Core J2EE Patterns book [ALUR].Planning for Portal DeploymentUsing Java StandardsFor many mission-critical development portal efforts, decisions need to be made about expensive softwareprocurements to satisfy your development needs. In order to protect this investment, it is wise toconsider standards when you make your purchasing decision because there is nothing worse thandumping a lot of money into a particular framework only to learn after you have obtained it that it is aclosed, proprietary system that does not work well with other systems. To guarantee that this does nothappen to you, you should become familiar with software standards and other application frameworks’use of them. Regrettably, systems that do rely heavily on proprietary extensions often force your projectto hire expensive expertise to help you deploy your program with their framework.Figure 7.21 illustrates some of the Java standards that could be considered for portal development. It isimportant to remember that these need to be established prior to procuring a portal framework or integratingexisting applications into a homegrown portal application. Always be cognizant of the latest versionsof the standards listed in Figure 7.21, and the effects that newer versions of those standards mighthave on your design decisions.Figure 7.21Figure 7.22 illustrates some of the portal standards that should be considered before building your portalapplication.On many portal implementations, a business case for adherence to language standards that relate toindividual portlets needs to be made so that proprietary extensions are not adopted by a program thatdisallows code reuse and promotes vendor lock-in. Being exposed to proprietary data formats, oneinevitably gets increasingly locked into the solutions of a particular vendor, which in turn limits theoptions for application software. This ultimately enables vendors to dictate enhancement prices andintroduces unnecessary risks to your systemFigure 7.22Model-View-Controller (MVC) PatternIn the portal architecture shown in Figure 7.23, theMVC Patternis where the servlet controller rendersdifferent views to the portal façade from a disparate set of data sources.Themodelis the piece that has no specific knowledge of its controllers or its views. The portal systemmaintains relations between the different models and views and broadcasts content to the views whenthe model changes state. The viewis typically the piece that manages the visualizations of the modeldata. Thecontrolleris the piece that manages user interaction with the model data.The MVC Pattern is used with many frameworks because of its ability to handle content delivery complexitiesthat are prominent in many enterprise systems. Jakarta’s Struts and BEA’s WebFlow are twonotable implementations that use this in their frameworks.Template Method PatternA good practice when developing JavaBeans in your portal applications is to use the Template MethodPattern [GoF] to enforce a common design across the portal back-end. The Template Method Pattern canbe used so that modifications to your get and/or set methods will not affect your presentation view.In the portal display in Figure 7.23, the JavaBean applications on the back-end implement the TemplateMethod Pattern to manage the logic in the accessor (get/set) methods.Memento PatternIn the sample portal visualization shown in Figure 7.23, the view labeled #4 indicates that a form will berendered to the user display. In many cases, the form will use JavaScript to perform validation testing sothat activities will be performed on the client side in order to alleviate unnecessary operations on theserver. This is a good practice for some Web applications, especially portals that perform heavy serveroperations, but sometimes incompatibilities in browsers allow inconsistent behaviors to occur.TheMemento Pattern [GoF] will persist the state of the form entries so that submits retain that data inthe form text fields, and can perform server-side validation operations on that data.Facade PatternThe Façade Pattern[GoF] is used in the portal application shown in Figure 7-23 to facilitate tediousoperations that are associated with a database connection. Some of the operations that would warrantthe use of a façade include the following: database connection handling, driver setups, and SQL statementconstruction.Adapter PatternThe Adapter Pattern[GoF] could be applied in the aforementioned portal application as a means torewrite legacy code implementations to share data from the back-end data stores. By wrapping existingcode with an object adapter, the application can support existing interfaces by adapting the interface ofthe parent class.The Adapter Pattern provides a mechanism to convert one interface into another. This is necessary when anewer interface has superceded an older one. Instead of recoding the implementation of the older interface,that implementation can be wrapped by an adapter that implements the newer interface. Calls to the newinterface methods are then translated into calls to the older interface methods. This enables the legacy codeto be extended to allow for more functionality, without having to rewrite existing code.Factory Method PatternThe Factory Method Pattern [GoF] can be used to instantiate objects, such as a factory, by abstracting thecreation and initialization of these objects from the user. This enables the client to focus on the applicationwithout being concerned with the object creation details. In our sample portal display, it can be usedto generate a taxonomy object (from an XML file) that will generate queries as the user traverses thenavigation tree.Singleton PatternThe Singleton Pattern[GoF] ensures that only one instance of a class is created, and provides a singlepoint of access to an object. In the portal example shown in Figure 7-23 a Singleton can be used to open adatabase connection or to generate a navigation tree from an XML file.Front Controller PatternThe Front Controller Pattern[ALUR] is part of the J2EE Presentation Tier Patterns library. The FrontController Pattern is similar to the MVC Pattern, and is actually used within the context of it, but it differsin that no model, or data access component, is associated with it. Referring to our sample portalshown in Figure 7-23, a Servlet controller is used to render different JSP views to the portal display.Note the following important features of the Front Controller Pattern: It allows for the handling ofrequests in a centralized location, which facilitates maintenance, and can perform authorization checkswithout having to spread unnecessary logic across multiple applications.Intercepting Filter PatternThe Intercepting Filter Pattern [ALUR] is another J2EE Presentation Tier Pattern thatwas introducedwith the Servlet 2.3 specification. This Pattern allows for the pre-processing and post-processing of userrequests, as well as the capability to alter response headers and data when processing requests.In the portal display, the Intercepting Filter Pattern can be used to swap presentation views within aportlet, meaning that the data sent back from the back-end database can be processed to render data inXML format so that an XSL stylesheet can be applied to the data to present a different user view.Client-Side ProcessingClient-side processing refers to the application processing done at the browser. All browsers have beenenabled to interpret scripting instructions that would usually be sent to the server. This activity reducesthe load on the server’s back-end.Sadly, many challenges are present in browsers because of inconsistencies in their adherence to scriptingstandards. One of the most troublesome problems with browsers is inconsistencies with their implementationsof the Document Object Model (DOM). The DOM standard is used to access elements and attributesof a Web document. These inconsistencies force developers to increase their development efforts to supportdifferent browserincompatibilities. To work around this issue, some portal efforts perform more serversideprocessing, which places a great load on the back-end. Other workaround measures involve allowingonly limited amounts of client-side processing, and the application of best practices obtained through otherdevelopment endeavors.JavaScriptDifferent Web browsers, and different versions of the same Web browser, will often treat the similarJavaScript documents slightly differently. This browser incompatibility becomes a more salient issuethe more your portal application applies it in its client-side processing. The trick to is to establish aJavaScript standard, and apply it across all of your portal applications that use JavaScript. With al l portalapplications that use JavaScript, make sure you’re aware of your presentations when JavaScript has beendisabled in your browser.Always remember to propagate your proven scripting practices across your portal development efforts.One best practice to apply across your JavaScripting effort in your portal is to put your JavaScript sourcein a separate JavaScript (.js) file. When this is done, the JavaScript source can be referenced with thescript tag in the following manner: <scriptsrc=””>.Server-Side ProcessingAccording to the JSR-168 Portlet Specification, portlets share many of the same attributes as servlet components.The following table compares the two Web components to highlight their commonalities anddifferences.Figure 7.24 describes the request-handling operations that occur during portlet processing in a portalthat implements the JSR-168 Portlet Specification APIs. The portlet container processes the action initiatedby the portal user first, and then renders the portlet fragments in no specific order to refresh theuser display.Figure 7.24Java Plug-insJava Plug-ins enable Web applications to supplant a browser’s default virtual machine so that more upto-date JVMs can be applied to that application. The Java Plug-in, which requires a one-time download,enables applications to be consistent in their operations by overriding browser inconsistencies.The first time a Web browser encounters a Web page that specifies the use of the Java Plug-in, the browsermust download and install the required files for proper operation. On most portals’ applications, a linkshould be provided to show users where a plug-in can be obtained to run their application. After the Java.Plug-in has been downloaded, subsequent invocations of Web pages that are reliant on the plug-in willretrieve it from the local hard drive when an applet component is rendered.The implementation of applets and Java Plug-ins in your portal deployments typically needs stakeholder“buy-in” prior to acceptance. This consideration needs to be addressed because of bandwidthand firewall issues that might prevent users from downloading theplug-in to access portlets that usethem. To gain better clarity on the implementation of the Java Plug-in on your portal implementationwith two of the most common browsers, Netscape and Internet Explorer, developers should refer toSun’s Java Plug-in reference at:/products/plugin/.Web Services for Remote Portals (WSRP)Web Services for Remote Portals (WSRP) is a new technology that will be an important feature oftheJSR-168 Portlet Standard Specification. It enables the plug-n-play of visual UI Web services with portalsor any other Web applications. WSRP services will allow content providers to expose content or applicationsin a non-intrusive manner that does not requireapplication-specific adaptation by consumingapplications.The intention of WSRP is to facilitate the integration of Web applications through a standard set ofWeb service interfaces. A simple sequence of steps (shown in Figure 7.25) is performed when addingportlets through Web services in portals. When a user puts a portlet on one of the portal pages, the portalrequests the creation of a corresponding portlet instance on the WSRP service’s side, by calling the createPortletInstanceoperation and obtaining a portlet instance handle that it uses in subsequentrequests. It can then obtain markup to embed from the WSRP service by calling the getPortletMarkupoperation and displaying that markup within a portlet. If the obtained markup contains links or formswith associated actions, and the user clicks into the portlet on one of these links or forms, the portlet triggersthe corresponding action in the WSRP service by calling the performActionoperation. Whentheportal doesn’t need the portlet i nstance anymore because the portlet is removed from a user’s page, itrequests to discard the portlet instance on the WSRP service’s side by calling the destroyInstanceoperation. A good reference on WSRP implementation can be found at /developerworks/library/ws-wsrp.Figure 7.25使用开放源码工具的专业便携式开发门户的模式设计与思考显然，有许多方法来完成这个设计，在这一章不能全部表述出来。