s. In a typical OSS environment, the EAI framework may well connect ten or more applications. Connector. EAI vendors use a variety of terms to describe the integration end points (e.g. connectors and adapters). Here we use connectors as a term for those end points. Whatever the name used for this integration point, the functional role is the same - Protocol Translation. The connector abstracts and normalizes the technical details of the application interface - API, Database Access, File Transfer, or other. It then makes the interaction with the application manifest itself as a series of messages that are either created (published) or consumed (subscribed) by the application. A secondary role is to maintain a connection or a session with the target application. An interesting side note is that while connectors provide a normalization mechanism, connectors themselves can be quite different in terms of the configuration required to implement them. The concept of configuring a connector may be counter-intuitive based on the previous discussion. Why does one need to configure a connector? Why has the vendor omitted some or all the messages? Referring back to the earlier discussion on the different style interfaces that application vendors provide we may, for example, consider those interfaces that allow database objects to be extracted and imported. With this style interface, it is necessary to identify those objects whose changing constitutes an event and whose attributes are required to be part of a published message. EAI vendors often provide a configuration mechanism that facilitates the identification of objects of interest and enables the construction or decomposition of messages. Many EAI vendors have developed a portfolio of connectors to common OSS application packages. In addition to providing application specific connectors, EAI vendors typically provide a set of infrastructure-type connectors to other middleware (e.g. MQSeries) or RDBMS (e.g. Oracle) that can be used to create connections to custom applica