Figure 7.14 As indicated in the XP processes diagram shown in Figure 7.15, careful consideration should be given to the deployment of a collaboration server during the inception phase of your deployment so that knowl- edge can propagate through the disparate participating groups in your program. Product discoveries that are captured and put on these servers will increase knowledge flows and free personnel from explaining lessons learned to other participants. The idea is to keep everyone involved “clued-in” to all activities so that changes or decision-making at one end of the development spectrum do not go unno- ticed by those on the other end. News Feed Appointment deletion confirmation Delete an Appointment Message insertion confirmation Display message Clickstream DB confirmation Monitor clickstreams Confirm new adds Add new content Spider external sites Confirm Spidering completion Add message Delete message View message thread Add an Appointment Message addition confirmation View Message Thread Portal Administrator Portal 0 Context Diagram Portal User Weather Feed Portal Content Manager Alerts 192 Chapter 7 11 469513 Ch07.qxd 1/16/04 11:08 AM Page 192 Portal development efforts evolve into nasty shouting matches and finger-pointing when CM processes have not been properly deployed and adhered to. Automation of these CM activities is paramount to con- trol the complexities that naturally arise among the different portlet developers of your portal system. Figure 7.15 Design Models for Visualization That Are Not in UML In Scott Ambler’s book Agile Modeling, he provides a practical approach to modeling that enables you to deploy UML artifact-generation best practices on your system. UML does not address two very impor- tant features of enterprise modeling: user interface design and data persistence design. Scott suggests crafting storyboards to visualize your User Interface design to address real estate and navigation con- cerns and to craft Data Flow Diagrams to enhance data content awareness [AMBLER]. The Data Flow Diagram (DFD) in Figure 7.16 illustrates how data flows from external entities through known processes into and out of a portal application. DFDs are great visualization models that portray all of the relevant inputs/outputs, processes, and persistence mechanisms on your system. JAMES Server Testing User Stories (Scenarios) Subject Matter Experts System Metaphor Conceptual Framework Release Planning Spike (Product Discovery) Test Scenarios Release Plan New User Story Bugs Latest Version Customer/Mgmt Approval Small ReleasesNext Iteration Iterations to Release Phase (6-8 weeks) Production Phase Maintenance Phase Iteration Planning Phase CVS Exploration Phase Portal User Backups ANT + FTP BugRat/Scarab/iTracker (bug tracking) ANT + CheckStyle (Peer review) CruiseControl Axis Client JUnit JMeter Collaboration Server UML Artifacts — (optionally) in Visual Paradigm/Poseidon Acceptance Tests UML Artifacts (Whiteboard) & CRC Cards Storyboards 193 Planning for Portal Deployment 11 469513 Ch07.qxd 1/16/04 11:08 AM Page 193 Figure 7.16 View/Add/ Delete/ Modify Message Messages Message info Portal User Message Tree View/Add/ Delete/ Search Appointment Appointment info Portal User Group Appointments Personal Appointments Perform Data Query Inquiry results Portal User Topic Lists Resources Country Lists Annotate Artifact Portal User Annotations Users Resources Site Metadata details URL query Portal Admin User Spider external site Email Server Email results Email inquiry Portal User Email Search Data inquiry Inquiry results Search Portal User Users Profiles Resources Monitor User Preferences Authenticated Users Clickstream References Portal Admin User 194 Chapter 7 11 469513 Ch07.qxd 1/16/04 11:08 AM Page 194 Design Decisions A design decision is generally an architectural or implementation decision that lies outside of the require- ments determined by external shareholders. From an architectural perspective, portal designers need to understand their user communities and their development resources in order to put forth a coherent implementation plan. Often, this understanding can assist portal architects in determining whether a commercial framework is needed for deployment, or a development team can roll their own. Figure 7.17 shows a few design decisions that a portal deployment might consider, along with system requirements that relate to the Requirements section previously described. Remember that the requirements listed are only a subset of possible needs that should be addressed prior to development, but they definitely are rel- evant and deserve consideration. Figure 7.17 Portal Design Decisions Requirements and Scenarios Goals: • Accommodating a disparate user community! • Data dissemination and Self-service • Satisfying your requirements with your design decisions Profiles and Roles Security Requirements Model Data Requirements Configuration Mgmt. Process Quality Assurance Requirements Personalization Standards Functionality Requirements Framework? Architecture Model? Java Standards and Design Patterns? View/Presentation Server-side processing Client-side processing Protocols and Interfaces Patterns Plug-ins Interface Requirements 195 Planning for Portal Deployment 11 469513 Ch07.qxd 1/16/04 11:08 AM Page 195 The following sections describe design decisions that relate to portal architectures. Prior to beginning an expensive portal procurement decision-making process, an understanding of the different portal archi- tectures could be beneficial when evaluating the different portal offerings. Model 1 Architecture A lack of strong enterprise-level development expertise combined with tight scheduling could warrant the Model 1 design. If this is the case, and the program needs to forgo the procurement of a portal frame- work, using Java Server Pages and servlets with a basic Web container could satisfy your needs. Typically, the Model 1 strategy, which is considered “page-centric,” can be deployed with a home page containing embedded pages. With this model, the leftNav.jsp page shown in Figure 7.18 would con- tain an XML-generated taxonomy that would enable users to navigate through Web content. Figure 7.18 content.jsp footer.jsp header.jsp leftNav.jsp 196 Chapter 7 11 469513 Ch07.qxd 1/16/04 11:08 AM Page 196 Many project designers have spent large investments in portal applications because they bought into the hype of the portal vendors, later deciding that their decision was a bad one. With the help of open- source portal frameworks such as JetSpeed (Pluto), LifeRay, eXo, and Jportal, which implement the JSR- 168 specification, developers can build applications without costly expenditures. Additionally, developers can build standardized portlets that can be reused on all of these disparate portal platforms. For enterprise portals, which service a large community of users and provide self-service capabilities along with information dissemination, an implementation should consider a framework model that can handle heavy loads of information and modifications. The procurement of non-standard portal systems should take into consideration the huge development costs that can be incurred for the services of devel- opers who are cognizant of proprietary product extensions on these closed systems. Concern might also be given to understanding how new components can be enabled in their frameworks. The upside to acquiring a ready-made portal framework is that they come with ready-made tables for data persistence and numerous tools that enable easy portlet customization and configuration of portlet visualization preferences. Model 2 Architecture As previously mentioned, the Model 1 architecture is well-suited for simple applications, but most Web applications have navigation and flow control difficulties that necessitate the use of the Model 2 Architecture (M2A), shown in Figure 7.19. With the M2A, which is also referred to as the Model-View- Controller (MVC), multiple views of the same data (model) can be rendered to the user community based on their navigation selections from the view. Most J2EE-compliant portal frameworks implement an MVC solution that uses a servlet controller to render appropriate JSP visualizations. M2A implemen- tations, like Jakarta Struts, can be more cumbersome than Model 1 systems because of labyrinthine parameter-passing through an XML file ( struts-config.xml) used by a controller servlet. This devel- opment complexity can be overcome, however, by time and experience. With M2A implementations, users can control and deploy Web components in an easier fashion than hard-coding dependencies inside the code itself, which presents maintenance problems when things change. Model 2X Architecture The Model 2X Architecture (M2XA), shown in Figure 7.20, demonstrates a slight difference between it and a Model 2 implementation. With M2XA, XML is generated by a servlet or JSPcomponent and is transformed into presentation script prior to being sent to a browser for presentation. These transforma- tions are generally performed by XSL stylesheets. The use of XSL stylesheets enables developers to ren- der different views with the same data. The benefits of M2XA for portal applications are twofold: a single stylesheet can be developed to present a unified view, and a portlet’s look and feel can be made at runtime, just like an application that implements the Decorator pattern. A great reference for the M2XA can be found at www.orbeon.com/model2x/. 197 Planning for Portal Deployment 11 469513 Ch07.qxd 1/16/04 11:08 AM Page 197 Figure 7.19 Option 1 Option 2 Option 3 Servlet (Controller) footer.jsp header.jsp Content 1 Content 2 Content 3 leftNav.jsp Data Layer Model View 1 View 2 View 3 198 Chapter 7 11 469513 Ch07.qxd 1/16/04 11:08 AM Page 198 Figure 7.20 Option 1 Option 2 Option 3 Servlet (Controller) footer.jsp header.jsp Content 1 Content 2 Content 3 leftNav.jsp Data Layer Model View 1 View 2 View 3 Apply XSLT Stylesheet 199 Planning for Portal Deployment 11 469513 Ch07.qxd 1/16/04 11:08 AM Page 199 Search Utilities Every portal deployment needs a reliable search utility to enable users to quickly find data that is reli- able and suits their needs. Some common search engines include Verity, Autonomy, Inktomi, Convera, Google, and the open-source offering called Lucene. Navigating through a portal using taxonomies is fine for some, but it can become tiresome when the amount of content available is overwhelming. When the sheer size of a site’s content can be too much to chew on, and you need to filter out content to get what you need, then a search utility is warranted. Most search engines perform queries against a database, XML, or binary data set generated from an indexing mechanism. Some search engines use robots to survey the Internet so that they can aggregate more content for their databases. Web documents are retrieved and indexed. When you enter a query at a search engine Web site, your input is checked against the search engine’s keyword indices. The best matches are then returned to you as hits. Two of the more prevalent text-searching capabilities involve searches by keyword and concept. A key- word search usually searches the metadata associated with an artifact for the user-specified keyword and returns all documents that are affiliated with it. Some search engines omit text submitted with the search request so that they can search for terms that are deemed more relevant. This operation means that words such as “a” and “the” might be overlooked during the search operation. Furthermore, some engines discriminate between uppercase and lowercase characters in a search string, others do not. A problem with keyword searching is that words that are spelled the same but have different meanings result in ambiguous content returns from your query. A concept search attempts to determine what the query string actually means and tries to obtain content that is statistically related to the string query. In addition to these two types of searches, search engines enable users to refine their queries to target content they need. Some of that refinement includes the capability to search for two or more words and to exclude words that might confuse the engine database. Boolean operators in the form of words or symbols are part of that query refinement. Boolean operators such as AND, OR, and NOT, as well as +, -, enable the search operation to combine and subtract terms from the request. Finally, most search engines return query results based on relevancy ratings. These relevancy ratings are generated by the number of times the keyword appears in that document; the more often it does, the more relevant the artifact is ranked. Keyword counts in documents are not an important distinguishing feature as to the importance, or relevancy, of a document. Sometimes a document may use a common word repeatedly, which could result in that document being irrelevant for your needs. Content Management On many portal applications, comprehensive solutions are needed to deliver content in a controlled fashion through content management applications. Data management encompasses content facilitation through workflow applications known as content management tools that provide management and publishing operations for Web content distribution. The implementation of content management systems typically occurs after a working system has been deployed and the portal implementers understand the content they possess. 200 Chapter 7 11 469513 Ch07.qxd 1/16/04 11:08 AM Page 200 Two open-source products, OpenCMS and Jakarta’s Slide, can be used to control Web content flow in portal deployments. You should examine many of the key features of these content management sys- tems to ensure that your system can deploy Web applications in an efficient manner with these tools. Here is a list of capabilities that you should look for in a content management application: ❑ Content Publishing entails the ability to draw information from a persistence store for publica- tion. This can be a database or an XML-based storage mechanism. ❑ Asset Management means that all types of content, from document-based files to graphical images, can be handled in an efficient manner so that redundancies are avoided. ❑ Workflow Management necessitates the creation of user profiles that delineate user roles and rights to Web artifacts. Once these have been established, users can pull down a document for edit or modification, after which the document can be pushed back into a workflow so that someone else can work on it. When the end of the workflow chain has been reached, the artifact is generally marked for publication. ❑ Versioning enables developers to track changes through a history log. More important, it enables versions to be rolled back when problems are found with deployed distributions, and baseline releases can be constructed and fielded to targeted systems. ❑ Scheduling enables content managers to distribute their content during “off-hour” times so that server implementations are not overloaded and can handle the new content flows in an efficient manner. ❑ Personalization is a tall order for most deployments, because it requires profiles and sophisti- cated rules to be set up so that targeted content can be distributed to user communities in an easy manner. Personalization is generally phased into a content management process because of the complexities involved in building rules and relevant target communities. Content management systems can be beneficial to your portal deployments, because they ensure that document standards propagate properly across your system and that portlet components can be man- aged efficiently in your portal operations. Design Pattern Considerations in Your Portal Clearly, there are many ways to implement a design that cannot be expressed adequately in this chapter alone. Hopefully, the introduction of high-level pattern constructs and brief discussion of the implementa- tion of 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 of quality can be attained in your development activities. This in turn can lead to increased partner adoption and portlet maintenance. Last, the adoption of design patterns should be applied so that best practices are propagated 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 provide high-level concepts of patterns that might be used in your portal deployments and to encourage you to explore them from the online Javaworld newsletter and from the Core J2EE Patterns book [ALUR]. 201 Planning for Portal Deployment 11 469513 Ch07.qxd 1/16/04 11:08 AM Page 201 [...]... of your portal applications that use JavaScript With all portal applications that use JavaScript, make sure you’re aware of your presentations when JavaScript has been disabled 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 source in... during portlet processing in a portal that implements the JSR- 168 Portlet Specification APIs The portlet container processes the action initiated by the portal user first, and then renders the portlet fragments in no specific order to refresh the user display 207 Chapter 7 Portlet Container SAMPLE Portal Finishes before the render requests start render() processAction() Fragment Portlet Container Portlet. .. found at www-1 06. ibm.com/ developerworks/library/ws-wsrp 1 The createPortletInstance operation is called when the portal requests a portlet instance 2 Markup script is procured and embedded in the portlet by calling the getPortletMarkup operation from the WSRP service Stock Portfolio Symbols Price Change Volume MSFT 26. 89 +0.20 63 403704 IBM 83.72 +0.39 8 567 500 ORCL 12.077 -0.013 242852 56 SUNW 4.59 34794800... markup within a portlet If the obtained markup contains links or forms with associated actions, and the user clicks into the portlet on one of these links or forms, the portlet triggers the corresponding action in the WSRP service by calling the performAction operation When the portal doesn’t need the portlet instance anymore because the portlet is removed from a user’s page, it requests to discard the portlet. .. adding portlets through Web services in portals When a user puts a portlet on one of the portal pages, the portal requests the creation of a corresponding portlet instance on the WSRP service’s side, by calling the createPortletInstance operation and obtaining a portlet instance handle that it uses in subsequent requests It can then obtain markup to embed from the WSRP service by calling the getPortletMarkup... developers should refer to Sun’s Java Plug-in reference at: http:/ /java. sun.com/products/plugin/ 208 Planning for Portal Deployment Web Ser vices for Remote Por tals (WSRP) Web Services for Remote Portals (WSRP) is a new technology that will be an important feature of the JSR- 168 Portlet Standard Specification It enables the plug-n-play of visual UI Web services with portals or any other Web applications... separate JavaScript (.js) file When this is done, the JavaScript source can be referenced with the script tag in the following manner: Ser ver-Side Processing According 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 and differences Capabilities Portlets... TopicGenerator .java 001: package portals; 002: /** 003: * @author MM 004: * 005: * To change this generated comment edit the template variable “typecomment”: 0 06: * Window>Preferences >Java> Templates 007: * To enable and disable the creation of type comments go to 008: * Window>Preferences >Java> Code Generation 009: */ 010: import java. net.*; 212 Planning for Portal Deployment 011: 012: 013: 014: 015: 0 16: 017:... facilitate the integration of portlets into a portal system Portlet Integration Plan Hardware: Software: Portlet Overview: Portlet Requirements: Portlet DB Schemas: Portlet Administration: • Describe hardware components here • Describe software components here • Name, Description, Deployment Descriptor and Web Services dependencies • J2EE Components and Web Services (JSP, Servlet, JavaBeans, EJBs, JMS, JMX... how to declare the use of in-line JavaScript code: // Javascript code goes here 222 Effective Client-Side Development Using JavaScript The other method is to create the JavaScript code in a separate file and include the file from the HTML page: . Portfolio Symbols MSFT IBM ORCL SUNW Price 26. 89 83.72 12.077 4.59 Change +0.20 +0.39 -0.013 +0.03 Volume 63 403704 8 567 500 242852 56 34794800 209 Planning for Portal Deployment 11 469 513 Ch07.qxd 1/ 16/ 04 11:08 AM Page 209 Figure 7. 26 Portal. during portlet processing in a portal that implements the JSR- 168 Portlet Specification APIs. The portlet container processes the action initi- ated by the portal user first, and then renders the portlet. Message Thread Portal Administrator Portal 0 Context Diagram Portal User Weather Feed Portal Content Manager Alerts 192 Chapter 7 11 469 513 Ch07.qxd 1/ 16/ 04 11:08 AM Page 192 Portal development