Enterprise Java evolúció, avagy JAVA EE (VS) Spring framework Balogh-Biró Attila 2015.04.15 Schönherz Bázis – IT és villamosmérnök meetup

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

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 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.

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

Historikus áttekintés És amit kaptak… 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.

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

1.0 2.0 2.5 3.0 3.1 3.2 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

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

1.2 1.3 1.4 5 6 7 J2EE(JAVA EE) EVOLÚCIÓ May’98 Dec’99 Sep’01 Nov’03 Apr’13 1.2 1.3 1.4 5 6 7 Project JPE J2EE 1.2 J2EE 1.3 J2EE 1.4 Java EE 5 Java EE 6 Java EE 7 EJB 1.0 Servlet 2.1 EJB 1.1 Servlet 1.1 JSP 1.1 JMS 1.0.2 JDBC 2.0 JNDI 1.2 JAF 1.0 JTA 1.0 JTS 0.95 JavaMail 1.1 EJB 2.0 (CMP, MDB, local EJB) Servlets 2.3 (Event, Filters) JSP 1.2 JDBC 2.1 JCA 1.0 JAAS 1.0 JAXP 1.0 EJB 2.1 Servlet 2.4 JSP 2.0 Web Services JMX J2EE Deploy JACC JAAS JAX-RPC JAXR JSTL EJB 3.0 JPA 1.0 JSF 1.2 Servlets 2.5 JSP 2.1 (Common EL) JAXB, SAAJ, WebService Injection Prunning Extensibility CDI JAX-RS Servlet 3.0 EJB 3.1 Lite JMS 2.0 Batch Caching TX Interceptor WebSocket JSON JAX-RS 2.0 10 specs 13 specs 20 specs 24 specs 28 specs 32 specs

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

Technológiai összehasonlítás, konfiguráció

Technológiai összehasonlítás, konfiguráció Spring XML, Class, Annotáció alapú konfiguráció Java EE 7 Minimális konfiguráció beans.xml nem szükséges többé web.xml nem szükséges Servlet 3.0 óta

Spring MVC (web.xml) konfiguráció XML alapon

Spring MVC(servlet-xml) konfiguráció XML alapon

Spring MVC 100 konfiguráció Kód alapon 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:

Spring MVC 100 konfiguráció Kód alapon

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

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

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

Spring Test(REST, MVC)

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?

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...

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

Hogyan migráljuk az annotáció alapú DI működést (@Qualifier)?

Hogyan migráljuk az XML alapú DI és factory bean működést?

Hogyan migráljuk az XML alapú DI és factory bean működést (Factory method)?

Támogatott-e a property placeholder mechanizmus?

Támogatott-e a property placeholder mechanizmus? Alapértelmezésben nem Használható kulső library (Apache DeltaSpike) Irható saját CDI kiterjesztés

Hogyan migráljuk az Aspektus orientált osztályainkat?

Hogyan migráljuk az Aspektus orientált osztályainkat?

Megoldott-e a programozott bean lookup? A BeanManager nagyjából ekvivalens az ApplicationContext objektummal (Inkább a BeanFactory-val)

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?

É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 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.

É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 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.

É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 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.

Mindenképpen választanunk kell?

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)

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

Köszönöm a figyelmet! attila.balogh86@gmail.com