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.

Update to 14.3.1.11

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.

See issue 5240 for disposition

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

See issue 5240 for disposition

: 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).

closed, no change

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).

Updates to Section 6.3.4

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

Revise Section 6.3.4

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'.

Clarify constraints.

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?

See issue 4854 for disposition

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

see above

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

Accept change precisely as worded.

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

Revise Sections 6.3.9 and 6.3.2.

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

see above

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

Change text in Section 8.2 to read “1 input terminal”

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.

See issue 5244 for disposition

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

See issue 5243 for disposition

Section 7.3.3/4: Uses TDLangElement without any introduction

Swap order of presentation of TD and TDLang models.

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

See issue 5237 for disposition

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

More text and a diagram in Section 7.2.

· 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.

see above

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.

See issue 5237 for disposition

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

.

See issue 5237 for disposition

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

See issue 5237 for disposition

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

closed, no change

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

See issue 5237 for disposition

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"?

Insert the word ‘to’ between ‘be’ and ‘instances’

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

closed, no change

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

Update Section 6.3.4.3

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.

see above

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

see above

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

see above

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

closed no change

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).

see above

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?

Update Section 14

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

closed, no change

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

see above

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?

Update section 5.5

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

See issue 5353 for disposition

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).

see above

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

see above

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.

see above

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.

closed, no change

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.

Update section 3.

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.

Accept the issue but not the proposed resolution. Update text as below.

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

Update sections 4.2, 4.3 and 8.1.1

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

Replace text of constraints section.

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).

Update figure.

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

Update Section 4.4

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

Update sections 4.2.1 and 4.3.1

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

see above

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!

Remove compliance points related to Section 15.

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).

Update section 5.1.6.

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

Update references

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

Clarify the introductory wording to chapter 3.

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

closed, no change

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.

se above

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.

see above

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.)

see above

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.

Change Figure 8-14.

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.

seen above

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.

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.

Update model to include missing information.

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

Update model to include missing information

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.

see above

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.

Show Y9 on Figure 8-10.

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

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

Update model to include missing information

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.)

see above

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.

See issue 4976 for disposition

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

see above

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'".

see above

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.

See issue 5247 for disposition

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

Update sample 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.

Update figure 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.

Update model to include missing information.

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.)

see above

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.

see above

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.

Remove the association from Figure 6-31.

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".

Show a multiplicity of "1..1".

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).

see above

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.

see above

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"

see above

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.

Eliminate the constraint.

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).

see above

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.

List the constraints under the Constraints heading.

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.

see above

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).

see below

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...".

Accept the issue precisely as worded (note that this now refers to section 6.3.10.7)

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.)

see above

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.

See issue 5380 for disposition

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.

see above

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."

see above

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."

see above

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))

see above

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".

Make the multiplicity "1..1".

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".

Change the name to "EAISinkAdapter".

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'."

see above

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'."

see above

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.

See issue 5367 for disposition

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?

No Data Available

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.

All of these adapters should be subclasses of FCMFunction.

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.

see above

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.

see above

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.

Answered by resolution of Issue 5371

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.

see above

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))

see below

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.

see below

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.

Change text as follows.

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.

Covered by the resolution to issue 4873

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".)

see above

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.

see above

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.

see above

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.

Revise Contents page of part 4.

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 revised text for issue 5375

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.

See discussion for issue 5375

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

Duplicate of 4897

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).

Covered by the revised text for issue 4892

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

<remove section 6.3.4 XML Message Elements>

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.

see below