J2EE Web Development

1. J2EE Web Development Karsten Schulz Terp-Nielsen Nordic Solution Manager, FMW Oracle Denmark

2. Agenda • J2EE Web Application Technologies • Motivation to Web Development • Web Development with JSF • Application Developer Framework (ADF) • ADF Faces

3. J2EE Web Application Development Technologies • Java Servlet 2.4 (JSR 154) • JavaServer Pages 2.0 (JSR 245) • JavaServer Pages Standard Tag Library (JSR 52) • JavaServer Faces 1.2 (JSR 252)

4. Motivation to Web DevelopmentModel 1 Architecture • Browser access JSP pages – JSPs access JavaBeans that represent model • Control de-centralized – current page display, determined next page to display • Complex navigation requires use of scriplet code • Blurs the line between presentation and navigation code and making reuse difficult • Not a model to use in practice - maintenance difficult and does not scale well

5. Motivation to Web Development Model 1 Architecture Model 1 Decentralized controller - in each JSP page

6. Motivation to Web Development Model 1 Architecture No MVC - Statically Linked Pages Servlet/JSP Servlet/JSP Servlet/JSP Servlet/JSP Web Server

7. Motivation to Web Development Model-View-Controller ~ Model 2 • Introduces a controller servlet • Controller Servlet handle the data access and navigational flow • JSPs handle presentation • Controller centralizes the logic for dispatching requests to the next view based on the request URL, input parameters, and application state • Controller also handles view selection, which decouples JSP pages and servlets from one another

8. DB Motivation to Web Development Model-View-Controller ~ Model 2 Controller HTTP State Change JavaBean Request Servlet View Selection User Actions JDBC Database HTTP Enterprise Response State Query JavaBean JSP Change Notification View Model

9. Motivation to Web Development Model-View-Controller ~ Model 2 Applying MVC to a Page Flow Web Server Servlet/JSP Controller

10. What is JavaServer Faces? • Standard J2EE Web UI framework • Developed through Java Community Process (JCP) as JSR-127, JSR-252 • Nickname: Faces • Started: May 2001 • First release: March 2004 • Oracle is a primary contributor

11. JavaServer Faces (JSF)Overview – Role of Faces • Focus on components, not markup • Automatic event and state handling • Designed to be leveraged by tools Goal is to simplify J2EE web application development

12. JSTL Custom Tag Libraries JavaServer Faces JavaServer Faces JavaServer Pages Servlet API JavaServer Faces (JSF)Overview - Evolution • JSF is a natural evolution of J2EE Web development Again, too low level… Finally, a comprehensive, standard API for J2EE Web applications! Not standard… Easier but…scriptlets Too low level…

13. HTML render kit WMLrender kit JavaServer Faces (JSF)Overview - JSF Architecture HTML Browser Front Controller Page BackendCode Page Phone/ PDA

14. JavaServer Faces (JSF)Overview - JSF Architecture • Abstracts away from HTTP • Developers don’t need to understand request-response cycle • Abstracts away from HTML • Developers work with components, not markup • Developers don’t need to decode requests

15. JavaServer Faces (JSF)Overview - JSF Architecture A typical JSF application consists of: • JSP pages containing UI Components encapsulated in JSP tag libraries: Core, HTML • A Navigation Model specified in the faces-config.xml • A set of Managed Beans which facilitate the UI logic of the application

16. JavaServer Faces (JSF)Patterns • JSF builds on the following patterns • MVC (Model View Controller) • Observer • Front Controller • JSF addresses both • View : in terms of UIComponents • Controller: in terms of the Front Controller • Model : in terms of Managed Beans – UIComponent model objects – NOT in terms of Business Model objects Focus

17. JavaServer Faces (JSF)Patterns – JSF implementation of MVC

18. JavaServer Faces (JSF)UIComponents JSF UI Components • Basic building blocks of a JSF application • Can represent simple to complex User Interface components ranging from a button or input field to a databound table. • Can be associated to Model data objects through Value Binding • UI Components use helper objects: validators, converters, listeners/events

19. JavaServer Faces (JSF)UIComponents - Examples

20. JavaServer Faces (JSF)UIComponents • Can be associated to Model data objects using an expression language (EL) that is similar to the JSP 2.0 EL (Value Binding) • Instead of using ${...} constructs, the JSF EL prefers the #{...} syntax so that it can be used with both JSP 1.2 and JSP 2.0 • This also allows JSF to evaluate (and reevaluate) the expressions any time is necessary, instead of letting the JSP container control the evaluation of the expressions

21. JavaServer Faces (JSF)UIComponents - Binding UI Components to Model Data UI Components and Value Binding to a Managed Bean <h:InputText value=#{Login.userid} /> <h:InputSecret value=#{Login.password} /> login.jsp Login – A “managed bean” with fields: userid, password

22. JavaServer Faces (JSF)UIComponents - Binding a button to an Action A Command UI Component bound to an “action” <h:commandButton action="#{Login.loginAction}"/> loginAction – A method from the Login managed bean.Returns String: “failure” or “success” or something else login.jsp

23. JSF Architecture Renderer UI Component Expr. Language • UIComponent is rendered through Renderer class • Expression Language Value Binding is used to access managed bean also know as a "backing bean" • Managed bean accesses J2EE persistence layer Managed bean JSF Page J2EE Persistence Layer / JDBC RDBMS

24. JavaServer Faces (JSF)JSF Lifecycle – FacesContext • The FacesContext holds all contextual information necessary for processing a request and generating a reponse • Message Queue • Current Component Tree • Application configuration objects • Life-Cycle flow control methods • External Context (Typical Servlet container environment)

25. JavaServer Faces (JSF)JSF Lifecycle - highlevel • When the user clicks the button, the Web browser sends the form data to the server • The JSF framework convert and validates the form data • The JSF framework returns the form to the user if there are any errors • Otherwise, the valid form data is stored into the properties of the managed bean • And JSF calls the action method that is bound to the clicked button • JSF uses the outcome returned by the action method to determine what page should be displayed next

26. Client / Browser Update Model Values Invoke Application Logic Render Response JavaServer Faces (JSF)JSF Lifecycle – simple version JSF LIFECYCLE Apply Request Values (Re)constitute Component Tree Process Events, Validators

27. JavaServer Faces (JSF)JSF Lifecycle – more detailed version

28. JavaServer Faces (JSF)JSF Lifecycle – Restore View Phase • Register Event Listeners • Register Validators • Get/Set Appropriate RenderKit • Get/Set Locale ViewRoot Label UIForm Submit UIInput UIGraphics UIOutput UICommand FacesContext

29. JavaServer Faces (JSF)JSF Lifecycle – Apply Request Values Phase Update Component Tree with request values by issuing processDecodes() Registered Converters are called here Eventual errors are queued in the message queue of Faces Context During the process of updating Component values, Events may be queued either by UIComponents or associated Renders ViewRoot UIForm UIInput UIGraphics UIOutput UICommand After updating the component tree eventually queued events will be processed if designated for this phase FacesContext Any errors, call to renderResponse() -> Render Response Phase Event Queue Msg Queue

30. JavaServer Faces (JSF)JSF Lifecycle – Process Validations Phase Make sure the Component Tree validates itself by issuing processValidates() Associated Validators are called here Eventual errors are queued in the message queue of Faces Context During the process of validating Component values, Events may be queued either by validators, UIComponents or associated Renders ViewRoot UIForm UIInput UIGraphics UIOutput UICommand After validating the component tree eventually queued events will be processed if designated for this phase FacesContext Any errors, call to renderResponse() -> Render Response Phase Event Queue Msg Queue

31. JavaServer Faces (JSF)JSF Lifecycle – Update Model Values Phase Make sure the Component Tree updates itself with the backing model by issuing processUpdates() Eventual errors are queued in the message queue of Faces Context During the process of validating Component values, Events may be queued either by UIComponents or associated Renders ViewRoot UIForm UIInput UIGraphics UIOutput UICommand After updating the component Backing model eventually queued events will be processed if designated for this phase FacesContext Any errors, call to renderResponse() -> Render Response Phase Event Queue Msg Queue

32. JavaServer Faces (JSF)JSF Lifecycle – Invoke Application Phase Make sure to process any ActionEvents that have been previously queued processApplication() All ActionEvents are processed here exception for those who have been marked immediate=”true” They are processed in the end of the Apply Request Values phase as we don’t want to have validations etc. executed ViewRoot UIForm UIInput UIGraphics UIOutput UICommand The default ActionListener passes the string returned from the action method to the JSF Default NavigationHandler which sets the ViewRoot according to Navigation rule FacesContext Event Queue Msg Queue ViewRoot

33. JavaServer Faces (JSF)JSF Lifecycle – Render Response Phase Render the Component Tree by issuing encode() Registered Converters are called here to encode the type as a string ViewRoot UIForm UIInput UIGraphics UIOutput UICommand FacesContext The state of the current Component Tree Is saved wither i request or in session Event Queue Msg Queue ViewRoot

34. Demonstration Develop a simple login Web Application based on JSF • Layout pageflow • Define command action method for login button • Define back button on failure page

35. Oracle ADFMotivation – Challenges building J2EE apps • Building J2EE applications can be complex. • Development time can be extensive. • Choosing and implementing appropriate design patterns can be overwhelming. • “Do it yourself” applications often repeat existing application code. • A large portion of “do it yourself” code is dedicated to common tasks. • The more code you write, the greater the chance of errors. • An application framework is needed.

36. Oracle ADFIntroduction • Reduces the complexity of J2EE development by providing visual and declarative development • Increases development productivity • Less coding, more reuse • Focus on the application, not the “plumbing” • Provides a flexible and extensible environment by allowing multiple technology choices and development styles • Encourages J2EE best practices by implementing standard J2EE design patterns

37. Rich Clients Web and Wireless Clients Controller Model Business Services Oracle ADFEnd-to-end J2EE Framework • Implements standard J2EE best practices • Model-View-Controller (MVC) design pattern • Focus on the application, not the “plumbing” • Consolidation and evolution of previous frameworks

38. Oracle ADFVisual and Declarative Development • End-to-end Application Development • J2EE & Services • Visual • WYSIWYG editors • UML modelers • Structure pane • Declarative • Structure pane • Property inspector • Code View/Design View Synchronization • No separate generation step - always synchronized • Underlying code always accessible

39. Oracle ADFJ2EE Architecture (Simplified) EnterpriseJavaBeans ADF Business Components Web Services Java Objects Clients Business Services Database

40. Oracle ADFNo Standard API for Client Binding EnterpriseJavaBeans ADF Business Components ? JDBC Web Services Java Objects Clients Business Services Database

41. Oracle ADFADF Model • Data Controls • Data Binding • JSR-227: “A Standard Data Binding & Data Access Facility for J2EE” BusinessComponent Web Service TopLink Model EJB JavaClass

42. Oracle ADFADF Model Architecture • Data control: describes the values and actions defined by the business service • Bindings: define how UI components use the values and actions in the data model Client Bindings Data Control Business Service

43. Oracle ADFADF Model Architecture • Decouples client and business service layers • Client code contains no references to the business service • Better design practice • Code is more maintainable • Architecture can be extended to add more types of business services

44. Flexible Deployment ADF Business Components Simplifies and optimizes O/R mapping Simplifies and optimizes binding of View to logic Deployed either as a Local Model or as a remote Session Facade

45. XML ADF BC High-level architecture HTML, Java, and XML Interfaces Task-BasedApp Service Data Presentation& Manipulation BusinessLogic Application View Entity PaymentPlan Mgmt SlowPayingCustomers Customer Bill LatePayments Payment

46. Entity Objects View Objects TopCustomers Customer Customer Ord PendingOrders Database Order Application Module ADF BC Application

47. Start with database tables DEPT EMP

48. DEPT EMP Entity objects encapsulate business rules, logic, defaults in a consistent way for a table Department Employee

49. DEPT EMP View objects encapsulate SQL queries to project, join, filter, order data for external client interaction Department ForeignDepts Employee Retiring Emps

50. DEPT EMP Application module defines data model of view object usages for a complete application use case Department ForeignDepts ForeignPensionsApp Employee Master RetiringEmps Detail