Protocol VS Integration pattern

[spakendralo]

A proposal. Looking at the documentation, the "protocol" should perhaps be called "integration pattern". The reason is that some integration patterns are made out of several protocols. There may be technical components that are not EA applications that are involved and create protocol adaptations.

Sometime later, in the tool or outside of it in some Wiki pages, one will want to have the Integration Pattern explained and will show what are the technical components that create it and what are associated protocols.

[mauvaisetroupe]

The reason is that some integration patterns are made out of several protocols.

Could you pleas give an example?

I understand that you talk about something like ESB protocol :

• (APPLICATION_1) --ESB--> (APPLICATION_2)
• that in physically implemented by (APPLICATION_1) --MQ--> --ESB--> --MQ--> (APPLICATION_2)

Is it Correct? Something else in your mind?

[spakendralo]

It's a bit complex to explain, I think.

Assumption: an architectural schema has to be created/maintained with a top-down (design) AND a bottom-up approach (discovery). I think you will agree ;)

Then what is the granularity of the architectural schema that you have to have? It seems obvious that you need to create a schema that permits discovery to confirm design. So it is obligatory that in the schema you specify how the information needs to be confirmed. Now take App1 and App2 that communicate through an ESB as in your example. You do actually need both informations: the protocol of the App2 which exposes the service (MQ) and the integration pattern (ESB):

• Yes, you need the protocol because it's nice to know that an application exposes e.g. APIs regardless of the integration pattern. But this is not the "interface" in EADesignIT. This is just the interface of the service of App2. But that is more interesting for the service, not for the interaction of two applications, because you can then have a list of services of an application, see the related protocols, supported IntegrationPatterns, etc.
• But you also need the integration pattern which is ESB. In this way you can do two things:

A. For schema confirmation, you can now easily relate the result of trace of the ESB with the schema, hence bottom-up discovery can match top-down design. B. For new architects that want to build something, they will know how that they can use the ESB and not only purely MQ.

So to answer more concretely, some examples in order of complexity:

1. Some applications expose APIs. Is this an API that is exposed by the enterprise API Gateway or is this some "private" REST API that is meant to be used differently, e.g. FaxMachineAPI?
2. Same question for queues. Do we need a direct queue or it is it on ESB?
3. Are we speaking about a some kind of "CBS Event" or is this an Event in the Enterprise Streaming Platform or similar?

And a bit more seriously:

4. A file is sent to the CBS. But in reality an EP opens the file and sends line by line to CBS for which it also gets async response that is dropped or used for an alert. It is not the same thing as sending a file directly to CBS which involves also a scheduler and is processed as a real batch. For points A and B above, you have no idea how to make discovery and you also don't know what are the technical capabilities if you just say: Protocol=FILE. Instead, if you would have said e.g. IntegrationPattern=CBS-MFT-Online, you could know that the flow is in MFT, that there is a Java endpoint in the game, etc...
5. CSB sends you an event, the event is picked up by an endpoint and an API is called. Not the same thing if the CBS calls an API itself for the same reasons as above.

So finally. What I would like to have is the IntegrationPattern. The IntegrationPattern is a limited list of elements and for each one of them I can click and be directed to my wiki page where I describe the integration pattern with all components, a schema, etc. Hence the elements like endpoints, ESB, and ApiGateway never need to figure on an EA schema because it's already implied by the IntegrationPattern.

In Archimate, you have concepts of Channels, Networks, etc. But finally they create a technology layer Service. So for example a cluster of MQs and an IIB together create a service of an ESB. The term Service seems to be close to IntegrationPattern.

I found these two examples. A service Messaging is described, this would match what I mean by having the IntegrationPattern on the wiki, so this would not need to be in EADesignIT

And this would be the usage. See how the two applications use a kind of an MFT:

So perhaps the name should be Infrastructure Service and not IntegrationPattern?

[mauvaisetroupe]

I understand your point. You have a very "physical" definition of protocol. I guess when I start using this word in the present context I had a more conceptual definition

From wikipedia

A communication protocol is a system of rules that allows two or more entities of a communications system to transmit information via any kind of variation of a physical quantity. The protocol defines the rules, syntax, semantics and synchronization of communication and possible error recovery methods. Protocols may be implemented by hardware, software, or a combination of both.

I have a conceptual interpretation of this definition (that I admit doesn't really fit with the rest of wikipedia post) Do you think we have a different definition of a protocol? What is yours?

[spakendralo]

I think we have the same definition. Protocol is a description of how the interaction needs to happen, but does not say how this is implemented - and this is precisely what interests me, the implementation framework. I am not interested if the protocol is "FILE", I want to know where to look for the file transfer definition.

I will express this as a requirement so you see the need: As a person who maintains the architectural landscape, I need to map discovered flows with the defined ones. E.g.: I will have some routes and validation schemas extracted from an MFT software, and I want to know where to map this. In the reverse order, if I look at an Interface, I would like to understand where to find the definition for it.

[mauvaisetroupe]

In conclusion, Protocol entity match your needs. Actually a Protocol has a name and a type. For a type "File" you can have many Protocols like "Sftp file" , "iMFT batch file", etc. that match your integration pattern concept. I propose to close the issue for now

[spakendralo]

Closing as agreed.