Issues for UML profiles for EAI Finalization Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 4853: Semantic information is poorly organized between the Chapter 6
Issue 4854: Purpose of the CCA Component Library for EAI
Issue 4855: Non-normative examples
Issue 4856: Constraints should be in OCL
Issue 4857: Deployment of the EAI Configuration
Issue 4858: The class of an operator that is a subclass of a primitive operator
Issue 4859: Superclass of EAIAdapter
Issue 4860: Errors in the FCM4EAI DTD
Issue 4861: EAIRequestReplyAdapter/EAICallAdapter temporary link
Issue 4862: EAIRouter output terminal type
Issue 4863: EAICompoundOperator as a new type
Issue 4864: Lack of use of the MOF Profile
Issue 4868: The relationship of EAILink to FCMDataLink and FCMControlLink
Issue 4869: Unnamed derived association between an EAITerminal and a source or sink
Issue 4872: Inconsistencies between text and diagram for EAIMessageContent
Issue 4873: The "languageElement" association vs. the "message" association for EAIPara
Issue 4874: specifiedReplyToTerminal" and "specifiedExceptionTarget" associations
Issue 4875: Issues with XML Message Elements
Issue 4876: The constraint on the parameters of an EAIMessageOperation
Issue 4877: The lack of mention of "faults" for EAIMessageOperations
Issue 4878: The "messages" associated with an EAIQueue
Issue 4879: There is no way to specify typed EAIQueues
Issue 4880: There is no way to specify unbounded EAIQueues
Issue 4881: Inconsistent statements on the use of queued terminals
Issue 4882: Poor wording in the discussion of EAIQueues
Issue 4883: Poor wording on the use of queued terminals with queued sources and sinks
Issue 4884: The "Refinement relationships" stated in the section on queued sources and
Issue 4892: Derivation of the "defines" association for EAIPrimitiveOperator
Issue 4894: The usefulness of EAIMessageFlow in itself
Issue 4896: Wording error in Section 6.3.10.2.2
Issue 4897: Missing derivation of the "promotedTerminal" association
Issue 4898: Missing discussion of promotedTerminals for EAISinks
Issue 4947: Missing constraints on the input terminal of an EAITargetAdapter
Issue 4948: Lack of generalization for message content
Issue 4949: Missing constraint on the output terminal of an EAISourceAdapter
Issue 4950: Missing constraints on the input terminal of an EAITargetAdapter
Issue 4951: The name "EAITargetAdapter"
Issue 4952: Misplaced constraints on the terminals of an EAICallAdapter
Issue 4953: The use of FCMTerminals on an EAICallAdapter
Issue 4954: Overconstraint on allowed connection to "request" terminal of EAICallAdapte
Issue 4955: specifiedReplyTerminal association of EAIRequestFormat is dynamic state dat
Issue 4956: Missing constraint on the terminals of an EAIRequestReplyAdapter
Issue 4957: Lack of FCMTerminals for an EAIRequestReplyAdapter
Issue 4958: Missing multiplicity for the "filterCondition" of an EAIFilter
Issue 4959: Unclear semantic description for EAIStream
Issue 4960: Lack of constraints on the terminals of an EAIStream
Issue 4961: Missing multiplicity for the "emissionCondition" of an EAIStream
Issue 4962: Inclusion of the dynamic state "buffer" in the metamodel for EAIStream
Issue 4963: Unclear semantic description for EAIPostDater
Issue 4964: Inclusion of dynamic state "buffer" and "timingCondition" in metamodel for
Issue 4965: Multiplicity of the "transformation" association for an EAITransformer
Issue 4966: Redundant "database" association for an EAIDBTransformer
Issue 4967: Inclusion of dynamic state in the metamodel for EAIAggregator
Issue 4968: The specification of EAIRouter and EAITimer as compound operators
Issue 4969: Inclusion of the dynamic state "routingTargets" for the EAIRoutingTable
Issue 4970: Redundancy of EAIRouterUpdate/EAIBroadcaster with EAISubscriptionOperator/E
Issue 4971: Missing specification for EAISubscriptionTable
Issue 4972: The meaning of "subscriptionModes"
Issue 4973: Redundant "filterCondition" association on EAISubscriptionFilter
Issue 4974: The lack of discussion of EAIContentRule
Issue 4975: EAIPublicationTerminal is not needed
Issue 4976: Missing specification of a table to hold EAIMessageTimerConditions
Issue 4977: Missing message content class for timer conditions
Issue 4978: It is unclear how a message is associated with a topic
Issue 5222: Incorrect description of Figure 8-1
Issue 5223: Terminal labeling constraints
Issue 5224: Poor wording of constraint on association rolename of a database resource
Issue 5225: Lack of semantics for a "false" terminal on an EAIFilter in the metamodel
Issue 5226: The semantics of Stream operators
Issue 5227: The semantics of Post Dater operators
Issue 5230: The mapping of the setTimingCondition opeation of a Post Dater
Issue 5237: Update to Type Descriptor Metamodel
Issue 5238: Update to TDLang Metamodel
Issue 5239: Update to COBOL Metamodel
Issue 5240: Update to C Metamodel
Issue 5241: Update to MFS Metamodel
Issue 5242: Update to BMS Metamodel
Issue 5243: Update to Convergent Metamodel (Figure 64)
Issue 5244: Update Sample XMI in Section 7.3.11
Issue 5245: Adapters are called operators in the profile but not the metamodel
Issue 5246: Missing request format Y9
Issue 5247: Sources and sinks are called operators in the profile but not the metamodel
Issue 5248: Diagram the queue for queued sources and sinks
Issue 5249: Issue: Typographical errors in Figure 8-14 on aggregators
Issue 5250: Insufficiency of the metamodel mapping for aggregators
Issue 5251: Incorrect constraint for aggregators
Issue 5252: Incorrect notation for message arrows in Figure 8-24
Issue 5342: Incorrect filenames
Issue 5343: Incorrect MOF files
Issue 5345: Modeling Approach: Phrasing of delivery
Issue 5346: Metamodel: Use UML profile for MOF
Issue 5347: Compliance/Overview: use consistent XMI and MOF levels
Issue 5348: Compliance/Visualization: Clarification of visualization requirement
Issue 5349: Need to qualify profile names with EAI prefix
Issue 5350: Compliance/metamodels: Clarify status of CAM
Issue 5351: clarify relationship between EAI, FCM and ECA
Issue 5352: Compliance: Consistency of statements about CAM compliance
Issue 5353: CWM transformations
Issue 5354: Update reference to EDOC
Issue 5355: MOF compliance
Issue 5356: IBM CWM products
Issue 5357: CAM/CWM alignment
Issue 5358: Related activities: Relationship to ebXML and BPML
Issue 5359: Use 'EAI' qualify references to profiles
Issue 5366: Wording of FCMSource description
Issue 5367: Use UML profile for MOF <<enumeration>> stereotype
Issue 5368: Clarify constraints on EAILink
Issue 5369: Constraints on EAITerminal
Issue 5370: Reword description of applicability of EAIMessageContent
Issue 5371: Clarify EAIParameter, EAIMessage
Issue 5372: EAIMessagePart
Issue 5373: Constraints on EAIMessageElement
Issue 5374: How is EAIMessageContent.part used?
Issue 5375: Conflict with XML production of XML schema
Issue 5376: XML Message Elements
Issue 5377: Relationship to CWM XML Schema model
Issue 5378: EAIQueue: Show association with EAIMessage
Issue 5379: EAIQueuedInputTerminal: Wording error on constraint
Issue 5380: Clarify the meaning of refinement relationships
Issue 5381: Operators: Wording change
Issue 5382: EAIPrimitiveOperator: Define derivations formally
Issue 5383: Relationship between EAIMessageFlow annotations and FCMComposition annotati
Issue 5384: Derivation of promoted terminal
Issue 5385: what is a 'CCA Component Library'
Issue 5386: Section 6.5.1.2, bottom p57
Issue 5387: CAM: Introduce products in 'EAI' terms
Issue 5388: CAM Type Descriptor Stereotypes
Issue 5389: CAM Type descriptor metamodel: Introduce TDLangElement
Issue 5390: CAM Type descriptor stereotypes: Heading change
Issue 5391: CAM InstanceTDBase: add a derived association
Issue 5392: CAM Type descriptor formulas
Issue 5393: CAM TDLang Metamodel diagram changes
Issue 5394: CAM TDLangModelElement: Classifier or Element
Issue 5395: CAM: Title of section 7.3.9
Issue 5396: CAM: Sample serialisation: Problems with XMI
Issue 5397: Collaboration model: error in text associated with figure 8-1
Issue 5398: Collaboration model: use UML operation specification property
Issue 5399: Describe the required properties of terminal-operator associations
Issue 5400: Use of containment in UML Collaboration Diagrams
Issue 5401: Explain underscores on names in collaboration diagrams
Issue 5402: Collaboration model: Explain how terminals are wired together
Issue 5403: Collaboration model: MessageContent core
Issue 5404: Activity Model: Describe how this relates to the EDOC process profile
Issue 5405: CAM Language Metamodels: Wording change
Issue 5406: CAM: COBOL Metamodel: Naming consistency
Issue 5407: CAM: C Derivation diagram
Issue 5408: CAM: C User Types
Issue 5409: CAM: CsourceText clarification

Issue 4853: Semantic information is poorly organized between the Chapter 6 (uml-eai-ftf)

Issue: Semantic information is poorly organized between the Chapter 6 (EAI Integration Metamodel) and Chapter 8 (Collaboration Modeling).

Document: UML Profile and Interchange Metamodel for EAI (ptc/02-02-02) 
Chapters: 6, 8 and 9 

Description: 
Chapter 6 describes the interchange metamodel and one would expect it to also provide the normative semantics of models constructed according to that metamodel. However, the specification of semantics is, in reality, spread between Chapter 6, Chapter 8 (which describes the collaboration modeling profile) and Chapter 9 (which describes the activity modeling profile). In practice, it is necessary to carefully read corresponding sections in both Chapters 6 and 8 (or 6 and 9) in order to understand the intended semantics. But, since the structure of the chapters is not parallel and since there are inconsistencies between the chapters [some of which will be identified in subsequent issues], the specification ends up being very difficult to use.

Recommendation: 

Structure Chapter 6 similarly to the specification of the UML 1.4 metamodel, but, perhaps, at a finer level of granularity. That is, for each major item (e.g., EAILink, EAITerminal, each kind of operator, etc.), organize the specification for that item under the following headings:

o Metamodel: The metamodel diagram for the item. (Analogous to the UML metamodel "Abstract Syntax".) 
o Constraints: Textual and OCL descriptions of each of the applicable constraints. (Analogous to the UML metamodel "Well-Formedness Rules".)

o Semantics: The COMPLETE specification of the semantics of the item. 

Chapter 8 should have a closely parallel structure to Chapter 6. For each major item, Chapter 8 should present: 
o Description of the profile notation/stereotypes and its mapping to the metamodel. 
o Textual and OCL descriptions of constraints associated with the stereotypes. (Note that, as part of the profile, these are constraints on the UML metamodel, as opposed to the constraints in Chapter 6, which are constraints on the EAI interchange metamodel.)

o Descriptions of the mapping between the UML semantics and the metamodel semantics. 

Note that Chapter 8 should ONLY describe the MAPPING to the Chapter 6 metamodel and semantics, and not otherwise contain any normative semantics. (Similar comments also apply to Chapter 9, "Activity Modeling", and its relation to Chapter 6.)

Discussion:
The point that the normative semantics are specified in chapter 6 is well made, and should be clarified.

Document: UML Profile and Interchange Metamodel for EAI (ptc/02-02-02) 
Section: 6.5 

Description: 
The purpose of Section 6.5, "CCA Component Library for EAI" is not very clear. The text says that "It is an informational supplement to the EAI integration metamodel.", but I am not sure what this means, since CCA is basically a modeling approach with its own metamodel and profile. Does "informational" mean that this section is not even normative?

Recommendation: 
The purpose of the CCA Component Library would seem to be to provide a CCA-based modeling notation for the metamodel. In this respect it would seem have a parallel purpose to the Collaboration and Activity Modeling profiles given in Chapters 8 and 9. Therefore, if this library is intended to be normative, then it should be included in Part 3 as a chapter on "CCA Modeling". If it is not intended to be normative, then this section should probably be moved to an appendix.

Document: UML Profile and Interchange Metamodel for EAI (ptc/02-02-02) 
Chapters: 10 and 11 

Description: 
The examples in Chapters 10 and 11 are useful, but they are non-normative. 

Recommendation: 
Move these Chapters to appendices. 

Document: UML Profile and Interchange Metamodel for EAI (ptc/02-02-02) 
Chapter: 6 

Description: 
Constraints are presented only as textual descriptions. 

Recommendation: 
Express all constraints in OCL as well as textually. 

I propose that we do not take 'special' action to resolve this issue independently but that we use OCL definitions where answering issues that relate to the EAI metamodel elements. Since issues cover all of the core elements of the EAI Integration Metamodel, this has the effect that OCL will be used throughout.

Document: UML Profile and Interchange Metamodel for EAI (ptc/02-02-02) 
(General) 

Description: 
The document does not address the deployment of different parts of the EAI configuration. 

Recommendation: 
It would useful to have some kind of location binding for either EAIMessageFlow or for each EAI node. 

Resolution:
It would useful to have some kind of location binding for either EAIMessageFlow or for
each EAI node.

Document: UML Profile and Interchange Metamodel for EAI (ptc/02-02-02) 
(General) 

Description: 
Even though integration with the "outside world" is out of scope for the spec the examples of such integrations would be really helpful. For instance it's not clear from the DTD what tag/association defines the class of the operator that is a subclass of the one of the standard primitive operators. Is it 'defines association' to the FCMType? (And why does EAIRequestReplyAdapter have EAIPrimitiveOperator.defines but EAICallAdapter does not in the DTD)?

The resolution to this issue is covered by the resolution to issue 4892, which discusses the 'defines' association and the definition of types.

Document: UML Profile and Interchange Metamodel for EAI (ptc/02-02-02) 
Sections: 6.3.11, 6.5 

Description: 
There is some confusion in the spec on the superclass for EAIAdapter. Section 6.3.11 says that EAIAdapter is a specialization of FCMFunction. Section 6.3.11.4 says that EAIRequestReplyAdapter is a subclass of FCMCommand. In section 6.5 we see that all adapters including EAIRequestReplyAdapter are a specialized EAIPrimitiveOperator. 

Document: UML Profile and Interchange Metamodel for EAI (ptc/02-02-02) 
(DTD) 

Description: 
There are errors (such as duplicate names and misspellings) in the FCM4EAI.dtd that seem. 

Document: UML Profile and Interchange Metamodel for EAI (ptc/02-02-02) 
Section: 6.3.11.4 

Description: 
The "replyOut" terminal and the "handleReply" terminal of the EAICallAdapter are connected dynamically via the a temporary EAILink that is not part of EAI configuration. It appears that information required to create the temporary EAILink can be stored only in the message. The only data that is there now is information required to locate replyTo terminal (terminal id I assume). It's not clear what type of the link the temporary link should be: synchronous or asynchronous? What is the name of the queue in case of the asynchronous link? What is the type of the "replyOut" terminal EAITerminal or EAIQueuedOutputTerminal considering that this temporary link can be synchronous or asynchronous?

Proposed Resolution:
Replace the following paragraph in Section 6.3.11.5 (which is the correct section in the Final Adopted Specification, not 6.3.11.4):
This effectively creates dynamic and temporary instances of EAILink between the "replyOut" terminal and the "handleReply" terminal of the EAICallAdapter that sent the request message.
with:
Note that, in addition to simply being placed on the "replyOut" terminal, the reply message is transmitted to the reply terminal that is dynamically identified by the incoming request message. Request messages a generated by EAICallAdapters, with the reply terminal of the request message being the "handleReply" terminal of the EAUICallAdapter. Thus, the semantics of an EAIRequestReplyAdapter effectively results in the creation of a dynamic and temporary EAILink between the "replyOut" terminal of the EAIRequestReplyAdapter and the "handleReply" terminal of the EAICallAdapter that generated the request message.
Now, if the identified reply terminal is not an EAIQueuedInputTerminal, then the dynamic EAILink is considered to have synchronization = unspecified.The reply message is simply placed on the identified input terminal. However, if the identified reply terminal is an EAIQueuedInputTerminal (see Section 6.3.8), then the dynamic EAILink is considered to have synchronization = asynchronous and the reply message is placed on the inputQueue of the reply terminal.
Update Section 6.3.11.5 (which is the correct section in the Final Adopted Specification,
not 6.3.11.4)

Document: UML Profile and Interchange Metamodel for EAI (ptc/02-02-02) 
Section: 6.6.1.7 

Description: 
EAIRouter has single output terminal that is connected to input terminals. This places a constraint on all connected input terminals to have the same type EAITerminal or EAIQueuedInputTerminal.

Reject. This limitation is inherent in the semantics of queued input and output terminals, which corresponds to communication mediated by a queue.

Document: UML Profile and Interchange Metamodel for EAI (ptc/02-02-02) 
Section: 6.3.10.2 (and DTD) 

Description: 
The compound operator can be defined as a group of primitive operators but it's not clear how to define the compound operator as a new type using the FCM4EAI.dtd. Is usage of EAIMessageFlow the answer?

Document: UML Profile and Interchange Models for EAI 
Chapter: 6 

Description: 
If the EAI Integration Metamodel is intended to be the basis for directly generating the FCM4EAI DTD (which it should be), then it should be presented with diagrams using the UML Profile for MOF, which was adopted as part of the UML for EDOC submission.

Recommendation: 
Express all diagrams in Chapter 6 using the UML Profile for MOF. 

Document: UML Profile and Interchange Models for EAI 
Section: 6.3.2 (EAILink) 

Description: 
This section implies that for any EAILink, there will really be THREE FCM links. The EAILink itself (an FCMTerminalToTerminalLink), an associated FCMDataLink and and associated FCMControlLink. The EAILink and the DataLink, in particular, seem redundant.

Recommendation: 
Since, conceptually, an EAILink is primarily a data link, it seems appropriate to make EAILink a child of FCMDataLink, rather than a direct child of FCMTerminalToTerminalLink. Then only one additional link, the FCMControlLink, is needed. This is less heavyweight and fits the conception of an EAILink as a data link that also implies a control link.

Resolution:
Since, conceptually, an EAILink is primarily a data link, it seems appropriate to make
EAILink a child of FCMDataLink, rather than a direct child of
FCMTerminalToTerminalLink. Then only one additional link, the FCMControlLink, is
needed. This is less heavyweight and fits the conception of an EAILink as a data link that
also implies a control link.

Document: UML Profile and Interchange Models for EAI 
Section: 6.3.3 (EAITerminal) 

Description: 
The last constraint in this section states that "An EAITerminal on the exterior of a node constructed from an FCMComposition has a derived association with a single source or sink." Since it is not named, it is unclear to what "derived association" this statement refers, if the association even exists in the metamodel.

Recommendation: 
The constraint needs to be made explicit. Perhaps the "interface" association from FCMNode to FCMTerminal (which is a derived association in Figure 6-2) is meant. In this case, however, note that the constraint cannot be written as a constraint on FCMTerminal, since this association is not navigable from FCMTerminal back to FCMNode. I think the constraint would have to be on FCMComposition (or, better, on EAIMessageFlow).

The FCM in the EDOC submission is now updated to include an association between terminal an FCMSource, FCMTerminal and FCMSink

Document: UML Profile and Interchange Models for EAI 
Section: 6.3.4 (EAIMessageContent) 

Description: 
The text under Constraints in Section 6.3.4 refers to "messageFormat" and "messageDomain", neither of which appear in the diagram in Figure 6-9. (By the way, the statement under Constraints does not really seem to be a constraint, but more a part of the description of the semantics.)

Recommendation: 
Perhaps "messageFormat" should be replaced by "languageElement", but it is not entirely clear that this is what is intended. If something else is intended, then it should be made explicit.

I think that "messageDomain" is should be simply "domain" (an attribute of EAIMessageContent). 

The whole statement should be moved to be part of the description of the semantics of EAIMessageContent.

Recommendation: 
Perhaps "messageFormat" should be replaced by "languageElement", but it is not entirely clear that this is what is intended. If something else is intended, then it should be made explicit.

I think that "messageDomain" is should be simply "domain" (an attribute of EAIMessageContent). 

The whole statement should be moved to be part of the description of the semantics of EAIMessageContent.
Resolution: duplicate (answered by resolution of 5371)

Document: UML Profile and Interchange Models for EAI 
Section: 6.3.4 (EAIMessageContent) 

Description: 
EAIParameter inherits a "languageElement" association with TDLangElement from FCMParameter (this association is part of the FCM specification and is shown in Figure 6-1). However, this association does seem not related in any way to the "message" association with EAIMessageContent. Indeed, an EAIMessageContent may be made up of several TDLangElements, so it is not clear which one of them might be considered to be "the" TDLangElement for the EAIParameter. This makes it unclear how the semantics of EAIParameter can be specialized from the FCM semantics for FCMParameter.

Recommendation: 
Perhaps one could require that the languageElement for an EAIParameter to be, say, the languageElement of the body of the EAIMessagePart. But I don't think this really quite captures the right semantics (and, besides, this body is actually optional).

Instead, what is probably required is a change to the FCM to break the unfortunate cyclic dependency between the FCM (in the EDOC specification) and the CAM (in this specification). For instance, the FCM could define an abstract type descriptor class for the use as the type of an FCMParameter. TDLangElement could then be one possible descendant of this abstract type descriptor. But, for the purposes of EAIParameter, EAIMessageElement should also be a descendant, with the constraint that the type of an EAIParameter is always an EAIMessageElement (and the additional "message" association then being unnecessary).

Recommendation: 
Perhaps one could require that the languageElement for an EAIParameter to be, say, the languageElement of the body of the EAIMessagePart. But I don't think this really quite captures the right semantics (and, besides, this body is actually optional).
Instead, what is probably required is a change to the FCM to break the unfortunate cyclic dependency between the FCM (in the EDOC specification) and the CAM (in this specification). For instance, the FCM could define an abstract type descriptor class for the use as the type of an FCMParameter. TDLangElement could then be one possible descendant of this abstract type descriptor. But, for the purposes of EAIParameter, EAIMessageElement should also be a descendant, with the constraint that the type of an EAIParameter is always an EAIMessageElement (and the additional "message" association then being unnecessary).
Proposed Resolution:
The class TDLangElement is already an abstract type descriptor, even if it is included in CAM, not in the EDOC specification. Further, TDLangClassifier provides a natural base for EAIMessageContent, which is basically a type definition. We can then define an EAIMessage as a descendant of TDLangElement, with an EAIMessageContent as its type, and EAIParameter can be constrained so that its languageElement is an EAIMessage.

Document: UML Profile and Interchange Models for EAI 
Section: 6.3.4 (EAIMessageContent) 

Description: 
The derived associations for "specifiedReplyToTerminal" and "specifiedExceptionTarget" are included in the metamodel to capture the "requirement that EAIHeader should specify the information required to locate replyTo and exceptionTarget terminals". However, this is dynamic instance state information that form part of the semantics of the EAIHeader, not its specification. It is thus not appropriate in the metamodel, since this results in corresponding elements in the DTD, even though it is not the intent that this information ever be provided in the SPECIFICATION of an EAIHeader (which is, after all, what is being modeled and interchanged in the XMI).

Recommendation: 
The metamodel is a syntactic model, not a semantic model. The "specifiedReplyToTerminal" and "specifiedExceptionTarget" associations should be removed.

Proposed Resoution:
Remove the following paragraph, which is the last paragraph of Section 6.3.4.2, "EAI Header":
The requirement that EAIHeader should specify the information required to locate replyTo and exceptionTarget terminals is recorded via derived associations with EAITerminal. These derived associations do not form part of the message itself.

Remove the "specifiedReplyToTerminal" and "specifiedExceptionTarget" associations from the metamodel shown in Figure 6-10.  RESOLUTION The metamodel is a syntactic model, not a semantic model. The
"specifiedReplyToTerminal" and "specifiedExceptionTarget" associations should be
removed.

Document: UML Profile and Interchange Models for EAI 
Section: 6.3.4 (EAIMessageContent) 

Description: 
Is the intent here to actually change the OMG "XMI Production of XML Schema" specification? Because the generalizations shown in Figure 6-12 do actually change the specification of elements from the XML schema model.

And, in any case, why are XMLMessageElements described in Section 6.3.4, rather than in Chapter 7, on the Common Application Metamodel?

Recommendation: 
Introduce a simple model in the CAM that has new classes for TDLangXSDType, TDLangXSDComplexType and TDLangXSDElementType that multiply inherit from the XML schema and TDLang classes. (Some further study is required of the XML schema model to confirm that this approach will actually work.)

It was agreed that this section was not intended to be normative, and that it should be removed to remove any potential for conflict

Document: UML Profile and Interchange Models for EAI 
Section: 6.3.5 (EAIMessageOperation) 

Description: 
The text under Constraints in Section 6.3.5 states that a parameter of an EAIMessageOperation must have "a 1:1 relationship with EAIMessageContent or a subclass of EAIMessageContent." I assume that this is intended to mean a "1..1" assocation, since a "1:1" (usually read "1 to 1") relationship would require EVERY EAIMessageContent instance to be associated with some EAIParameter, as well as the converse, that every EAIParameter is associated with some EAIMessageContent instance (which, I think, is all that is intended). However, in this case, the constraint is already covered by the 1..1 multiplicity shown on the "message" association from EAIParameter to EAIMessageContent in Figure 6-9, and no other constraint on the association is needed.

Recommendation: 
The constraint should read simply "Every input and output of an EAIMessageOperation is an EAIParameter." The corresponding OCL is:

self.inputs->union(self.outputs)->forAll(oclIsType(EAIParameter)) 

Document: UML Profile and Interchange Models for EAI 
Section: 6.3.5 (EAIMessageOperation) 

Description: 
EAIMessageOperations are required to have EAIParameters for inputs and outputs, but no constraint is put on the faults for these operations (faults are part of the FCM specification of FCMOperations, see Figure 6-1). Are EAIMessageOperations allowed to have faults? If so, are they required to be EAIParameters?

Recommendation: 
Either include a constraint prohibiting an EAIMessageOperation to have faults, or include them in the statement of the constraint requiring the other parameters to be EAIParameters.

Resolution:
Either include a constraint prohibiting an EAIMessageOperation to have faults, or include
them in the statement of the constraint requiring the other parameters to be
EAIParameters.

Document: UML Profile and Interchange Models for EAI 
Section: 6.3.7 (EAIQueue) 

Description: 
The description of EAIQueue states that "EAIQueue has an ordered collection 'messages' of EAIMessageContent". This is stated as if it is describing an association in the metamodel, but no such association appears in the diagram in Figure 6-15. The name "messages" is also used in the OCL statement under Constraints.

Including such a "messages: association would not be appropriate in the metamodel, however, since this represents the dynamic state of the queue, not a part of the specification of the queue. The statement that an EAIQueue has an ordered collection of messages, and the constraint on its state, is part of the description of the semantics of EAIQueue, not part of the definition of the metamodel.

Recommendation: 
Remove the reference to a "messages" association and remove the constraint. Instead, discuss the behavior of an EAIQueue as part of the description of its semantics.

Resolution:
Remove the reference to a "messages" association and remove the constraint. Instead,
discuss the behavior of an EAIQueue as part of the description of its semantics.

Document: UML Profile and Interchange Models for EAI 
Section: 6.3.7 (EAIQueue) 

Description: 
As defined in Section 6.3.7, any EAIQueue can contain any kind of EAIMessageContent. There is no way to specify that an EAIQueue is restricted to contain only certain kinds of messages.

Recommendation: 
Add an optional "messageType" association from EAIQueue to EAIMessageContent. If a specific type of EAIMessageContent is specified for an EAIQueue, then the semantics is that the queue is restricted to only contain that kind of message content.

Resolution:
Add an optional "messageType" association from EAIQueue to EAIMessageContent. If a
specific type of EAIMessageContent is specified for an EAIQueue, then the semantics is
that the queue is restricted to only contain that kind of message content.

Document: UML Profile and Interchange Models for EAI 
Section: 6.3.7 (EAIQueue) 

Description: 
As defined in Section 6.3.7, every EAIQueue must have a maxLength. There is no way to specify an "unbounded" queue. 

Recommendation: 
Add an attribute "isBounded: Boolean" to EAIQueue. The semantics are that, if isBounded is true, then the EAIQueue can hold only up to maxLength messages, otherwise the length of the queue is not bounded.

(Also, the type of maxLength should be "Integer", not the language-specific "int".)

Resolution:
Add an attribute "isBounded: Boolean" to EAIQueue. The semantics are that, if
isBounded is true, then the EAIQueue can hold only up to maxLength messages,
otherwise the length of the queue is not bounded.
(Also, the type of maxLength should be "Integer", not the language-specific "int".)

Document: UML Profile and Interchange Models for EAI 
Section: 6.3.8 (EAIQueuedInputTerminal and EAIQueuedOutputTerminal) 

Description: 
Section 6.3.8 states that "We represent the fact that an *Operator* uses queuing via the use of" queued terminals (emphasis added). Later, however, it is stated that "Queued input and output terminals may be used on _any of the EAI constructs that have terminals_", which is more expansive than the previous statement.

Recommendation: 
Since the concept of "operators" has not yet even been introduced in the linear sequence of the document at this point, it would be better if the initial statement was worded something like: "EAIQueuedInputTerminal and EAIQueuedOutputTerminal are subclasses of EAITerminal that are used to represent message communication that occurs via queuing."

Since the concept of "operators" has not yet even been introduced in the linear sequence
of the document at this point, it would be better if the initial statement was worded
something like: "EAIQueuedInputTerminal and EAIQueuedOutputTerminal are subclasses of EAITerminal that are used to represent message communication that occurs
via queuing."

Document: UML Profile and Interchange Models for EAI 
Section: 6.3.8 (EAIQueuedInputTerminal and EAIQueuedOutputTerminal) 

Description: 
The discussion in Section 6.3.8 says that "...an EAIQueuedOutputTerminal has an association with each of the queues _used by its target EAIQueuedInputTerminals_" (emphasis added). This is poorly worded, since links have targets, not terminals.

There is a constraint that states that "All EAILinks from an EAIQueuedOutputTerminal must _be instances of_ EAIQueuedInputTerminal".  This is also poorly worded, since an EAILink cannot be "an instance of" an EAIQueuedInputTerminal.

Recommendation: 
Change the wording of the first item to "...an EAIQueuedOutputTerminal has an association with each of the inputQueues of the EAIQueuedInputTerminals to which it is linked by EAILinks."

Change the wording of the constraint to "All EAILinks with an EAIQueueOutputTerminal as the sourceTerminal must have an EAIQueuedInputTerminal as the targetTerminal."

Change the wording of the first item to "...an EAIQueuedOutputTerminal has an
association with each of the inputQueues of the EAIQueuedInputTerminals to which it is
linked by EAILinks."
Change the wording of the constraint to "All EAILinks with an
EAIQueueOutputTerminal as the sourceTerminal must have an
EAIQueuedInputTerminal as the targetTerminal."

Document: UML Profile and Interchange Models for EAI 
Section: 6.3.9 (EAIQueuedSource and EAIQueuedSink) 

Description: 
The last paragraph under Description in Section 6.3.9 states "Note that EAIQueuedSink and EAIQueuedSource could themselves be specialized to use queued terminals." There is no need to "specialize" these metaclasses in order to use queued terminals -- such terminals can simply be attached to them if desired, since queued terminals are kinds of regular EAITerminals.

Recommendation: 
Change the quoted sentence to: "Note that the terminals of EAIQueuedSink and EAIQueuedSource (used within the EAIMessageFlow) could themselves be queued terminals." Keep the following sentence unchanged.

Change the quoted sentence to: "Note that the terminals of EAIQueuedSink and
EAIQueuedSource (used within the EAIMessageFlow) could themselves be queued
terminals." Keep the following sentence unchanged.

Document: UML Profile and Interchange Models for EAI 
Section: 6.3.9 (EAIQueuedSource and EAIQueuedSink) 

Description: 
There is a heading "Refinement relationships" in Section 6.3.9 that don't seem to have anything to do with queued sources and sinks (which is the topic of the section). Indeed, it is not clear what these statements are supposed to be about at all.

Recommendation: 
Remove these statements unless they can be clarified. 

Recommendation: Remove these statements unless they can be clarified.

Document: UML Profile and Interchange Models for EAI 
Section: 6.3.10.1 (EAIPrimitiveOperator) 

Description: 
Under Constraints in Section 6.3.10.1 it states that "When used in an EAIMessageFlow, an EAIPrimitiveOperator also 'defines' a type." Since this is listed as a constraint, and since the "defines" association is shown as <<derived>> in Figure 6-18, one would assume that the constraint is intended to give the derivation of the association. But it certainly does not state that clearly, nor do I see any way, in the underlying FCM, for an EAIPrimitiveOperator (as an FCMFunction) to define an FCMType in the context of an EAIMessageFlow (as an FCMComposition).

Recommendation: 
Either make the association not derived (in which case the constraint statement needs to be expanded into a statement of the semantics of what it means for a primitive operator to "define a type") or make the derivation constraint much more explicit (i.e., provide the OCL).

The 'defines' relationship was erroneously labelled as derived in the final adopted submission. 
An EAIOperator may 'define a type', in effect by defining a 'prototype'. All instances of the EAIType are identical copies of the prototype, in terms of their properties but not the connectivity of their terminals. This allows the EAI model to use a simple 'template' scheme where multiple instances of essentially the same operator are required.
The resolution to this issue is also affected by changes to the Flow Composition Model in the EDOC Finalisation Taskforce. This has introduced the 'FCMCompositeNode', which is used as the base for nodes defined from compositions of other nodes. The EAIOperator class has been introduced to allow the common characteristics fo EAI operators to be defined.

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

Description: 
The concept of an EAIMessageFlow is useful in itself, separately from its use in defining a compound operator. (For example, we are using it as the basis for the deployment of pieces of our message broker configuration to different platforms.) However, the fact that it is defined within Section 6.3.10.2 (EAICompoundOperator) makes it seem like it is intended just for defining compound operators.

Recommendation: 
Move the definition of EAIMessageFlow out of Section 6.3.10 into its own subsection of Section 6.3. (Moving it to before the discussion of sources and sinks would also make those discussions clearer, though there would then instead be a forward reference to operators in the constraint on the contents of EAIMessageFlows.)

EAIMessageFlow is placed into a peer section at the same level as
EAICompoundOperator under 6.3.10 EAIOperator and after 6.3.10.5
EAICompoundOperator. So it becomes 6.3.10.6 (though other changes may affect the
precise numbering) numbering)

Document: UML Profile and Interchange Models for EAI 
Section: 6.3.10.2.2 ('Exposing' terminals in an EAIMessageFlow) 

Description: 
The first sentence after the bullets in Section 6.3.10.1 reads "This consequently determines the type _of that the_ external EAITerminal represents" (emphasis added).

Recommendation: 
Change "...of that the..." to "...that the...".

Document: UML Profile and Interchange Models for EAI 
Section: 6.3.10.2.2 ('Exposing' terminals in an EAIMessageFlow) 

Description: 
The meaning of the derived "promotedTerminal" association is discussed in Section 6.3.10.2.2, but no clear derivation constraint is given.

Recommendation: 
Given the FCM metmamodel (see Figure 6-2), the appropriate constraint is not so easy to formulate. I think the following will do, as a constraint on EAICompoundOperator (NOT EAITerminal).

The output terminal of each EAISource in the implementingComposition of an EAICompoundOperator is promoted to the input terminal of the EAICompoundOperator that represents the same EAIParameter (of the FCMOperation implemented by the EAISource) as the output terminal of the EAISource.

let sourceTerminals = 
       self.implementingComposition.nodes->select(oclIsType(EAISource)).interface in 
   self.interface->select(terminalKind = #in) 
      ->includesAll(sourceTerminals.promotedTerminal) and 
   sourceTerminals->forAll(promotedTerminal->notEmpty() 
      and parameter = promotedTerminal.parameter) 

(This assumes that there is already a constraint requiring an EAISource to have output terminals that represent the input parameters of the operation it implements.)

Resolution:
Conceivably, the name of an FCMTerminal could be given by the name of
languageElement of the FCMParameter represented by the FCMTerminal (via the
association given in Section 6-6), and this could be defined as a derived attribute of
FCMTerminal. However, it is not clear that this makes sense for an EAITerminal,
because the status of the languageElement associated with an EAIParameter is
questionable (see previous issue). Therefore, it seems simpler to have an explicit name
attribute for EAITerminals and leave FCMTerminals unnamed (unless the FCM is
separately updated to add names to FCMTerminals).

Document: UML Profile and Interchange Models for EAI 
Section: 6.3.10.2.2 ('Exposing' terminals in an EAIMessageFlow) 

Description: 
The first paragraph of Section 6.3.10.2.2 discusses both EAISources and EAISinks, but the remainder seems to only cover EAISources. It would seem that there also need to be promoted terminals for EAISinks, but with the roles of input and output reversed.

Recommendation: 
Extend the definition of "promotedTerminal" to include the input terminal of an EAISink being promoted to an output terminal of an EAIMessageFlow. There needs to be a similar constraint on EAICompoundOperators to define this association for terminals of EAISinks as for EAISources.

See discussion for 4897

Document: UML Profile and Interchange Models for EAI 
Section: 6.3.3 (EAITerminal) 

Description: 
In subsequent sections on adapters and operators, references are made to the "name" of a terminal. However, an FCMTerminal does not have a name (see Figure 6-2) and no name attribute is given for EAITerminal in Section 6.3.3 (see Figure 6-8). (Actually, a name attribute is shown for EAITerminal in some later diagrams, such as Figure 6-16 and Figures 6-20 and later.)

Recommendation: 
Conceivably, the name of an FCMTerminal could be given by the name of languageElement of the FCMParameter represented by the FCMTerminal (via the association given in Section 6-6), and this could be defined as a derived attribute of FCMTerminal. However, it is not clear that this makes sense for an EAITerminal, because the status of the languageElement associated with an EAIParameter is questionable (see previous issue). Therefore, it seems simpler to have an explicit name attribute for EAITerminals and leave FCMTerminals unnamed (unless the FCM is separately updated to add names to FCMTerminals).

Recommendation: 
Conceivably, the name of an FCMTerminal could be given by the name of languageElement of the FCMParameter represented by the FCMTerminal (via the association given in Section 6-6), and this could be defined as a derived attribute of FCMTerminal. However, it is not clear that this makes sense for an EAITerminal, because the status of the languageElement associated with an EAIParameter is questionable (see previous issue). Therefore, it seems simpler to have an explicit name attribute for EAITerminals and leave FCMTerminals unnamed (unless the FCM is separately updated to add names to FCMTerminals).

Proposed Resolution:
Add the attribute "name: String" to the class EAITerminal in the metamodel shown in Figure 6-8 and  6-20. (Note that, despite the comment in the "Description" above, Figure 6-20 does not show a "name" attribute for EAITerminal. However, all other figures besides 6-8 and 6-20 seem to.)
6.3.11.1	EAISourceAdapter

Document: UML Profile and Interchange Models for EAI 
Section: 6.3.4 (EAIMessageContent) 

Description: 
The metamodel has no way to model a generalization/specialization relationship between message content. This is a serious limitation in being able to model general message flows (at least for a number of the things we want to do). Note that the ability to specify generalization/specialization for TDLangElements (which is presumably available, depending on the is not sufficient (and would only seem to be available in language-specific metamodels anyway). The desire is to be able to specify a general message flow that can carry any of a number of potentially differently formatted message contents that all specialize a common message-content specification.

Recommendation: 
Add to the EAIMessageContent metamodel (Figure 6-9) a generalization/specialization association from EAIMessageContent to itself.

Resolution:
Add to the EAIMessageContent metamodel (Figure 6-9) a generalization/specialization
association from EAIMessageContent to itself.

Document: UML Profile and Interchange Models for EAI 
Section: 6.3.11.1 (EAISourceAdapter) 

Description: 
An EAITargetAdapter (Section 6.3.11.2) is limited to have a single input terminal, but Section 6.3.11.1 does not have a corresponding constraint for EAISourceAdapter. It seemingly allows an EAISourceAdapter to have many output terminals (or even none). This is also inconsistent with the discussion of source adapters under Collaboration Modeling (Section 8.3.6).

Recommendation: 
Replace the first constraint in Section 6.3.11.1 with: "An EAISourceAdapter has a single output terminal, which is an EAITerminal with the name 'out'."

Replace the first constraint in Section 6.3.11.1 with: "An EAISourceAdapter has a single
output terminal, which is an EAITerminal with the name 'out'."

Document: UML Profile and Interchange Models for EAI 
Section: 6.3.11.2 (EAITargetAdapter) 

Description: 
Section 6.3.11.2 states that "An EAITargetAdapter has a single input EAITerminal ("in")." However, this constraint is not listed under the Constraints heading in the section.

Recommendation: 
Add the constraint: "An EAITargetAdapter has a single input terminal, which is an EAITerminal with the name 'in'."

Resolution:
Add the constraint: "An EAITargetAdapter has a single input terminal, which is an
EAITerminal with the name 'in'."

Document: UML Profile and Interchange Models for EAI 
Section: 6.3.11.2 (EAITargetAdapter) 

Description: 
The name "EAITargetAdapter" is not consistent with the source/sink pairing always used elsewhere. 

Recommendation: 
Change the name to "EAISinkAdapter". 

Recommendation: 
Change the name to "EAISinkAdapter". 

Proposed Resolution:
Change "EAITargetAdapter" to "EAISinkAdapter" and the general term "target adapter" to "sink adapter" throughout the document. Change the stereotype name "TargetAdapter" to "SinkAdapter" in Chapter 8.
6.3.11.3 	EAICallAdapter

Document: UML Profile and Interchange Models for EAI 
Section: 6.3.11.3 (EAICallAdapter) 

Description: 
The constraints on the terminals of an EAICallAdapter in Section 6.3.11.3 are not listed under the Constraints heading. 

Recommendation: 
List the constraints under the Constraints heading. 

Recommendation: 
List the constraints under the Constraints heading. 

Proposed Resolution:
Add the following paragraphs at the beginning of the "Constraints" part of Section 6.3.11.3:
An EAICallAdapter has two input terminals, one of which is an FCMTerminal that is not an EAITerminal and the other of which is an EAITerminal with the name "handleReply".
An EAICallAdapter has two output terminals, one of which is an FCMTerminal that is not and EAITerminal and the other of which is an EAITerminal with the name "request".
(Note that FCMTerminals that are not EAITerminals cannot have names, so it is not possible to require the names "call" and "out" for them.)

Document: UML Profile and Interchange Models for EAI 
Section: 6.3.11.3 (EAICallAdapter) 

Description: 
In Section 6.3.11.3, an EAICallAdapter is defined as a specialization of FCMFunction (see Figure 6-23). Now, an FCMFunction invokes a single FCMOperation (see Figure 6-2). The terminals of an FCMFunction represent the FCMParameters of the FCMOperation (see Figure 6-6 and discussion in Section 6.2.5), with input terminals representing input parameters and output terminals representing output terminals (one assumes). However, the semantics of an EAICallAdapter are not properly reflected by the invocation of a single operation with the signature (input call, input handleReply, output request, output out). Rather, the semantics of an EAICallAdapter are to invoke the callToRequestMapping, wait for a reply and then call the replyToOutputMapping. Nevertheless, it is necessary to have EAIParameters that the request and handleReply terminals can represent, since that is the only way that message content typing can be provided for those terminals.

Recommendation: 

Define the invoked operation for an EAICallAdapter as having the FCMParameters corresponding to the call and out FCMTerminals (this reflects that, from the point of view of the caller, the semantics of an EAICallAdapter is that of an operation with "call" as its input and "out" as its output). Add two associations from EAICallAdapter to EAIParameter (say, "requestParameter" and "replyParameter") and define derivation rules such that these are represented by the "request" and "handleReply" terminals (since the representation association is a derived association -- see Figure 6-6).

Resolution:
Define the invoked operation for an EAICallAdapter as having the FCMParameters
corresponding to the call and out FCMTerminals (this reflects that, from the point of
view of the caller, the semantics of an EAICallAdapter is that of an operation with "call"
as its input and "out" as its output). Add two associations from EAICallAdapter to
EAIParameter (say, "requestParameter" and "replyParameter") and define derivation
rules such that these are represented by the "request" and "handleReply" terminals (since
the representation association is a derived association -- see Figure 6-6).

Document: UML Profile and Interchange Models for EAI 
Section: 6.3.11.3 (EAICallAdapter) 

Description: 
Section 6.3.11.3 states that an EAICallAdapter sends its requests "...to the input terminal of an EAIRequestReplyAdapter." More stringently, the section includes the constraint that "The 'out' terminal of [an] EAICallAdapter must be connected via an EAILink to the 'requestIn' terminal of an EAIRequestReplyAdapter." This means that the requests coming out of an EAICallAdapter cannot be routed through any operators, but must flow DIRECTLY to the input terminal of an EAIRequestReplyAdapter. This seems to seriously limit the usefulness of splitting call and request/reply adapters at all, and it certainly prevents a core capability that we need of being able to route request messages just like any other messages. Obviously, at the end of a message flow, a request message generally needs to flow into a EAIRequestReplyAdapter, but there is no reason the connection has to be DIRECT.

Recommendation: 
Eliminate the constraint. 

Recommendation: 
Eliminate the constraint. 
Proposed Resolution:
Remove both the following constraints from Section 6.3.11.3:
The "out" terminal of EAICallAdapter must be connected via an EAILink to the "requestIn" terminal of an EAIRequestReplyAdapter.
The "handleReply" terminal of EAICallAdapter is the target of connections via an EAILink from the "replyOut" terminal of an EAIRequestReplyAdapter.
Replace them with:
The parameter associated with the "out" terminal of an EAICallAdapter must be an EAIParameter with a message that is an EAIRequestFormat.
(Note that appropriate changes to the "Description" text are already covered in the resolution to Issue 4953.)

Document: UML Profile and Interchange Models for EAI 
Section: 6.3.11.3.1 (EAIRequestFormat) 

Description: 
Section 6.3.11.3.1 defines a "specifiedReplyTerminal" derived association (Figure 6-24) for an EAIRequestFormat that "...specifies a terminal to which replies should be sent." However, this information is not part of the specification of a request message, but it is part of the dynamic state of a request message, since it cannot be determined until that request message is actually created. As a metaclass, an instance of EAIRequestFormat is NOT a request message, but is rather a SPECIFICATION of a request message, and therefore should not include the state of the message itself.

Recommendation: 
Include the discussion of the identification of reply terminals as part of the semantics of an EAIRequestFormat, not the syntax. Remove the "specifiedReplyTerminal"

Resolution:
Include the discussion of the identification of reply terminals as part of the semantics of
an EAIRequestFormat, not the syntax. Remove the "specifiedReplyTerminal".

Document: UML Profile and Interchange Models for EAI 
Section: 6.3.11.4 (EAIRequestReplyAdapter) 

Description: 
Section 6.3.11.4 states that an EAIRequestReplyAdapter "has a single input terminal 'requestIn' and a single output terminal 'replyOut'", but this constraint is not listed under the Constraints heading in the section.

Recommendation: 
List an appropriate constraint under the Constraints heading. This constraint should also require that the terminals be EAITerminals.

Resolution:
List an appropriate constraint under the Constraints heading. This constraint should also
require that the terminals be EAITerminals.

Document: UML Profile and Interchange Models for EAI 
Section: 6.3.11.4 (EAIRequestReplyAdapter) 

Description: 
In Section 6.3.11.3, an EAICallAdapter is defined to have FCMTerminals that represent the  call from an external system into a message flow. However, Section 6.3.11.4 defines an EAIRequestReplyAdapter to have ONLY the "requestIn" and "replyOut" EAITerminals, without any other FCMTerminals to allow connection to the external system. This is not parallel with the definition of EAICallAdapter, and, indeed, it is inconsistent with the definitions of other adapters, which allow FCMTerminals for external connection (for example, the definition of an EAISourceAdapter places constraints on the output terminal of the adapter, which connects into the message flow, but specifically does not constrain the input terminal(s), to allow external connection).

Recommendation: 
Define an EAICallAdapter to have two additional FCMTerminals, "callOut" and "handleReturn". Define the "requestIn" and "replyOut" terminals to represent the EAIParameters of the EAIOperation invoked by the EAIRequestReplyAdapter. Add two new assocations from EAIRequestReplyAdapter to FCMParameter (say "callParameter" and "returnParameter") and define the "callOut" and "handleReturn" terminals as representing these parameters (this provides the typing for the new terminals).

Resolution:
Define an EAICallAdapter to have two additional FCMTerminals, "callOut" and
"handleReturn". Define the "requestIn" and "replyOut" terminals to represent the
EAIParameters of the EAIOperation invoked by the EAIRequestReplyAdapter. Add two
new assocations from EAIRequestReplyAdapter to FCMParameter (say "callParameter"
and "returnParameter") and define the "callOut" and "handleReturn" terminals as
representing these parameters (this provides the typing for the new terminals).

Document: UML Profile and Interchange Models for EAI 
Section: 6.4.1.1 (EAIFilter) 

Description: 
Figure 6-26 of Section 6.4.1.1 does not show any multiplicity for the "filterCondition" of an EAIFilter. 

Recommendation: 
Show a multiplicity of "1..1". 

Proposed Resolution:
Add the multiplicity of "1" to the "filterCondition" association for EAIFilter shown in the metamodel in Figure 6-26.
6.4.1.4 	EAITransformer

Document: UML Profile and Interchange Models for EAI 
Section: 6.4.1.2 (EAIStream) 

Description: 
Section 6.4.1.2 states that the output behavior of an EAIStream is "abstracted via an 'emissionCondition' that determines under what circumstances a message is emitted from the stream." However, it is not clear exactly what this condition is really to be on or when it is invoked. Also, the next sentence says that "The message emitted may be _any_ element of the 'buffer'", but this is inconsistent with the previous paragraph, which states that "The streaming algorithm determines when to place messages from the _top_ of the buffer onto the 'out' terminal" (emphasis added). 

Recommendation: 
Define the semantics of EAIStream to be the following: 

When a message is received on the input terminal, the message is placed in the buffer at a place determined by the streaming algorithm associated with the EAIOperation invoked by the operator. The emissionCondition is then evaluated on the current state of the buffer. If the condition evaluates to true, then the first ("top") element of the buffer is placed on the output terminal. Otherwise the operator produces no output (i.e., the output of the EAIOperation is "null").

Document: UML Profile and Interchange Models for EAI 
Section: 6.4.1.2 (EAIStream) 

Description: 
It seems to be implicit in the discussion of an EAIStream in Section 6.4.1.2 that there such an operator has a single input terminal and a single output terminal. However, this is not explicited stated anywhere in the section.

Recommendation: 
Add a constraint that "An EAIStream has a single input terminal that is an EAITerminal named 'in' and a single output terminal that is an EAITerminal named 'out'." (Note that this also makes the similar constraint in Section 6.4.1.3 on the terminals of an EAIPostDater redundant and unnecessary.)

Document: UML Profile and Interchange Models for EAI 
Section: 6.4.1.2 (EAIStream) 

Description: 
Figure 6-27 of Section 6.4.1.2 does not show any multiplicity for the "emissionCondition" of an EAIStream. 

Recommendation: 
Show a multiplicity of "1..1". 

Document: UML Profile and Interchange Models for EAI 
Section: 6.4.1.2 (EAIStream) 

Description: 
Figure 6-27 in Section 6.4.1.2 shows a "buffer" association on EAIStream. However, this is part of the dynamic state of an EAI stream operator, not part of the specification of the operator. An instance of EAIStream is a SPECIFICATION of an EAI stream operator, not the operator itself, and therefore should not include the dynamic state of the operator.

Recommendation: 
Remove the "buffer" association from Figure 6-27. 

Document: UML Profile and Interchange Models for EAI 
Section: 6.4.1.3 (EAIPostDater) 

Description: 
Section 6.4.1.3 states that an "EAIPostDater" holds a message in its buffer "until its individual timing condition is met". Does this mean that, at the appropriate time, the EAIPostDater autonomously emits the message, with no other stimulus, or that the operator checks the timing conditions each time it receives an incoming message? Also, as a child of EAIStream, EAIPostDater inherits the "emissionCondition" of a stream. How does this effect the behavior of the EAIPostDater?

Recommendation: 
Define the semantics of EAIPostDater to be the following: 

When a message is received on the input terminal, an EAIPostDater acts like an EAIStream in placing the message in its buffer and, possibly, immediately emitting a message. In addition, if the new incoming message is not the one that is immediately emitted, the EAIPostDater evaluates the timerMapping to create a timing condition for the message. Further, whenever any timing condition is met for any message in the buffer, the EAIPostDater autonomously places that message on its output terminal.

  
(An alternative would be to have EAIPostDater NOT be a child of EAIStream, with its semantics defined in a stand-alone fashion without an emission condition.)

Inclusion of the dynamic state "buffer" and "timingCondition" in the metamodel for EAIPostDater 
Document: UML Profile and Interchange Models for EAI 
Section: 6.4.1.3 (EAIPostDater) 

Description: 
Figure 6-28 in Section 6.4.1.3 shows "buffer" and "timingCondition" associations on EAIPostDater. However, this is part of the dynamic state of an EAI post-dater operator, not part of the specification of the operator. An instance of EAIPostDater is a SPECIFICATION of an EAI post-dater operator, not the operator itself, and therefore should not include the dynamic state of the operator.

Recommendation: 
Remove the "buffer" and "timingCondition" associations from Figure 6-28.

Document: UML Profile and Interchange Models for EAI 
Section: 6.4.1.4 (EAITransformer) 

Description: 
Figure 6-29 in Section 6.4.1.4 shows the "transformation" association of EAITransformer with FCMMapping as having a multiplicity of "0..n" [sic]. However, it is unclear what it means for a transformer to have more than one mapping (or to have zero mappings).

Recommendation: 
Make the multiplicity "1..1". 

Recommendation: 
Make the multiplicity "1..1". 

Proposed Resolution:
Change the multiplicity of "0..n" to "1" on the "transformation" association for EAITransformer shown in the metamodel in Figure 6-29.
6.4.1.5 	EAIDBTransformer

Document: UML Profile and Interchange Models for EAI 
Section: 6.4.1.5 (EAIDBTransformer) 

Description: 
According to Figure 6-18 in Section 6.3.10.1, any EAIPrimitiveOperator may already have any number of associated EAIResources. Since EAIDBTransformer is a descendant of EAIPrimitiveOperator (via EAITransformer), and EAIDatabase is a child of EAIResource, it is not necessary to have a specific additional association from EAIDBTransformer to EAIDatabase. In fact, having the specific association hides the fact that an EAIDatabase is really just in the role of one of the resources of the EAIDBTransformer operator (which may be important to a tool which is managing the general allocation of resources to operators).

Recommendation: 
Remove the "database" association from Figure 6-30. Instead, add a constraint that "An EAIDBTransformer has exactly one resource, which is an EAIDatabase", with corresponding OCL:

(self.resources->size() = 1) and (self.resources.oclIsKindOf(EAIDatabase)) 

Remove the "database" association from Figure 6-30. Instead, add a constraint that "An
EAIDBTransformer has exactly one resource, which is an EAIDatabase", with
corresponding OCL:
(self.resources->size() = 1) and (self.resources.oclIsKindOf(EAIDatabase))

Document: UML Profile and Interchange Models for EAI 
Section: 6.4.1.6 (EAIAggregator) 

Description: 
Figure 6-31 in Section 6.4.1.6 shows an unnamed association between EAIMessageAggregation and EAIMessageContent. However, this is part of the dynamic state of an EAI aggregator operator, not part of the specification of the operator. An instance of EAIMessageAggregator, with one or more EAIMessageAggregations is a SPECIFICATION of an EAI aggregator operator, not the operator itself, and therefore should not include the dynamic state of the operator.

Recommendation: 
Remove the association from Figure 6-31. 

Recommendation: 
Remove the association from Figure 6-31. 

Proposed Resolution:
Remove the association between EAIMessageAggregation and EAIMessageContent from the metamodel shown in Figure 6-31. (Also remove EAIMessageContent from the diagram but not, of course, from the model.)
6.4.1.9 	EAISubscriptionOperator

Document: UML Profile and Interchange Models for EAI 
Sections: 6.4.1.7 (EAIRouter) and 6.4.1.10 (EAITimer) 

Description: 
The specification of EAIRouter and EAITimer as compound operators does not correctly follow the FCM semantics for FCMCommands (which is the parent of EAICompoundOperator), for two reasons.

1. In order to promote the terminals of the primitive operators contained in the compound operator to terminals of the compound operator, there must be EAISources and EAISinks in contained in the compound operator corresponding to the external terminals. These are not specified in the discussion of the EAIRouter and EAITimer compounds.

2. An FCMCommand is a specialization of an FCMFunction, which invokes a single FCMOperation (see Figure 6-2). The content of the FCMCommand is simply a means to implement this operation. The expected FCM semantics are thus that, when all the inputs are provided, the operation is invoked, producing the specified outputs (via the internal composition, in the case of an FCMCommand). However, the semantics of EAIRouter and EAITimer, as described in Sections 6.4.1.7 and 6.4.1.10, are really to provide the functionality of the contained primitive operators as, effectively, multiple operations of the compound operator. This is not consistent with the FCM semantics, which implies a that an FCMCommand implements a single function from inputs to outputs.

Recommendation: 
Do not implement EAIRouter or EAITimer as compound operators. Instead, simply provide the component primitive operators, as appropriate. (See subsequent issues for more detailed recommendations.)

Document: UML Profile and Interchange Models for EAI 
Section: 6.4.1.7.1 (EAIRouterUpdate and EAIBroadcaster) 

Description: 
From the point of view of an EAIRouterUpdate, the "routingTargets" association on its EAIRoutingTable, as shown in Figure 6-33 in Section 6.4.1.7.1, is dynamic state and therefore not appropriate for a metamodel. From the point of view of an EAIBroadcaster, the "routingTargets" of its EAIRoutingTable may also be dynamic state (if added by an EAIRouterUpdate). However, it is also desirable to be able to statically specify, in the message-flow model, the connection of EAILinks to an EAIBroadcaster. Since an EAIBroadcaster is defined to have its own output terminal, one would assume that these static EAILinks would be connected to it. Do the terminals so connected also need to be statically specified in the EAIRoutingTable? This would be the only reason to keep the "routingTargets" association in the metamodel.

Recommendation: 
Remove the "routingTargets" association from Figure 6-33. Further, make EAIRoutingTable a  child of EAIResource and remove both the "routingTable" association (between EAIRouterUpdate and EAIRoutingTable) and the currentRoutingTable association (between EAIBroadcaster and EAIRoutingTable), instead adding the constraints that EAIRouterUpdate and EAIBroadcaster each have exactly one resource, which is an EAIRoutingTable.

The semantics for EAIRouterUpdate remains essentially unchanged. Define the semantics for EAIBroadcaster as follows: 

The target terminals of any EAILinks connected to the output terminal of an EAIBroadcaster are added to the EAIRoutingTable for that EAIBroadcaster as the initial set of routing targets. This set may be changed by the operation of an EAIRouterUpdate operator. When a message is received on the input terminal of an EAIBroadcaster, dynamic EAILinks are established between the output terminal of the EAIBroadcaster and each of the terminals in the current set of routing targets of the EAIRoutingTable of the EAIBroadcaster. The input message is then copied to the output terminal and thus sent to each of the routing targets.

Issue: Redundancy of EAIRouterUpdate/EAIBroadcaster with EAISubscriptionOperator/EAIPublicationOperator 
Document: UML Profile and Interchange Models for EAI 
Section: 6.4.1.7.1 (EAIRouterUpdate and EAIBroadcaster) 

Description: 
Particularly without the enclosing EAIRouter compound operator (see earlier issue on "The specification of EAIRouter and EAITimer as compound operators"), the EAIRouterUpdate/EAIBroadcaster operator pair update is pretty much redundant with the EAISubscriptionOperator/EAIPublicationOperator pair. Providing the simplified "subscription" model of EAIRouterUpdate does not seem worth the price of complicating what could be a very simple but still useful EAIBroadcaster concept.

Recommendation: 
Eliminate the EAIRouterUpdate operator and the concept of the EAIRoutingTable. Instead, define an EAIBroadcaster to simply be a primitive operator with a single input terminal and a single output terminal, with the semantics of copying each message received at the input terminal to the output terminal. The EAIBroadcaster then provides a simple "hub" capability for providing fan-in/fan-out connection points in a message flow. (The name "EAIBroadcaster" is more appropriate than "EAIRouter" for this semantics.)

(Note that, if this recommendation is adopted, it makes moot the previous issue on "Inclusion of the dynamic state "routingTargets" for the EAIRoutingTable".)

--

Reject. This is a greater change to the submission than is necessary for finalization. If a modeler does not wish to use EAIRouterUpdate, it can simply be ignored. With the changes proposed in the resolution to Issue 4969, an EAIBroadcaster (renamed EAIRouter) can also be used, if desired, as a simple hub independently of EAIRouterUpdate

Document: UML Profile and Interchange Models for EAI 
Sections: 6.4.1.8 (EAISubscriptionOperator) and 6.4.1.9 (EAIPublicationOperator) 

Description: 
The concept of a subscription table is discussed in Sections 6.4.1.8 and 6.4.1.9 as if the table was a reified entity in the metamodel (and, in fact, the class name "EAISubscriptionTable" is used in Section 6.4.1.9). However, Figure 6-35 in Section 6.4.1.8 and Figure 6-40 in Section 6.4.1.9 show, instead, the subscription table defined as individual associations from EAISubscriptionOperator and EAIPublicationOperator to EAISubscription. Not only does this define dynamic state rather than metadata, it defines DIFFERENT dynamic states for the two operators, rather than the single shared table that is necessary.

Recommendation: 
Remove the "subscriptionTable" association (between EAISubscriptionOperator and EAISubscription) and "currentSubscriptions" association (between EAIPublicationOperator and EAISubscription) from Figures 6-35 and 6-40. Instead, define an EAISubscriptionTable class as a child of EAIResource and put constraints on EAISubscriptionOperator and EAIPublicationOperator that each has a exactly one resource, which is and EAISubscriptionTable. The class EAISubscription (Figure 6-37) is also no longer needed as part of the metamodel.

Resolution:
Remove the "subscriptionTable" association (between EAISubscriptionOperator and
EAISubscription) and "currentSubscriptions" association (between
EAIPublicationOperator and EAISubscription) from Figures 6-35 and 6-40. Instead,
define an EAISubscriptionTable class as a child of EAIResource and put constraints on
EAISubscriptionOperator and EAIPublicationOperator that each has a exactly one
resource, which is and EAISubscriptionTable. The class EAISubscription (Figure 6-37) is
also no longer needed as part of the metamodel.

Document: UML Profile and Interchange Models for EAI 
Section: 6.4.1.8 (EAISubscriptionOperator) 

Description: 
Section 6.4.1.8 states "There could be some indirection in the specification of the rules and terminl [of an EAISubscriptionFormat], indicated by subscriptionModes." There is an attribute "subscriptionMode" (singular) shown in Figure 6-36 with a type "SubscriptionModes" (plural), but no further definition is given for SubscriptionModes. This provides no information on what "subscription modes" really are, or how they indicate the "indirection in the specification."

Recommendation: 
Either define the type SubscriptionModes and clarify its semantics or eliminate the concept. 

Document: UML Profile and Interchange Models for EAI 
Section: 6.4.1.8 (EAISubscriptionOperator) 

Description: 
An EAISubscriptionFilter is shown in Figure 6-38 as a child of EAIFilter. As such, it already inherits a "filterCondition" association from EAIFilter (see Figure 6-26). Therefore, the additional "filterCondition" association shown in Figure 6-38 is unnecessary (and, indeed, would indicate that the EAISubscriptionFilter has two filter conditions, which does not seem to be the intent).

Recommendation: 
Remove the "filterCondition" association from Figure 6-38. Instead, add a constraint that the filterCondition of an EAISubscriptionFilter must be an EAISubscriptionRule.

(Note also that the multiplicity of the "filterCondition" association shown in Figure 6-38 is "1..n" [sic], while the multiplicity of the "filterCondition" association for EAIFilter is not shown in Figure 6-26, but is implied in the text to be "1..1". If the multiplicity of the EAIFilter association is ultimately made "1..*", then the constraint on EAISubscriptionFilter should be that all the filterConditions are EAISubscriptionRules. If the desire is to have a "1..1" multiplicity on the EAIFilter association, but still to have multiple EAISubscriptionRules for an EAISubscriptionFilter, then an EAICompositeSubscriptionRule needs to be defined to group multiple EAISubscriptionRules into one FCMCondition.)

----

Remove the "filterCondition" association from Figure 6-38. Instead, add a constraint that
the filterCondition of an EAISubscriptionFilter must be an EAISubscriptionRule.
(Note also that the multiplicity of the "filterCondition" association shown in Figure 6-38
is "1..n" [sic], while the multiplicity of the "filterCondition" association for EAIFilter is
not shown in Figure 6-26, but is implied in the text to be "1..1". If the multiplicity of the
EAIFilter association is ultimately made "1..*", then the constraint on
EAISubscriptionFilter should be that all the filterConditions are EAISubscriptionRules. If
the desire is to have a "1..1" multiplicity on the EAIFilter association, but still to have
multiple EAISubscriptionRules for an EAISubscriptionFilter, then an
EAICompositeSubscriptionRule needs to be defined to group multiple
EAISubscriptionRules into one FCMCondition.)

Document: UML Profile and Interchange Models for EAI 
Section: 6.4.1.8 (EAISubscriptionOperator) 

Description: 
Figure 6-39 in Section 6.4.1.8 shows EAITopicRule and EAIContentRule as children of EAISubscriptionRule. EAITopicRule is discussed in Section 6.4.2. However, there does not seem to be any discussion of what EAIContentRule is.

Recommendation: 
Describe the purpose and semantics of EAIContentRule. 

Document: UML Profile and Interchange Models for EAI 
Section: 6.4.1.9 (EAIPublicationOperator) 

Description: 
Section 6.4.1.9 asserts that a specialized EAIPublicationTerminal (stated to be a subclass of EAITerminal, though this is not shown in Figure 6-40) is needed because input messages to an EAIPublicationOperator are sent only to subscribers for which "the message conforms to the EAISubscriptionRule for that subscriber", unlike the behavior of a normal EAITerminal, "which sends a copy of the message to every target terminal". However, the EAILinks to the target terminals for messages output from an EAIPublicationOperator are not going to be statically modeled links, but are instead going to be "dynamic" EAILinks, somewhat like in the case of the "replyOut" terminal of an EAIRequestReplyOperator, determined by the current state of the subscription table for the EAIPublicationOperator. As in the case of an EAIRequestReplyOperator, it is therefore not necessary to have a specialized kind of terminal -- the specialized message distribution behavior is captured in the operator, not in the terminal.

Recommendation: 
Eliminate the EAIPublicationTerminal. Define the semantics of an EAIPublicationOperator as follows: 

When a message arrives at the input terminal of an EAIPublicationOperator, the EAISubscriptionRules for all subscriptions in the current state of the subscriptionTable are evaluated on the message. For each subscription for which the rule is true, a dynamic EAILink is established from the output terminal of the EAIPublicationOperator to the subscriber EAITerminal from the subscription. The input message is then copied to the output terminal and thus distributed to each subscriber.

Resolution:
Eliminate the EAIPublicationTerminal. Define the semantics of an
EAIPublicationOperator as follows:
When a message arrives at the input terminal of an EAIPublicationOperator, the
EAISubscriptionRules for all subscriptions in the current state of the subscriptionTable
are evaluated on the message. For each subscription for which the rule is true, a dynamic
EAILink is established from the output terminal of the EAIPublicationOperator to the
subscriber EAITerminal from the subscription. The input message is then copied to the
output terminal and thus distributed to each subscriber.

Document: UML Profile and Interchange Models for EAI 
Sections: 6.4.1.10.1 (EAITimeSetOperator) and 6.4.1.10.2 (EAITimeCheckOperator) 

Description: 
Figure 6-42 in Section 6.4.1.10.1 and Figure 6-45 in Section 6.4.1.10.2 show the  individual associations from EAITimeSetOperator and EAITimeCheckOperator to EAIMessageTimerCondition. Not only does this define dynamic state rather than metadata, it defines DIFFERENT dynamic states for the two operators, rather than the single shared table that is necessary.

Recommendation: 
Remove the "timeSetConditions" association (between EAITimeSetOperator and EAIMessageTimerCondition) and "timeCheckConditions" association (between EAITimeCheckOperator and EAIMessageTimerCondition) from Figures 6-42 and 6-45. Instead, define an EAITimerConditionTable class as a child of EAIResource and put constraints on EAITimeSetOperator and EAITimeCheckOperator that each has a exactly one resource, which is and EAITimerConditionTable.

This and the associated issue 4976 refer to section 6.4.1.10.1, but 02-02-02.pdf has no
such section.
Section 6.4.1.11 - EAI Timer, has a subtitle TimeSetOprerator
Section 6.4.1.12 is entitled EAITimeCheckOperator
Section 6.4.1.13 is entitled EAITimer, with no subtitle.
There is a corruption of the numbering here somehow.
For its resolution, I suggest renumbering/reorganizing existing text:
Rationale: EAITImer is composed of EAITimeSetOperator & EAITimeCheckOperator so
arrange it as such.
Revise text and diagrams.

Document: UML Profile and Interchange Models for EAI 
Sections: 6.4.1.10.1 (EAITimeSetOperator) 

Description: 
Section 6.4.1.10.1 states that an EAITimeSetOperator "processes a _message_ (EAIMessageTimerCondition)..." (emphasis added). However, in Figure 6-43, EAIMessageTimerCondition is defined as a child of FCMCondition, not EAIMessageContent. Further, under the Constraints heading it is stated that "No more than one EAIMessageTimerCondition can apply to any single message in the timeSetConditions." But, as shown in Figure 6-42, the timeSetConditions are themselves EAIMessageTimerConditions, not messages, so it is not at clear what the constraint means.

EAIMessageTimerCondition seems to be part of the dynamic state of a time-set operator, not its specification. What is needed instead really is a message format for representing a timer condition.

Recommendation: 
Replace the EAIMessageTimerCondition with an EAITimerConditionFormat class that is a child of EAIMessageContent and has "timerCondition" and "correlationCondition" associations with FCMCondition.

Document: UML Profile and Interchange Models for EAI 
Section: 6.4.2 (Topic-based publish/subscribe) 

Description: 
Section 6.4.2.2 discusses the relation between topic-based publishers and subscribers. However, the semantics of an EAIPublicationOperator (see Section 6.4.1.9) require that a message conform to an EAITopicRule (a kind of EAISubscriptionRule) in order to be published on a topic. But it is not clear how to determine that a message is on a topic just from looking at that message. Presumably, messages produced by an EAITopicPublisher (Section 6.4.2.1) are somehow tagged as being on a specific topic, but this is not said explicitly.

Recommendation: 
At the very least, explicitly state in Section 6.4.2.1 that messages produced by an EAITopicPublisher are such that they satisfy the EAITopicRule for a one or more EAITopics relevant to the EAITopicPublisher. However, if the EAIPublicationOperator can then determine topic(s) for a message just by evaluating a condition on the message, it would seem that the topic(s) must be encoded in the message content someplace, in which case it is unclear what the difference is between an EAITopicRule and an EAIContentRule. Perhaps it would be best just to eliminate EAIContentRule, regarding this as being covered by the general case of EAISubscriptionRule, and have EAITopicRule as a specialized EAISubscriptionRule for which the condition is that the message is on one of a given set of topics. In this case, an association should be added from EAITopicRule to EAITopic with a multiplicity of "1..*".

Resolution: 
The relationship between an EAITopicPublisher and an EAITopicRule is, in fact, discussed in Section 6.4.2.3. Note, however, that some confusion may be caused by the fact that that Figure 6-48 is incorrectly a repetition of the diagram in Figure 6-49. Figure 6-48 should instead show the derived association of an EAITopicRule to the EAITopics it allows (which is, an association with multiplicity 0..*, as shown in Figure 6-49).

Document: UML Profile and Interchange Models for EAI 
Section: 8.2 (Terminals) 
  
Description:  
The first paragraph of Section 8.2 describes the "prototypical example" of the notation for terminals shown in Figure 8-1 as follows: "This shows a primitive operator with two input and two output terminals. The output terminals are of the same kind, but the input terminals are not (one is known to be a queued terminal, even though they both handle the same kind of message format). The names of the terminals are, in this case, label1 and label2."

This description has two problems: 

o The diagram only shows one input terminal (the queued terminal is not shown). 
o The text only lists two of the three terminal labels (the label "outName2" for the second output terminal is not listed.

Recommendation: 
1. Show a queued input terminal on Figure 8-1. 
2. List all the terminal names, identifying which are the names of input terminals and which of output terminals (if possible, use better names, too).

This description has two problems:
The diagram only shows one input terminal (the queued terminal is not shown).
The text only lists two of the three terminal labels (the label "outName2" for the
second output terminal is not listed.  Recommendation:
1. Show a queued input terminal on Figure 8-1. 2. List all the terminal names, identifying which are the names of input terminals and
which of output terminals (if possible, use better names, too).

Document: UML Profile and Interchange Models for EAI 
Section: 8.3.2 (Transformers and Database Transformers) and others 
  
Description: 
Under the Constraints heading in Section 8.3.2 it states that "The input terminal must be labelled 'in' and the output terminal must be labelled 'out'." However, there is no constraint on the names of the terminals of EAITransformers in the metamodel (see Section 6.4.1.4).

(Similar constraints appear in Sections 8.3.3, 8.3.4, 8.3.5, 8.3.6, 8.3.7, 8.3.10, 8.3.11, 8.3.12, 8.3.15, 8.3.16 and 8.3.17 without corresponding constraints in the metamodel.)

Recommendation: 
Unless there an overriding notational reason can be stated for requiring specific names for terminals, do not require names when they are not required by the metamodel. (Though it might be appropriate to recommend specific consistent naming conventions.)

Resolution:
Unless there an overriding notational reason can be stated for requiring specific names
for terminals, do not require names when they are not required by the metamodel.
(Though it might be appropriate to recommend specific consistent naming conventions.)

Document: UML Profile and Interchange Models for EAI 
Section: 8.3.2 (Transformers and Database Transformers) 
  
Description:  
The last constraint in Section 8.3.2 states that "For database transformers, there must be a directed association to a database resource (i.e., a class with stereotype <<Database>>). This should be labeled 'database'."

In the second sentence, it would seem that "this" refers to the datanase resource or the directed association. In reality, it is the rolename of the resource that should be "database".

Recommendation: 
Change the second sentence to: "The rolename of the database resource must be 'database'". 

Change the second sentence to say that the rolename of the database resource must be
'database'.

Document: UML Profile and Interchange Models for EAI 
Section: 8.3.3 (Filters) 
  
Description:  
Section 8.3.3 states that a filter has two output terminals, labeled "true" and "false", and, if a message content meets the filter criteria, then "the content is sent to the 'true' output terminal, otherwise it is sent to the 'false' output terminal." However, this is inconsistent with Section 6.4.1.1 on EAIFilter in the metamodel, which states that "A filter's output is a copy of its input. No output occurs if the input message does not satisfy the filter condition." There is no semantics given for a "false" terminal.

Recommendation: 
Having "true" and "false" outputs on a filter is quite useful. The semantic descriptions in Section 6.4.1.1 should be changed to reflect the semantics of true/false output terminals

Resolution:
Having "true" and "false" outputs on a filter is quite useful. The semantic descriptions in
Section 6.4.1.1 should be changed to reflect the semantics of true/false output terminals.

Document: UML Profile and Interchange Models for EAI 
Section: 8.3.4 (Streams) 
  
Description: 
Section 8.3.4 describes the semantics of stream operators as follows: 

"Messages that arrive from the input terminal do not get passed on, but instead are stored in a buffer or some other appropriate data structure. The emit operation defines the algorithm used to decide when and in what order messages get emitted to the output terminal. Abstractly, one can imagine a loop that continually calls the emit operation. It returns a message to be put on the output terminal at each call. There may be a delay between its being called and its returning a message."

Some issues with this description are: 

1. The concept of "a loop that continually calls the emit operation" does not clearly seem to reflect the semantics described in Section 6.4.1.2 (see Issue 4959 on the lack of clarity of the semantics in that section) and does not reflect the underlying Flow Composition Model semantics of the metamodel.

2. Section 8.6.2 states that, for an EAIStream, "12. The emissionCondition of the operator maps to the emit operation in the corresponding class". However, in Section 8.3.4, the emit operation is not a condition (which would return a Boolean) but, rather, has a message content return type.

3. How is the "buffer or some other appropriate data structure" specified? Section 6.4.1.2 (EAIStream) shows the buffer as a set of EAIMessageContent, but this is not appropriate for the metamodel and should rather be addressed as a model-level concern (see Issue 4962).

Recommendation: 
Consistent with the recommendations given for Issues 4959 and 4962: 

1. Require an "insert" operation that takes a single argument of the input content type. This operation maps to the "streaming algorithm" of the EAIOperation of the EAIStream and is triggered when a message arrives on the input terminal. It defines where the incoming message content is placed in the stream operator's buffer.

2. Define the emit operation to have a Boolean result. This operation maps to the emissionCondition of the EAIStream. The emit operation determines whether the top element of the buffer is emitted or not.

3. State that a buffer data structure for a stream class may be explicitly modeled, in order to provide more precise specification of the insert and emit operations. However, this model is considered part of the specification of the EAIOperation and EAICondition (emissionCondition) of the stream, and is not otherwise mapped explicitly into the EAI metamodel.

Document: UML Profile and Interchange Models for EAI 
Section: 8.3.5 (Post Daters) 
  
Description: 
Section 8.3.5 states that "As the definition for 'emit' is fixed for post daters, only a definition for 'setTimingCondition' should be provided." It is not clear that this description is consistent with the description of the semantics for EAIPostDater in Section 6.4.1.3, since the metamodel still requires the specification of an emissionCondition (inherited from EAIStream). (See also Issue 4693, "Unclear semantics description for EAIPostDater".)

Recommendation: 
Either allow an emit operation on a post dater, to permit the possibility of immediate emission, or change the metamodel to not require an emissionCondition on an EAIPostDater. (See also the recommendation for Issue 4693.)

Document: UML Profile and Interchange Models for EAI 
Section: 8.3.5 (Post Daters) 
  
Description: 
In the Section 6.4.1.3, the timing condition for a message received by an EAIPostDater is described as possibly entailing "a derivation from the content of the input message by a 'timerMapping'." This seems to indicate that a "timerMapping" is a mapping from a message (or message content) to a timing condition. However, while the "setTimingCondition" operation, which reflects the timerMapping, specified for a Post Dater class in Section 8.3.5 has a message content argument, it produces no result.

Recommendation: 
To correctly reflect the timerMapping, it would seem that the setTimingCondition operation should instead be "createTimingCondition", returning a TimingCondition. A model could also include a specification of exactly what a TimingCondition is, if this is necessary for precision of specification (though this would not be mapped to the metamodel, except as part of the specification of the FCMMapping that is the timerMapping).

Resolution:
This issue is covered by the new semantic approach described in the resolution to Issue 5227

This model needs to be updated to contain additional mapping information
from source language files.  Issue discovered at implementation time.


This description has 3 problems:
   Introduce Bi-DirectionStringTD class
   Add attributes to InstanceTDBase, PlatformCompilerInfo, StringTD, and
   DateTD classes
   Change structure of NumberTD classes.


Recommendation:
Update model to include missing information

Description:
This model needs to be updated to contain additional mapping information
from source language files.  Issue discovered at implementation time.


This description has 1 problem:
   Change association type for TDLangComposedType to TDLangElement



Recommendation:
Update model to include missing information.

Discovered model needs to be updated to contain additional mapping
information from original COBOL source files.  Issue discovered at
implementation time.


This description has 1 problem:
   Introduce a method to COBOLSimpleType class


Recommendation:
Update model to include missing information.

Description:
Discovered model needs to be updated to contain additional mapping
information from original C source files.  Issue discovered at
implementation time.


This description has 1 problem:
   Update associations between two C Classes.


Recommendation:
Update model to include missing information

Description:
Discovered model needs to be updated to contain additional mapping
information from original MFS source files.  Issue discovered at
implementation time.


This description has 3 problems:
   Introduce DIVISION class
   Add more attributes to classes
   Update association to TDLang


Recommendation:
Update model to include missing information

Description:
Discovered model needs to be updated to contain additional mapping
information from original BMS source files.  Issue discovered at
implementation time.


This description has (X number of) problems:
   Add more attributes to classes
   Update association to TDLang



Recommendation:
Update model to include missing information.

Description:
Add additional subclasses to TDLangElement.


This description has 1 problem:
   Add BMS and MFS models under TDLangElement



Recommendation:
Update figure to include missing information.

Description:
Fill in additional information in sample.


This description has 1 problem:
   Fill in additional information in sample.



Recommendation:
Update sample to include missing information

Document: UML Profile and Interchange Models for EAI 
Sections: 8.3.6 (Source Adapters), 8.3.7 (Target Adapters), 8.3.8 (Call Adapters), 8.3.9 (Request/Reply Adapters) 
  
Description: 
Sections 8.3.6 to 8.3.9 describe adapters as kinds of operators. However, in Sections 6.3.11.1 through 6.3.11.4, the corresponding metamodel elements are NOT defined as subclasses of EAIOperator, but rather are directly subclasses of FCMFunction. (Actually, in Section 6.3.11.4, EAIRequestReplyAdapter actually is diagrammed as a subclass of EAIPrimitiveOperator, but it is described in the text as being a subclass of FCMCommand and should probably really be a subclass of FCMFunction like the other adapters -- see Issue 4859). This would seem to indicate that adapters are NOT operators, since not all their terminals are EAITerminals.

Recommendation:
Do not describe adapters as operators. Move the description of adapters out of Section 8.3 on operators. 

Document: UML Profile and Interchange Models for EAI 
Section: 8.3.9 (Request/Reply Adapters) 
  
Description: 
Figure 8-10 repeats the <<LangElement>>s Y3 and Y8 from Figure 8-9, but not the <<RequestFormat>> Y9. 

Recommendation: 
Show Y9 on Figure 8-10. 

Document: UML Profile and Interchange Models for EAI 
Sections: 8.3.10 (Sources and Queued Sources), 8.3.11 (Sinks and Queued Sinks) 
  
Description: 
Sections 8.3.10 and 8.3.11 describe sources and sinks as kinds of operators. However, in Section 6.3.6, the corresponding metamodel elements are NOT defined as subclasses of EAIOperator, but rather are directly subclasses of FCMSource and FCMSink. Indeed, EAI sources and sinks cannot be operators, if they are really to serve the role of FCMSources and FCMSinks (which is to provide the internal view within an FCMCommand of the external terminals of that FCMCommand), since operators are FCMFunctions, and FCMSources and FCMSinks are not.

Recommendation:
Do not describe sources and sinks as operators. Move the description of sources and sinks out of Section 8.3 on operators.

Resolution:
Issues 5245 & 5247 relate to parallel inconsistencies in the profile definitions of Adapters
and Sources & Sinks. The isssue raiser recommends the same solution for each - to move
them to their own sections at the same level as Operators - as they are in the metamodel
definition.
I agree with this proposal that we regard the metamodel as the master and rearrange the
profile definition accordingly. Each new section involves a considerable amount of
moving & renumbering sub-sections, Figures, Tables & lists in section 8.3. To ease the
task of the editor, i have merged the edits for these 2 issues (5245 & 5247) into one
series (below). I have also amended the Parent stereotypes in the table of mappings to
match the metamodel, in line with the issues raised. These particular details are not
mentioned by the issue raiser, but they are implied by his correction.

Document: UML Profile and Interchange Models for EAI 
Sections: 8.3.10 (Sources and Queued Sources), 8.3.11 (Sinks and Queued Sinks) 
  
Description: 
The constraints in Sections 8.3.10 and 8.3.11 require that queued sources and sinks have "a directed association to a queue resource". However, this is not shown in Figure 8-12 ("Class diagram for prototypical queued source") and there does not seem to be a sample diagram for a queued sink at all.

Recommendation: 
Draw the queue resource in Figure 8-12 and include a diagram with an example of a queued sink. 

Resolution:
Draw the queue resource in Figure 8-12 and include a diagram with an example of a
queued sink.

Document: UML Profile and Interchange Models for EAI 
Section: 8.3.12 (Aggregators) 
  
Description: 
In Figure 8-14, the name of the operation "aggregateCompleted" is inconsistent with the text and the metamodel and the operation name "aggregateToAggregate" is incorrect in the leftmost note.

Recommendation: 
Change "aggregateCompleted" to "aggregateComplete" in the operation definition. Change "aggregateToAggregate" to "addToAggregate" in the note.

Document: UML Profile and Interchange Models for EAI 
Section: 8.3.12 (Aggregators) 
  
Description: 
The metemodel for EAIAggregator in Section 6.4.1.6 allows a DIFFERENT aggregateComplete and addToAggregate condition for EACH aggregate being formed. However, Section 8.3.12 only provides for the specification of a one aggregateComplete and one addToAggregate operation for the entire aggregator. (These operations take a specific aggregate as an argument, but the BEHAVIOR of the operation will be the same for all aggregates.)

Recommendation: 
Define a new <<MessageAggregation>> stereotype. A class with this stereotype must have aggregateComplete and addToAggregate operations. Such a class maps to the EAIMessageAggregation metaclass (see Section 6.4.1.6). Require that a class with the stereotype <<Aggregator>> have associations with one or more <<MessageAggregation>> classes (note that multiple message aggregations can be achieved both by having an association with a multiplicity at the message aggregation end of greater than 1 or by having multiple associations with different message aggregation classes with different operator specifications).

(Also change mapping constraints 20 an 21 in Section 8.6.2 to be consistent with this.) 

Define a new <<MessageAggregation>> stereotype. A class with this stereotype must
have aggregateComplete and addToAggregate operations. Such a class maps to the
EAIMessageAggregation metaclass (see Section 6.4.1.6). Require that a class with the
stereotype <<Aggregator>> have associations with one or  <<MessageAggregation>> classes. (Note that multiple message aggregations can be
achieved both by having an association with a multiplicity at the message aggregation
end of greater than 1 or by having multiple associations with different message
aggregation classes with different operator specifications).
(Also change mapping constraints 20 and 21 in Section 8.6.2 to be consistent with this.)

Document: UML Profile and Interchange Models for EAI 
Section: 8.3.12 (Aggregators) 
  
Description: 
The second constraint in Section 8.3.12 (Aggregators) states: "The content format of in and out must match the format of the parameter and result, respectively, of the transform operation." However, aggregators do not have "transform" operations.

Recommendation: 
Change the constraint to describe the types required for the parameters and results of the addToAggregate, aggregateComplete and aggregate operations required on an aggregator

Change the constraint to describe the types required for the parameters and results of the
addToAggregate, aggregateComplete and aggregate operations required on an
aggregator.

Document: UML Profile and Interchange Models for EAI 
Section: 8.3.18.2 (Collaboration diagrams) 
  
Description: 
The arrows for synchronous and asynchronous messages shown in Figure 8-24 do not use the correct UML 1.4 notation. 

Recommendation:
Use the correct UML notation in Figure 8-24: an arrow with a filled, solid arrowhead for synchronous and an arrow with a stick arrowhead for asynchronous (see Section 3.72.2.1 of formal/01-09-67).

Use the correct UML notation in Figure 8-24: an arrow with a filled, solid arrowhead for
synchronous and an arrow with a stick arrowhead for asynchronous (see Section 3.72.2.1
of formal/01-09-67).

End Section 1.2: the filenames for DTD and XMI zip files are not correct

Linda Heaton of the OMG editorial staff confirms that the files are still at ad/2002-80-25
as shown in section 1.2.

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.

Resolution
All issue resolutions have used the MOF profile. This has provided the opportunity to fix the visible form of these issues across the affected part of the specification.  'Non-visible' problems will be fixed as a quality control measure

End 3.0: slightly wrong to say it's delivered as a metamodel and profile - there are several.

Section 3.1 Should refer to UML Profile for MOF (part of EDOC)
Packages are structural to the resultant model and should not be scoped by what can fit onto one diagram. 

Section 4.1: XMI 1.2 is based on MOF 1.4 so to include it with MOF 1.3 and UML 1.3 is inconsistent.

XMI 2.1 does not explicitly reference MOF 1.3. The submitted XMI files are based on
MOF 1.3. Hence, the submission is correct as it stands.

Section 4.2-4.3
Unclear what visualization is required above UML.
Hence point out that any UML compliant tool will also be EAI Profile compliant?
Requiring that tools enforce constraints goes further than MOF and is hard when the constraints have not been formally specified in either the spec nor the XMI files.
According to 5.1.1 Activity and Collaboration representations are alternatives. This is not reflected in section 4.

Resolution:
Update sections 4.2.2 and 4.3.2 as below.
In section 4.2.1 and 4.3.1, delete: Furthermore it checks the well-formedness
constraints that the Profile defines.
In section 4.4 delete: It also checks the well-formedness constraints defined by
the metamodel.
Section 4 does give examples of compliance with separate compliance with
the Collaboration or Activity representations.

Section: 4.3 It's unclear to just refer to 'UML Activity Profile' and 'UML Collaborations Profile' without the 'for EAI' qualification.

Section 4.4 does not include the CAM metamodel - is this not normative?

Section 2.3 of EDOC explains that architectures will be defined at the E/CCA level and thereby mapped to business processes etc. CCA components will then be 'mapped down' to various technology choices with FCM (and hence EAI) being one of them. EDOC contains only a proof of concept mapping for Business Process to FCM and not CCA to FCM.
This section also states that "Normative mappings from ECA to these models in the subject of future RFPs." It would seem that the current EAI RFP does not provide such a normative mapping (which I find disappointing though to be fair it was not a RFP requirement) and it should be made clear that this means one still has neither a development lifecycle nor a mechanism for either developing nor even recording the refinement from ECA (Enterprise/business architectures) to EIA technology. Just defining a correspondence between concepts or a means of representing EAI artefacts as CCA Components (6.5) does not achieve that. In particular it does not show how an arbitrary CCA design (possibly with defined constraints) can map to a EAI technology implementation. Without this, it is hard to evaluate the adequacy of the EAI proposal.

FCM "is a low-level metamodel focused on the middleware machinery for executing message flows. Higher levels of abstraction can be built upon the FCM for integrating a whole range of technologies and runtime environments:" (examples include Message Brokering). FCM allows the definition of hierarchic decompositions and the mapping of flows to FCMComponents.
EAI actually extends FCM rather than creating a higher level of grouping/abstraction

The resolution to issue 4854 provides further detail on the relationship between CCA and EAI. The relationship between FCM and EAI is detailed in section 6.1

Section 5.1.2: states that the language metamodels in section 14 are non-normative; however they are the basis of compliance points in section 4!

Section 5.1.4: the spec does not permit the use of CWM transformations due to the inconsistent way of modeling information resources

Resolution:
The purpose of the CWM model and CAM models are distinct and different.
They were not designed with integration of the two models in mind.
However, for the sake of integrating any existing non-normative CWM
COBOL models with CAM’s normative COBOL model, a converged model of the
two COBOL models will be produced to ease the transition to CAM’s COBOL
model. The proposed integrated model will be non-normative and is
suggested as a temporary solution.

Section 5.1.5, Section 6: update to adopted version of EDOC (ad/01-08-19 for the convenience document including errata).

Section 5.1.6: response re extending MOF doesn't address the requirement to conform to it (e.g. the metamodels should be MOF compliant - which they're not quite: they do not comply with the UML Profile for MOF in EDOC).

Section 5.4.3 para 2: why the mention of IBM CWM products?

Section 5.4.3 while comprehensive is not at all convincing and smacks of NIH. What is someone wanting to manage the mapping of EAI to databases supposed to do/ These are not at all isolated universes. If CAM and CWM are both needed to meet different perspectives then there should be a mapping and moreover a common core. It's like saying in a UML context that there should be no relationship between state charts and class diagrams since they address different perspectives.
In fact datawarehousing is just an example of application integration and CWM even supports event-based communication (in the Warehouse Process submodel).
Does not allow the use of CWM transformations.
Inconsistent use of data vs programming constructs (e.g. for C++) operations etc

Section 5.5: ebXML is at a different level to and encompasses many of the other B2Bstandards mentioned.
What's the relationship of EAI to BPML? And Workflow Process Definition?

Use of the term 'UML Collaboration Profile' is misleading and too general and should include 'EAI' somewhere

Section 6.2.5: To  say that "an FCMSouce implements an FCMOperation" is a misreading of the model in Figure 2 (though not helped by the poor association end name) which should be read as "FCMOperation plays the implements role in its association with FCMsource" i.e. it is the FCMOperation that implements the FCMSource.

Section 6.3.2 Figure 6-7. This should use the UML Profile for MOF (defined in EDOC) to depict the metamodel (i.e. EAISyncMode should have stereotype <<enumeration>> and each value should be depicted as an attribute).

Section 6.3.2: Is an EAILink constrained to only link EAINodes?

Section 6.3.3: the third constraint in particular needs more description, especially to describe in terms of the metamodel the notion of a Terminal being on the 'exterior of a node'.

Section 6.3.4: reference to "MOM infrastructure" seems too technology-specific.

Section 6.3.4 introduces a number of new classes (EAIParameter, EAIMessageContent etc) with no real description. (in particular the attributes of EAIMessageContent are a mystery).

Section 6.3.4: It would make sense for EAIMessagePart.header to reference EAIHeader rather than its superclass EAIMessageElement: would it ever make sense for it to reference another type of EAIMEssageElement

Resolution:
The issue is a good one, but the suggestion is incorrect – not all headers need to subclass
from EAIHeader, which is specifically provided to cope with replies and fault. Some
headers (such as WS-Routing, etc) do not deal with these issues. Instead we insert
explanatory text into EAIHeader.

Section 6.3.4: There should be constraints on the EAIMessageElements referred to by an EAIHeader (e.g. that they do allow navigation to Terminals and that they do not themselves have headers?) The derivations for the references to Terminals should be defined.

Association to EAITerminal has been removed (resolution to issue 4874), so the
requirement to specify this derivation has gone away. Otherwise, I agree.

Section 6.3.4 EAIExceptionNotice: Again refers to "MOM infrastructure". How if at all is the inherited reference EAIMessageContent.part used?

Section 6.3.4 XML Elements: XMI Production of XML Schema is now an adopted specification

It was agreed that this section was not intended to be normative, and that it should be removed to remove any potential for conflict.

Figure  6-12, though described as "showing a linkage"  is in fact implicitly proposing a change to that specification through adding the new generalizations shown. This should be made a lot clearer. IMO it is not an appropriate change since it does not apply to other uses of that XML Schema metamodel and so EAI should introduce (one-way) associations instead of the generalizations that let (for example) a TDLangClassifier optionally refer to a XSDType.

Section 6.3.4 XML Elements: CWM also has a XML metamodel which might be more appropriate through its support for transformations. Justify not using it

See discussion for issue 5375

Section 6.3.7: I would expect Figure 15 to show the association with EAIMessage (which is needed to implement the constraint).

Reject. This is operational information.
Should we remove maxdepth?

Section 6.3.8, first constraint: an EAILink cannot be an instance of a Terminal. Presumably the target of the EAILinks must be instances of EAIQueuedInputTerminal. And there should be a similar constraint on "all links to an EAIQueuedInputTerminal"?

Section 6.3.9, refinement relationships: this is the first mention of refinement relationship and the topic needs some general introduction/context including how refinement is represented in the metamodel

Section 6.3.10, para 2: should be "EAICompoundOperator".

Section 6.3.10.1: the derivations should be more formally defined, especially "defines": the semantics of this are also unclear (especially since EDOC does not describe FCMType).

The 'defines' association was erroneously labelled as derived in the original specification. The resolution to this issue is covered by the resolution to issue 4892

Section 6.3.10.2.1: what's the difference between EAIMessageFlow.operatorAnnottions and the reference FCMComposition.annotations which it inherits?

Explanation: EAIMessageFlow annotations are associated with EAI Operators, which are
subclasses of FCMNode. FCMComposition annotations are associated with
FCMComponent. Will remove inheritance from FCMAnnotation to prevent inheritance
of the association to FCMComponent.

Section 6.3.10.2.2: this really needs an example to help explain this. And detail for the derivation of promotedTerminal.

What is a 'CCA Component Library' - this is not described in EDOC? What is the motivation for this? How is the mapping formally represented? Why the different concepts? When would one define compositions via CCA and when via FCM/EAI Integration? Can CCA be thought of as a higher level architectural view on the FCM/EAI Integration model? If so is that not more important for the RFP scope?

·	Section 6.5.1.2, bottom p57: Implies that rather than EAI being just a low-level technology mapping for CCA, CCA components are required to provide the further detail of aspects such as transformations. Which means that EAI could be topped and tailed by CCA? A full example is needed.

Resolution:
This paragraph is just pointing out some potentials for specification of
transformations. Technology mappings export whatever functionality is
relevant to each technology layer, as such it is reasonable that information
from a CCA component may also map to EAI transformer implementations as is
implied. The only change recommended is to include "EAI

Section 7.2, last para: not clear without a clear understanding of the various products and their role (in EAI terms). E.g. IMS Connect, OTMA. It's also not clear how any connector built via the 'connector builder tool' fits into the picture. A diagram might help

Figure 7-5: <<Enumeration>> stereotype missing from two of the classes.

Section 7.3.3/4: Uses TDLangElement without any introduction

Section 7.3.4.13 The heading is wrong - it should refer to 'enumerated types' not 'stereotypes'.

Section 7.3.4.8: a 'parent' derived association should be defined to encapsulate the navigation described. Similarly in 7.3.4.11

Navigation is already provided by the normative TDLang model classes.

Section 7.3.5, p7-12: need to define "level-1 data structure" and "level-1 parent".

Figure 7-6: the associations are shown as derived (the '/') which is not correct.
Figure 7-6: the composition should be shown as {ordered}.

Section 7.3.8.4: Each instance of TDModelElement will represent EITHER a Classifier or an Element - not a combination (though an Element will in turn refer to its Classifier).
I think more explanation/example is needed for the difference between TDClassifier and TDLangElement (which does not have any concrete examples); and why mappings are not made at the Classifier as opposed to the Element level.

Section 7.3.9: it's confusing to imply this is a separate metamodel - it just describes how the 2 previous metamodels are used together

Section 7.3.11: Lots of problems with the XMI: it is not valid for showing the relationship between the TDLangElements and the TDLangClassifiers (in fact the XMI represents no relationship at all between them!): also it's wrong to show the SimpleInstanceTDs nested within the COBOLComposedType since there is no Composition (in fact no direct relationship at all in the metamodel) between them. Also defaultFloatType is not an attribute of SimpleInstanceTD but of PlatformCompilerInfo. And the SimpleInstanceTDs do not have the mandatory 'sharedType' reference, which would have been useful to see expressed, and none of the TDs have the mandatory 'platformInfo' reference.
Typos: the COBOLComposedType element is incorrectly terminated on the first line (just need to remove the "/") and 'AggregateInstanceTDBase' should be just 'AggregateInstanceTD'

The XMI should, I believe, be as below. An instance diagram would help undestanding!:
  <COBOLElement xmi.id='CE-1'name="NAME" instanceTDBase='AIT-1' tdLangSharedType='CCT-1'/>
  <COBOLComposedType xmi.id='CCT-1'>
     <TDLangComposedType.tdLangElement>
          <COBOLElement xmi.id='CE-2' name="FIRST" instanceTDBase='SIT-1' tdLangSharedType='CT-1'/>
          <COBOLElement xmi.id='CE-3' name="LAST" instanceTDBase='SIT-2' tdLangSharedType='CT-1'/>
     </TDLangComposedType.tdLangElement>
  </COBOLComposedType>
  <COBOLAlphaNumericType xmi.id='CT-1' name="PICX10" pictureString="PIC X10"/>

  <AggregateInstanceTD xmi.id='AI-1' languageInstance='CE-1' platformInfo='PC'/>
  <SimpleInstanceTD xmi.id='SIT-1' languageInstance='CE-2'/ sharedType='ST-1' platformInfo='PC'/>
  <SimpleInstanceTD xmi.id='SIT-2' languageInstance='CE-3' sharedType='ST-1' platformInfo='PC'/>
  <StringTD xmi.id='ST-1' nickname='COBOL PIC X10' width=10 addrUnit=byte encoding='ASCII'…./>
  <PlatformCompilerInfo xmi.id='PC' …../>

The above shows no top-level container. This lack of a packaging structure seems to be an omission from the metamodel.

Section 8.2: the example does not have 2 input terminals as claimed

Summary: P92 para 2: In UML, Operation already has a 'specification' property which should be used instead of attaching notes to the class.

Resolution:
Change text in section 8.1.1. to state that any definition of an operation used in operator
specifications must be provided as part of the specification of that operation. If tools do
not support the display of operations specifications on diagrams (as many don’t) a UML
note may be used in addition to repeat the definition on the diagram. Note that the
specification of operations in examples used in this document will always be relayed by
notes on the diagram.

Collaboration model: Describe the required properties of terminal-operator . Section 8: Does not describe the required (or otherwise) properties of the associations linking terminals and operators (multiplicity, navigability etc).

The associations are navigable only from operator to terminal, and have cardinality 1.
These markings (which never change) may be omitted from the diagram (tool permitting)
to avoid clutter. Any other properties are inconsistent with the profile.
Add text to this effect in Section 8.2

Collaboration model: Use of containment in UML Collaboration Diagrams. Section 8.3.18.2: 
UML Collaboration diagrams do not have the notion of containment. 
Also it's not clear how this notation, if supported, would map to the UML metamodel

UML does allow containment in Collaboration Diagrams. See, for example, p3.130 of the UML 1.4 spec. UML does allow containment in Collaboration Diagrams. See, for example, p3.130 of the
UML 1.4 spec. Rather containment is shown in the class diagram of Figure 85.

Collaboration model: Explain underscores on names in collaboration diagrams. Fig 8-23: should explain the use of underscores at the start of names. And the use of the names to represent the values.
The figure seems to use names such as 'true' to the association ends being connected which should be explianed

Resolution:
Underscores are there because the tool used to create the diagrams did not allow objects
on the same diagram to have the same name. There is already text explaining the naming
scheme used (see text below Fig 8.23 and text in section 8.3.18.6, which provides the
detailed constraints). This can be made clearer, perhaps, by making a forward reference
to the latter from the former.

In general it's not clear how the terminals are wired together: what Association does the Link shown represent?

Resolution:
The UML 1.4. metamodel requires links to be connected to associations. In this case, the
associations are redundant, but, of course, any UML tool strictly conforming to UML 1.4.
should force the link to be associated with an association. To get around this, we propose
that all EAI-UML models includes a class EAITerminal from which all Terminal classes
inherit, which has an association to itself with cardinality 0..* on each end, and whose
end names are left empty. All terminal to terminal links will be instances of this
association.
This is only required when using tools that strictly enforce UML 1.4.
An explanation to this effect should be provided in section 8.3.18.2.

8.5.1: Table 2 does not show the base classes for the stereotypes. 
Fig 93: <<LangElement>> is shown applied to both Attributes and Classes, which does not seem good practice.

Section 9: should be related to the EDOC Process Profile, and the mapping in EDOC Part II between that and FCM.

I propose no changes to the document to repsond to this issue, since the document already
answers the question.
I did consider whether the organizarion of the material in the document makes it more
difficult than necessary to follow the chain necessary to answer the queston, but on
reflection, i see no way to improve it without major disruption that would make the
document less readable overall.

Section 14: the metamodels start off by describing themselves in terms of "The .. metamodel is a MOF Class instance at the M2 level". This does not make sense. Possibly a MOF Model instance?

: CAM: COBOL Metamodel: Naming consistency: COBOLNumericType and COBOLNumericEditedType. Fig 14-1: Inconsistency e.g. COBOLNumericType.currencySymbol:char compared to COBOLNumericEditedType.currencySign:String
And random use of 'name' sometimes derived sometimes not.
It is not sensible to have VariableLengthArray as a subclass of FixedLengthArray (or vice versa - they are alternatives).

Naming consistency: COBOLNumericType and
COBOLNumericEditedType. Fig 14-1: Inconsistency e.g.
COBOLNumericType.currencySymbol:char compared to
COBOLNumericEditedType.currencySign:String
Response: Resolved in issue 5239 And random use of 'name' sometimes derived sometimes not.
Response: Use of derived is not random. Attributes are only marked
derived if they are inherited from a parent class.
It is not sensible to have VariableLengthArray as a subclass of
FixedLengthArray (or vice versa - they are alternatives).
Response: Both fixed and variable length arrays share a maximum upper
bound, while variable length arrays can have a minimum upper bound set
by a Occurs Depending On clause such that the size of the array does
not reach the maximum upper bound. Because both classes share the same
maximum upper bound property on class, one can be considered a
specialization of the other, i.e., a subclass.

Fig 14-9: Cderived has 2 references 'derives'. In any case it is not a sensible role name.

Fig 14-12: CunsignedLong should not be a subtype of CunsignedInt since it's a larger set: it should inherit from Clong. Likewise CunsignedLongLong should inherit from ClongLong.
Moreover Long should not inherit from Cint and CWChar not from CCHar.
Finally it's not clear what the dependency arrows mean.

14.3.1.11: (CsourceText). The granularity of the text is not clear (e.g. a parameter or a CField can in theory have its own CsourceText instance). Also the model has no obvious way of storing line numbers as claimed.