El Blog de Trespams

En el negoci on-line cada cop és més important adaptar-se als canvis més ràpid, posar nous serveis a l'abast dels clients i fer-ho per ahir. Fins ara havíem fet servir dues aproximacions diferents:

• aplicacions fetes en Python i Django, per les parts més dinàmiques i mensy crítiques del negoci
• aplicacions desenvolupades anb Java/J2EE de contenidor fi (Tomcat) per les parts més serioses del negoci.

Llevat de la conya de que Java deixa més tranquils a consultors i auditors, he de dir que la tecnologia té moltes coses bones, la qualitat del programari obert és molt bona, i bastiments com XFire (ara baix l'ala del projecte Apache), Spring o Hibernate fan la vida del programador molt més senzilla, encara que la corba d'aprenentatge sigui gran. La tecnologia està té un gran nombre d'eines i els IDE de desenvolupament com Eclipse o Netbeans són vertaderes meravelles.

El problema fonamental que té fer-ho tot en Java és que és força lent fer el desplegament de les aplicacions, així com fer petits canvis en la lògica de negoci o la capa de presentació. Fer un canvi que afecti a la part del model implica sovint tenir que recarregar l'aplicació a Tomcat, maleir quan a la sessió de depuració veus que no t'ha refrescat les classes, reiniciar el contenidor, esperar fins a un minut o dos que recarregui tot i començar la depuració.

La posada en producció també es veu afectada per com fa les coses la tecnologia, la velocitat i l'estabilitat que dona Java i el Tomcat s'aconsegueixen fent que les aplicacions es despleguin al contenidor, que la capa de presentació es compili en temps d'execució. La qual cosa vol dir, que un desplegament típic de les aplicacions pot dur un mínim d'uns 15 minuts entre baixar el servidor, posar-hi l'aplicació, pujar el servidor i fer que aquest compili els jsp. Baixar el servidor no vol dir aturar-ho, sinó llevar-ho de l'accés públic, encara que sovint aquest llevar-ho de l'accés públic també implica l'aturada.

Davant això tenim aplicacions fetes amb Django i Python, on provar un canvi no duu més que uns pocs segons, el servidor de desenvolupament respon de manera immediata als canvis fets en el codi. Posar una aplicació a l'entorn de proves normalment implica actualitzar el repositori de subversion al tag que s'hagi determinat com estable i fer un reload de l'Apache, tot plegat menys de 15 segons. Passar-ho a producció normalment és igual de senzill, moltes vegades ni tan sols és necessari establir un procediment d'aturada del servei, ja que l'actualització de les plantilles no implica aturada i un reload de l'Apache no arriba al segon en els mega servidors de producció.

Hem d'aconseguir anar cap a una arquitectura d'aplicacions i de desenvolupament que aconsegueixi unificar el millor dels dos mons: la facilitat de desenvolupar i testejar aplicacions sense capa de presentació que té Java i la potència i facilitat de fer canvis a la capa de presentació de Python i Django.

En altres apunts ja he comentat cap a on volia anar, fer els serveis en Java, que se n'encarregaran d'accedir a les bases de dades i fer tota la fontaneria necessària i fer tota la capa de presentació web en un llenguatge dinàmic, en el nostre cas Python amb el bastiment Django, que sigui un consumidor dels serveis web.

Amb això podem no tant sols escalar les aplicacions, sinó també escalar l'equip de desenvolupament, ja que podem tenir equips fent feina a cada una de les capes de l'aplicació sense que hi hagi pràcticament interferències una vegada s'han definits els serveis.

Donat que els serveis no tenen capa de presentació i per tant no hi ha compilacions de JSP per exemple, resulta que el temps necessari per desplegar-los és molt petit comparat amb de l'aplicació sencera. El testeig es relativament senzill, bé amb tests d'unitat direcatament en Java o amb eines com SoapUI.

Ens queda doncs lligar la capa de serveis (arquitectura SOA que queda millor), amb la capa de presentació. Consumir serveis web Soap complexes amb Python fins ara no era senzill, l'espacificació Soap és tan complexe que llevat de el propi Java i .net (a la seva manera), són capaços de convertir el wsdl publicat a classes manejables pel programador. Però això està canviant i ho està fent molt ràpid, el projecte ZSI ha madurat molt els darrers temps i a les darreres proves ha demostrat que és capaç de consumir els serveis web fets amb XFire sense problemes. També hi ha que dir que els serveis ja s'han pensat de tal manera que siguin fàcils de mapejar, evintat fer us de característiques sols suportades sols per Java, però això no crec que sigui una mancança sinó una inversió de futur, augmentar la complexitat implica augmentar també temps de depuració i tenir que lluitar amb incompatibilitats entre versions.

Els prototips realitzats fins al moment són molt encoratjadors, els temps de resposta de tot plegat és excel·lent, sense fer optimitzacions tenim temps de 0.6s des de la capa de presentació feta amb Python fins a la capa de base de dades a la que s'hi ha accedit mitjançant un servei web fet amb Java i XFire.

Encara que hi ha una regla que diu que quan es fa un estudi per veure la viabilitat d'un projecte aquest estudi sempre dóna que és viable, per ara tot pareix demostrar que el camí pel que estam anant és correcte i que per projectes amb molts programadors és molt productiu, ja que a més de separar l'aplicació en capes, estam separant en capes el propi desenvolupament.

Queden encara força aspectes a estudiar, però que no són tant d'arquitectura d'aplicacions com de metodologia de desenvolupament i de desplegament de les aplicacions, de manera que s'acabin optimitzant tant els mètodes de desenvolupament, el mètodes de desplegament com la comunicació entre els membres del projecte. L'objectiu és poder respondre ràpid a les necessitats del negoci i que la tecnologia no ens condicioni de manera negativa el temps de resposta, mantenint al mateix temps l'estabilitat i l'escalabilitat de les aplicacions.

Hi som molt aprop....!