Comercio electrónico, su arquitectura

Establecer la arquitectura de un sistema distribuido no es fácil. Tenemos mucho en juego y un error podría costarnos caro. Si bien nos viene en mente dos grandes plataformas para hacer esto, debemos separar la parte empresarial con la parte masiva.
Un framework PHP puede hacer todo pero no tendríamos la solvencia y capas necesarias con respecto a JEE6 o NET, por ejemplo.
Sin embargo, un portal de ventas masivas con aspx o JSF no estaría para el bolsillo de cualquier empresa, sobre todo en cuanto a recursos nos referimos.
Para esto establecemos la arquitectura básica a desarrollar. La gestión empresarial en JEE , NET y el portal de ventas en PHP, RUBY, Python, etc. El puente debe ser sin excepción: WebServices.
Los WebServices, REST o SOAP, nos proporcionan el mecanismo mas practico para exponer metodos remotos. CORBA es superior a ellos, pero como todos sabemos debido a su complejidad quedo relegada para el modelo de objetos EJB únicamente.
Las reglas de negocios solo se exponen cuando se necesitan (Stateless) evitando, en primer lugar abrir las bases de datos, eliminar conexiones sincrónicas con estados y consumir menor ancho de banda.
Peligrosamente un archivo XML no es lo mas liviano que podríamos enviar, pero sin dudas es inferior a peticiones SQL cliente-servidor.
La pregunta es: ¿Debo exponer los métodos con nuevos objetos o utilizar los que tenemos para que se conviertan en WebServices?
En JEE cada EJB puede convertirse en un WebServices solo con simples anotaciones.

 

Anuncios