0

It is my impression that in software engineering, a connection can mean many things depending on context and the level of abstraction at which some system is considered. I'm surprised no one has asked this before, as I feel that a connection is such a fundamental concept, but also very easy to misunderstand. I want to wash away any misunderstandings I might have, and thus I ask: What does it mean for two components to be connected? Additionally, how does the view of a connection differ from an software architecture perspective and an implementation perspective?

My current understanding of the concept of "connection" is that two components (or entire systems) have some agreement with eachother 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.

  • 2
    Are you trying to define "connection" as new word? Why not use existing words, that better describe what you mean. – Euphoric May 24 '18 at 7:29
  • I am merely asking for a clarification of the concept of "connection" in a software engineering perspective. I am familiar with the intuitive meaning of a "connection". – Tom V M May 24 '18 at 7:34
  • But you said it yourself! Meaning of "connection" is different based on context. We can't enumerate all different contexts in which "connection" has different meaning. – Euphoric May 24 '18 at 7:35
  • I said that it is "my impression" that the meaning of connection means a multitude of things based on context. I was not stating some fact. My question was: "What does it mean for two components to be connected? Additionally, how does the view of a connection differ from an software architecture perspective and an implementation perspective?" – Tom V M May 24 '18 at 7:43
  • The first sentence of your understanding I can agree with, but not the second one. If one class has a reference to another class and calls methods on that other class, I would also say that they have a connection. – Bart van Ingen Schenau May 24 '18 at 8:26
0

What does it mean for two components to be connected?

Let's note that the notion of a live connection between components in two computers, is really just some state held in each computer, that allows protocols to be followed to send bits to each other having desirable intentions and effects.

However, from an architectural point of view regarding two connected components:

In order to understand the connection between components, subsystems, services, client-server, or plain old objects, look to the specific approach used by one component to refer to the other.

The direction of the reference between components gives us the notion of dependency: the referrer is dependent upon the referee.

There are many approaches for reference, some result in tighter coupling than others.

In general, a direct reference uses the name of the other component, as in a line of code doing new XYZ() for objects, or, the direct use of a well-known URL for services, and, such a direct dependency is a tightly coupled connection.

A somewhat more loosely coupled dependency uses an intermediate, though still directly named, such as a factory class for objects, or service locator for services.

Even looser coupling still is the injection approach where a parameter that was supplied during instantiation (or invocation) refers to an abstract capability rather than a directly named component (e.g. interface for objects or abstract service for services).  Typically such components are seen to have a dependency on an abstraction rather than on another (concrete) component.  The actual dependencies between concrete components are configured externally to the connected components.

Another aspect of connection is mutual dependency, where one component is directly dependent upon another and vice versa (i.e. the latter is directly dependent upon the former); this is often considered bad form as it leads to ordering issues and problems in instantiation and tear down.  (In order to avoid cyclic dependencies, one or both components can use an approach of looser coupling, though this can be a difficult refactoring if such technical debt has been accruing for long.)

Additionally, how does the view of a connection differ from an software architecture perspective and an implementation perspective?

Architectural points of view often abstract out certain details in order to reason about some particular aspect of the system.  For example, we might speak of a hard coded URL in one component referring to another component.  This description ignores the DNS lookup that provides a level of indirection.

Another way they might differ is: Let's say an implementation uses an injection oriented approach, and that it is a data driven approach to configuration, where the data is supplied in a configuration file.  Such an approach allows for changes between versions of the software, though for any given version, we might take an architectural point of view of the system that ignores the reconfigure-ability and looks at the interactions of components we know will be configured a certain way in this version.

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.

The handshaking & eventual transfer of data you're describing can be thought of as protocol, and applies to services, though in some sense can also be applied to objects and their APIs where certain things have to happen before others.  Also relevant are the terms contract and abstraction, in addition to interface.  These are various terms used to describe those prearranged agreements to exchange information using interfaces.  These things happen and can be described many levels, e.g. wire protocols: TCP, REST APIs (the meaning of a single GET or POST vs. the collection and formation of query strings), document schemas for query results, etc...

Still, key to the notion of connection between components is the approach to how one component initially locates and identifies another component, as this is the essential element of the formation of connection from an architectural point of view, which goes to the above discussion on dependency and coupling, e.g. direct naming vs. service locator, vs. injection, or other, and from the implementation point of view, these connections and types of connections are manifest in specific ways.

0

There are some major vagaries in your question that require some disambiguation:

  • Definition of component: there are different types of components that have their own concept of connections and interdependencies
    • External components (aka Services) -- whether we are talking micro-services or monolithic ones, the services have some sort of wire protocol between them. That wire protocol can be a REST API, a message queue, or even a proprietary data protocol
    • Internal components -- this is simply a way of organizing code so that you reduce code coupling and isolate unrelated parts of the application from each other. Most often they call each other directly
  • Connection or Dependency? often in computer science, the concept of a connection is synonymous with a wire protocol. I don't want to speak in absolutes here, but I can't come up with any examples where connection does not mean a wire protocol is involved. The more generic concept is a dependency.

The specifics of your answer depend on your audience and what scope you are referring to.

What does it mean for two components to be connected?

The correct terminology is that one component has a dependency on another component. The consumer component (the one with the dependency) will make calls to the producer component (the component depended on). The producer component will have a defined interface that is shared publicly. The consumer component only interacts with the interface, allowing the implementation to be replaced without breaking the system.

Additionally, how does the view of a connection differ from an software architecture perspective and an implementation perspective?

The concept of a dependency is an architectural concern. The concept of a connection (i.e. wire protocol) is an implementation concern. Connections are not always needed (i.e. the internal context).

I think you are merging concepts in your mind that really are separate things and that is what is confusing.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.