Tjenestebasert design med dynamiske proxyer og Spring Bjørn Vidar Bøe, JavaZone 2005

Agenda  Introduksjon til eksisterende design  Fordeler og ulemper  Mål for ny løsning  Verktøy for jobben  Ny løsning!  Fordeler og ulemper  Erfaringer

Oversikt over hele applikasjonen Brukergrensesnittlag DB PatientViewPortlet……… Tjeneste- og forretningslag PatientService……… Portal … …

Detaljer om tjeneste- og forretningslaget  Gruppert i 5 tjenester med ca 70 metoder  Forretningslogikken er implementert i POJOs og pakket inn i stateless session beans  Inneholder også annen funksjonalitet felles for alle tjenester som  Caching av resultater fra tjenestekall  Logging av eksekveringstid på alle kall

Detaljert design for en tjeneste Brukergrensesnittlag DB Portlet Tjeneste- og forretningslag Business delegate Stateless session bean Caching Tjeneste-implementasjon Data access object Service interface POJOs

Flere tjenester… Brukergrensesnittlag DB Portlet Tjeneste- og forretningslag Data access object Service interface Business delegate Stateless session bean Caching Tjeneste-implementasjon Data access object 2 Service interface 2 Business delegate 2 Stateless session bean 2 Caching 2 Tjeneste-implementasjon 2

Fordeler og ulemper  Enkelt å jobbe med fra klienten sin side  Service interfaces forhindrer inkonsistens mellom lagene  All testing av logikk kan gjøres i IDE pga bruk av POJOs  Rammeverkskode er tungt å vedlikeholde  Endring i tjenestegrensesnittet krever oppdatering mange steder  Vanskelig å implementere nye ikke-funksjonelle krav

Ny visjon!  En tjeneste skal kun bestå av spesifikasjon i et interface og implementasjon  Gjøre business delegaten helt generisk  Benytte AOP for å løse ikke-funksjonelle krav som:  Caching  Logging  Men:  Ikke røre grensesnittet, forretningslogikk, dataaksesskode eller testkode!  Ikke føre til endringer i hvordan klienten forholder seg til tjenestelaget  Grensesnittet skal fremdeles være remote

Verktøy for jobben  Dynamiske proxyer for å generere business delegate  Generisk stateless session bean for å beholde tilgjengelighet utenfra  Spring for å knytte sammen tjenestene bak EJBen  Spring AOP for implementering av caching og logging

Dynamiske proxyer PatientService +findPatient(…) : Patient[] +retrievePatient(…) : Patient Invocation handler public Object invoke(Object proxy, Method m, Object[] args) PatientService patientService = (PatientService) Proxy.newProxyInstance (PatientService.class.getClassLoader(), new Class[] { PatientService.class }, businessDelegateHandler);

Stateless session bean wrapper public Object callServiceTransactionSupported(...) throws Throwable; public Object callServiceTransactionRequired(...) throws Throwable;  Enkel å bygge på grunn av dynamisk proxy i front  Inneholder ingen logikk som ikke lar seg teste utenfor en J2EE-container

Spring som lettvektscontainer public class PatientServiceImpl implements PersonService { private PatientDataAccess patientDataAccess; public PersonServiceImpl (PatientDataAccess patientDataAccess) { this.patientDataAccess = patientDataAccess; }... }

Spring AOP  Integrert del av Spring  Krever kun endring i Spring-konfigurasjon for å ta i bruk  Fungerer godt for konfigurering av oppførsel på klassenivå  Benytter egen xml-fil for detaljert styring av oppførsel på metode-nivå

Service interface Caching advice Logging advice Nytt design Service impl Generic service facade Dummy facadeStateless session bean facade Service invocation handler Service DAO interface Logging advice DAO impl Dynamic proxy Spring Eget rammeverk

Flere tjenester Service B Caching advice Logging advice Service impl B Generic service facade Dummy facadeStateless session bean facade Service invocation handler Service B DAO B Logging advice DAO impl B Service A Caching advice Logging advice Service impl A DAO A Logging advice DAO impl A Service C Caching advice Logging advice Service impl C DAO C Logging advice DAO impl C Service AService C

Strategi for å implementere dette  Gode enhetstester!  Jobb fra topp til bunn  Ta kontroll over instansiering av BD  new PatientService() => ServiceFactory.getPatientService()  Sørg for at klienten forholder seg til et interface  Legg over et og et sett med tjenester i nytt rammeverk inkludert minimal konfigurasjon i Spring  Gjør nødvendig refactoring på DAOene for å skille de i grensesnitt og implementasjon  Knytt DAOene inn via Spring  Legg på advices  Alle enhetstester skal gå på grønt under hele refactoringen!

Resultat av redesignet  Høyere produktivitet  Mindre rammeverkskode å forholde seg til  Har fått muligheter for caching på DAO- laget gratis  IOC gjør det enklere å benytte mock- objects i enhetstester  Har fungert stabilt i produksjon i 9 mnd

Erfaringer fra bruk av AOP  Gir en løsere kobling mellom rammeverkskode og forretningslogikk  Gjør det mulig å gjenbruke rammeverkskode  Fjerner ikke behov for å vite om logikken  Konfigurering av aspekter i Spring kan virke rotete  Debugging med AOP er vanskelig  Lange og stygge stack-tracer