Component and Connector issueshttps://community.opengroup.org/archimate-community/workgroups/component-and-connector/-/issues2021-09-12T09:45:23Zhttps://community.opengroup.org/archimate-community/workgroups/component-and-connector/-/issues/6ArchiMate constructs: Representing APIs2021-09-12T09:45:23ZBorjan CaceArchiMate constructs: Representing APIs## Representing APIs
The meta-model for API interconnections:
![](https://community.opengroup.org/archimate-user-community/workgroups/component-and-connector/-/raw/master/doc_images/API_meta_simple.png)
Two ArchiMate elements are suit...## Representing APIs
The meta-model for API interconnections:
![](https://community.opengroup.org/archimate-user-community/workgroups/component-and-connector/-/raw/master/doc_images/API_meta_simple.png)
Two ArchiMate elements are suitable for representing an API interconnection: Application Service and Application Interface. There is only one possibility for attaching the providing component (the element Application Component) to the “connector”; we have to attach:
- the _Application Interface_ element with the _Composition_ relationship
- the _Application Service_ element with the _Realization_ relationship
We have two options for attaching the consuming component, disregarding which ArchiMate element represents the “connector”; the possible ArchiMate relations are:
- _Triggering_
- _Serving_
This leads us to four options in representing API interconnections, visualized here below:
![](https://community.opengroup.org/archimate-user-community/workgroups/component-and-connector/-/raw/master/doc_images/API-all.png)
We shall not base or discussions of PROS and CONS of these options. Instead, we shall elaborate on the use of _Application Interface_ vs _Application Service_ and on the use of _Triggering_ vs _Serving_.
#### Using Application Interface
**PROS**
- Reflects better the fact that our knowledge of the interconnection is limited to awareness of the interface.
**CONS**
- Application Interface has to be attached to the providing component with the Composition relation. That may appear strange; what we want to convey is that the Interface element represents the interface to a specific web service, and not to a component (which may be exposing more than one API).
#### Using Application Service
**PROS**
- Associates intuitively the connector with the provided functionality, better than Application Interface
**CONS**
- May cause confusion when combined with services that are not exposed by means of APIs.
#### Using Triggering
**PROS**
- Reflects better the limited knowledge of the interaction between the components. We know that the execution is being invoked (triggered!) but we do not know where the actual service is being delivered.
**CONS**
- Triggering may appear counterintuitive
#### Using Serving
**PROS**
- Reflects correctly that the request of the invoking application is satisfied,
**CONS**
- May intuitively imply that the actual service is always being delivered to the component that invokes the API.https://community.opengroup.org/archimate-community/workgroups/component-and-connector/-/issues/5Terminology: use of the terms: “model” and “view”2021-08-15T12:06:07ZBorjan CaceTerminology: use of the terms: “model” and “view”My use of the terms: “model” and “view” is not in de spirit of ISO/IEC/IEEE 42010, and that should be noted. I will try to describe the issue and the reason why I will not attempt (at least for the time being) to be more in line with ISO...My use of the terms: “model” and “view” is not in de spirit of ISO/IEC/IEEE 42010, and that should be noted. I will try to describe the issue and the reason why I will not attempt (at least for the time being) to be more in line with ISO-42010 (IEEE-1471).
In ISO 42010, a view is a set of architectural models.
> “An Architecture View in an Architecture Description expresses the Architecture of the System of Interest from the perspective of one or more Stakeholders to address specific Concerns, using the conventions established by its viewpoint. An Architecture View consists of one or more Architecture Models.”
quoted from http://www.iso-architecture.org/ieee-1471/cm/
A model, in its turn, is a coherent set of architectural elements. To put it simply, the term model has a formal meaning, while the term view denotes a collection of models (not formalized, but conformant to a Viewpoint).
This contrasts the use of the terms in Archi, the favorite tool for most of us. In Archi, views are collections of elements from a model (i.e., not all elements from the model are included, and some may be included more than once).
As I understand it, ISO 42010 shifts the terminology of Architecture Description: what has been called a view, is now being called a model. For example, in “Software Architecture in Practice”, Third Edition - by Len Bass, Paul Clements, and Rick Kazman of SEI, we can read: “A view is a representation of a coherent set of architectural elements, as written by and read by system stakeholders.” (page 22)
The C&C views are defined accordingly.
The definition from “Software Architecture in Practice” is in line with the original vocabulary of the people who gave form to the idea of “architecture views” like Kruchten - check his paper on 4+1 views from 1995 (... To describe a software architecture, we use a model composed of multiple views or perspectives ...). At the time, as it appears, the word “model” didn’t have a specific meaning in the context of Architecture Description.
To sum it up: a change from “view terminology” to “model terminology” has taken place.
That is not something I want to go into it, but I felt I have to mention it to avoid confusion.
Entering a thorough discussion in the context of this effort (C&C in ArchiMate) would not bring much, I believe. My preference is to deal with the issue pragmatically.
I propose we continue to use the term “view” in the way it is defined in “Software Architecture in Practice” and used in Archi. We need a term that can indicate a subset of a model; let it be “view”. If there are better ideas, I would be glad to hear them. Formally, the use of the term in Archi is probably not incorrect: an ISO 42010 architecture view may consist of only one model, and not all elements of that model need to be included.Jean-Baptiste SarrodieJean-Baptiste Sarrodiehttps://community.opengroup.org/archimate-community/workgroups/component-and-connector/-/issues/4ArchiMate constructs: representing point-to-point and publish-subscribe messa...2023-10-04T13:10:35ZBorjan CaceArchiMate constructs: representing point-to-point and publish-subscribe messaging
## Representing data-oriented interconnections
We have identified *_three alternative ArchiMate constructs_* for representing a data-oriented interconnection. Our preference is to use a single ArchiMate element to model one real-life ...
## Representing data-oriented interconnections
We have identified *_three alternative ArchiMate constructs_* for representing a data-oriented interconnection. Our preference is to use a single ArchiMate element to model one real-life entity which determines the interconnection. The alternative representations for that entity (and its relationships) are the following:
* Use a Technology Service element and use Flow relationships to attach Application Components. The direction of the flow denotes the flow of data.
* Use a Data Object element and use Access relationships to attach Application Components. Components can either read, write or read-and-write data (the Access type).
* Use an Artifact element and use Access relationships to attach Application Components. Components can either read, write or read-and-write data (the Access type).
### Representing interconnections realized through point-to-point and publish-subscribe messaging
The meta-models for point-to-point and publish-subscribe messaging:
![](https://community.opengroup.org/archimate-user-community/workgroups/component-and-connector/-/raw/master/doc_images/P2P_pub-sub_meta_simple.png)
The element representing the object that holds messages (_queue_ or _topic_) will be stereotyped with \<\<queue>> or \<\<topic>> respectively, and the name of the element will be the name of the object it represents.
We have noticed that the _pros_ and _cons_ of a representation do not differ either we are modeling queues or topics, so we shall discuss them together.
#### Using Technology Service elements to represent queues and topics
In this representation, the Flow relationship denotes the role of the attached component. The message producer and the message publisher are attached as data sources, while the message consumer and the message subscribers are attached as data sinks.
![](https://community.opengroup.org/archimate-user-community/workgroups/component-and-connector/-/raw/master/doc_images/data-conn/QT-Technology_Service.png)
**PROS**
* The Technology Service element representing the _queue / topic_ emphasizes the use of additional services of a messaging system.
**CONS**
* In this construct, the _Technology Service_ element is used to denote the service associated with a specific object (a single queue or a single topic), which may be misleading. Implicitly, the actual technology service is being provided by a messaging system (middleware) and it is common to view such services more broadly, like "queuing services" or "publish/subscribe" services.
* The view includes an element from the ArchiMate _Technology Layer_ and therefore does not conform to the Application Cooperation viewpoint.
* * *
#### Using Data Object elements to represent queues and topics
The Access relationship is used for all attachments. The message producer and the message publisher use the _write_ access, while the message consumer and the message subscribers use the _read_ access.
![](https://community.opengroup.org/archimate-user-community/workgroups/component-and-connector/-/raw/master/doc_images/data-conn/QT-Data_Object.png)
**PROS**
* The use of the Data Object element emphasizes messages: producers / publishers are creating messages (data objects) which are subsequently read by consumer / subscribers.
* The view conforms to the Application Cooperation viewpoint.
**CONS**
* The use of the Data Object element could be misleading as that element is not intended to represent a queue or topic (an entity supporting the exchange of messages) but rather messages as such.
#### Using Artifact elements to represent queues and topics
The Access relationship is used for all attachments. The message producer and the message publisher use the _write_ access, while the message consumer and the message subscribers use the _read_ access.
![](https://community.opengroup.org/archimate-user-community/workgroups/component-and-connector/-/raw/master/doc_images/data-conn/QT-Artifact.png)
**PROS**
* The Artefact element is likely the most appropriate choice to represent _queues_ and _topics_. Queues and topics are comparable to files and database tables.
**CONS**
* The view includes an element from the ArchiMate _Technology Layer_ and therefore does not conform to the Application Cooperation viewpoint.Borjan CaceBorjan Cacehttps://community.opengroup.org/archimate-community/workgroups/component-and-connector/-/issues/3ArchiMate constructs: principles, assumptions, and constraints2021-09-02T09:53:03ZBorjan CaceArchiMate constructs: principles, assumptions, and constraints## Principles, assumptions, and constraints
* * *
- **What is our concrete goal?**
We want to introduce guidelines for modeling the observed runtime structure of application landscapes in terms of components and connectors. For clarit...## Principles, assumptions, and constraints
* * *
- **What is our concrete goal?**
We want to introduce guidelines for modeling the observed runtime structure of application landscapes in terms of components and connectors. For clarity and expressiveness, those models should stay close to the observed reality; this is to say that the models should be understandable on the operational level and not only to enterprise architects.
* * *
- **What is our approach?**
As stated before, we first define non-ArchiMate meta-models that describe each interconnection option (the connector type) separately. The objective is to determine which real-life entities and concepts need to be modeled to appropriately represent interconnections. In doing that we also consider limitations in observing the actual application landscape: the model should include only the information that can be obtained without major efforts and that can be maintained.
After that, we elaborate the ArchiMate modeling options for each such meta-model (connector type). The elements from our meta-models are represented (one-to-one) with ArchiMate elements.
For specifically discussing the C&C views, we use illustrative examples (“example models”) based on the respective meta-model.
_For clarity reasons, example models are intentionally reduced to include only the entities that may be a part of a C&C view. A separate section of the definitive document will describe how to include other entities (that in the real-world practice are also expected to be a part of the model)._
We aim to produce ArchiMate models suitable for creating C&C views without model transformations – one should be able to create such views simply by excluding unnecessary elements and relationships.
![](https://community.opengroup.org/archimate-user-community/workgroups/component-and-connector/-/raw/master/process.png)
* * *
- **Which ArchiMate Layer?**
It is self-evident that components and connectors should be represented in the Application Layer as much as possible.
* * *
- **How to represent "components"?**
It is equally evident that we should use the Application Component element to represent components.
* * *
- **Structural vs Behavioral elements?**
Regarding the use of structural vs. behavioral elements of ArchiMate for representing interconnections:
Our model shows the structure of an application landscape; therefore, Intuitively, one may expect that ArchiMate representations should include only the structural elements. However, that would make the ArchiMate modeling less effective. Although we are dealing with interconnections (which stand for a structure), interconnections are there for a purpose, namely, to facilitate interactions. In the C&C approach, a connector primarily describes the behavior of the interaction it mediates. Accordingly, the preference is to use an ArchiMate behavioral element or an active structure element, if possible (?)
* * *
- **C&C views are broadly defined. How to get most of it in our context?**
C&C views are broadly defined so that they may be used to show the architecture of any system. The first step in using the approach of “Views and Beyond” should be narrowing down the available choices to our concrete needs. As outlined in the preceding paragraphs, we intend to represent application components as they are identified by observing their managed connections (or, in other words, the potential interactions with other application components). We also intend to have connectors representing the mainstream interaction mechanisms. This leads to the following reductions:
- We will not use C&C ports. The abstraction “port” is introduced to specify different attachment points on the component element. That has no meaning in our case – we can assume that each attachment has its own, exclusive port.
- The semantics of C&C roles will be assigned to attachments (relation between components and connectors). The ArchiMate relationship will then denote the role. That can be done either by using different relation types or, in cases where we can have only two roles, by using the direction of the relation. This is illustrated with the following example that shows how to represent three applications interacting via a topic.
![](https://community.opengroup.org/archimate-user-community/workgroups/component-and-connector/-/raw/master/principles_pub-sub_example.png)
* * *
- **In general, language idioms evolve over time through usage practices. How would it be ensured that the proposed constructs representing connectors are recognized as (intended) idioms?**
To achieve that we need to explicitly specify what the used elements and relations are representing. In other words, we shall use Specializations of ArchiMate concepts. All elements having a specific meaning will be denoted with a stereotype (UML guillemet notation) that would clearly indicate that meaning.
* * *
- **Should we visualize connectors with connecting lines or with "in-between" boxes?**
C&C views may visualize connectors as a line or as a box (showing connectors in a graph either by nodes or by edges). We assume that a box representation would be more suitable for most uses. We will thus primarily elaborate on how to represent connectors with ArchiMate elements (rather than with ArchiMate relationships). As in some cases one would prefer showing a connector with a line (for example, when one wants to focus on dependencies between applications in general) we will also discuss direct ArchiMate-relationships between interacting components.
* * *
- **Should we uniformly represent all interconnections?**
API interconnections are most commonly service-oriented, while all others are data-oriented. Accordingly, representing API-connectors differently than the rest would improve the expressiveness. There is not much value in striving for uniformity and representing all connectors in the same way.
* * *
- **Can our model include more information (extending C&C), and, if yes, how to deal with it?**
- The model representing the observed reality should include additional information if it is available. It may therefore also include additional elements, not only those representing components and connectors. Moreover, the model is intended to be a departing point for further modeling, therefore it should be accommodating for more information. However, the semantics of C&C must be preserved. This is to say, for example, that additional elements shouldn’t be in-between a component and a connector. In other words, the direct relation between components and connectors (that bears the semantics) must be preserved.
- Not all information pertinent to application interconnection is suitable for ArchiMate representation, nor we need to have it stored in a modeling tool. (for example, some details like OpenApi or WSDL definitions) Instead, we should use links to switch from a modeling tool (ArchiMate) to another information source.
- We may use properties to convey more information.https://community.opengroup.org/archimate-community/workgroups/component-and-connector/-/issues/2What will be represented in our ArchiMate model?2021-09-12T17:28:40ZBorjan CaceWhat will be represented in our ArchiMate model?
As indicated in the ["motivation" file](https://community.opengroup.org/archimate-user-community/workgroups/component-and-connector/-/blob/master/motivation.md), we need to start with agreeing on what we will be representing in ArchiMa...
As indicated in the ["motivation" file](https://community.opengroup.org/archimate-user-community/workgroups/component-and-connector/-/blob/master/motivation.md), we need to start with agreeing on what we will be representing in ArchiMate. In essence, we need to explicate how we look upon interconnections in application landscapes: what do we see as “components” and what are “connectors”?
To express our views and to provide a rationale for the choices we have made, we have taken the following three steps:
- **_Step 1:_ Categorize interconnections ("connectors") into types**
Our objective is to introduce guidelines for the modeling of "as is" application landscapes in terms of components and connectors. For clarity and expressiveness, the models created in accordance with those guidelines should stay close to the observed reality. That is to say that the models should be understandable on the operational level and not only to enterprise architects.
More specifically, the ArchiMate constructs should not be targeting “connectors” in general, but rather the concrete types of interconnections (connector types), as they exist in practice.
- **_Step 2:_ Clarify what do components in our C&C views represent**
Our model should be reflecting the real-life topology of the application landscape. That implies that the components have to be identified from the perspective of IT operations when dealing with interconnections. In other words, the managed interconnections demarcate application components.
- **_Step 3:_ Decide which entities need to be represented for each interconnection type.**
We aim to use ArchiMate elements as direct representations of real-life entities (like queues and topics) or easily recognizable concepts established in the operational practice. After categorizing interconnections, we have to choose which real-life entities and concepts should be representing them.
We shall formulate our choices in informal, elementary non-ArchiMate meta-models describing each interconnection option (the connector type).
We shall keep our C&C ArchiMate constructs in conformance with those meta-model: the elements from our meta-models are represented (one-to-one) with ArchiMate elements. That direct representation will be emphasized through ArchiMate Specialization.
# Step 1: Categorizing interconnections:
Let us categorize interconnections by using integration styles, as described in the EAPJ article [“Accurate Insights into the Runtime Topology of Application Landscapes.”](https://lnkd.in/gDNBZsk). We would be thus using the (slightly adjusted) list of patterns defined by [ G. Hohpe and B. Woolf in Enterprise Integration Patterns (Addison-Wesley, 2003)](https://www.enterpriseintegrationpatterns.com/). Adjustments are needed to reflect the nowadays practices and product offerings.
> _Picking appropriate connector abstractions is often one of the most difficult jobs of producing effective architectural documentation using the C&C viewtype. If the connector abstractions are too low-level, then the view will become cluttered both with connectors and with components that are actually logically part of the connector mechanism (see below). If the connector abstractions are too high-level, it may be difficult to map from the C&C views to more implementation-oriented views. While deciding how abstract to make connectors is a matter of taste and the needs of architectural analysis, documentation that one finds for today’s systems tends to err on the side of being too low-level._ (**from**: [Documenting Software Architectures: Views and Beyond, Second Edition](https://resources.sei.cmu.edu/library/asset-view.cfm?assetID=30386))
> **_Request-Response (Remote Procedure Invocation)_**
>
> An application exposes interfaces of some of its procedures so that they can be invoked via network endpoints, and other applications can invoke those to run behavior and exchange data. The interaction takes place in real-time and synchronously.
> By far most solutions nowadays are based on the HTTP protocol (SOAP, gRPC and REST-like web services/APIs). The use of web services is fully supported in all application platforms (Java, .NET, Python, etc.) and requires no intermediate components.
>
> **_Point-to-point Messaging (Queuing)_**
>
> An application sends a message to a receiving application via a queue. An intermediary messaging system facilitates queuing and ensures that the message is made available to the recipient.
>
> **_Publish/Subscribe_**
>
> An application publishes an event to an intermediary messaging system using a message that addresses a “topic.” One or more other applications are subscribed to this topic and are notified of the event.
>
> **_File Exchange_**
>
> Files are moved from one file location to another; alternatively, a “producing” application creates a file in a shared directory. Most commonly, receiving applications monitor the file location for changes.
>
> **_Shared Database_**
>
> Multiple applications share the same physical database.
>
>(**from**: [Accurate Insights into the Runtime Topology of Application Landscapes](https://eapj.org/accurate-insights-into-the-runtime-topology-of-application-landscapes/))
In C&C terms, we would be aiming at the following "connectors":
| Connector Type (supported interactions) | Associated real-life Entity | Possible roles that can be taken by an attached component |
| --- | ----------- | ----------- |
| **API** (Remote Procedure Invocation Style): Synchronous APIs (web services), possibly all based on HTTP. Encompasses WSDL/SOAP services, REST-like APIs, gRPC, etc. | Web service (API) or access point | Service provider (1), Service consumer (multiple)|
|**Queuing** (Point-to-point messaging via queues)|Queue|Message producer (multiple), Message consumer (1) |
|**Topic** (Publish/subscribe)|Topic|Publisher (multiple), Subscriber (multiple) |
|**File Exchange**: FTP file transfers, shared directories|Directory or something else (?)|Source, Sink, Source&Sink (all multiple) |
|**Shared Database**|Database| Source, Sink, Source&Sink (all multiple) |
|**Other**: Any other integration option (presumably a “legacy”)|| Source, Sink, Source&Sink (all multiple) |
* * *
# Step 2: What do Application Components represent?
Obviously, components in our model should be representing recognizable real-life application components. However, this is not as straight-forward as it may appear and several issues require a discussion and a kind of consensus:
- When describing "as is" application landscapes in terms of components and connectors, the managed interconnections demarcate the components. By saying "managed" we emphasize that not all interconnections are visible; there may be smaller grained application components embodied in larger components but not visible as such. In other words, some compositions of application components may not be visible in our views. Consequently, our model is intermixing components that are otherwise perceived as being at a different composition level.
- To be complete, our model needs to show all interconnections which also includes those that support interactions across the organization's boundaries. Consequently, we need to show how the external applications are connected which also implies that we should show those external applications. If an internal application consumes an API provided by another organization, there is no knowledge about the component that exposes that API. The agreements about such interactions are made about the provided and consumed services, and the actual components of the other party are completely out of sight.
- A similar situation arises with microservices, where the premise is that one component provides one service only. Consequently, some stakeholders talk only about services and disregard the providing components completely.
- How to deal with integration brokers, ESBs and other application components that provide for application integration,B2B integration and orchestration of business processes? Products like Dell Boomi, Mule ESB, Azure Logic Apps, BizTalk … all provide “connectors”, a kind of advanced fabric that enable easy integration. It is likely the most appropriate to model runtime instances of these products as application components. The "connectors" of those products are oriented towards providing the functional integration (data model transformations and alike) and the concrete interconnections are based on some standard integration mechanism covered with our categorization.
To summarize (through examples), application components in **_our_** model (and C&C views) could represent:
- _**An enterprise application component**_ deployed either on-premises or in a managed cloud infrastructure environment (IaaS, PaaS), as identified by its business owner. In most organizations, these components will have the highest presence;
- _**A SaaS application**_ - Although we know that SaaS solutions are not monoliths, their inner structure is beyond the knowledge and concern of the organization using it;
- _**An external application**_ authorized to interact with the enterprise’s applications by providing or consuming web services, being message queue producer or consumer … (external means that it is owned by another organization).
- _**An entire (partner) organization**_ - For example, enterprise publishes selected APIs to partners – often we do not know which concrete application components consume exposed services and we equally don’t care – it is outside of the enterprise, beyond our concern … In this case, when specifying external components, we may aggregate all these to one (substitute) component;
- _**An instance of an integration/B2B broker, ESB**_ or alike.
- _**All anonymous consumers of an API with unrestricted access**_ - One component stands for multiple unidentifiable applications)
- _**A uniformly managed set of handheld or browser-based applications or information kiosk applications**_ - One component stands for multiple runtime instances of an application;
- ...
* * *
* * *
# Step 3: Which entities should be included?
Obviously, our model needs to include elements that stand for components and connectors. We have discussed what we intend to represent with component elements; in this section, we shall elaborate on what the connector element of each specific type is going to represent.
_Later, in the chapter_ "**_Relation with other Viewpoints_**"_, we shall discuss the options for extending our meta-models with information that would be of use in other views. The_ **_‘rudimentary’ meta-models laid down in this section_** _will then be extended with the representations of other real-life entities. Here we assume that one would be retrieving the information over those entities in conjunction with the information about components and connectors. And, in addition, we shall elaborate on options for combining the derived ArchiMate models with other ArchiMate based information._
## Request-Response (API) interconnections
Here we deal with remote procedure invocations:
> An application exposes interfaces of some of its procedures so that they can be invoked via network endpoints, and other applications can invoke those to run behavior and exchange data. The interaction takes place in real-time and synchronously.
The API-functionality (or service) is thus central to API interconnections; therefore, it is natural to have connector elements representing that service. However, from the perspective of IT Operations, we cannot claim that we have any information about the functionality, except the interface to it - the API. And, with "interface", we do not mean an endpoint, but the interface as it is exposed by the providing application. (There could be multiple endpoints exposing the same service of a component – that is discussed in the chapter _Relation with other Viewpoints_).
The meta-model:
![API meta-model](https://community.opengroup.org/archimate-user-community/workgroups/component-and-connector/-/raw/master/doc_images/API_meta_simple.png)
* * *
* * *
## Interconnections realized through point-to-point and publish-subscribe messaging
An intermediate messaging system (a message broker) provides the technique for asynchronous message exchange. The message transmission is reliable - the reliability is ensured by persisting messages in a message store.
In point-to-point messaging, messages are exchanged via queues: one application produces messages and the other one consumes them. In publish-subscribe messaging, messages are exchanged via topics: one application publishes a message to a topic, and the subscribed applications receive notifications.
In our model we shall be representing the real-life objects queues and topics; those entities are determinative for their respective type of interconnection.
That leads us to the following meta-models for point-to-point and publish-subscribe messaging.
![Messaging meta-models](https://community.opengroup.org/archimate-user-community/workgroups/component-and-connector/-/raw/master/doc_images/P2P_pub-sub_meta_simple.png)
* * *
* * *
## All other (data-oriented) interconnections
This concerns interconnections based on integration patterns _**File Exchange**_, _**Shared Database**_, and all other data-oriented integration options. Those interconnections are not supported by integration mechanisms that are available in application platforms (unlike it is the case with APIs, point-to-point messaging and pub/sub messaging). Apart from that, there is very little in common among them.
However, we discuss their modeling option jointly because we focus on the direction of the data flow: interconnected applications can either be a source or a sink of data, or both. And that part we can represent with a single meta model. What will be different is the “connector” element; it has to stand for the entity that is determinative for the interconnection type being modeled, and they are obviously different.
The challenge is to decide which real-life entity or concept to represent in the model. For some types of data-oriented interconnections it is straightforward and for some other it is problematic. We propose the following for some (this list is by no means exhaustive):
- For **_Shared Databases_**, represent the data table that is being shared
- **_File Exchange_**:
| Exchange Mechanism| Represented real-life entity/concept/... |
| ------ | ------ |
| Exchange via a shared directory | shared directory |
| Exchange via a file hosting service (DropBox, Google Drive …) | hosting service |
| Exchange via an FTP server | FTP service <br/>or <br/>exchange directory where the files are collected|
Compared to APIs and messaging, we are apparently lacking rigor here. However, that should not be regarded as a problem; these interconnection types are not frequent (disregarding how important they may be) and therefore there is no real need for uniformity, as in case with APIs. Yet it is important to ensure clarity by proper stereotyping and naming/labeling and possibly by adding a descriptive property.
The meta model:
![API_meta1](https://community.opengroup.org/archimate-user-community/workgroups/component-and-connector/-/raw/master/doc_images/Data_meta_simple.png)
* * *
* * *https://community.opengroup.org/archimate-community/workgroups/component-and-connector/-/issues/1Representing proxies and gateways2021-06-26T08:20:05ZMichael BoeynaemsRepresenting proxies and gatewaysA problem I often encounter is how proxies and gateways should be represented. My focus is on such components that have been put there for security reasons, but they may have other responsibilities as well (unified service access, usage ...A problem I often encounter is how proxies and gateways should be represented. My focus is on such components that have been put there for security reasons, but they may have other responsibilities as well (unified service access, usage quota, etc.).
Note: I hope this is relevant in the context of this workgroup, apart from the topics mentioned in https://community.opengroup.org/archimate-user-community/home/-/issues/35