This AntiPattern is occurring when the architecture of an application is done while using an inappropriate communication protocol.

The protocol can be inappropriate in several ways (not exhaustive):
* It is used outside its application domain;
* Some constraints of the protocol cannot scale the desired way (especially the encoding/decoding part with grammars);
* The protocol is not adapted in complex architectures (like MT ones, clusters, clouds, etc.) and the work to adapt it in those contexts totally violate the protocol fundamentals;
* The protocol dialogs are incompatible with the application logic;
* Some basic protocol services are required by the application but not in place in the protocol stack (such as secured delivery, ordering of messages, retries, possible duplicates, etc.).

The consequences are often critical for the application itself that, in the best of cases, will work quite badly, but that can also not work at all. As certain problems can come from scalability, the critical issues can be discovered once in production, which is the worst case to manage inside a company.

This is a severe AntiPattern as most of ArchitectureAntiPattern''''''s because it is not easy to recover without throwing away a lot of the developed code.
----
Samples:
* Use of a protocol that cannot guarantee the order of messages while your core application is relying on that order.
* Use of a protocol that is based on infinite retries on RTOs while the application is adapted to a simple possible duplicate management.
* GoogleWave is a good sample of this AntiPattern: the use of XMPP was imposing XML validation in core use cases. This validation had to be done with hundreds of threads modifying the same XML tree at the same time while other threads should be in charge of pushing the "validated XML" over XMPP to the clients (huhu!). The fact is it is not possible to validate a XML file while hundreds of threads are modifying it. You cannot determine when the XML is OK while there are always customer threads performing updates on it. The main design fault was to believe that hundreds of threads working on an XML message could be assimilated to an XMPP client. Indeed, the XMPP client is not supposed to be in reality hundreds of concurrent clients. GoogleWave could have been a promising product, but it was NotTheAppropriateProtocol.
* Trying to run a event based protocol (like IRC) over a request based protocol (like HTTP).
----
CategoryArchitectureAntiPattern