Balogh-Biró Attila

2015.04.15

Schönherz Bázis – IT és villamosmérnök meetup

ENTERPRISE JAVA EVOLÚCIÓ, AVAGY JAVA EE (VS) SPRING FRAMEWORK

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

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…

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

SPRING FRAMEWORK EVOLÚCIÓ

Dependecy InjectionPOJO oriented developmentDeclarative AOP & transactionsMVC Framework

Proble Specific XMLExtensible ConfigurationBean ScopingGroovy, JRuby and BeanShell JSP tag libraryJava 5 autoboxing and generics

Annotation driving wiring Automatic bean configurationNew annotation driven MVC framework JUnit 4-based integration testing

JSR 300 “at inject”New Spring Expression LanguageFirst-class REST support Java based configuration Several new Spring MVC featuresSupport for JSR 303 declarative validationScheduled Jobs

A new “C” namespaceConfiguration profilesUnified property resolutionJava configuration featuresServlet 3.0 supportDeclarative cachingSpring MVC enhancements

3.0 3.1 3.2

Mobile featuresModern WebData AccessSocialSecurityCloud 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

651.2 1.3 1.4 7

J2EE(JAVA EE) EVOLÚCIÓ

May’98 Dec’99 Sep’01 Nov’03 May’06 Dec’09

EJB 1.0Servlet 2.1

EJB 1.1Servlet 1.1JSP 1.1JMS 1.0.2JDBC 2.0JNDI 1.2JAF 1.0JTA 1.0JTS 0.95JavaMail 1.1

Apr’13

ProjectJPE

J2EE 1.2 J2EE 1.3 J2EE 1.4 Java EE 5 Java EE 6 Java EE 7

10 specs 13 specs 20 specs 24 specs 28 specs 32 specs

EJB 2.0(CMP, MDB, local EJB)Servlets 2.3(Event, Filters)JSP 1.2JDBC 2.1JCA 1.0JAAS 1.0JAXP 1.0

EJB 2.1Servlet 2.4JSP 2.0Web ServicesJMXJ2EE DeployJACCJAASJAX-RPCJAXRJSTL

EJB 3.0JPA 1.0JSF 1.2Servlets 2.5JSP 2.1(Common EL)JAXB, SAAJ, WebServiceInjection

PrunningExtensibilityCDIJAX-RSServlet 3.0EJB 3.1 Lite

JMS 2.0BatchCachingTX InterceptorWebSocketJSONJAX-RS 2.0

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

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

É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

É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

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