JAVA versus NET

Mucho se dijo sobre este tema. Sin embargo, en el fondo las conclusiones no son claras, dado que es muy dificil encontrar opiniones objetivas de alguien que maneje los dos entornos, ya que por lo general prefiere uno u otro.

Hace unas semanas presencié un WebCast (que se puede descargar de aquí) que en un par de horas compararon ambas tecnologías desde muy diversos aspectos. Lo interesente es que fueron dos expositores (uno por Net y otro por Java) pero en un clima muy ameno y bastante objetivo, ya que eran amigos y expertos cada uno en lo suyo. Se comparó la versión 4.0 de Net contra la 6.21 de Java (la última disponible en ambos casos).

Les resumo a continuación las conclusiones que pude sacar para los que no puedan ver ese seminario o bien quieran un resumen de sus conclusiones.

Exposición
Se compararon ambos productos desde muy diferentes aspectos. Los principales fueron:

• Runtime de ejecución: modalidad y características soportadas
  
• Tipos de datos contemplados
  
• Programación: arquitectura general
  
• Gestión de excepciones
• Orientación a objetos: características soportadas
• Herramientas: IDE
  
• Costos de los IDE
  
• Ofertas de trabajo en mercado: disponibilidad de recursos
  
• Frameworks disponibles
  
• Documentación: soporte disponible
• Performance: velocidad de ejecución y peso de los programas
  
• Compatibilidad y migración entre versiones: complejidad de las actualizaciones
  
• Desarrollo de aplicaciones de escritorio
• Desarrollo de aplicaciones web
• Utilización en general

Primero se desarrollaba la característica en cuestión en Net y luego en Java. Terminado el tema (en general, no más de 10 minutos cada uno) la audiencia votaba por la plataforma que a su entender cubría mejor el punto en cuestión. Net superó a Java en la mayoría (casi el 90%) de los casos.

De 200 usuarios aproximadamente que presenciaron el seminario, más del 60% votó al final a favor de Net. Estimo que esto se debe a que la versión actual de Net es más potente que la versión actual de Java. Además, es más simple y rápida la programación en Net gracias a su IDE (Visual Studio), el cual no se compara con los disponibles para Java.

Conclusiones
Quedó claro que ambas tecnologías están en constante evolución, por lo cual la comparación realizada ahora tal vez sea obsoleta con la siguiente versión de cualquiera de las dos. Es decir, que la versión actual de Net supera en varios aspectos a la de Java. Sin embargo, esas ventajas desaparecerán en su mayoría con la versión 7 de Java, que tal vez supere a Net en algunos aspectos, los cuales serán cubiertos en la siguiente versión de este último...

Básicamente se puede lograr lo mismo con ambas plataformas. Se pueden construir buenos o malos sistemas con cualquiera de ellas. La elección deberá basarse en aspectos más sutiles y no en la simple pregunta de "¿quién es mejor: Net o Java?", porque sinceramente la respuesta no es absoluta e imparcial. La elección deberá basarse en el conocimiento o dominio de una u otra plataforma, la familiaridad con sus IDEs, los costos totales de licenciamiento del proyecto, la disponibilidad de resursos, los frameworks desarrollados o adquiridos para uno u otro lenguaje.

Cualquiera sea la herramienta que decida utilizar, es recomendable basar sus sistemas en algún framework de alto nivel, tanto más conveniente cuanto más compleja o grande sea la aplicación a desarrollar, ya que ambas plataformas, aunque potentes, son altamente sofisticadas.


Lic. Oscar Valente
CTO ItSouth Consultores
www.itsouth.com.ar


Fuentes
Seminario Java vs Net
http://cid-bef06dffdb192125.office.live.com/browse.aspx/2010%2006%2015%20Evento%20Java%20vs%20Net
Java EE
http://es.wikipedia.org/wiki/Java_EE
Net
http://es.wikipedia.org/wiki/Microsoft_.NET
Frameworks
http://fwnet.blogspot.com/2009/11/framework-para-desarrollo-de.html

¿Paradigma tecnológico? (sobreviviendo a los cambios)

En el mundo del conocimiento, existen "verdades incuestionables" que funcionan como "reglas". Verdades tales como que "necesitamos aire para respirar. "Estas reglas están y todos las aceptan... (o casi todos) y son conocidas en su conjunto como "un paradigma".Es el cuestionamiento a esas verdades lo que produce entonces los llamados"cambios de paradigmas. En el mundo de la tecnología son cada vez más cortos los ciclos de conocimiento "incuestionable" y cada vez más los cambios.

Recuerdo que hace muchos años atrás... siendo un poco más que adolescente, llegó a mis manos un libro que nada tenía que ver con tecnología, pero que explicaba ese concepto de paradigma en una forma muy sencilla.

El libro, que tenía que ver con el liderazgo y las organizaciones, versaba acerca de que los cambios profundos en cualquier tipo de empresa generan resistencia, y explicaba ese proceso como un cambio de PARDIGMAS.

Allí mismo, daba una ilustración bastante ingeniosa de lo que la palabra paradigma significa. Comenzaba su explicación con la afirmación que el valor más importante de las organizaciones es el conocimiento, en realidad el va

lor más importante de la sociedad es el conocimiento.

Ese conocimiento era descrito como un pozo, y en el fondo de ese pozo, se estaban los expertos, los sabios (ahondando el conocimiento, profundizando, buscando...).Una vez cada tanto, alguno de esos sabios, saca la cabeza del pozo y mira hacia afuera.... ve otras oportunidades, distintas a la de "su pozo" y decide salir.... y comienza a cavar un nuevo pozo, es decir, produce un cambio de visión, un cambio de "paradigma".

Pero ¿que pasa con los que están muy metidos en el pozo?.., muchas veces no tienen voluntad de salir, y van a pelear contra aquellos que proponen el cambio, es decir, "ejercen resistencia", aquí encontramos el concepto de "resistencia"

Lo interesante es que con el tiempo, el nuevo pozo se ha profundizado, tiene también expertos y en definitiva, alguien también va a sacar la cabeza y comenzar otro pozo, y aqu

í encontramos el concepto "comportamiento cíclico".

El otro punto que vale la pena encarar, es el que cada tanto, alguien que está metido en un pozo, encuentra que sale de ese pozo de conocimiento, y encuentra que "un pozo viejo" que ya se creía extinto, de repente vuelve a tener valor... este es el concepto de "reciclado".

¿Y que tiene que ver esto con la tecnología?

El mundo de la tecnología últimamente ha efectuado "varias salidas del pozo" y los que eran expertos hasta hoy, mañana son obsoletos. Y eso ocurre en cuestión de unos pocos años.El cambio de paradigma tecnológico, es un hecho, todo el tiempo ocurre, y resulta que muchas veces nos encontramos con que lo que sabíamos ya no funciona o ya se pasó de moda.

Lo cierto es que eso produce mucha inseguridad y bastante angustia, porque de repente ya no dominamos la situación sino que la situación nos domina a nosotros.

Así es que con el auge de .Net, Java, Objetos, Web, etc. viejos "expertos" ya no saben como seguir, y los expertos en esas tecnologías hacen crisis cuando derepente aparecen MVC, Silverlight y todas las cosas más nuevas.

¿Y quién podrá ayudarnos?

La verdad es que muchas veces desearíamos que ante nuestra pregunta el Chapulín Colorado viniese a ayudarnos. Hace poco hablaba con un colega y amigo, "experto" en Cobol. Gracias a Dios todavía tiene trabajo, pero está muy preocupado, su resistencia no es mas que un mecanismo de defensa.

Y si el Chapulín, no viene a ayudar, no obstante, este problema es un problema que todos, tarde o temprano tenemos que enfrentar y lo cierto es que hay alternativas para no quedarnos abajo en un cambio de paradigmas tecnológico.

Estas alternativas tienen que ver con buscar las herramientas y los profesionales adecuados que en la forma menos traumática nos ayuden a hacer frente a los cambios.

No dije que era gratis, y menos "facilísimo", pero puntualmente en el campo de las tecnologías Net, Java, Web, etc, existen múltiples entornos y frameworks que nos facilitan el ingreso a las nuevas tecnologías con un know how que ya han pagado otros.

En nuestra consultora, hace casi 10 años, con las primeras versiones beta de .Net, desarrollamos las bases de lo que hoy es una herramienta muy poderosa en cuanto a prestaciones, el StartPoint Net Framework, pero obviamente no es la única, ni siquiera la mejor (aunque quisiéramos), ahí cavando sus propios pozos de experiencia, están, Spring, Fullcrum, y otros. Todos con visiones distintas, pero todos ayudando en el cambio de paradigma.

Será entonces cuestión de no asustarse, sino de buscar bien, porque en algún lugar encontraremos a nuestro "Chapulín colorado".

Recorriendo el camino de VB6-VFP a NET

La revolución tecnológica que hace ya más de una década que se viene gestando (desde inicios del 2001 con J2EE de Sun y .NET de Microsoft), conduce al mercado hacia las nuevas plataformas tecnológicas, y, como siempre, el mercado obliga a las empresas que prestan sus servicios informáticos a actualizarse para no quedar en el camino.

Podríamos enumerar decenas de razones por las cuales actualizarse tecnológicamente, las cuales redundarían en el concepto de poder construir mejores sistemas más rápidamente y más interconectados. Sin embargo, la principal razón es que si no lo hacemos, quedaríamos fuera del mercado (o bien con una porción demasiado pequeña del mismo).


1 – El paradigma de programación
Una vez tomada la decisión de actualizarse tecnológicamente, el primer paso es estudiar y comprender los nuevos paradigmas de programación. En primer lugar, entendamos por tal a un enfoque particular o filosofía para la construcción de software.
En las tecnologías pre-Net el paradigma más difundido era el conocido como programación estructurada, el cual fue parcialmente sustituido por programación dirigida por eventos. En cambio, los paradigmas actualmente vigentes son programación orientada a objetos, por capas u orientada a servicios, entre otros.

2 – El lenguaje de programación
Una vez familiarizado con los nuevos paradigmas, hay que explorar las herramientas de programación para conocer las posibilidades que brindan. Este paso no es tan complejo porque las opciones se redujeron a poco más de dos, dónde Java y Net son los jugadores principales. Dentro de Net, tenemos un amplio conjunto de lenguajes que pueden seleccionarse. No es demasiado importante el lenguaje elegido: opte por el que mejor conoce, ya que las posibilidades tecnológicas que brinda son muy similares.

3 – Arquitectura (tecnología) de la solución
Dentro de los nuevos paradigmas, encontrará varias arquitecturas tecnológicas posibles a la hora de crear una nueva solución. Este punto es todo un tema, el cual ya ha sido tratado en otra oportunidad (ver nota al respecto). En resumen, la arquitectura o tecnología empleada está íntimamente asociada al tipo de solución que desea crear: Desktop, Web App, Servicio Windows, Servicio Web, RIA, Móvil, etc.

4 – Marco de la solución (Framework)
Una vez definido el tipo de solución a crear (arquitectura tecnológica), deberá contar con un Framework, el cual, independientemente de la tecnología empleada, es el marco de trabajo o esquema arquitectónico bajo el cual se desarrolla y luego se ejecuta una aplicación de Software.

Existen diferentes tipos de Frameworks según las funcionalidades que cubran cada uno de ellos. Hay desde simples componentes reutilizables para realizar tareas puntuales (como ser el acceso a datos) hasta marcos completos conocidos como Hight Level Frameworks. Estos son los que cubren necesidades que van más allá de la infraestructura y del marco arquitectónico, abordando aspectos tales como la capa de presentación de una aplicación. Generalmente se asocia a los High Level Frameworks con el desarrollo rápido de aplicaciones (conocido como RAD o Rapid Application Development), dado que hacen simple tareas de programación rutinaria, ganando mucho tiempo en el desarrollo de un proyecto y obteniendo una mayor calidad final.

Aquí deberá decidir si construye su propio framework o bien adquiere alguno existente en mercado. Deberá sopesar muy bien esta decisión porque significan muchas horas de programación.

Un framework debería cubrir algunos de los siguientes aspectos:

5 – Manos a la obra
Si pasó por los puntos anteriores exitosamente, ya se encuentra en condiciones de crear las nuevas aplicaciones NET. El tiempo o esfuerzo que le lleve, será directamente proporcional a la calidad del framework utilizado.
Cabe aclarar que no existe una forma segura de migrar aplicaciones desarrolladas con tecnologías pre-Net. Lo mejor en todos esos casos es realizar una reingeniería del diseño y la plataforma tecnológica.

Conclusión
A pesar de que este cambio tecnológico es tal vez el más complicado de los últimos 10 o 15 años (comparable a la migración de DOS a Windows), es tan importante como el mencionado suceso, ya que le abre las puertas a un mundo totalmente nuevo donde las aplicaciones pueden interactuar con otras aplicaciones y no sólo entre PCs pertenecientes a una misma red, sino a través de distintas plataformas (Windows, Web, Linux) y dispositivos móviles (notebooks, PDAs, colectores de datos, celulares).

Lic. Oscar Valente
CTO ItSouth Consultores
www.itsouth.com.ar

Fuentes
Java EE
http://es.wikipedia.org/wiki/Java_EE
Net
http://es.wikipedia.org/wiki/Microsoft_.NET
Paradigmas de programación
http://es.wikipedia.org/wiki/Paradigma_de_programaci%C3%B3n
La evolución tecnológica en la última década
http://fwnet.blogspot.com/2009/11/evolucion-tecnologica-10-anos-no-son.html
Elección de una arquitectura adecuada
http://fwnet.blogspot.com/2010/01/eleccion-de-una-arquitectura-adecuada.html

Aplicaciones Empresariales para Pymes

Históricamente, siempre hubo una línea divisoria entre las aplicaciones o herramientas que estaban disponibles para las grandes empresas de las que lo estaban para las Pymes. Las razones de dicha división son diversas:

• Costos: las Pymes no podían costear el hardware, software y consultoría necesarias para implementar y mantener esas aplicaciones.


• Necesidades: en realidad, una Pyme tenía problemáticas muy diferentes a las que se daban en las grandes empresas.


• Acceso a la tecnología: estas herramientas estaban generalmente montadas por software y hardware propietario y poco difundido, razón por la cual se dificultaba el acceso no solo a su adquisición sino a su distribución, capacitación e implementación.
  

En esta última década fuimos testigos de una explosión tecnológica tal que llevó a las Pymes (entiéndase por tal a una empresa de al menos 50 empleados) las herramientas y aplicaciones que se consideraban exclusivas de las grandes empresas. Más concretamente, estamos hablando, entre otros ejemplos, de las siguientes categorías de productos:

• Software E.R.P. del tipo World Class, como ser SAP (el cual ahora cuenta con una versión comercializada bajo el nombre de All In One destinada para Pymes y que no es muy diferente del conocido R3 pero preconfigurado y a un costo accesible).


• Cubos OLAP, sistemas de reportes empresariales y herramientas de business intelligence (ahora disponibles a través de SQL Server Analysis Services y Reporting Services).


• Integración de sistemas Desktop con sistemas Web y dispositivos móviles como colectores de datos, PDAs, notebooks (que se integran en forma sumamente simple a través de la utilización de las nuevas tecnologías de comunicación del Microsoft Net Framework).

Si nos preguntamos a qué se debe esta popularización de la tecnología de alta gama, encontraremos diferentes razones que influyeron en ello, como ser:

1. Hardware más potente a menores costos.


2. Mercado corporativo saturado, razón por la cual las grandes empresas de tecnología se vieron obligadas a mirar hacia otros mercados.


3. Internet con todas sus potencialidades de globalización e integración que ofrece.


4. Revolución tecnológica liderada por Net Framework de Microsoft y Java Enterprise Edition de Sun.


5. Mayor cantidad de consultores con conocimientos y acceso a tecnologías consideradas altamente complejas.


6. Gran cantidad de programas gubernamentales de subsidios para el crecimiento y la innovación tecnológica de las Pymes (al menos en nuestro país).

Más allá de los motivos por los cuales esta tecnología está ahora al alcance de cualquier Pyme en crecimiento, lo importante es entender que estamos, como consultores, frente a una gran oportunidad de llevar a nuestros clientes (o potenciales clientes) tecnología de alta gama a un costo accesible.

De todas formas, hay que entender que la mencionada tecnología requiere de cierta experiencia y capacitación particular para lograr implementarla correctamente. Imaginemos la construcción de un sistema basado en un cubo OLAP alimentado del E.R.P. de la empresa complementado por una aplicación de reportes empresariales con indicadores y alarmas, accedido remotamente por el presidente de la empresa o sus ejecutivos de ventas desde la Web o su portátil en el que pueda ver un informe de ventas por región montado sobre un mapa de Google Maps o Microsoft Virtual Earth y publicado en SharePoint. Este tipo de aplicaciones son posibles hoy en día y a un costo accesible. Construir el mencionado sistema utilizando la suite de productos de SQL Server Business Intelligence y Visual Studio .Net es mucho más sencillo y económico que intentar hacerlo con algún producto propietario o herramientas aisladas. Sin embargo, no deja de ser un servicio de consultoría de alta especialización, por lo cual es imprescindible tomarse el debido tiempo para dominar la tecnología antes de decidirse a ofrecerla, o bien hacerlo en alianza con partners que cuenten con cierta experiencia en la materia.

Conclusión
El primer paso antes de ofrecer esta tecnología a sus clientes es comprenderla, imaginar sus posibilidades, capacitarse en forma global para tener claro alcances, costos, arquitectura general de la solución, hardware requerido, etc. Con todo esto en claro, recién entonces está en condiciones de idear un proyecto que considere de interés para sus clientes, ya sea sólo o en asociación con partners especializados.

Lic. Oscar Valente
CTO ItSouth Consultores
www.itsouth.com.ar

Fuentes
Cubos Olap:
http://es.wikipedia.org/wiki/Cubo_OLAP
Business Intelligence:
http://es.wikipedia.org/wiki/Inteligencia_empresarial
SQL Server Analysis Services:
http://msdn.microsoft.com/es-es/library/ms130214.aspx
Microsoft Net Framework:
http://msdn.microsoft.com/es-ar/netframework/default.aspx
Microsoft Virtual Earth:
http://www.microsoft.com/maps/
Java Enterprise Edition:
http://java.sun.com/javaee/

Elección de una Arquitectura Adecuada

En primer lugar, aclaremos que por el término “arquitectura del sistema” nos referimos a la organización fundamental de un sistema, que incluye sus componentes, las relaciones entre sí y el ambiente en el que se ejecutan, los principios que gobiernan su diseño y su evolución.

Es de común conocimiento que no existe una única arquitectura posible a la hora de definir el marco sobre el cual una aplicación deberá ser construida y, posteriormente, ejecutada. Una misma solución puede responder en forma aceptable a los requerimientos de los usuarios en más de una forma de implementación. Sin embargo, las consideraciones y el esfuerzo para construir un mismo sistema en una u otra arquitectura no son los mismos. Por ello, hay que diferenciar bien claramente lo que es una arquitectura posible de una arquitectura adecuada para un sistema dado.




Lamentablemente, muchas veces esas decisiones se toman por razones totalmente inadecuadas, como ser:

• Moda: no pocas veces se decide por una arquitectura sólo porque está de moda, si cabe el término en sistemas.
• Conocimiento: un analista/desarrollador se siente obviamente más cómodo al imaginar un sistema dentro del marco tecnológico que mejor domina.
• Desconocimiento: hay ocasiones en que el encargado de decidir la arquitectura no tiene conocimiento de ciertos modelos posibles que serían más apropiados para una determinada problemática.

Tenga en cuenta que una mala elección tiene un impacto no sólo en los costos de desarrollo (si la arquitectura se adapta mejor a los requerimientos, el desarrollo será más rápido), sino también en el resultado final alcanzado (tal vez la aplicación no cubra las expectativas del usuario o la performance deseada).

La única elección realmente válida es mediante un proceso en el cual se analicen las características de la aplicación que debe construirse y en base a ello se determine la arquitectura más apropiada para el caso. No es posible generalizar una única respuesta para todas las aplicaciones a desarrollar, sino que debe estudiarse cada caso en particular.

Resumiendo, los principales aspectos que deberían determinar la arquitectura de un sistema son:

• Funcionalidades deseadas: algunas operaciones sólo son posibles en ciertos contextos.
• Tipos de usuarios que accederán a la aplicación: nivel de conocimiento, habilidad y forma de uso de la tecnología.
• Ubicación física de dichos usuarios: locales, remotos, móviles.
• Interoperabilidad con otras aplicaciones: formatos, protocolos y mecanismos de comunicación.
• Performance: velocidad de respuesta y de procesamiento.
• Seguridad: tanto de la aplicación en sí como del acceso a la información que contiene.

Conclusión

Dada la cantidad de tecnologías disponibles, es recomendable que un arquitecto de software con experiencia sea el responsable de tomar estas decisiones, incluso debería considerar la posibilidad de tercerizar al menos el proceso de evaluación de los requerimientos y determinación de la tecnología, aunque luego decida que no tercerizará el desarrollo.

Lic. Oscar Valente
CTO ItSouth Consultores
www.itsouth.com.ar

Fuentes
Arquitecto de sistemas: http://es.wikipedia.org/wiki/Arquitecto_de_sistemas
La evolución tecnológica en la última década: http://fwnet.blogspot.com/2009/11/evolucion-tecnologica-10-anos-no-son.html