web-services - servicios - soap vs rest vs json
SOA: ¿qué tan detallados deben ser los servicios para mantener el rendimiento? (3)
¿Qué nivel de granularidad es aceptable en un establo de servicios sin sacrificar el rendimiento?
Entidades individuales Según lo descrito por el consultor.
¿Estoy siendo demasiado escéptico con respecto a los éxitos en el desempeño que implementaremos todas nuestras entidades como servicios?
Sí. Demasiado escéptico.
Un marco decente puede optimizar algunas de estas solicitudes para que no involucren una gran cantidad de gastos generales de red.
Al igual que con las bases de datos SQL, los problemas se resuelven en gran medida. Descubrirá que las aplicaciones subyacentes que presenta como servicios son los cuellos de botella. La capa SOA es principalmente de fontanería. Los bits todavía necesitan moverse a través de las tuberías, la capa SOA simplemente los organiza de forma más inteligente que la mayoría de las alternativas.
¿Deberían implementarse solo los servicios cuando son necesarios, con el enfoque de "preparación" en lugar de diseñar la capa de negocio para la probabilidad de que los servicios se vuelvan a colocar encima de ella?
Sí.
Eso es lo que significa "Ágil".
Encuentra una historia de usuario. Construya solo los servicios (y entidades) para esa historia.
Tendrá algunos gastos indirectos significativos para las primeras historias en lograr que su marco SOA se cuadre y se pueda implementar como un paso de lanzamiento simple y repetible.
Nunca hagas una "preparación" extensa para cosas que "quizás" necesites en un futuro improbable. Lea sobre Agile y cómo priorizar una acumulación.
Estoy asumiendo un proyecto para reemplazar un antiguo sistema heredado desde cero. Antes de comenzar, la compañía contrató a un consultor que armó un bosquejo básico del sistema y presionó fuertemente a SOA. Esto dio como resultado una larga lista de "servicios de entidades", con la intención de que estuvieran compuestos por combinaciones de servicios más complejas. Por ejemplo, un usuario que desee información del comité golpearía el servicio "Comité", que luego llama al servicio "Persona" para obtener sus miembros, y el servicio "Reunión" para obtener sus reuniones, y así sucesivamente.
Entiendo las ganancias de flexibilidad en esto, pero mis preocupaciones son sobre el rendimiento. Me parece que un sistema construido con un nivel tan fino de granularidad para sus servicios gasta demasiados recursos en la traducción de mensajes de servicio, y el rendimiento será inaceptable. También me parece que las ganancias de flexibilidad aún se pueden hacer utilizando objetos básicos reutilizables, aunque en ese caso el beneficio de una interfaz independiente de la tecnología se pierde para obtener rendimiento.
Para obtener más información: la organización que solicita este software no cuenta actualmente con un conjunto de software de terceros estable con el que sea necesario integrarse. Este software reemplazará todas las suites. Actualmente tampoco hay consumidores externos que necesiten acceder a los datos fuera de la interfaz del sitio web provista, todas las llamadas de servicio serán de otras piezas dentro de nuestro sistema. La elección de SOA en este caso parece basarse por completo en el concepto de "preparación".
Entonces mi pregunta es: ¿qué nivel de granularidad es aceptable en un establo de servicios sin sacrificar el rendimiento? ¿Estoy siendo demasiado escéptico con respecto a los éxitos en el desempeño que implementaremos todas nuestras entidades como servicios? ¿Debería la funcionalidad estar disponible como servicios web solo cuando se necesitan, con el enfoque de "preparación" en lugar de diseñar la capa de negocios para la probabilidad de que los servicios caigan luego sobre ella?
Cuando digo "Servicio", me refiero al componente vertical completo que puede realizar una operación independiente completa. Y no prefiero ir en mayor detalle a menos que haya un requisito excepcional. En mi opinión de SOA, un servicio debe realizar la función comercial significativa que se puede realizar de forma independiente. Un servicio no debería requerir otro servicio para completar su función.
En primer lugar, es difícil encontrar el "punto óptimo" en la cantidad de servicios. Demasiados servicios, y sus costos de integración sufren, muy pocos, y sus costos de implementación sufren. Tienes que encontrar un buen equilibrio.
Mi consejo para usted es seguir la metodología de Juval Lowy en el sentido de que debe desglosar sus servicios por áreas de volatilidad o áreas de cambio. Esto le dará su nivel de granularidad. También deberías leer su libro de WCF si puedes.
En cuanto al rendimiento, WCF admitirá inherentemente miles de llamadas por segundo según sus casos de uso y hardware. Servicios de llamadas no es un problema. La plataforma lo apoyará si usted hace su parte. Por ejemplo, use el enlace correcto para el escenario correcto (conductos con nombre para llamar a los servicios en la misma máquina y TCP para llamar a los servicios a través de la máquina cuando sea posible). También debe implementar una porción vertical de la aplicación y realizar pruebas de rendimiento antes de compilar el resto de la aplicación. Esto verificará su arquitectura.