2. CÉLKITŰZÉS
• Mi a célja ennek a mai beszélgetésnek?
• Historikus áttekintés
• A Spring framework evolúciója
• Java EE evolúció
• Technológiai összehasonlítás, konfiguráció
• Migráció
• Kapcsolódási pontok
3. MI A CÉLJA ENNEK A MAI BESZÉLGETÉSNEK?
• Egy fair összehasolítás
• Bemutatni a főbb szolgáltatásait a két versenyzőnknek
• Mérlegelni egy lehetséges, jó megközelitést nagyvállalati rendszerek feljlesztéséhez
• Nem célom a beszélgetés végén „győztest” hirdetni
4. HISTORIKUS ÁTTEKINTÉS
• 90-es évek vége
• Nehézkes, komplex és drága a nagyvállalati rendszerek fejlesztése
• Nincs iparági sztenderd
• A J2EE specifikáció nagy ígértetekkel érkezett anno (1998 JPE)
• A fejlesztők, az 1998-ban megjelent EJB specifikációt, kvázi szent Grálnak hitték
6. HISTORIKUS ÁTTEKINTÉS
• 2003 a Spring megjelenésének éve
• Célja a fejlesztés egyszerűsítése a J2EE-hez képest
• POJO programing model
• IOC konténer
• Alkalmazás-szerver független
7. SPRING FRAMEWORK EVOLÚCIÓ
Dependecy
Injection
POJO oriented
development
Declarative
AOP &
transactions
MVC
Framework
Proble Specific XML
Extensible
Configuration
Bean Scoping
Groovy, JRuby and
BeanShell
JSP tag library
Java 5 autoboxing
and generics
Annotation driving
wiring
Automatic bean
configuration
New annotation
driven MVC
framework
JUnit 4-based
integration testing
JSR 300 “at inject”
New Spring
Expression Language
First-class REST
support
Java based
configuration
Several new Spring
MVC features
Support for JSR 303
declarative validation
Scheduled Jobs
A new “C” namespace
Configuration profiles
Unified property
resolution
Java configuration
features
Servlet 3.0 support
Declarative caching
Spring MVC
enhancements
Mobile features
Modern Web
Data Access
Social
Security
Cloud Ready
8. SPRING FRAMEWORK EVOLÚCIÓ
• Jelenlegi verzió a 4.0.5
• Java 8 támogatás
• Java EE 7 támogatás
• Generikus típusok használata DI során Qualifier-ként
• WebSocket támogatás
10. TECHNOLÓGIAI ÖSSZEHASONLÍTÁS,
KONFIGURÁCIÓ
• A Java EE és a Spring egyaránt ad middleware szolgáltatásokat
• A funkcionalitások sok esetben nagyon hasonlóak, sokszor azonban elértő
megközelítést alkalmazva
• Vanilla alkalmazások esetében, a kódok szinte teljesen megegyeznek
17. ANNOTÁCIÓK
Java EE 7 Spring
@Named @Component
@Inject,@EJB,@Resource @Autowired
@Alternative @Primary
@PostConstruct,@Predestroy @PostConstruct,@PreDestroy
@Request
@ConversationScoped
@SessionScoped
@ApplicationScoped
@Scope(“request”)
N/A (w/ Spring WebFlow)
@Scope(“session”)
@Scope(BeanDefinition.SCOPE_SINGLETON
)
@Produces @Configuration + @Bean
18. TERVEZÉSI MINTÁK
Java EE 7 Minta Spring
@Singleton Singleton Alapértelmezetten minden
bean singleton
@Observes Observer Spring esemény-kezelés
@Produces Factory @Configuration + @Bean
@Decorator + XML (for order) Decorator N/A, github: spring-decorator
@Interceptor AOP @Aspect, @Around, @After,
@AfterReturning,
@AfterThrowing, @Before,
@Pointcut
@Inject DI @Autowired
@Asynchronous, Servlet 3.0+,
Websockets
Asynchronous programming @Async
@Schedule Timer @Scheduled
19. TESZTELHETŐSÉG
Java EE 7 SPRING
Arquillian konténer teszt Rugalmas teszt környezet, konténer nélküli
tesztelhetőség (Spring Test Framework)
Beágyazott Glassfish konténer Servlet API mock objektumok
(MockHttpServletRequest)
Bean profiling, a különbőző környezetekhez
Könnyű tesztelhetőség a REST-es API
esetében is a builder API segitségével
21. MIGRÁCIÓ
• Milyen esetben érdemes példálul Spring alapokról JEE-re migrálni?
• Legacy alkalmazással van dolgunk (Korábbi Spring verzióban iródott)?
• Milyen okokból érdemes váltani?
• Gyorsabb lesz a rendszer?
• Biztonságosabb?
• Jobban menedzselhető?
• Milyen technikai szempontokat kell figyelembe vennünk?
22. MIGRÁCIÓ, NÉHÁNY MEGVÁLASZOLANDÓ
KÉRDÉS
• Hogyan migráljuk az annotáció alapű DI működést?
• Hogyan migráljuk az XML alapú DI és factory bean máködést?
• Támogatott-e a property placeholder mechanizmus?
• Hogyan migráljuk az Aspektus orientált osztályainkat?
• Megoldott-e a programozott bean lookup?
• A Java EE támogatja a profilok használatát?
• Hogyan migráljuk a megirt Spring alapú teszt eseteinket?
• Felmerület számos egyéb kérdés...
23. HOGYAN MIGRÁLJUK AZ ANNOTÁCIÓ ALAPÚ DI
MŰKÖDÉST?
• A bean szkópokat korábban megvizsgáltuk
• Amire figyelnünk kell, hogy a CDI-nak és a Spring-nek eltérőek az alapértelmezett bean
szkópja
• Vigyázzunk a FINAL minősitéssel, a CDI a java assist API-t használja a PROXY
objektumok elkészitéséhez
28. TÁMOGATOTT-E A PROPERTY PLACEHOLDER
MECHANIZMUS?
• Alapértelmezésben nem
• Használható kulső library (Apache DeltaSpike)
• Irható saját CDI kiterjesztés
31. MEGOLDOTT-E A PROGRAMOZOTT BEAN
LOOKUP?
• A BeanManager nagyjából ekvivalens az ApplicationContext objektummal (Inkább a
BeanFactory-val)
32. A JAVA EE TÁMOGATJA A PROFILOK
HASZNÁLATÁT?
• A válasz majdnem
• Használható a @Alternative annotáció, azonban ennek működéséhez szükséges az XML-
ben történő konfiguráció
• Nincs dinamikus környezet specifikus aktiválás
• Globális megoldás lehet egy CDI extension irása?
33. ÉRVEK ÉS ELLENÉRVEK(SPRING)
• Gyakran felmerülnek érvek az egyik, vagy másik technológia mögött
• A Spring framework jóval rugalmasabb, jobban használható, például az AOP
esetében
• A Spring esetében gyorsabbak a releasek, mivel nem iparági sztenderd és egy
gyártóval számolhatunk
• A JEE alkalmazás-szerverek lassúak, robosztusak, például egy Tomcat-hez képest
34. ÉRVEK ÉS ELLENÉRVEK
• Mivel a Java EE csak egy halmaza sztenderd specifikációknak, igy gyártó független, több
implementáció közül választhatunk
• Mivel nagy iparági szereplők állnak a JEE mögött, igy a folyamatos fejlesztés,
fenntarthatóság biztositott
• Nagyjából minden olyan feature-rel rendelkezik, mint a Spring, könnyen használhatóak
külső osztálykönytárak
35. ÉRVEK ÉS ELLENÉRVEK
• Mivel a Java EE csak egy halmaza sztenderd specifikációknak, igy gyártó független, több
implementáció közül választhatunk
• Mivel nagy iparági szereplők állnak a JEE mögött, igy a folyamatos fejlesztés,
fenntarthatóság biztositott
• Nagyjából minden olyan feature-rel rendelkezik, mint a Spring, könnyen használhatóak
külső osztálykönytárak
37. BÉKÉS EGYÜTTÉLÉS
• Spring bean-ek injektálhatókak JSF menedzselt beanekbe
• Nativ Java EE támogatás a Spring oldaláról
• A Spring képes alapértelmezetten kezelni a különféle JPA implementációkat
• A Spring támogatja az alkalmazás-szervereket (jee névtér)
38. KONKLÚZIÓ
• Nincs olyan praktikus érv ami miatt választanunk kellene a kettő között, adott use
case-től függ
• Egyfajta kiegyensúlyozott verseny egyaránt jó a fejlesztőknek és az eszköz
gyártóknak
• Adottak az integrációs lehetőségek
• Azonban felmerülnek mindkét oldalról érvek, ellen érvek
Kb úgy érdemes összehasonlítani a két versenyzőnket, mint almát a narancssal.
Míg a JEE egy specifikáció, addíg a Spring egy technológiai framework
Fontos az arany középút, megtalálni a lehető legjobb megközelítést
Egy enterprise projekt fejlesztése során.
Esetleg megemlíthető a polyglot programming.
J2EE was horrible. So much XML configuration, so many interfaces, and so lame application servers. This is why the Spring framework was created. It solved many problems of J2EE. It was lightweight, easy to use, and applications could be deployed in a web container (such as Tomcat) instead of a heavy J2EE application server. Deployment took seconds instead of 15 minutes. Unfortunately, JRebel did not exist at that time. The Spring framework is no standard as J2EE, nevertheless it became very widespread and an large community arose.
Since Servlet 3.0+, the above registration for Spring’s dispatcher servlet can be done programmatically (code-based), thanks to the Servlet 3.0’s new feature called shared libraries/runtimes pluggability which scans jar files bundled in the WEB-INF\lib directory for implementations of the ServletContainerInitializer interface and invokes its onStartup() method which contains initialization/bootstrapping code, during servlet container/web application startup. In respond to this new feature, Spring 3.1+ provides its own implementation by the SpringServletContainerInitializer class which is bundled in configured in the spring-web-VERSION.jar file.
The SpringServletContainerInitializer class is bootstrapped automatically by any Servlet 3.0-compliant container (e.g. Apache Tomcat 7), and it will look for an implementation of the WebApplicationInitializer interface and invoke its onStartup() method. Following is an example of a WebApplicationInitializer’s implementation that does the same thing as the XML-based approach above:
Rugalmasság: All enterprise projects – of many different clients – which I have seen, are not that flexible. Enterprise applications do not change every month or year. If there is a project, where you can change your version very easily, Spring might be better than JEE under some circumstances. But in most enterprise projects, you cannot simply upgrade from Spring 2.5 to Spring 3.x or from JEE 5 to JEE 6. I wish this would be possible, but low flexibility and politics rule in large companies with thousands of employees.
Rugalmasság: All enterprise projects – of many different clients – which I have seen, are not that flexible. Enterprise applications do not change every month or year. If there is a project, where you can change your version very easily, Spring might be better than JEE under some circumstances. But in most enterprise projects, you cannot simply upgrade from Spring 2.5 to Spring 3.x or from JEE 5 to JEE 6. I wish this would be possible, but low flexibility and politics rule in large companies with thousands of employees.
Rugalmasság: All enterprise projects – of many different clients – which I have seen, are not that flexible. Enterprise applications do not change every month or year. If there is a project, where you can change your version very easily, Spring might be better than JEE under some circumstances. But in most enterprise projects, you cannot simply upgrade from Spring 2.5 to Spring 3.x or from JEE 5 to JEE 6. I wish this would be possible, but low flexibility and politics rule in large companies with thousands of employees.
