b7938bd47aed456860f5f40d90afd997.ppt
- Количество слайдов: 50
The Spring Framework Rod Johnson Interface 21 TM
Spring framework goals • • • Make J 2 EE easier to use Address end-to-end requirements rather than one tier Eliminate need for middle tier “glue” Provide the best Inversion of Control solution Provide a pure Java AOP implementation, focused on solving common problems in J 2 EE • Fully portable across application servers – Core container can run in any environment, not only a server – Works well in Web. Sphere
…Spring framework goals • “Non-invasive” framework – Application code has minimal or no dependency on Spring APIs – Key principal seen throughout Spring’s design – More power to the POJO • Facilitate unit testing – Allow effective TDD – Allow business objects to be unit tested outside the container • Facilitate OO best practice – We’re used to implementing “EJB” or “J 2 EE” applications rather than OO applications. – It doesn’t have to be this way. • Provide a good alternative to EJB for many applications • Enhance productivity compared to “traditional” J 2 EE approaches
Part of a new wave of frameworks • Big change in how J 2 EE applications are written • Less emphasis on EJB – EJB has been overused: Often not appropriate • Not just Spring: Pico. Container, Hive. Mind and other Inversion of Control frameworks – EJB 3. 0 (2005) programming model looks a lot like (Spring Io. C – features) + Hibernate – EJB still has some unique capabilities for a minority of apps (distributed transaction management, RMI remoting) • These lightweight frameworks are different • Spring is the most mature, most powerful and most popular
Unique Spring capabilities • Declarative transaction management for POJOs with or without EJB • Consistent approach to data access, with common exception hierarchy – Simplifies working with JDBC, Hibernate, JDO etc • • Flexible MVC framework Io. C/AOP integration Integration with a wide variety of popular products Gestalt – More than the sum of its parts – Hard to explain in a snappy phrase, but our users love it • Solid, robust, works now • In production in mission-critical apps now
Spring focus • Spring complements application servers like Web. Sphere – Spring comes out of the application space, rather than the server space • Spring avoids the need for costly in-house frameworks – – Can produce real savings Focus your developers on your domain Well-understood, generic, high-quality solution Facilitates testability, increase productivity • Provides a simpler, yet powerful, alternative to the EJB component model in many applications – But also plays well with EJB if you prefer to stick with EJB
A layered framework • Web MVC • AOP framework – Integrates with Io. C • Io. C container – Dependency Injection • Transaction management • Data access • One stop shop but can also use as modules
Web MVC • Most similar in design to Struts – Single shared Controller instance handles a particular request type • Controllers, interceptors run in the Io. C container – Important distinguishing feature – Spring eats its own dog food
Web MVC: Advantages over Struts • Allows multiple Dispatcher. Servlets – More elegant than even Struts 1. 1 solution – Dispatcher. Servlets can share an “application context” • More flexible – Interface not class-based • Easier to customize • Less tied to JSP – Velocity, Excel, PDF etc – Easy to implement custom Views
Web MVC: Advantages over Struts • Cleaner MVC separation – Cleanly separates controller, model and view – Model is not tied to Servlet API or Spring API • No need for custom Action. Forms: can reuse domain objects or TOs • Much easier to unit test web tier, because Spring uses interfaces, not classes • Integrates with middle tier with zero custom coding – No more Service Locators or ad hoc Singletons
Web tier integration But I love Web. Work/Tapestry/Struts/JSF/whatever • The customer is always right • We don’t dictate how to use Spring – You can preserve your investment (tools etc) – You can refactor to use what parts of Spring you need • Web. Work, Tapestry, Struts integration is seamless • Support for JSF and Portlet development in Spring 1. 1 (August) – JSF leaders (Ed Burns, David Geary) are working with us on Spring/JSF integration
Spring in the Middle Tier • Complete solution for managing business objects – – Write your business objects as POJOs Spring handles wiring and lookup Simple, consistent, XML format (commonest choice) But the Io. C container is not tied to XML • Application code has few dependencies on the container —often no dependencies on the container – Spring Pet Store has no dependencies on Spring Io. C – No magic annotations for Io. C: nothing Spring-specific • Easy unit testing. TDD works!
Spring in the Middle Tier • The most complete Io. C container – Setter Dependency Injection • Configuration via Java. Bean properties – Constructor Dependency Injection • Configuration via constructor arguments • Pioneered by Pico. Container – Dependency Lookup • Avalon/EJB-style callbacks – I favour Setter Injection, but the Spring philosophy is that you make the choice • We are not ideological. • A good Io. C container must provide sophisticated support for both injection models to allow use of legacy code
Middle Tier: Setter Injection public class Service. Impl implements Service { private int timeout; private Account. Dao account. Dao; public void set. Timeout(int timeout) { this. timeout = timeout; } public void set. Account. Dao(Account. Dao account. Dao) { this. account. Dao = account. Dao; } // Business methods from Service …
Middle Tier: Constructor Injection public class Service. Impl implements Service { private int timeout; private Account. Dao account. Dao; public Service. Impl (int timeout, Account. Dao account. Dao) { this. timeout = timeout; this. account. Dao = account. Dao; } // Business methods from Service
Middle Tier: Dependency Injection • Simple or object properties – Configuration (timeout) – Dependencies on collaborators (account. Dao) • • Configuration properties are also important Can run many existing classes unchanged “Autowiring” Trivial to test application classes outside the container, without Spring • Can reuse application classes outside the container • Hot swapping, instance pooling (with AOP)
Spring in the Middle Tier • Advanced Io. C features – Can manage lists, maps or sets, with arbitrary nesting – Leverages standard Java. Beans Property. Editor machinery • Register custom property editors – “Post processors”
Why AOP? • AOP complements Io. C to deliver a non-invasive framework • Externalizes crosscutting concerns from application code – Concerns that cut across the structure of an object model – AOP offers a different way of thinking about program structure to an object hierarchy • EJB interception is conceptually similar, but not extensible and imposes too many constraints on components • Spring provides important out-of-the box aspects – Declarative transaction management for any POJO – Pooling – Resource acquisition/release
AOP + Io. C: A unique synergy • AOP + Io. C is a match made in heaven • Any object obtained from a Spring Io. C container can be transparently advised based on configuration • Advisors, pointcuts and advices can themselves be managed by the Io. C container • Spring is an integrated, consistent solution
Custom AOP • Complements, rather then conflicts with, OOP – Email administrator if a particular exception is thrown – Apply custom declarative security checks – Performance monitoring – Auditing – Caching
Aspect. J integration • Coming in Spring 1. 1 (August) • Particularly relevant to Web. Sphere users given IBM’s backing for Aspect. J • Integrates Aspect. J aspects into Spring Io. C – Configure and parameterize aspects in a consistent way • Will allow the use of the Aspect. J pointcut expression language to target Spring advice • Can mix Spring and Aspect. J aspects within a consistent architectural model
Spring DAO • Integrated with Spring transaction management – Unique synergy – Gestalt again… • Doesn’t reinvent the wheel. – There are good solutions for O/R mapping, we make them easier to use • Out-of-the-box support for – – JDBC Hibernate JDO i. BATIS • Model allows support for other technologies (Top. Link etc) • Consistent Data. Access. Exception hierarchy allows truly technology-agnostic DAOs
Spring DAO: Consistent exception hierarchy
Spring DAO: JDBC • Class library offers simpler programming model than raw JDBC – Two flavours of usage: • Callbacks (Jdbc. Template) • JDBC objects: Model queries, updates and stored procedures as objects • • No more try/catch/finally blocks No more leaked connections – Spring will always close a connection: no scope for programmer error • Meaningful exception hierarchy – No more vendor code lookups • Spring autodetects database and knows what Oracle, DB 2 error codes mean • More portable code – More readable code • catch (Bad. Sql. Grammar. Exception ex) • • Stored procedure support Can refactor to clean up JDBC without adopting Spring overall – Incremental adoption: Step by step
Spring DAO: Hibernate • Manages Hibernate sessions – – No more custom Thread. Local sessions Sessions are managed within Spring transaction management Works with JTA if desired Works within EJB container with CMT if desired • Hibernate. Template makes common operations easy – Simpler, consistent exception handling – Many operations become one-liners – Less, simpler, code compared to using Hibernate alone • Portability: Switch between Hibernate, JDO and other transparent persistence technologies without changing DAO interfaces – Can even switch to JDBC where transparent update is not implied • Mixed use of Hibernate and JDBC within the same transaction
Hibernate. Template DAO example public class My. Hibernate. Dao implements My. Dao { private Hibernate. Template hibernate. Template; public My. Hibernate. Dao (net. sf. hibernate. Session. Factory session. Factory) { hibernate. Template = new Hibernate. Template(session. Factory); } public Collection get. Workflows() { return hibernate. Template. find("from Workflow"); }
Spring DAO: JDO • Comparable to Hibernate support • Mixed use of JDO and JDBC within the same transaction • Will support JDO 2. 0 features (detach) and vendor extensions in a portable manner – All major vendors support similar concepts
Spring Transaction • Consistent abstraction – Platform. Transaction. Manager – Does not reinvent transaction manager – Choose between JTA, JDBC, Hibernate, JDO etc with simple changes to configuration not Java code – No more rewriting application to scale up from JDBC or Hibernate local transactions to JTA global transactions – Use the simplest transaction infrastructure that can possibly work • Programmatic transaction management – Simpler API than JTA – Use the same API for JTA, JDBC, Hibernate etc. – Write once have transaction management everywhere. TM
Declarative Transaction Management • Most popular transaction management option • Built on same abstraction as programmatic transaction management • Declarative transaction management for any POJO, without EJB: even without JTA (single database) • More flexible than EJB CMT – Declarative rollback rules: roll back on My. Checked. Exception – Non-invasive: Minimizes dependence on the container • No more passing around EJBContext
Make Service. Impl POJO transactional public class Service. Impl implements Service { private int timeout; private Account. Dao account. Dao; public void set. Timeout(int timeout) { this. timeout = timeout; } public void set. Account. Dao(Account. Dao account. Dao) { this. account. Dao = account. Dao; } public void do. Something() throws Service. Withdrawn. Exception { } }
" src="https://present5.com/presentation/b7938bd47aed456860f5f40d90afd997/image-31.jpg" alt="Make Service. Impl transactional
Make Service. Impl transactional • Rollback rule means that we don’t need to call set. Rollback. Only() – Of course Spring also supports programmatic rollback • Can run this from a JUnit test case – Doesn’t depend on a heavyweight container • Can work with JTA, JDBC, Hibernate, JDO, i. BATIS transactions… – Just change definition of transaction manager
Make Service. Impl transactional • Alternative approaches, simpler in large applications: – Use “auto proxy creator” to apply similar transaction attributes to multiple beans – Use metadata or another pointcut approach to apply transactional behaviour to multiple classes
Spring J 2 EE • No more JNDI lookups – Jndi. Object. Factory. Bean – Generic proxy for Data. Sources etc. • No more EJB API dependencies, even in code calling EJBs – – EJB proxies No more home. create() No more Service Locators or Business Delegates Codeless EJB access • Callers depend on Business Methods interface, not EJB API • Exposed via Dependency Injection (naturally) • Maximize code reuse by minimizing J 2 EE API dependencies • Spring does not prevent you using the full power of J 2 EE – Full power of Web. Sphere lies under the covers – Spring makes it easier to use effectively
Spring OOP • No more Singletons – An antipattern as commonly used • Program to interfaces, not classes • Facilitates use of the Strategy pattern – Makes good OO practice much easier to achieve • Io. C Dependency Injection keeps the container from messing up your object model – Base object granularity on OO concerns, not Spring concerns • Combine with transparent persistence to achieve a true domain model
Spring Productivity • • • Less code to develop in house Focus on your domain Reduced testing effort Try it and you won’t look back “Old” J 2 EE has a poor productivity record – Need to simplify the programming model, not rely on tools to hide the complexity
“Old” J 2 EE vs Spring • Write a SLSB – – – Home interface Component interface “Business methods” interface Bean implementation class Complex XML configuration POJO delegate behind it if you want to test outside the container – Much of this is working around EJB – If you want parameterization it gets even more complex • Need custom code, Io. C container or “environment variables” (ouch) • Implement a Spring object – Business interface – Implementation class – Straightforward XML configuration – The first two steps are necessary in Java anyway – Oops, I really meant “implement a Java object, ” not “implement a Spring object” – If you want to manage simple properties or object dependencies, it’s easy
“Old” J 2 EE vs Spring • Use your SLSB • Use your Spring object – Write a Service Locator and/or Business Delegate: need JNDI code – Each class that uses the service needs to depend on EJB interface (home. create) or you need a Business Delegate with substantial code duplication – Just write the class that uses it in plain old Java – Express a dependency of the business interface type using Java (setter or constructor) – Simple, intuitive XML configuration – Hard to test outside a container – No lookup code – Easily test with mock object
Productivity dividend • Spring removes unnecessary code • You end with no Java plumbing code and relatively simple XML – If your Spring XML is complex, you’re probably doing things you couldn’t do the old way without extensive custom coding • The old way you have lots of Java plumbing code and lots of XML – A lot of the XML is not standard • Combine with Hibernate or JDO for transparent persistence and the advantage is huge
Quotes: Plenty of choice from Spring users… • I use the Spring Framework daily and I've simply been blown away by how much easier it makes development of new software components • Spring lets me port my business logic across those environments [application server, Swing client] with ease. That's why I love Spring.
Quotes: Plenty of choice from Spring users… • Lightweight containers make a lot of sense. Spring’s ability to decouple layers within an applications is very addictive. • You will wonder how you ever developed anything in Hibernate without spring, it just makes it so much easier. You gotta love Hibernate. Template. You gotta love the session management. • The proof of concept went up to 150 requests per second! Man, you guys did a hell of job with the whole thing. Spring MVC overhead is *minimal* and it took only 15 hours to implement it, thanks for the dependency injection!
Quotes • I'm a new user of spring and I have to say, it's great. It's really speeding up our development time • One of the great things for me about the Spring Framework is that it makes using some of those "old" technologies easier to bear … the org. springframework. ejb. support package is nice to use to reduce the amount of duplicate code around EJBs • Spring now has the momentum to dominate the J 2 EE framework space – OO guru and consultant Craig Larman
The Spring community • www. springframework. org • 15 developers – Around 6 “core” developers – Significant number of contributors • Architects and key developers – Rod Johnson – Juergen Hoeller • Test-first development on the framework • Vibrant community – Very active mailing lists and forums • JIRA Issue tracker at Atlassian • Over 50, 000 downloads total
…The Spring community • At least six books coming out in 2004 – Spring Live (June): Matt Raible – J 2 EE Without EJB (May): Johnson/Hoeller – Professional Spring Development (Q 4): Johnson/Risberg/Hoeller/Arendsen – Better, Faster Lighter Java (Bruce Tate) – Bruce is also writing an introductory Spring book for O’Reilly (due out Q 4) – Manning Spring in Action (Q 4) • Related projects – Acegi Security for Spring
Spring services: Interface 21 • • Training Commercial support Consulting We offer more choices for companies who wish to form a strategic partnership with us • We provide unique Spring and J 2 EE expertise
Who’s using Spring (partial list) • Banking – Global investment bank • 2 projects live with Spring MVC, Io. C, AOP, JDBC; 10, 000 users daily (whole Intranet) • Even bigger project rolling out this month (Web. Sphere) – – German domestic bank Leading US bank: online banking service (8 m hits per day) At least three more global banks to my knowledge Several household names in US • • Defence Publishing Health care (Web. Sphere) Power generation (Web. Sphere)
Who’s using Spring (partial list) • Government/NGO – – European Commission WHO CERN Several universities in the US and UK, including • Rutgers University (New Jersey) • Warwick University (UK) • u. Portal project (US University portal) • Many sophisticated websites – – Used by several consultancies on multiple client sites Major European delivery tracking service Nominet FA Premier League football
Where it all began… • Describes the motivation for Spring and basic concepts • Practical approach to J 2 EE development that works • One of the first expressions of “lightweight J 2 EE”
Episode 2… • Describes the Lightweight Container Architecture in detail • Practical guide to more efficient, more productive J 2 EE – Not just a polemic • Not purely about Spring, but – Uses Spring for all examples – Discusses all key parts of Spring
Questions