1. Page 1 R MVC Design Pattern Definition Properties Describing MVC design patterns

2. Page 2 R Patterns “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice” – Christopher Alexander (building architect)

3. Page 3 R Object Technology Patterns A pattern is a named description of a problem and solution that can be applied in new contexts. Patterns codify the principles and idioms that guide experienced developers in their creation of software. What is and isn’t a pattern depends on your point of view.

4. Page 4 R Object Technology Patterns 2 Design patterns are not about structures such as vectors that can be encoded in classes and reused as is, nor are they complex domain specific designs. Ideally, patterns should include guidance for how they can be applied in novel situations. Many patterns provide guidance for how responsibilities should be assigned to objects.

5. Page 5 R MVC Model View Controller Increases reusability by partially decoupling data presentation, data representation, and application operations. Enables multiple simultaneous data views.

6. Page 6 R Intent Facilitates maintenance, extensibility, flexibility, and encapsulation by decoupling software layers from one another.

7. Page 7 R Advantages The Model-View-Controller ("MVC") design pattern separates the application data from both the ways the data can be viewed or accessed, and from the mapping between system events (including user interface events) and application behaviors

8. Page 8 R Architecture

9. Page 9 R Applicability Use Model View Controller: – for distributed applications – for larger applications – for applications with a long lifetime – to enhance interface and back-end portability – where identical data must be viewed and manipulated in multiple ways. – to improve maintainability – to support concurrent, modular development with many developers – to facilitate division of labor by skill set – to facilitate unit testing – with enterprise beans that are reusable across applications

10. Page 10 R Model – abstracts application functionality – encapsulates the application state – provides access to application functions – manages persistence, when there is persistence – notifies interested parties when data change

11. Page 11 R View – abstracts data presentation – presents data to the user – maintains consistency with model data

12. Page 12 R Controller – abstracts user interaction/application semantic map – translates user inputs into application actions – select appropriate data displays based on user input and context

13. Page 13 R Collaboration - Model notifies Views when it changes application data can be queried by the View provides application functionality access to the Controller

14. Page 14 R Collaboration – View presents Model data to the user updates display when informed of data changes by the Model forwards user input to the Controller

15. Page 15 R Collaboration - Controller translates user inputs into application actions on the Model selects the View to present based on user input and Model action outcome(s)

16. Page 16 R Consequences Clarifies design by separating data modeling issues from data display and user interaction. Allows the same data to be viewed in multiple ways. Allows the same data to be viewed by multiple users. Improves extensibility by simplifying impact analysis. Improves maintainability by encapsulating application functions behind well-known APIs, and decreasing code replication ("copy-paste-and-hack"). Enhances reusability by decoupling application functionality from presentation. Makes applications easier to distribute, since MVC boundaries are natural distribution interface points. Can be used to partition deployment and enable incremental updates. Facilitates testability by forcing clear designation of responsibilities and functional consistency. Enhances flexibility, because data model, user interaction, and data display can be made "pluggable."

17. Page 17 R Implementation - Issues Since components can't take advantage of knowledge of other components' implementation details, performance must be balanced with the other considerations above. Skillful API design can overcome this pitfall to some extent. MVC may not scale well in distributed systems, if communication volume and latency issues are not carefully addressed. MVC applications can be difficult to maintain if the Model's API is in flux, since the Controller is written in terms of the Model API. Implementing Controller/Model communication as a Command pattern can minimize API drift and provide a hook for Controller extensions to handle new Model functions. Alternately, in many cases it's possible to use an Adapter to provide backward API compatibility.

18. Page 18 R Example 1 – ULM diagram

19. Page 19 R Example 2 - Dynamics

20. Page 20 R The Problem with Servlets From http://www.servlets.com/soapbox/problems-jsp.htmlhttp://www.servlets.com/soapbox/problems-jsp.html HTML content has to be created within code Content creators have to ask developers to make all content changes

21. Page 21 R JSP - Model 1 Architecture

22. Page 22 R Strengths of Model 1 Very easy to implement initially requires "no brainer" knowledge of JSP and Java http://www.brainopolis.com/jsp/mvc/KDuffey_MVC.html;jsessionid=PAKAIKKBNABA

23. Page 23 R Problems with Model 1 Having web designers and developers working on the same file isn't ideal. Java inside HTML proves almost as awkward as having HTML inside Java

24. Page 24 R Model 2 explanation requests are submitted to a servlet "controller" that performs business logic and generates an appropriate data "model" to be displayed This data is then passed internally to a JSP page "view" for rendering The appropriate JSP page can be selected to do the display

25. Page 25 R Model 2 Architecture

26. Page 26 R Advantages of Model 2 takes advantage of the predominant strengths of both technologies, using JSP to generate the presentation layer and servlets to perform process-intensive tasks the more complex your application, the greater the benefits of using the Model 2 architecture should be

28. Page 28 R Tomcat Moving Parts JSP files Completed servlets Static documents HTTP request HTTP response JSP servlets Servlet engine Apache web server Client JSP Engine JSP engine

29. Page 29 R Tomcat and JBOSS = J2EE (X)HTML XML Applet Client application HTTP(S) RDBMS Mail server JDBC JavaMail RMI IIOP eDirectory™ JNDI Message queue JMS Servlets Tag library RMI / IIOP JNDI JTA JDBC JMS Java mail JAF Tomcat web container JSPs RMI / IIOP JNDI JTA JDBC JMS Java mail JAF EJB container Session beans beans Entity beans Java application CORBA server

30. Page 30 R A Tomcat Application Tomcat WebApps examples images JSP servlets Meta-inf Web-inf Web.xml Classes ServletServlet ServletServlet ServletServlet ServletServlet JSPJSP JSPJSP JSP compiler Lib Web application

31. Page 31 R Tomcat in Stand-Alone Mode When a servlet container is stand- alone, it acts as its own web server – It completely bypasses the traditional HTTP server When running in stand-alone mode, special requests are generally forwarded to port 8080 Servlet Container Servlet JVM

32. Page 32 R In-Process Container The in-process container configuration requires the servlet container to be bound to the web server by a plug-in that is responsible for mediating communication between the server and the container The plug-in and the container run in the server’s memory space, as does the JVM that executes the servlet and its container Web server Java plug-in Servlet JVM Servlet

33. Page 33 R Out-of Process Servlet Container This configuration option involves utilization of two memory spaces The first supports the web server and the Java plug-in The other supports the JVM and the servlet container JVM Web server Java plug-in Servlet Servlet Container

34. Page 34 R MVC Architecture Data (Bean properties) Event (request) Display info Data Action URLs Model View Controller Model Beans View JSPs Controller Servlets Event (forward) Event (request) Browser

35. Page 35 R MVC Architecture JSP/servlet beans (controller) Format beans (view) Command beans (model) MVC

36. Page 36 R Command Beans Java bean that encapsulates a single business logic task Provides a stable boundary between the business logic and user interface Allows business logic to evolve without disrupting the rest of the web application Can be serialized and distributed

37. Page 37 R Creating Dynamic Content Using Novell eDirectory™ Using eDirectory beans to dynamically create web content – Authentication – Identity management – Content management Demonstration Sequence

38. Page 38 R JSP Pages and the useBean Tag Demonstration Sequence

39. Page 39 R Authorization Bean Chris Cooper is already a registered member who has specific interests His identity is kept in the directory along with specialized attributes that are extensions of his user object // Call the execute method command bean authBean.execute(); Demonstration Sequence

40. Page 40 R Cooper’s Page after Authentication Passing input parameters to the authorization bean  get name  get password  ou=people, o=aspen

41. Page 41 R CreateBean—New Member Registration Demonstration Sequence Passing parameters to the CreateBean – ObjectClass – Name – E-mail – Password

42. Page 42 R