The XMI files are not MOF-compliant and incomplete. For example datatypes have no type codes, some datatypes (e.g. Boolean) are defined as classes, several associations are not contained in a package, several AssociationEnds have no Multiplicity.

Document: UML Profile and Interchange Models for EAI
Section: 6.3.10.2.1 (EAIMessageFlow)

Description:
The second sentence of Section 6.3.10.2.1 is "Each of its 'nodes' (see Figure 6-2) must be one of the operator classes (EAIPrimitiveOperator or EAICompoundOperator), and its connections must be EAILinks." This statement is a constraint. It is also incorrect, since an EAIMessageFlow can also contain EAISources and EAISinks.

Recommendation:
Move this statement under a Constraints heading for EAIMessageFlow, adding EAISource and EAISink to the allowable kinds of nodes for an EAIMessageFlow.

I see a reference to a metadata repository, and I would hoped that you would spell out your perception of its role. (I personally would like to see the ebXML Registry and Repository called out...).

I think the concept of an adapter vs. a connector is only causing confusion. Most people relate to the adapter as per the Gang of Four pattern, which is a transformation between interfaces. Yet the connector appears to have the ability to perform a transformation too. An adapter (or connector in OMG world) IS middleware, but you have middleware as this nebulous cloud in the architecture

Document: UML Profile and Interchange Models for EAI
Section: 8.3.18.6 (Constraints)

Description:
In the first paragraph of Section 8.3.18.6 (Constraints [on Compound Operators]), "<<Compound>>" should be "<<CompoundOperator>>" and "cardinality" should be "multiplicity".

Recommendation:
Make the above corrections

Document: UML Profile and Interchange Models for EAI
Section: 6.3.10.2 (EAICompoundOperator)

Description:
Section 6.3.10.1 includes a constraint that requires the FCMOperation invoked by an EAIPrimitiveOperator to be an EAIMessageOperation. An EAICompoundOperator is a kind of FCMCommand, which is a kind of FCMFunction, and, therefore, it also has an invoked FCMOperation. But there is not constraint on this operation in Section 6.3.10.2. Further, this operation is important, because it would seem to be the operation whose parameters provide the basis for the terminals of the EAICompoundOperator and, therefore, for the terminals of EAISources and EAISinks in the implementingComposition of the operator.

Recommendation:
Add the following constraints to EAICompoundOperator.

An EAICompoundOperator invokes an EAIMessageOperation.
self.invokes->oclIsKindOf(EAIMessageOperation)

All EAISources in the implementingComposition of an EAICompoundOperator must implement the EAIMessageOperation invoked by the EAICompoundOperator.

self.implementingComposition.nodes->
select(oclIsKindOf(EAISource))->forAll(implements = self.invokes)

3) Most of the extensions are transformation service "patterns", such as filter, aggregator, etc., yet some are messaging service "patterns" such as pub/sub, topic, etc. I like the idea that they can be stereotyped, but they are not associated to the traditional middleware services stack that we have been using for a while. I could get real detailed (e.g., aggregator should have a sort or orderby operation, etc.) but I am swamped at the time

2) There is no concept of "Management" within the specification. Integrations need to be managed, and there is no protocol that is established for managing the state of the integration, which could bind to a transaction service (since a message could prescribe a transaction that could span multiple systems), or a middleware management service that is interested in the "heartbeat" of the system. These concepts borrow heavy from the OSI Protocol Engine, which is the origin of the adapter concept (other than SADT / IDEF0 modeling techniques). Sorry to bring up stuff dated 20+ years. A managed adapter is a thicker adapter that provides middleware services or can access middleware services, plus report out to a middleware management service to tell the MMS how its doing. Most application servers today can be utilized as a managed adapter, but no one is really formalizing the protocol (I know webMethods was promoting something they called OMI, but its been about a year now with no published specs).

There is no concept of process integration, to integration process models (e.g., B2B -> A2A, where a B2B activity initiates an entirely separate A2A either via one-way message or request/response). Even IDEF0 allowed that via the Call function. In fact, I think that using EAI already makes this document outdated, most energies are being focused on BPI). Activity graphs are the tip of the iceberg so to speak

To promote "flow" is overly simplistic, as an activity is a transformation (even in its earliest IDEF0 definition). A transformation occurs when all signals and conditions are present, generating state(s) that conform to defined constraints. I prefer "state transition" vs.. flow.

To create a metamodel for data structures is only half the battle, as one would expect from OMG a metamodel for bindings, which could be a model of a finite state machine that could create NxN transformations