aplicaciones web origen y evolución - uv.es · pdf filediciembre de 2015 aplicaciones...

1Copyright © Capgemini 2013. All Rights Reserved

Diciembre de 2015

Cátedra Capgemini – Universitat de València

Diciembre de 2015

Aplicaciones Web – Origen y Evolución

Pablo Mir Gómez


Diciembre de 2015

Contextualización

Arquitectura de Capas

Evolución

› JSPs y Servlets

› EJB

› Spring Fwk

› SOA

› Put it all together

Metodología

Fwk devon


Diciembre de 2015

Contextualización


Evolución

Metodología

Fwk devon

¿Dónde podemos encontrar hoy en día aplicaciones web? ¿Por qué se han impuesto

en el modelo de negocio actual? ¿Para qué sirven realmente?

Fundamentos básicos de las Aplicaciones Web


Diciembre de 2015

Definición de Aplicación Web

Definimos Aplicación Web como toda aquella herramienta software codificada en un lenguaje

soportado por navegadores web y donde se confía la ejecución al navegador.

Existe una independencia clara y marcada de la plataforma, evitando problemas de distribución,

compatibilidad, actualizaciones, seguimiento, etc. Pero una dependencia estricta en su ejecución

(requieren siempre de un navegador web y cumplir estándares).

Facilita la interacción y la comunicación activa entre usuario e información.

En muchas ocasiones permite una centralización de la solución.

› Ofreciendo herramientas multi-dispositivo y evitando la generación de numerosas

versiones para escritorio, móvil (iOS, Android, Wphone).

› Leyendo y escribiendo información directamente en la fuente.


Diciembre de 2015

Antecedentes en el mundo de las Aplicaciones Web

Inicialmente, cada aplicación tenía su propio programa cliente instalada por separado en cada

ordenador.

El cliente realizaba peticiones y el servidor respondía.

Una mejora en la parte servidor, implicaba en muchos casos la modificación del cliente, con el

coste que ello suponía (soporte técnico, actualizaciones, gestión de errores…).

En las aplicaciones web, es la propia aplicación la que te sirve las páginas, es decir, cliente y

servidor son un único todo.


Diciembre de 2015

Ventajas en el uso de Aplicaciones Web

Multiplataforma Independencia del sistema operativo pero adaptación a navegadores del mercado.

Centralización Unificación de la información leída y escrita normalmente a tiempo real.

Free Space No ocupan espacio en disco y por consiguiente, evitan instalaciones de software.

Instant Update Siempre se dispone de la última versión liberada por el autor.

Recursos Evitan el consumo de recursos que puede ocasionar una aplicación de escritorio.

Disponibilidad En aplicaciones web de envergadura se ofrece servicio desde múltiples fuentes para evitar caídas.

Seguridad Los virus no afectan al cliente, puesto que si existen, se alojan en el servidor.

Colaboración Se favorece un modelo colaborativo y compartir la información.


Diciembre de 2015

Desventajas en el uso de Aplicaciones Web

Limitación Normalmente están limitadas por el entorno y no ofrecen el 100% de funcionalidad.

Disponibilidad La disponibilidad del servicio está supeditada a un tercero (pj. Empresa de hosting).

Conectividad Pese a permitir funcionamientos offline, en algún momento deben sincronizar con servidor.

Recursos La incorrecta gestión de memoria por parte del desarrollador, puede originar experiencias de

usuario nefastas y bloqueos en la operativa.

Seguridad Los virus no afectan al cliente, pero pueden afectar a los datos del servidor si no están

debidamente protegidos.

Privacidad Nuestra información se almacena en servidores cuya ubicación desconocemos. ¿Renunciamos a

nuestra privacidad?


Diciembre de 2015

Concepto de Centralización en Aplicaciones Web

Unificación de las fuentes de datos empleadas en los procesos de lectura y escritura, así como del

backend empleado en negocio.

En ocasiones, también se realiza unificación de la parte de vista, gracias a soluciones responsive.

Las características de la centralización son:

› Origen de información único sin réplicas ni sincronizaciones

› Mayor control y seguridad de la información

› Fácil de mantener

› Backend/Vista única favoreciendo multicanalidad (Móvil, Tablet, Escritorio…)


Diciembre de 2015


Descentralización

A

B

Vista A

Negocio A

Vista B

Negocio BResponsive development

Pj. Cordova project


Diciembre de 2015


A

A

Centralización

Negocio

Vista


Diciembre de 2015

Consideraciones a tener

en cuenta en el desarrollo

de AW

Una de las principales ventajas

competitivas de las Aplicaciones

Web es la independencia del

entorno, no obstante, esta

independencia del entorno

contrarresta con la fuerte

dependencia de ejecución

(navegador y estándares).


Diciembre de 2015

El desarrollador debe concienciarse del uso de

tecnologías estándar y transversales a cualquier

entorno de ejecución, desestimando aquellas que

puedan suponer un callejón sin salida en pocos

años (Flash, Silverlight, Applets…)

La vulneración de estándares sobre los

navegadores web más comunes puede ocasionar

problemas de visualización y funcionamiento que

pueden ser arrastrados a negocio (pj. Valores

undefined en JavaScript).

Consideraciones a tener en cuenta en el

desarrollo de AW


Diciembre de 2015

Cronología de las Aplicaciones Web más relevantes de la historia

Las aplicaciones web han

revolucionado la forma de utilizar

internet, pasando de páginas con

contenido exclusivamente estático

a contenidos ricos e interactivos.

1987

Comienzo del camino

Surge uno de los primeros lenguajes

para el desarrollo de WebApps: PERL

SurgePHP

Rasmus Lerdorf pone a disposición el

lenguaje PHP que revolucionó la parte

servidor

1995

SurgeHotmail

Sabeer Bhatia y Jack Smith construyen una

de las primeras WebApps más

famosas

1996

Aparece Flash

Surge una de las primeras soluciones de vista interactiva

contra las WebApps

1997

PrimerPeriodismo en línea

Nunca se había tomado como medio de

comunicación. Difundió noticia mediática antes

que la prensaescrita

1998

NaceJavaScript

Nuevo enfoque de las WebApps. Gracias a él se puede cambiar el contenido de forma

dinámica

1995


Diciembre de 2015

Cronología de las Aplicaciones Web más relevantes de la historia

1998

Google

Google desarrolla su primer motor de

búsqueda

MySpace

Se convirtió en el medio de

comunicación social más visitado

2003

SurgeDigg y Facebook

FB surge inicialmente para estudiantes y

ahora es el segundo sitio más visitado del

planeta

2004

Se lanzaYoutube

Permite compartir videos, alquilar

películas y es uno de los sitios más famosos

hoy en día

2005

Wikipedia

Aparece como sub-proyecto de Nupedia y fomenta en desarrollo

colaborativo

2001

ConferenciaWeb 2.0

John Battelle y Tim O'Reilly liberaron el concepto de Web como Plataforma

2004

2006 – Se lanzaTwitter

2007 – Aparece el

primer iPhone

2011 – KickStarter


Diciembre de 2015

Las Aplicaciones Web en el entorno empresarial

Hoy en día las empresas apuestan por la elaboración de soluciones íntegras, con una marcada

centralización tanto en arquitectura como en solución.

Los clientes buscan invertir poco dinero a cambio de soluciones desproporcionadamente

completas (pj. Para entornos de escritorio y móvil) y cada día abogan más por un modelo de fácil

mantenimiento y con una gran capacidad de interconexión entre los sistemas que ya poseen.

Gracias al modelo de centralización y a la arquitectura usada actualmente por la mayor parte de

consultoras (SOA), es mucho más sencillo conseguir la satisfacción del cliente y por consiguiente,

aportar más valor a los desarrollos. Esto no quiere decir que sea más sencillo construir una

solución (os cansareis de oír: “hacer esto no cuesta nada ¿no?” o “bueno, esto con una jornadita…”)…


Diciembre de 2015

Contextualización


Evolución

Metodología

Fwk devon


Principal definición de la arquitectura de capas sobre aplicaciones web. ¿Para qué se

emplea? ¿Programación modular?


Diciembre de 2015

Arquitectura de capas

El objetivo principal de esta

arquitectura se basa en la separación

de lógica de negocio y presentación.

Cuando existe un problema sólo se

ataca al nivel afectado.

Permite un entorno colaborativo, en

el que los desarrolladores pueden

trabajar en paralelo sin perjudicarse.

Capa Web

Presenta el sistema al

usuario. Debe contemplar

principios de usabilidad,

accesibilidad, sencillez y

limpieza.

Capa Negocio

Recibe y responde a todas

las peticiones de usuario. Se

establecen las reglas y

filtrados o se realizan

peticiones a sistemas

externos.


Diciembre de 2015

Programación modular

La arquitectura de capas es el primer paso hacia la programación modular. Tecnologías como JSP,

PHP, JSF… no siguen puramente (por sí solas) un modelo MVC (Modelo-Vista-Controlador), lo que

provoca en muchas ocasiones que el programador localice Vista y Negocio sobre la página

implementada.

El hecho de introducir directivas (lenguaje servidor) en capas de vista acarrea validaciones,

condicionales, bucles… que únicamente deberían aparecer en negocio.

Por deferencia a estas tecnologías, cabe destacar que la principal culpa la tiene el desarrollador y

las prácticas que adquiera. Podemos separar CSS, JS, Java… en ficheros independientes tales

como *.css, *.js, *.java (servlets), pero incluso con ello, en algunas ocasiones seguiremos sin

emplear un modelo puro MVC.


Diciembre de 2015


El principal objetivo de la programación modular radica en la posibilidad de poder sustituir una

capa/modulo por otro, sin necesidad de adaptaciones o con un conjunto de cambios mínimos.

Del mismo modo que podemos sustituir un CSS por otro y cambiar el aspecto de una página en

segundos, podemos sustituir la capa de Base de Datos por otra y no tocar ninguna línea de

código.

Servlets + Backend

JSPs


Diciembre de 2015

Contextualización


Metodología

Fwk devon

Evolución » JSP + ServletsEvolución de las aplicaciones web

Las aplicaciones web desde su origen, JSP-Servlets, EJB, Spring. Arquitectura SOA. El

modelo actual y su cohesión con la programación modular y la arquitectura de capas.


Diciembre de 2015

Orígenes de Aplicaciones Web Empresariales – JSPs/JSFs y Servlets

Siempre desde el contexto MVC presente:

› Servlets: Tratan la información de los formularios, generan contenido, redireccionan

peticiones…

› JSP: Facilitan el desarrollo y mantenimiento del contenido HTML.

› No crea beans!!

› Usar <jsp:useBean … type=“paquete.Clase” /> en vez de <jsp:useBean … class=“paquete.Clase” />

› No modifica beans!!

› Usar jsp:getProperty en vez de jsp:setProperty

› Java Beans y Enterprise Beans: Facilitan la implementación de la lógica de negocio.

Independientes de la presentación.


Diciembre de 2015

Controlador Vista Modelo

Petición HTTP

Servlets Java Beans

Enterprise Beans

JSPs

Respuesta HTTP

2. Procesado de petición

3. Acceso a BD


Diciembre de 2015

Contextualización


Metodología

Fwk devon

Evolución de las aplicaciones web



Evolución » EJBs


Diciembre de 2015

Orígenes de Aplicaciones Web Empresariales – EJBs

EJB es un modelo de componentes o framework que permite crear aplicaciones sin tener que

reinventar servicios como transacciones, seguridad, persistencia automática, etc.

El código se ejecuta en un entorno llamado “Contenedor EJB” encargado de proveer servicios.

Se apoyan mucho en tecnologías que nos aporten los servidores de aplicaciones (cada servidor

aporta las suyas…)

La versión actual de la especificación EJB es la 3.2

Existen numerosas evoluciones de EJB, sin embargo, es a partir de la 3.0 donde realmente el

trabajo con esta tecnología merece la pena, puesto que las versiones anteriores eran demasiado

complejas y tenían muchos problemas.


Diciembre de 2015

Problemas con la especificación EJB 2.x

Acoplamiento Fuerte acoplamiento entre el código generado y las funciones propias de EJB. Se introducen

métodos en nuestras clases exclusivos para el funcionamiento de EJB (ejbCreate, ejbActivate…).

Descriptores Se usan descriptores de despliegue (son complejos y propensos a fallos). Describen cómo se debe

desplegar cada EJB (de sesión con estado o sin estado, de entidad…)

Dependencia Dependencia del JNDI cada vez que se tiene que acceder a un recurso, lo que supone una

operación repetitiva y tediosa en J2EE.

Persistencia El desarrollo y gestión del modelo de persistencia es muy complejo.


Diciembre de 2015

Características principales del nuevo modelo simplicado de EJB 3.x

POJO Los EJBs son objetos POJO (Plain Old Java Object) sin requisitos heredados.

Anotaciones Se emplean anotaciones sobre los POJOs con objeto de generar código Java sin intrusiones.

Descriptores Se elimina la dependencia de los descriptores de despliegue. Se pueden sustituir por anotaciones.

Persistencia Se utiliza un nuevo modelo de persistencia completo basado en el estándar JPA y que reemplaza

los beans de entidad.

Enfoque Los valores predeterminados se usan siempre que sea posible (enfoque “configuración por

excepción”).

Home Se elimina el requerimiento de especificar una interfaz HOME.

Interceptores La existencia de interceptores, elimina la necesidad de implementar interfaces de tipo callback.


Diciembre de 2015

Ejemplo de código entre EJB 2.x y EJB 3.x

// EJB 2.x

public class AccountBean implements javax.ejb.SessionBean {

SessionContext ctx;

DataSource accountDB;

public void setSessionContext(SessionContext ctx) {

this.ctx = ctx;

}

public void ejbCreate() {

accountDB=(DataSource)ctx.lookup("jdbc/accountDB");

}

public void ejbActivate() { }

public void ejbPassivate() { }

public void ejbRemove() { }

public void setAccountDeposit(int empId, double deposit){

...

Connection conn = accountDB.getConnection();

...

}

...

}

// EJB 3.x

@Stateless

public class AccountBean implements Account {

@Resource

private DataSource accountDB;

public void setAccountDeposit(int customerId,

double deposit) {

...

Connection conn=accountDB.getConnection();

...

}

...

}


Diciembre de 2015

Ejemplo de código entre EJB 2.x y EJB 3.x

// EJB 2.x

<session>

<ejb-name>AccountBean</ejb-name>

<local-home>AccountHome</local-home>

<local>Account</local>

<ejb-class>com.example.AccountBean</ejb-class>

<session-type>Stateless</session-type>

<transaction-type>Container</transaction-type>

<resource-ref>

<res-ref-name>jdbc/accountDB</res-ref-name>

<res-ref-type>javax.sql.DataSource</res-ref-type>

<res-auth>Container</res-auth>

</resource-ref>

</session>

...

<assembly-descriptor>...</assembly-descriptor>

// EJB 3.x


Diciembre de 2015

Cliente Remoto

Servidor de Aplicaciones

Contenedor de EJB

Cliente Remoto

Cliente Local

Pool de servicios: JMS, JTA, JNDI,

JDBC, Seguridad, WS…

Lógica de negocio Módulo DAO

Proveedor JMS

Beans de sesión

Beans gestionados por

mensajes

Entidades JPA

Gestor de entidades

Módulo Vista


Diciembre de 2015

Competidores directos: Spring vs EJB

La enorme dificultad en la utilización de las versiones previas de EJB (1.0, 1.1, 2.0, 2.1) motivaron

la aparición de tecnologías como Spring, que supieron imponerse y mantenerse hasta el día de

hoy en el mercado.

La versión 1.0 de Spring Framework fue liberada en Marzo de 2004 y su principal punto clave es

la flexibilidad y aportar una serie de ventajas que EJB incorporó demasiado tarde.

Pese a ello, no debemos olvidar los estándares y en esto, EJB es dominante.


Diciembre de 2015

Contextualización


Metodología

Fwk devon




Evolución » Spring Fwk


Diciembre de 2015

Orígenes de Aplicaciones Web Empresariales – Spring Fwk

Spring Fwk no es una evolución de EJB, sino una alternativa... Y todo sea dicho, muy buena.

Algunas de sus principales características son:

flexibilidad

Permite una conexión sencilla con otras tecnologías o fwk’s (estándar o no), ampliando así sus capacidades

de manera muy relevante (alta capacidad de integración).

actualización

Al ser un fwk de un único fabricante, lo mantiene al día e incorpora últimas tecnologías.

aislamiento

Sólo necesitamos Spring para poder trabajar, lo podemos instalar en cualquier servidor de aplicaciones y no

presenta problemas ni condicionamientos. Podemos usarlo con aplicaciones web, con swing, JavaFX… Nos

aísla de muchas problemáticas.


Diciembre de 2015

Orígenes de Aplicaciones Web Empresariales – Spring Fwk

En contraprestación:

no estándar

Pero se ha consolidado

como estándar de facto

en el mercado

complejo

¿Configurar múltiples

características para que

funcionen juntas sin colisiones?

Sí claro y ¿cuándo decías que lo

necesitabas?


Diciembre de 2015

La solución del modelo empresarial

Spring Fwk es una solución muy versátil para grandes empresas, puesto que éstas disponen de

múltiples clientes que usan Servidores de Aplicaciones e infraestructuras muy diversas.

El motivo principal es que EJB presenta mucho acoplamiento de cara a Servidores de

Aplicaciones y por consiguiente, todos los desarrollos no se podrían enfocar de forma

homogénea.


Diciembre de 2015

Spring es un framework para el desarrollo de aplicaciones y contenedor

de inversión de control, de código abierto para la plataforma Java.


Diciembre de 2015

Inversión de Control (IoC)

Tradicionalmente, el desarrollador especificaba el flujo de acciones y decisiones mediante la

llamada a métodos… En la inversión de control es justamente al contrario: se especifican las

respuestas deseadas y se cede el control a una arquitectura externa.

Spring gestiona las creaciones y destrucciones de los objetos generados por el usuario y son

estos objetos los que procesan las respuestas y las gestionan.


Diciembre de 2015

Inyección de Dependencias

Otro de los puntos relevantes y esenciales de Spring es la inyección de dependencias. En este

caso, Spring gestiona los objetos y permite que, en vez de crear nuevos objetos en cada clase,

sean suministrados mediante su “inyección”.

Mediante la utilización de estos dos conceptos, nos es más sencillo cumplir con otros, tales como

la modularidad y la reutilización. Por lo que podemos generar bibliotecas comunes y modulares

que luego inyectaremos en los lugares requeridos de nuestra aplicación.


Diciembre de 2015

Página de vista


Dispatcher Servlet Entidades JPA

Gestor de entidades

Petición HTTP

Módulo Vista

Handler Mapping

Controller

2. El Controller lanza

la petición

View Resolver

Basado en el patrón: Front

Controller, que nos da un

punto de entrada único.


Diciembre de 2015

Contextualización


Metodología

Fwk devon




Evolución » SOA


Diciembre de 2015

Arquitectura Orientada a Servicios - SOA

Esta arquitectura tiene tres objetivos principales: flexibilidad, escalabilidad e integración con

sistemas heredados.

Permite encapsular pequeños bloques funcionales y hacerlos accesibles mediante interfaces.

Estos bloques funcionales son considerados servicios (petición-respuesta) y pueden ser

consumidos por la propia aplicación web que los contiene o por aplicaciones externas.

Por tanto, pese a lo que se diga, SOA NO ES UNA METODOLOGÍA.


Diciembre de 2015

Arquitectura Orientada a Servicios - SOA

El encapsulado de servicios no sólo supone un buen sistema para la construcción de

aplicaciones, sino que beneficia al programador, puesto que permite atacar un problema de

forma más localizada. Gracias a esto, también mejora el tiempo de realización de cambios.

Esta arquitectura es el punto fuerte de la oferta de las consultoras actuales. La mayor parte de

clientes busca integración con los sistemas de los que ya dispone, migrando poco a poco sus

ecosistemas de aplicaciones, sin que les suponga un impacto grave en coste económico.


Diciembre de 2015

Contextualización


Metodología

Fwk devon




Evolución » Put it all together


Diciembre de 2015

View


Entidades JPA

Petición HTTP

Módulo Vista

Controller

Model

Controller Service

Interface

DAO

Interface

Model JPA <<

DTO

Módulo SOA aislado y accesible desde sistemas externos

POOL de Servicios publicados

>> DTO

REST

Spring Fwk

Centralizamos Arquitectura y Lógica. No lo hacemos con vista.

Utilizamos una arquitectura de capas con MVC tanto en negocio como en vista.

Hacemos uso de la programación modular para elaborar componentes reutilizables.

Utilizamos maven para asegurar una gestión de dependencias del proyecto centralizada


Diciembre de 2015

Contextualización


Metodología

Fwk devon

EvoluciónMetodología

Proceso de Testing: JUnit, pruebas unitarias, pruebas de pares, pruebas de

integración… Integración continua, Análisis Estático, SCRUM


Diciembre de 2015

Me acaban de asignar un proyecto!! Y ahora qué hago?

En muchas ocasiones y sobretodo al comenzar nuestra carrera profesional, desconocemos los

pasos a seguir en el momento de asignación a un proyecto.

Si el alcance está definido y ya se ha acordado un comienzo, finalización, presupuesto y recursos

con el cliente, debemos seguir unos “sencillos” pasos que nos pueden facilitar la vida.

Requisitos

Acribilla al cliente a preguntas. Deja claros los objetivos y remarca las

facetas en las que pone interés. Posiblemente cuando entregues el

producto, lo primero que haga sea buscarlas.


Diciembre de 2015


Analiza

Todo evolutivo debe acompañarse de un documento funcional que recoja

un análisis contextual, modelo de dominio, Arquitectura, Casos de Uso y

Mockups.

Estima

Cada caso de uso puede resumirse en un número: el volumen de horas

que va a costar implementarlo. El cliente debe ser conocedor del coste y

validarlo.


Diciembre de 2015


Planifica

Jamás dejes nada al azar!!! El “Creo que llegamos” o “no te preocupes que

sobra tiempo” no suelen funcionar nunca. Toda acción debe ser

cuantificada y valorada para su inclusión en el pool de tareas.

SCRUM

Utiliza metodologías ágiles para la consecución de proyectos. Avanzar con

pequeños pasos y con una monitorización continua del cliente, motivará

acercarse más a un nivel óptimo de satisfacción.


Diciembre de 2015

Genial.

Pero… ¿para qué nos adentramos en metodología si el curso es sobre

Aplicaciones Web y Backend?


Diciembre de 2015

SCRUM y su vinculación con negocio

La metodología SCRUM establece una forma de relacionarse dentro del proyecto, pero también

define y acota las tareas del desarrollador (tarjetas).

Toda tarjeta SCRUM contempla un Caso de Uso completo o parcial y en algunos casos hay

dependencias entre ellos.

Una tarjeta SCRUM, es decir, un desarrollo, se considera terminada cuando:

› Se ha desarrollado el caso de uso reflejado en la misma.

› Se ha documentado tanto la parte técnica como la parte de usuario.

› Se han elaborado las pruebas necesarias para garantizar la calidad del software.


Diciembre de 2015

¿Cómo probamos el Backend?

Los métodos habituales para la realización de pruebas sobre el backend-vista de cualquier

aplicación web son:

Pruebas Unitarias Normalmente se hace uso de JUnits y deben encargarse de cubrir los escenarios

funcionales básicos para el correcto desarrollo del Caso de Uso.

Pruebas de pares Son realizadas por un miembro del equipo ajeno al desarrollo y por consiguiente a la

tarjeta SCRUM asignada. Garantizan la solución de errores básicos.

Pruebas funcionales Son realizadas por el analista funcional que elaboró el documento origen de todo y

desencadenan en un documento de Plan de Pruebas escrito sin tecnicismos.

Pruebas integración Batida de pruebas realizada sobre una réplica del entorno de despliegue oficial con objeto

de validar comportamientos anómalos en caso de interacción con terceros.

http://www.uv.es/capgeminiuv/programa.html


Diciembre de 2015

¿Cómo estabilizamos el Backend del proyecto?

Tras el ciclo de pruebas, el código se sube a los repositorios y puede dar comienzo un proceso de

integración de código fuente (automatizado en muchos casos).

El objetivo de este procedimiento se basa en evitar que el equipo trabaje de forma aislada y que

conforme avance el tiempo, las discrepancias del código sean tan graves que puedan producirse

errores por el propio merge (normalmente suele ocurrir los viernes o cualquier día a la hora de

irse a casa).

El proceso de integración continua abarca todo el ciclo de vida de construcción de la solución:

Compilación > Testing > Testing de Calidad > Despliegue


Diciembre de 2015

¿Cómo aportamos valor a nuestro desarrollo?

Dentro del proceso de integración continua, se lanza una tarea para evaluar la calidad del código

subido por cada usuario.

Este procedimiento permite al desarrollador mejorar su código y hacer frente a posibles errores,

tales como variables que pueden llegar a ser null en algún momento de la traza, vulneraciones

de estándares, reservas de memoria innecesarias…

Capgemini presenta a sus desarrolladores el estado de los

proyectos en todo momento mediante monitores y de este

modo, es posible ver a tiempo real quién ha subido un fallo

en algún proyecto de los existentes y corregirlo cuanto antes.


Diciembre de 2015

Contextualización


Metodología

Fwk devon

EvoluciónFwk devon

Breve introducción al fwk de desarrollo utilizado por Capgemini.


Diciembre de 2015

Contextualización

Devon nació como herramienta de desarrollo propia y con el único objetivo de facilitar el día a día

a los desarrolladores.

Asimismo, con ella garantizábamos la estandarización de la forma de trabajo y un amplio

hándicap de reutilización (hasta entonces cada proyecto diseñaba su arquitectura y los

movimientos de personas entre proyectos se hacían complicados por el tiempo de adaptación).

Actualmente su versión estable es la 5.0, donde se incluyen las últimas librerías de Spring,

Hibernate, ExtJS 5, SenchaTouch 2 y un sinfín de módulos más. Sus principales principios son:

Multiplataforma, MultiBrowser/Multicanal, Opensource, SOA, continua evolución y últimas

tecnologías.


Diciembre de 2015

Aceleración en el desarrollo

Gracias al fwk, la gente que se dedica a desarrollar ha dejado de preocuparse por:

› Configuración de librerías (Spring, Hibernate, Caché, Seguridad, i18n, properties, Reports…)

› Crear un proyecto y partir de cero (Cuando creas un proyecto con el fwk partes de una plantilla

funcional)

› Dependencias, builds… (Maven está automatizado para eliminar todos estos problemas al

desarrollador)

› Tener un entorno de trabajo (devonfw no es sólo un fwk, sino un bundle de herramientas con todo

lo necesario para gestionar un proyecto: BD, Entornos, sistemas de caché, aplicaciones…)

› Transaccionalidad (se utiliza el principio de transaccionalidad declarativa, evitando que el

desarrollador tenga que gestionar transacciones o se queden abiertas).

› Gestión de conexiones (se aísla al desarrollador de la apertura y cierre de conexiones).

› Controllers (se ha homogeineizado la comunicación de vista y negocio a través de anotaciones).


Diciembre de 2015

Datos Más…Negocio

Estructura

BO

Controles

Forms

Caché

Gestión de Errores

Validaciones

Caché URLs

Grids

Búsquedas

Accesos rápidos por teclado

Integración con Maps

Componente Gantt

Permisos de visibilidad

Web

Programación de tareas

Schedulers

Eventos

BO

BO Asíncronas

Monitorización de BO

Caché BO

Drools

jBPM

Batch

Optimistic locking

Auditoría

Funcionalidades extendidas

Paginación

Conversores

Batch Query

Permisos y gestión de autorización

Web Services

Mail

Test en memoria

Seguridad

EDI

Informes


Diciembre de 2015

Flexibilidad modular

The happy path

core

batch

bpm

ibatis

JPAhibernate

birt

ws

sws

bam

jsf

test

reporting

web

edi

ucm

JDBC

rules

WebExtJS5

Touch2

WebExtJS3

WebExtJS4


Diciembre de 2015

Imagen visual, vista y multicanalidad

Devon hace uso de ExtJS como interfaz de vista por su gran versatilidad, rapidez, estandarización,

flexibilidad y escalabilidad.

Los proyectos móviles no son un problema con Sencha Touch, puesto que es multi-dispositivo y

multi-plataforma. Además funciona perfectamente con PhoneGap, que puede ser usado para

distribuir nuestras aplicaciones en las stores de Android, Apple, Wphone…

Asimismo, gracias a PhoneGap, podemos hacer uso de la API nativa del dispositivo y acceder así

a la cámara, contactos, etc.

Con devonfw la tecnología no es un problema, sino una oportunidad para el cliente


Diciembre de 2015

[email protected]


Diciembre de 2015

© 2015 Capgemini. All rights reserved.

Acerca de Capgemini

Con alrededor de 120.000 empleados en 40 países, Capgemini es uno de los principales líderes en servicios de consultoría, tecnología y outsourcing del mundo. El Grupo Capgemini ha alcanzado unos ingresos globales de 9.700 millones de euros en 2011.

Capgemini en colaboración con sus clientes, crea y proporciona las soluciones tecnológicas y de negocio que mejor se ajustan a sus necesidades y que conducen a alcanzar los resultados deseados.Siendo una organización profundamente multicultural, Capgemini ha desarrollado su propia forma de trabajar, la CollaborativeBusiness Experience TM, basada en su modelo de producción Rightshore ®.

Para más información: www.es.capgemini.com

Rightshore® is a trademark belonging to Capgemini

www.capgemini.com

http://www.facebook.com/Capgemini

http://www.facebook.com/Capgemini

http://www.linkedin.com/company/capgemini

http://www.linkedin.com/company/capgemini

http://www.slideshare.net/capgemini

http://www.slideshare.net/capgemini

http://www.twitter.com/capgemini

http://www.twitter.com/capgemini

http://www.youtube.com/capgemini

http://www.youtube.com/capgemini

aplicaciones web origen y evolución - uv.es · pdf filediciembre de 2015 aplicaciones...

Documents