20110910-115133.jpg
Anteriormente en este Blog ya había tratado el tema del registro de servicios (puedes ver esta entrada). Lo vuelvo a sacar a colación porque he visto una entrada aquí que viene a decir que si no tenemos un registro (un producto comercial) hagamos nuestra propia aplicación a medida para poder disponer de las ventajas de tener un registro de servicios en tiempo de ejecución.

Y es que si la alternativa es pagar un producto caro (al alcance de grandes empresas) como puede ser el que proporcionan grandes fabricantes como IBM o Oracle o no tener ninguno, lo mejor es hacer uno nosotros mismos.

Si no tenemos registro, no podremos proporcionar la capacidad de ser distribuible que tiene que tener un servicio SOA. Es decir, no podemos abstraer al consumidor del mismo de la localización física de donde está desplegado el servicio a consumir.

Realmente, un registro en su versión más básica es bastante simple. Necesitamos únicamente una tabla (puede ser una tabla hash en memoria persistida en un fichero plano) que tenga como clave un par de strings (id del servicio y versión) y como dato el endpoint del mismo.

Así, antes de que el cliente invoque al servicio, preguntará al servicio por un ID y una versión específica (es posible que en ejecución se tengan varias versiones del mismo servicio) y nos devolverá la localización física donde está el mismo.

¿Quien tiene que acceder al registro?
Esta es una cuestión inportante. En una gran empresa tendremos un gran parque de aplicaciones, de muy diferente tipo, y seguramente implementadas con muy variadas tecnologías: visual basic, Oracle Forms, .NET, Java, COBOL, etc. También tendremos productos comerciales que son consumidores de web services, como puede ser el servidor de fax, los escáneres de documentos, etc. Etc. Pues bien, todos y cada uno de ellos deben acceder al registry para consultar la localización del servicio que quieren invocar.
Así pues, debemos disponer de una interfaz sencilla que todas estas tecnologías puedan usar. Lo mejor en este caso seria disponer de una interfaz XML sobre HTTP o REST.
Por otra parte todas las implementaciones de los clientes del registro deberán disponer de un caché que guarde temporalmente el endpoint del servicio. Si no es así, dadas las cientos de miles de invocaciones al registro que se podrían producir al cabo del día contra el servidor del registro podrían tumbarlo.

Conclusión:
Para tener un verdadero servicio web debemos disponer de un registro de servicios, y si no podemos o no queremos comprarlo tendremos que hacerlo nosotros mismos.

Anuncios