Connectors
Interacciones con significado
Un connector representa un mecanismo o relación arquitectónica que media interacción entre components. Permite explicar cómo colaboran las partes y qué propiedades tiene esa colaboración. No equivale únicamente a conexión de red ni a una flecha sin significado.
En Commerce, Orders y Payments realizan responsabilidades distintas. Una llamada local, un intercambio HTTP o un canal de mensajes puede mediar su colaboración. El connector describe esa interacción; no reemplaza la responsabilidad de decidir qué constituye una autorización válida.
Usamos el término en el sentido arquitectónico amplio de interacción, declarando la vista y el alcance considerados. Una notación concreta puede reservar connector para una relación más limitada. La convención del Atlas no pretende convertir todos esos usos en una definición universal.
Garlan y Shaw presentan un marco con components y connectors, incluyendo interacciones tan distintas como llamadas de procedimiento, difusión de eventos, consultas a datos y pipes. Esa diversidad permite tratar la colaboración como parte del diseño, en vez de limitarla a cables o protocolos. An Introduction to Software Architecture, sección 3.
Components y connectors
Components realizan responsabilidades o mantienen estado relevante; connectors median interacción entre ellos. La distinción ayuda a separar qué hace cada participante de las condiciones bajo las que colaboran. No afirma que su implementación sea siempre físicamente separable.
Un broker puede ser un component con responsabilidades de almacenamiento y enrutamiento en una vista operativa. En una vista de colaboración, un canal de mensajes mediado por ese broker puede representarse como connector entre productores y consumidores. El mismo mecanismo concreto participa en modelos con preguntas diferentes.
Algo similar ocurre con datos compartidos. Una vista puede mostrar el almacenamiento como component y accesos como connectors. Otra puede destacar una relación de intercambio mediante repositorio común. Hay que declarar la interpretación, especialmente antes de concluir quién tiene autoridad sobre los datos.
Una relación de importación entre módulos no se vuelve connector de runtime por dibujar una flecha. dependency-structure analiza obligaciones y conocimiento entre unidades. En una vista de ejecución importa qué interacción ocurre realmente; no toda dependencia necesita representarse como intercambio.
Mecanismos posibles
Una llamada de procedimiento transfiere control dentro del entorno considerado. Una interacción HTTP intercambia representaciones mediante peticiones, respuestas o callbacks. Un canal de mensajes puede separar envío, entrega y procesamiento. Un stream puede conservar registros para múltiples lectores con posiciones propias.
Un pipe permite transferir datos entre etapas. El acceso a datos compartidos media colaboración mediante lectura y modificación de estado. Una conexión de base de datos puede integrar un subsistema con su almacenamiento, pero mencionar la conexión no explica qué transacciones, permisos o expectativas acompañan ese acceso.
Estos ejemplos no forman una taxonomía cerrada. El nivel adecuado depende de las consecuencias que interesa analizar. Enumerar sockets individuales puede ser innecesario para revisar el protocolo de autorización, y describir únicamente «integración» puede ocultar esperas y puntos de confirmación relevantes.
Connector y Communication
communication es el Decision Axis que pregunta cómo intercambiamos información: local o remoto, síncrono o asíncrono, directo o mediado, entre otras dimensiones. Connector representa parte de una respuesta concreta en una vista arquitectónica. La pregunta analítica y el elemento del modelo cumplen papeles diferentes.
Decidir que Orders envía una solicitud y continúa antes de la autorización no identifica por sí solo el canal, la persistencia ni el mecanismo para recuperar el resultado. Un connector definido puede concretar esas condiciones. A su vez, comparar connectors permite revisar si la respuesta elegida en Communication sigue siendo adecuada.
No hace falta duplicar todas las dimensiones del eje dentro de cada dibujo. Hay que recuperar aquellas que condicionan la colaboración observada. La representación debe permitir distinguir una decisión explícita de un supuesto todavía sin verificar.
La semántica importa más que el nombre
Dos intercambios HTTP pueden implicar continuaciones distintas. Una petición cuya respuesta comunica el resultado final no funciona como otra que devuelve aceptación y publica después un callback. Ambos usan HTTP, pero cambian correlación, espera y tratamiento de resultados tardíos.
| Aspecto | Pregunta para Orders y Payments |
|---|---|
| Dirección y continuación | ¿Quién inicia y qué resultado permite avanzar? |
| Confirmación y durabilidad | ¿Qué se conserva cuando se confirma recepción? |
| Orden y duplicados | ¿Qué secuencias admite el receptor y qué puede repetirse? |
| Fallos | ¿Qué sabe Orders cuando no recibe respuesta? |
| Protocolo y obligaciones | ¿Qué representaciones y expectativas deben coincidir? |
El SEI destaca que los connectors C&C tienen semántica propia, y que representar solamente asociaciones puede ocultarla. Su ejemplo de un pipe lleno muestra cómo el comportamiento del mecanismo condiciona a los components participantes. No basta identificar las dos puntas. Documenting Component and Connector Views with UML 2.0, sección 4.3.
La presencia de un broker no garantiza finalización asíncrona del negocio. Orders podría publicar y esperar inmediatamente una respuesta antes de continuar. Tampoco una confirmación del broker demuestra que Payments haya autorizado el pago. La semántica necesita indicar qué hecho confirma cada respuesta.
Connector e interface
interfaces describe qué expone deliberadamente un elemento. Connector describe cómo ocurre la interacción entre participantes. En el ejemplo, Payments ofrece la capacidad AuthorizePayment; Orders puede usarla mediante un mecanismo local o remoto.
Como ayuda de razonamiento del Atlas, distinguimos superficie expuesta, mecanismo de interacción y contrato de expectativas. El contrato puede precisar significado, resultados, errores y compatibilidad. La literatura puede incluir todo ello dentro de interface o asociarlo al connector; nuestra distinción busca aclarar preguntas, no imponer capas universales.
Una interface comparable puede realizarse mediante distintos connectors, pero la sustitución necesita revisar obligaciones. Cambiar una llamada local por mensajes suele cambiar cómo se observa el resultado y cuándo puede continuar el consumidor. Conservar nombre y parámetros no prueba equivalencia de comportamiento.
Commerce: tres variantes
En la variante local, Orders llama a una operación de Payments dentro del mismo proceso. Compartir memoria y runtime permite ciertas formas de colaboración, pero también posibilita interferencia y acceso accidental a internals. Una excepción no demuestra que no haya ocurrido ningún efecto.
En la variante HTTP, Orders envía una petición a Payments. La representación cruza un límite remoto; puede perderse la respuesta después de autorizar. Es necesario definir qué significa el resultado, cómo identificar la operación y qué hacer ante incertidumbre.
En la variante de mensajes, Orders envía una solicitud de autorización y recibe posteriormente un resultado correlacionado. Aceptar el mensaje y autorizar son hechos diferentes. Las garantías de entrega, duplicados y retención condicionan recuperación y expectativas del flujo.
Las responsabilidades Orders y Payments pueden mantenerse conceptualmente similares en las tres variantes. También puede conservarse la regla de que Orders no modifique el estado privado de Payments. Cambian características de comunicación y fallos; no son tres implementaciones automáticamente intercambiables del mismo compromiso temporal.
Fallos y confiabilidad
Un connector remoto introduce condiciones que no se resuelven escondiendo la red bajo un método. timeout limita una espera observada, sin demostrar ausencia de efecto remoto. retry requiere analizar si repetir es seguro. circuit-breaker regula admisión cuando una colaboración falla, sin garantizar recuperación de operaciones anteriores.
En una interacción con mensajes, delivery-guarantees permite distinguir garantías de entrega y resultados de procesamiento. El connector puede conservar una solicitud y aun necesitar tratamiento de duplicados o resultados inciertos. No corresponde atribuir exactly-once de negocio al nombre de una tecnología.
También los mecanismos locales tienen fallos y costos. Compartir una cola en memoria exige decidir qué ocurre si se llena o el proceso termina. Compartir datos introduce contención y obligaciones sobre autoridad. «Local» reduce ciertas diferencias, no elimina toda necesidad de razonar sobre comportamiento.
Relación con profiles y límites
architecture-profile reúne decisiones sobre varias dimensiones. monolith suele usar más colaboración local dentro de su unidad; microservices introduce colaboraciones remotas entre servicios. Esas tendencias no definen todo el perfil ni prohíben interacciones externas en un monolito.
En event-driven-architecture, los eventos adquieren centralidad arquitectónica. Brokers, streams o dispatchers pueden realizar sus intercambios; el profile no se reduce al connector elegido. Los compromisos sobre responsabilidades, autoridad y evolución siguen importando.
Un connector cruza o participa en boundaries concretas. El mecanismo debe respetar qué está permitido y qué se oculta. Una llamada a una operación pública y una escritura directa en tablas privadas no preservan necesariamente el mismo límite aunque ambas logren un resultado visible.
Revisar una interacción
Precisar participantes, mecanismo, hechos confirmados, continuaciones y comportamiento ante fallos. Después revisar cómo esas condiciones afectan responsabilidades y resultados de Commerce. Así el connector aporta evidencia arquitectónica, en vez de una etiqueta tecnológica que deja intactas las preguntas importantes.