What does it mean for two components to be connected?
Notiamo che la nozione di una connessione live tra componenti in due computer, è in realtà solo uno stato in ogni computer, che consente di seguire protocolli per inviare bit l'uno all'altro con intenzioni ed effetti desiderabili.
Tuttavia, da un punto di vista architettonico per quanto riguarda due componenti connessi:
Per comprendere la connessione tra componenti, sottosistemi, servizi, client-server o semplici vecchi oggetti, cerca l'approccio specifico usato da un componente per fare riferimento all'altro.
La direzione del riferimento tra i componenti ci dà la nozione di dipendenza : il referente dipende dall'arbitro.
Esistono molti approcci di riferimento, alcuni dei quali hanno un accoppiamento più stretto rispetto ad altri.
In generale, un riferimento diretto usa il nome dell'altro componente, come in una riga di codice che fa new XYZ() per oggetti, o, l'uso diretto di un noto URL per i servizi e, tale dipendenza diretta è una connessione strettamente accoppiata.
Una dipendenza un po 'più liberamente accoppiata usa un intermediario, anche se ancora direttamente denominato, come una classe factory per oggetti o un localizzatore di servizi per i servizi.
L'accoppiamento ancora più lento è ancora l'approccio di iniezione in cui un parametro fornito durante l'istanziazione (o invocazione) fa riferimento a una capacità astratta piuttosto che a un componente direttamente denominato (ad es. interfaccia per oggetti o servizio astratto per servizi). In genere tali componenti sono considerati dipendenti da un'astrazione piuttosto che da un altro componente (concreto). Le dipendenze effettive tra i componenti concreti sono configurate esternamente ai componenti collegati.
Un altro aspetto della connessione è la mutua dipendenza, in cui un componente è direttamente dipendente su un altro e viceversa (cioè, quest'ultimo è direttamente dipendente dal primo); questo è spesso considerato una cattiva forma in quanto porta a problemi di ordine e problemi nella creazione di istanze e abbattere. (Al fine di evitare le dipendenze cicliche, uno o entrambi i componenti possono utilizzare un approccio di accoppiamento più lento, sebbene questo possa essere un difficile refactoring se tale debito tecnico si è accumulato a lungo.)
Additionally, how does the view of a connection differ from an software architecture perspective and an implementation perspective?
I punti di vista architettonici spesso estrapolano alcuni dettagli per ragionare su alcuni aspetti particolari del sistema. Ad esempio, potremmo parlare di un URL hard coded in un componente che si riferisce a un altro componente. Questa descrizione ignora la ricerca DNS che fornisce un livello di riferimento indiretto.
Un altro modo in cui potrebbero differire è: diciamo che un'implementazione usa un approccio orientato all'iniezione e che si tratta di un approccio alla configurazione basato sui dati, in cui i dati vengono forniti in un file di configurazione. Un simile approccio consente modifiche tra le versioni del software, anche se per una data versione, potremmo prendere un punto di vista architettonico del sistema che ignori la riconfigurazione-abilità e guarda le interazioni di componenti che sappiamo saranno configurati in un certo modo in questa versione.
My current understanding of the concept of "connection" is that two components (or entire systems) have some agreement with each other to exchange data across some interface. This is usually accomplished through initial request from one part, a subsequent process of handshaking, synchronization and eventually some communication session.
Handshaking & l'eventuale trasferimento dei dati che stai descrivendo può essere considerato come protocollo e si applica ai servizi, anche se in un certo senso può essere applicato anche agli oggetti e alle loro API in cui determinate cose devono accadere prima degli altri. Altrettanto rilevanti sono i termini contratto e astrazione, oltre all'interfaccia. Questi sono vari termini usati per descrivere quegli accordi prestabiliti per lo scambio di informazioni usando le interfacce. Queste cose accadono e possono essere descritte su molti livelli, ad es. protocolli wire: TCP, API REST (il significato di un singolo GET o POST vs. raccolta e formazione di stringhe di query), schemi di documenti per risultati di query, ecc ...
Tuttavia, la chiave della nozione di connessione tra componenti è l'approccio a come un componente individua inizialmente e identifica un altro componente, in quanto questo è l'elemento essenziale della formazione della connessione da un punto di vista architettonico, che va al precedente discussione sulla dipendenza e l'accoppiamento, ad es la denominazione diretta rispetto all'individuazione del servizio, l'iniezione o altro, e dal punto di vista dell'implementazione, queste connessioni e tipi di connessioni si manifestano in modi specifici.