Servicio y componentes son términos que se usan para referirse a los objetos dentro de una aplicación. Si bien tienen cierta relación, no significan exactamente lo mismo. No existe una definición única de estos dos términos, puedes encontrar variantes en otros lugares que son perfectamente válidas.
Todo depende del contexto.
Para empezar cualquier clase u objeto de tu código puede ser un componente o servicio, depende del contexto donde lo estés empleando. Si la clase u objeto es accesible localmente vía un package, ensamblado o módulo, estamos hablando de un componente, en cambio, si el código invocado está en una ubicación física distinta o es ejecutado remotamente, entonces nos referimos a un servicio, esto es una convención.
No todos los servicios son remotos.
Un servicio puede significar que el código se ejecuta remotamente, como es el caso de la arquitectura de micro servicios, Esto no significa que todo servicio debe residir fuera. Un servicio es un objeto especializado en ejecutar una serie de tareas conceptualmente similares, este puede ser invocado local o remotamente. La arquitectura de tus aplicaciones no debería estar interesada en el cómo tus servicios son ejecutados. Desde el punto de vista de tu aplicación, tanto un servicio como un componente deberían lucir y comportarse igual, incluso ser intercambiables.
El cableado servicio-componente.
En cualquier arquitectura se necesitan mecanismos para cablear los distintos objetos del programa, El cemento que da cohesión a tu programa son las entidades, objetos del dominio del problema, kernel compartido o como sea que las llames. Estos son objetos de poco valor en la ejecución, pero alto valor conceptual, dicen el quién y el qué, no especifican el cómo. Otra referencia que puedes encontrar que haga la distinción entre un servicio y un componente, es que los componentes son las interfaces, clases abstractas o superclases, contratos, protocolos, etc. y sus implementaciones ya sean local o remotamente son los servicios.
Casi en todos los contextos son términos intercambiables.
No vas a encontrar una frontera clara cuando te refieras a un componente o a un servicio. Por ejemplo, tienes una clase que recibe una dependencia vía inyección de dependencias en el constructor, la dependencia en cuestión no es un objeto concreto sino una interfaz. Vamos a asignarle un tipo IServicio. Desde el punto de vista de la clase, cualquier implementación de IServicio es un componente porque no interesa el origen, solo que cumpla con el comportamiento esperado. Es posible que la instancia que se reciba sea un cliente Proxy de un webservice SOAP, o la abstracción de un webservice REST, o un componente ejecutado localmente, no importa. En cambio, si ves la implementación concreta de la interfaz, quizá tengas que cambiar el término de componente a servicio dependiendo del objeto mismo.
Autor imagen: Fernando Hernández
- NVL in SQL Server - 2023-11-01
- ¿Que es Cake Build? - 2023-02-22
- #How to fix error: MSB4019: The imported project «Microsoft.Data.Tools.Schema.SqlTasks.targets» was not found - 2023-02-20