Web Services para todo?

En lo que va de este año, ya van por lo menos dos clientes en los que observo una especie de "obsesión" con la utilización de Web Services, indicando que las aplicaciones a construir deben estar basadas en SOA y, por lo tanto, deben consumir servicios internos mediante SOAP. WTF?

Para tener una arquitectura basada en u orientada a servicios, no se requieren Web Services! Es más, si las aplicaciones consumidoras y proveedoras de servicios están escritas en el mismo lenguaje de programación, se vuelve una pésima opción, por cuestiones de rendimiento y complejidad innecesaria en el diseño. Recordar los principios KISS y YAGNI!

Acerca del tema de la distribución innecesaria de los objetos se ha dicho bastante. Es más, es una de las razones por las que surgió Spring como respuesta al status quo impuesto por el estándar EJB 1.x/2.x. Esto lo explican bastante bien Rod Johnson y Juergen Hoeller en su libro J2EE Development without EJB.

Por poner otro ejempo, y citando a Martin Fowler:

Rule # 1 of Distributed Computing - Don't distribute your objects!

Finalmente, todos deberían conocer las 8 falacias de la computación distribuida:

1. La red es confiable.
2. La latencia es cero.
   
3. El ancho de banda es infinito.
   
4. La red es segura.
   
5. La topología no cambia.
   
6. Existe un único administrador.
   
7. El costo del transporte es cero.
8. La red es homogénea.
   

Personalmente, recomiendo utilizar Spring (o algo parecido) para exponer servicios y sólo hacerlos accesibles remotamente si la necesidad de integrar clientes externos (por ejemplo implementados en una plataforma o lenguaje distinto) surge.

10 Cosas que Todo Arquitecto de Software Debería Conocer

Richard Monson-Haefel, uno de los fundadores de los proyectos Geronimo y OpenEJB y miembro de varios grupos importantes de definición de estándares dentro del JCP (JSR-151, JSR-153, JSR-220 y JSR-241) ha publicado una presentación muy interesante sobre las cosas que todo aquel que se hace llamar "arquitecto" dentro de un proyecto o empresa de desarrollo de software (ej: arquitecto de software, arquitecto de soluciones, arquitecto empresarial, etc) debería conocer y entender.

En resumen, son las siguientes:

• People are the platform
• All solutions are obsolete
• Data is forever
• Flexibility breeds complexity
• Nothing works as expected
• Documentation is the universal source code
• Know the business
• Maintain the vision
• Software architects should also be coders
• There is no substitute for experience

Este es el enlace para bajar la presentación: 10 Things Every Architect Should know. Me parece una excelente oportunidad de difundir las ideas de Monson-Haefel entre varios de nuestros muy apreciados powerpoint architects (seguramente deben conocer a más de uno).