Interfaces y libertad de elección.
Fecha de creación: 15.12.2005
Revisión 1.0.1 (15.12.2005)
Alberto Molpeceres
alberto DOT molpeceres AT linkingpaths DOT com
| Copyright (c) 2005, Alberto Molpeceres. Este documento puede ser distribuido solo bajo los términos y condiciones de la licencia de Documentación de javaHispano v1.0 o posterior (la última versión se encuentra en /licencias/). |
|
Este trabajo se ha publicado también en Sólo Programadores nº 132. Diciembre 2005.
La industria.
Casi desde sus inicios, el mundo de la informática ha tratado de definir lo mejor posible las interfaces entre las distintas partes que intervienen en un sistema. Ya desde la definición de las siete capas del modelo OSI para las redes, quedó claro que cuanto menor control se tenga sobre algún componente del sistema, mejor es tener una interface fuerte que nos permita intercambiarlos de forma sencilla, de manera que no se ponga en peligro la inversión realizada si un componente falla o si un proveedor deja de ser el de nuestra elección.
La definición de estas interfaces suele tomar la forma de estándar o de especificación, pero para que tenga verdadero éxito tiene que venir definida por la propia industria, unas veces articulada en la forma de un organismo público, otras como un consorcio de empresas.
Estos estándares o especificaciones tienen dos consecuencias claras:
- Protegen a los clientes y usuarios. Los distintos proveedores competirán por dar un mayor valor añadido, añadiendo extras o mejorando su nivel de servicio, pero siempre sin salirse del estándar. Esto se debe a que el cliente deja de estar atado al componente, de modo que los proveedores deben esforzarse para mantener a los clientes y ganar nuevos de entre las filas de sus competidores.
- Mejora continua. Los proveedores estarán interesados en realizar ellos mismos aportaciones al estándar, a través del organismo correspondiente, pues tendrán más posibilidades de ser los primeros que implementen dichas mejoras que ellos mismos propongan.
- Compatibilidad hacia atrás. Como son varios los proveedores que ofertan productos sobre una interface, sólo un acuerdo entre todos ellos pueden eliminar partes de esa interface de cara al futuro, de modo que nos aseguramos que futuras versiones de los productos no nos obligan a realizar cambios en otros componentes estables.
Los desarrolladores.
De la misma forma, los desarrolladores e integradores de sistemas, aún a un nivel de abstracción superior, se encuentran en la misma situación a la hora de desarrollar sus aplicaciones. Las distintas partes que forman su aplicación deberían estar lo mejor aisladas posible para minimizar el impacto de los cambios: son los conceptos clásicos de cohesión y acoplamiento.
Los desarrolladores buscan (o deberían buscar) escribir y usar componentes que puedan ser reemplazados de forma sencilla, que facilite el trabajo de mantenimiento, que se lleva el 80% del coste de un proyecto, y por tanto, el 80% de su jornada laboral. Estos componentes deberían tener también definidos esos interfaces que sirven para comunicarlos, de forma que cada uno se pueda centrar en los problemas propios de su negocio, y no en cuestiones tecnológicas de más bajo nivel.
Para lograrlos se ha ido evolucionando en las tareas de programación, aplicando nuevas técnicas y ayudas al desarrollo como las buenas prácticas, los patrones o el refactoring, que ayudan a mejorar las aplicaciones y reducir el impacto de los cambios.
Pero por buenos que seamos aplicándolas, si disponemos de especificaciones o estándares que definan la interface entre estos componentes nuestra labor será aún más sencilla. Y más aún en la situación en la que nos encontramos actualmente, con todos los sistemas empresariales conectados en red, con una necesidad de interoperabilidad impuesta por nuestros clientes, que no aceptarán perder su negocio porque uno de sus socios utilice otra tecnología o uno de sus sistemas críticos tenga cinco años. El ejemplo más claro de esta situación es el de los servicios web, pero es también aplicable al acceso a sistemas Host o diversos tipos de bases de datos o fuentes de información. Con interfaces bien definidas podremos escoger entre distintos proveedores o realizar nuestra propia implementación, que además podremos vender a terceros si ofrecemos un buen producto y servicio.
Ir por libre
Pero, ¿por qué seguir esas especificaciones o estándares?. La respuesta en sencilla, porque de no seguirlas estás hipotecando el futuro de tu proyecto y/o producto, o estas perdiendo oportunidades de negocio.
Para el primer caso pongamos el ejemplo de la WWW. Algo tan simple como texto con unas pocas etiquetas de formato no debería habernos dado demasiados problemas, sobre todo estando ya en los años 90. Pero la realidad es que no sólo los dio, sino que los sigue dando. Hasta la llegada de HTML 4.0, la W3C se limitó a emitir recomendaciones, pero no dictar estándares. Esto nos dejó en una situación en la que cada fabricante de software de navegación decidió que partes implementar, cuales no, o que partes se comportan de la forma esperada o cuales nos daban sorpresas. Todos sabemos que al final se impuso una empresa, de modo que se podría considerar que estableció un estándar de facto. Pero las consecuencias, que seguimos sufriendo diez años después, es que ese proveedor decidía por nosotros, ya que nuevas versiones de su programa podían eliminar funcionalidad, o no documentaban nueva, o lo que es peor, no permitía a nuestros cliente usar otro producto de su elección.
Aunque esto nos pueda parecer un mal menor, puesto que a fin de cuentas un proveedor puede ser el claro dominador del mercado y nosotros requerir su utilización para utilizar nuestra aplicación, tenemos que tener claro que seguimos ligando el futuro de nuestro proyecto o aplicación a ese proveedor, hipotecándolo. Si ese proveedor es comprado por otro rival, o decide abandonar el producto, o si la legislación cambia, o su cuota del mercado disminuye, estaremos obligados a realizar una inversión importante en tiempo y dinero para continuar nuestro trabajo.
El ejemplo de Java.
Java, como lenguaje y como plataforma, es un caso especial dentro del mundo del desarrollo del software. En Java todas las herramientas que necesitamos para construir software están (o estarán) definidas por una especificación. Desde el propio lenguaje o la máquina virtual hasta los servidores de aplicaciones, de librerías de acceso a base de datos hasta otra para el procesamiento de XML, desde la utilización de motores de workflow a la gestión de teléfonos móviles o tarjetas inteligentes. De esta forma, nada nos impide cambiar de un proveedor a otro si nos ofrece mejor servicio o precio. Nada salvo nuestra propia lealtad o decisión de utilizar extensiones de sus productos. Por poder cambiar, podemos en casi todos los casos cambiar de sistema operativo sin vernos afectados por ello.
¿Pero cómo se articula esto en Java?, a través del Java Community Process (JCP). El destino de todo lo que pueda ser Java esta regido por este consorcio formado por la mayoría de las grandes empresas del sector. El JCP se encarga de agrupar a las empresas y profesionales que destacan en cada ámbito de la industria de forma que definan estas especificaciones, que como hemos comentado no sólo se refieren a las distintas plataformas (estándar, empresarial y móvil), sino de APIs de soporte (persistencia, comunicación, etc.), acceso a recursos (bases de datos, sistemas de mensajería, etc.) o incluso tipos de aplicaciones (como servidores, gestión de contenidos, multimedia, etc.).
Los miedos a seguir estándares.
Como empresa, si seguir una especificación o un estándar nos puede parecer una amenaza, puesto que significa que nos pueden robar clientes, la respuesta es fácil, ¿y los que podemos robar a nuestros competidores si damos mejor servicio?. Seguir estándares nos abre oportunidades de negocio.
Como desarrollador, si seguir una especificación o determinados estándares internos y/o externos nos puede hacer pensar que somos más fácilmente reemplazables por otros desarrolladores, a dejar de sentirnos imprescindibles. La respuesta también es fácil: ¿No nos será entonces también más fácil encontrar otro trabajo si podemos aplicar los aprendido de forma sencilla?, ¿no podremos aprender de otros de forma más sencilla?, ¿no será más fácil mantener aplicaciones de otros?. Seguir estándares facilita nuestro trabajo reduciendo tiempos de desarrollo, mantenimiento así como facilita compartir información.
La época de los clientes cautivos ha pasado a mejor vida. Los clientes cada vez más requieren la interoperabilidad, entre sus propios sistemas y los de sus clientes, proveedores, socios tecnológicos o administraciones públicas. Requieren proveedores que puedan adaptar sus aplicaciones a los cambios permanentes de la actualidad de forma rápida, proveedores que den solución a sus problemas de forma eficaz. Y quién no los siga se quedará fuera. Todo esto sólo es posible a través de estándares y especificaciones que definan claramente las interfaces de comunicación intra e intersistemas. Sólo así conseguiremos alcanzar el potencial que nos ofrecen las nuevas tecnologías.
|
Alberto Molpeceres
es asesor tecnológico para la empresa Linking Paths S.L. , empresa dedicada a la formación especializada de profesionales del sector de TI así como a la asesoría J2EE y el desarrollo de software propio y ajeno.
Alberto es además el fundador de javaHispano así como desarrollador de software libre y conferenciante habitual.
Contacto: alberto PUNTO molpeceres ARROBA linkingpaths PUNTO com
|
|
jueves, diciembre 29, 2005 at 11:19AM 