Download
building enterprise web applications with spring 3 0 and spring 3 0 mvc n.
Skip this Video
Loading SlideShow in 5 Seconds..
Building Enterprise Web Applications with Spring 3.0 and Spring 3.0 MVC PowerPoint Presentation
Download Presentation
Building Enterprise Web Applications with Spring 3.0 and Spring 3.0 MVC

Building Enterprise Web Applications with Spring 3.0 and Spring 3.0 MVC

239 Views Download Presentation
Download Presentation

Building Enterprise Web Applications with Spring 3.0 and Spring 3.0 MVC

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Building Enterprise Web Applications with Spring 3.0 and Spring 3.0 MVC JavaOne 2010 By AbdelmonaimRemani abdelmonaim.remani@gmail.com

  2. License • Creative Commons Attribution-NonCommercial 3.0 Unported • http://creativecommons.org/licenses/by-nc/3.0/

  3. Who Am I? • Software Engineer at Overstock.com • Particularly interested in technology evangelism and enterprise software development and architecture • President and Founder of a number of organizations • The Chico Java User Group • The Chico Flex User Group, • The Chico Google Technology User Group. • LinkedIn • http://www.linkedin.com/in/polymathiccoder • Twitter • http://twitter.com/polymathiccoder

  4. Warning This presentation is very long and covers a lot of material

  5. Introduction

  6. Enterprise Application Software (EAS) • Complex • In terms of requirements • Functional • Non-Functional • Execution • Performance • Reliability • Security • Evolution • Testability • Maintainability • Extendibility • Scalability (Horizontal and Vertical)

  7. Enterprise Application Software (EAS) • In the words of Edsger W. Dijkstra: • […] The Separation of Concerns […] is yet the only available technique for effective ordering of one’s thoughts […] • Artificially Reducing complexity by means of Abstraction • Specific Choices of abstraction • Produces a architectures

  8. Modern Enterprise Application • The Architecture • Layered / N-Tiered • Presentation Layer • Web Layer • Service Layer • Persistence Layer • Aspects • Middleware • Other

  9. Frameworks • A Framework is an architecture • A well-defined structure to solve a problem • A pre-existing hierarchy to be extended • Library • Framework vs. Library • Invoking vs. being invoked • Generic vs. specific • Tools • Compiler, debugger, etc… • Scaffolding and other utilities • Etc…

  10. Frameworks • Heavyweight vs. Lightweight • The need for a platform or a stack (JEE as example) • The ability to load in-demand necessary components • The memory footprint • The build size • Deployment ease • Etc…

  11. The Spring Framework

  12. What is Spring? • Application Framework • Java • Other implementations are available (Spring .NET) • Open-Source • Lightweight • Non-Invasive (POJO Based) • Extendible • A platform with well-defined extension points for other frameworks • By Rod Johnson • Expert One-on-One J2EE Design and Development, 2002 • J2EE without EJB, 2004 • Became the De facto standard of Java Enterprise Applications

  13. Spring Source: Spring 3.0.x Framework Reference http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/htmlsingle/spring-framework-reference.html 20 Modules

  14. Libraries • Wrappers for most popular frameworks • Allowing injection of dependencies into standard implementation • Struts • JSF • Apache Tapestry • Etc… • Full Integration with the JEE stack

  15. The Address Book

  16. The Address Book • The Address Book from polymathic-coder.com • A web application for Contact management

  17. Functional RequirementsUse Case 1 - Contact Management • Details: • As a user I should be able to view, add, delete, and edit personal contacts data on my address book including: • First Name • Last Name • Email • Phone Number • Image • Primary Actors: Regular user / Administrator • Assumptions: • The user is authenticated and has proper privileges to access the Contact Management Area • Access is granted both through the web interface and a RESTful API

  18. Functional RequirementsUse Case 1 - Contact Management • Business Rules • A First Names are required • Phone Numbers must be valid US phone numbers • Emails must be valid

  19. Functional RequirementsUse Case 2 - User Management • Details: • As an administrator I should be able to view, add, delete, and edit the user data including: • Username • Password • Role (Regular or Administrator) • Whether the account is enabled or not • Email • Primary Actors: Administrator • Assumptions: • The user is authenticated and has proper privileges to access the User Administration Area • Access is granted through the web interface

  20. Functional RequirementsUse Case 2 - User Management • Business Rules • Username is required and must be unique • Passwords must be complex (The should contains at least 1 lowercase letter, 1 uppercase letter, 1 digit, and 1 special character) • Emails must be valid • An email must be sent to the newly created user

  21. Functional RequirementsUse Case 3 - Reporting • Details: • As an administrator I should be able to view audit and health check reports • Primary Actors: Administrator • Assumptions: • The user is authenticated and has proper privileges to access the Reporting Area • Access is granted through the web interface • The reports are periodically generated by the system

  22. Non-Functional Requirements Security • RBAC (Role-based access control) • Authentication • Form-based • Http Basic • Authorization • Security Roles • Regular User • Access to personal contact management area • Administrators • Access to personal contact management area • Access to user administration area • Access to reporting area • Access Control • No Rules • Transport Security • Not required

  23. Spring Core

  24. Inversion of Control • The problem: • Acquiring Resources via • Instantiation of a concrete class • Using a static method of a singleton factory • Using a Directory Services API that allows for discovery and lookup (JNDI for example) • Etc.. • Creates hard dependencies • Coupled code is hard to reuse (DRYness) • Painful Unit Testing

  25. Inversion of Control • The Solution: • Coding against Interfaces • Inversion of Control: Dependency Injection • Reflectively supply external dependency at runtime • The Hollywood principle: “Don’t call us, we’ll call you” • Wait a minute this a lot of work! • Spring to the rescue

  26. Spring Core Source: Spring 3.0.x Framework Reference http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/htmlsingle/spring-framework-reference.html • Container  • POJO • Configuration Metadata • XML-Based • Annotation-Based • Java-based

  27. JSR 330 – Dependency Injection for Java Spring Annotations @Autowire @Qualifier JSR 330 • @Inject • @Named • JSR 250 -  Common Annotations • javax.annotation • JSR 299 – Contexts and Dependency Injection • Scopes and contexts: javax.context • Dependency injection service: javax.inject • Framework integration SPI: javax.inject.manager • Event notification service: javax.event

  28. Stereotypical Spring • Used to mark a class that fulfills a role or a stereotype • Stereotyped classes can be automatically detected • Spring Stereotypes • @Component • @Repository • @Service • @Controller

  29. Domain Model

  30. Domain Model

  31. Domain Model • A modelof the “concepts” involved in the system and their relationships • Anemic Domain Model • POJOs (Plain Old Java Objects) or VOs (Value Objects) • Clear separation between logic and data • Parallel object hierarchies are evil • Metadata is interpreted depending on the context as the object moves across the layers of the application • Object-Relational mapping to persistent entities • Validation • Marshaling / Un-marshaling • Etc…

  32. JSR 303 - Bean Validation Source: Hibernate Validator Reference Guide 4.1.0.Final http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_single/ Ensuring the correctness of data based on a set predefined rules

  33. JSR 303 - Bean Validation Source: Hibernate Validator Reference Guide 4.1.0.Final http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_single/ javax.validation Reference Implementation: Hibernate Validator

  34. Domain Model • Instantiation (Items 1 & 2 of Josh Bloch’s Effective Java) • Static Factories • Telescoping • Provide builders • Override the default implementations of hashCode(), toString(), and equals(Object) methods • Use Pojomatic at http://pojomatic.sourceforge.net/ • Be aware of any circular dependency in your model • Versioning • @Version of JSR 317 – JPA 2.0

  35. Persistence Layer

  36. Persistence Layer • A logical encapsulation of classes and interfaces whose responsibilities fall within the scope of: • Create, Read, Update, and Delete (CRUD) operations on persistence storage mechanisms such as file systems and Database Management Systems (DBMS) • Interacting with Message-Oriented Middleware (MOM) infrastructures or Message Transfer Agents (MTA) such as JMS or mail servers

  37. JSR 317 – JPA 2.0 • javax.persistence • Reference Implementation EclipseLink • Primer • A persistence entity is a POJO whose state is persisted to a table in a relational database according to predefined ORM metadata • An entity is managed by an Entity Manager • Do we still need a Persistence Layer? • Highlights • Support for JSR 303 validation

  38. Spring Data Access / Integration • Beans Stereotyped with @Repository • Enables exception translation to a consistent exception hierarchy • Run-time exceptions and do not have to be declared or caught • Use JPA annotations to inject EntityManager and EntityManagerFactory • @PersistenceContext • @PersistenceUnit • Follow a convention (I suggest CRUD) • Declaring transaction semantics • @Transactional

  39. Spring Data Access / Integration • Java Mail API • javax.mail • Spring Helpers for various Templating Engines • Velocity • FreeMarker

  40. Persistence Layer • Testing • JUnit • Take advantage of what JUnit 4.7 has to offer (Explore Theories, Rules, Etc…) • Libraries • DbUnithttp://www.dbunit.org/ • Dumpster http://quintanasoft.com/dumbster/ • Consider HADES http://redmine.synyx.org/projects/show/hades

  41. Service Layer

  42. Service Layer • A logical encapsulation of classes and interfaces that provide the system functionality consolidating Units of work. Service layer classes should be: • Transactional • Stateless • Beans Stereotyped with @Service • Follow a convention (I suggest VADER)

  43. Web Layer

  44. Web Layer • A logical encapsulation of classes and interfaces whose responsibilities fall within the scope of: • Navigational logic • Rendering page views in the proper order • As simple as mapping a single URL to a single page • As complex as a full work flow engine • Web concerns (Request variables, session variables, HTTP methods, HTTP response codes, Etc…) should be separated from business logic

  45. Web Layer • Two types of Web Frameworks • Request / Response Web Frameworks • Wrap the Servlet API • Adopt push model • Compile result • Push it out to be rendered in a view • Struts, Spring MVC, Etc… • Component Web Frameworks • Dot only hide the Servlet API • Event-driven component • JSF, Tapestry, Etc…

  46. Spring MVC

  47. Spring MVC • Request / Response Web Frameworks • A Front Controller Pattern • One Dispatcher servlet • Application Contexts • Application Context • Web Application Context

  48. Spring MVC - Controllers • The promise Non-invasiveness • Fully annotation-driven • No extension of framework classes • No overriding methods • Controllers • Beans (Spring Managed-POJOs) Stereotyped with @Controller

  49. Spring MVC - Controllers • Mapping Rules • @RequestMapping • By • Path • HTTP method • Query Parameters • Request Headers

  50. Spring MVC - Controllers • Handler Methods • Parameters are request inputs • Request data • @RequestParam • @PathVariable • @RequestHeader • @CookieValue • Command Objects (Domain Objects) • Injection of standard objects • Automatic Type Conversion • Custom Type Conversion • JSR 303 Support • @Valid • Exposing reference data to the views • @ModelAttribute