79 pages To simplify the development of message-based integration solutions, EAI patterns can be gathered. They describe software components, which handle recurring problems within an integration solution. For example messaging systems need message translators to transform data from one applications format to another ones. [HW03] identified the most important patterns for messaging systems. But to use them concrete parameters must be ascertained. This led to parameterized EAI patterns [Dru07, Yua08]. And after that [SL08] made the next step by presenting a framework for executable parameterized EAI patterns. So we can call services from around the world and we can integrate them with reusable EAI patterns. But we still have to integrate each single request to a partner by ourselves. [SML08] showed a way to commit the responsibility for the integration infrastructure to a SaaS provider. This concept is named EAI as a Service. Thus, one must only model the integration scenario and can leave the execution to someone else. The architecture of a particular integration scenario, that uses a set of EAI patterns as solution, is named EAI system model. To retrieve an EAI system model the patterns must be configured firstly. Therefore a modeler will be supported by the guideline process, which defines tasks to combine patterns, and by the parameterization process, which is responsible for setting parameters of a single EAI pattern. Variability descriptors can be used to assist these processes. [Mie08] introduced variability descriptors to constrain application configurations on a per-tenant basis. For that purpose variability points refer to modifiable software artifacts and dependencies describe correlations between these artifacts.