UML Profile for Enterprise Application Integration Avatar
  1. OMG Specification

UML Profile for Enterprise Application Integration — Closed Issues

  • Acronym: EAI
  • Issues Count: 148
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
EAI-134 what is a 'CCA Component Library' EAI 1.0b1 EAI 1.0 Resolved closed
EAI-133 Relationship between EAIMessageFlow annotations and FCMComposition annotati EAI 1.0b1 EAI 1.0 Resolved closed
EAI-132 Operators: Wording change EAI 1.0b1 EAI 1.0 Resolved closed
EAI-131 Clarify the meaning of refinement relationships EAI 1.0b1 EAI 1.0 Resolved closed
EAI-138 CAM Type descriptor metamodel: Introduce TDLangElement EAI 1.0b1 EAI 1.0 Resolved closed
EAI-137 CAM Type Descriptor Stereotypes EAI 1.0b1 EAI 1.0 Resolved closed
EAI-136 CAM: Introduce products in 'EAI' terms EAI 1.0b1 EAI 1.0 Resolved closed
EAI-135 Section 6.5.1.2, bottom p57 EAI 1.0b1 EAI 1.0 Resolved closed
EAI-145 CAM: Sample serialisation: Problems with XMI EAI 1.0b1 EAI 1.0 Resolved closed
EAI-144 CAM: Title of section 7.3.9 EAI 1.0b1 EAI 1.0 Resolved closed
EAI-143 CAM TDLangModelElement: Classifier or Element EAI 1.0b1 EAI 1.0 Resolved closed
EAI-157 CAM: CsourceText clarification EAI 1.0b1 EAI 1.0 Resolved closed
EAI-156 CAM: C User Types EAI 1.0b1 EAI 1.0 Resolved closed
EAI-155 CAM: C Derivation diagram EAI 1.0b1 EAI 1.0 Resolved closed
EAI-154 CAM: COBOL Metamodel: Naming consistency EAI 1.0b1 EAI 1.0 Resolved closed
EAI-153 CAM Language Metamodels: Wording change EAI 1.0b1 EAI 1.0 Resolved closed
EAI-152 Activity Model: Describe how this relates to the EDOC process profile EAI 1.0b1 EAI 1.0 Resolved closed
EAI-151 Collaboration model: Explain how terminals are wired together EAI 1.0b1 EAI 1.0 Resolved closed
EAI-150 Explain underscores on names in collaboration diagrams EAI 1.0b1 EAI 1.0 Resolved closed
EAI-149 Use of containment in UML Collaboration Diagrams EAI 1.0b1 EAI 1.0 Resolved closed
EAI-142 CAM TDLang Metamodel diagram changes EAI 1.0b1 EAI 1.0 Resolved closed
EAI-141 CAM Type descriptor formulas EAI 1.0b1 EAI 1.0 Resolved closed
EAI-140 CAM InstanceTDBase: add a derived association EAI 1.0b1 EAI 1.0 Resolved closed
EAI-139 CAM Type descriptor stereotypes: Heading change EAI 1.0b1 EAI 1.0 Resolved closed
EAI-148 Describe the required properties of terminal-operator associations EAI 1.0b1 EAI 1.0 Resolved closed
EAI-147 Collaboration model: use UML operation specification property EAI 1.0b1 EAI 1.0 Resolved closed
EAI-146 Collaboration model: error in text associated with figure 8-1 EAI 1.0b1 EAI 1.0 Resolved closed
EAI-80 Redundant "database" association for an EAIDBTransformer EAI 1.0b1 EAI 1.0 Resolved closed
EAI-79 Multiplicity of the "transformation" association for an EAITransformer EAI 1.0b1 EAI 1.0 Resolved closed
EAI-78 Missing multiplicity for the "filterCondition" of an EAIFilter EAI 1.0b1 EAI 1.0 Resolved closed
EAI-77 Lack of FCMTerminals for an EAIRequestReplyAdapter EAI 1.0b1 EAI 1.0 Resolved closed
EAI-76 Missing constraint on the terminals of an EAIRequestReplyAdapter EAI 1.0b1 EAI 1.0 Resolved closed
EAI-75 specifiedReplyTerminal association of EAIRequestFormat is dynamic state dat EAI 1.0b1 EAI 1.0 Resolved closed
EAI-74 Overconstraint on allowed connection to "request" terminal of EAICallAdapte EAI 1.0b1 EAI 1.0 Resolved closed
EAI-73 The use of FCMTerminals on an EAICallAdapter EAI 1.0b1 EAI 1.0 Resolved closed
EAI-72 Misplaced constraints on the terminals of an EAICallAdapter EAI 1.0b1 EAI 1.0 Resolved closed
EAI-71 The name "EAITargetAdapter" EAI 1.0b1 EAI 1.0 Resolved closed
EAI-70 Missing constraints on the input terminal of an EAITargetAdapter EAI 1.0b1 EAI 1.0 Resolved closed
EAI-69 Missing constraint on the output terminal of an EAISourceAdapter EAI 1.0b1 EAI 1.0 Resolved closed
EAI-89 Lack of semantics for a "false" terminal on an EAIFilter in the metamodel EAI 1.0b1 EAI 1.0 Resolved closed
EAI-88 Poor wording of constraint on association rolename of a database resource EAI 1.0b1 EAI 1.0 Resolved closed
EAI-87 Terminal labeling constraints EAI 1.0b1 EAI 1.0 Resolved closed
EAI-86 Missing message content class for timer conditions EAI 1.0b1 EAI 1.0 Resolved closed
EAI-85 Missing specification of a table to hold EAIMessageTimerConditions EAI 1.0b1 EAI 1.0 Resolved closed
EAI-84 EAIPublicationTerminal is not needed EAI 1.0b1 EAI 1.0 Resolved closed
EAI-83 Redundant "filterCondition" association on EAISubscriptionFilter EAI 1.0b1 EAI 1.0 Resolved closed
EAI-82 Missing specification for EAISubscriptionTable EAI 1.0b1 EAI 1.0 Resolved closed
EAI-81 Inclusion of dynamic state in the metamodel for EAIAggregator EAI 1.0b1 EAI 1.0 Resolved closed
EAI-96 Update to Convergent Metamodel (Figure 64) EAI 1.0b1 EAI 1.0 Resolved closed
EAI-95 Update to BMS Metamodel EAI 1.0b1 EAI 1.0 Resolved closed
EAI-94 Update to MFS Metamodel EAI 1.0b1 EAI 1.0 Resolved closed
EAI-93 Update to C Metamodel EAI 1.0b1 EAI 1.0 Resolved closed
EAI-92 Update to COBOL Metamodel EAI 1.0b1 EAI 1.0 Resolved closed
EAI-91 Update to TDLang Metamodel EAI 1.0b1 EAI 1.0 Resolved closed
EAI-90 Update to Type Descriptor Metamodel EAI 1.0b1 EAI 1.0 Resolved closed
EAI-108 Metamodel: Use UML profile for MOF EAI 1.0b1 EAI 1.0 Resolved closed
EAI-107 Modeling Approach: Phrasing of delivery EAI 1.0b1 EAI 1.0 Resolved closed
EAI-106 Incorrect filenames EAI 1.0b1 EAI 1.0 Resolved closed
EAI-105 Incorrect notation for message arrows in Figure 8-24 EAI 1.0b1 EAI 1.0 Resolved closed
EAI-104 Incorrect constraint for aggregators EAI 1.0b1 EAI 1.0 Resolved closed
EAI-103 Insufficiency of the metamodel mapping for aggregators EAI 1.0b1 EAI 1.0 Resolved closed
EAI-102 Issue: Typographical errors in Figure 8-14 on aggregators EAI 1.0b1 EAI 1.0 Resolved closed
EAI-101 Diagram the queue for queued sources and sinks EAI 1.0b1 EAI 1.0 Resolved closed
EAI-100 Sources and sinks are called operators in the profile but not the metamodel EAI 1.0b1 EAI 1.0 Resolved closed
EAI-99 Missing request format Y9 EAI 1.0b1 EAI 1.0 Resolved closed
EAI-98 Adapters are called operators in the profile but not the metamodel EAI 1.0b1 EAI 1.0 Resolved closed
EAI-97 Update Sample XMI in Section 7.3.11 EAI 1.0b1 EAI 1.0 Resolved closed
EAI-120 Wording of FCMSource description EAI 1.0b1 EAI 1.0 Resolved closed
EAI-119 Use 'EAI' qualify references to profiles EAI 1.0b1 EAI 1.0 Resolved closed
EAI-118 Related activities: Relationship to ebXML and BPML EAI 1.0b1 EAI 1.0 Resolved closed
EAI-117 CAM/CWM alignment EAI 1.0b1 EAI 1.0 Resolved closed
EAI-116 MOF compliance EAI 1.0b1 EAI 1.0 Resolved closed
EAI-115 Update reference to EDOC EAI 1.0b1 EAI 1.0 Resolved closed
EAI-125 Clarify EAIParameter, EAIMessage EAI 1.0b1 EAI 1.0 Resolved closed
EAI-124 Reword description of applicability of EAIMessageContent EAI 1.0b1 EAI 1.0 Resolved closed
EAI-123 Constraints on EAITerminal EAI 1.0b1 EAI 1.0 Resolved closed
EAI-122 Clarify constraints on EAILink EAI 1.0b1 EAI 1.0 Resolved closed
EAI-121 Use UML profile for MOF <> stereotype EAI 1.0b1 EAI 1.0 Resolved closed
EAI-114 CWM transformations EAI 1.0b1 EAI 1.0 Resolved closed
EAI-113 Compliance: Consistency of statements about CAM compliance EAI 1.0b1 EAI 1.0 Resolved closed
EAI-112 Compliance/metamodels: Clarify status of CAM EAI 1.0b1 EAI 1.0 Resolved closed
EAI-111 Need to qualify profile names with EAI prefix EAI 1.0b1 EAI 1.0 Resolved closed
EAI-110 Compliance/Visualization: Clarification of visualization requirement EAI 1.0b1 EAI 1.0 Resolved closed
EAI-109 Compliance/Overview: use consistent XMI and MOF levels EAI 1.0b1 EAI 1.0 Resolved closed
EAI-130 EAIQueuedInputTerminal: Wording error on constraint EAI 1.0b1 EAI 1.0 Resolved closed
EAI-129 EAIQueue: Show association with EAIMessage EAI 1.0b1 EAI 1.0 Resolved closed
EAI-128 How is EAIMessageContent.part used? EAI 1.0b1 EAI 1.0 Resolved closed
EAI-127 Constraints on EAIMessageElement EAI 1.0b1 EAI 1.0 Resolved closed
EAI-126 EAIMessagePart EAI 1.0b1 EAI 1.0 Resolved closed
EAI-68 Lack of generalization for message content EAI 1.0b1 EAI 1.0 Resolved closed
EAI-67 Missing constraints on the input terminal of an EAITargetAdapter EAI 1.0b1 EAI 1.0 Resolved closed
EAI-66 Wording error in Section 6.3.10.2.2 EAI 1.0b1 EAI 1.0 Resolved closed
EAI-65 The usefulness of EAIMessageFlow in itself EAI 1.0b1 EAI 1.0 Resolved closed
EAI-64 The "Refinement relationships" stated in the section on queued sources and EAI 1.0b1 EAI 1.0 Resolved closed
EAI-63 Poor wording on the use of queued terminals with queued sources and sinks EAI 1.0b1 EAI 1.0 Resolved closed
EAI-62 Poor wording in the discussion of EAIQueues EAI 1.0b1 EAI 1.0 Resolved closed
EAI-61 Inconsistent statements on the use of queued terminals EAI 1.0b1 EAI 1.0 Resolved closed
EAI-60 There is no way to specify unbounded EAIQueues EAI 1.0b1 EAI 1.0 Resolved closed
EAI-59 There is no way to specify typed EAIQueues EAI 1.0b1 EAI 1.0 Resolved closed
EAI-58 The "messages" associated with an EAIQueue EAI 1.0b1 EAI 1.0 Resolved closed
EAI-57 The lack of mention of "faults" for EAIMessageOperations EAI 1.0b1 EAI 1.0 Resolved closed
EAI-56 The constraint on the parameters of an EAIMessageOperation EAI 1.0b1 EAI 1.0 Resolved closed
EAI-43 Relationship to CWM XML Schema model EAI 1.0b1 EAI 1.0 Resolved closed
EAI-42 XML Message Elements EAI 1.0b1 EAI 1.0 Resolved closed
EAI-41 Conflict with XML production of XML schema EAI 1.0b1 EAI 1.0 Resolved closed
EAI-55 specifiedReplyToTerminal" and "specifiedExceptionTarget" associations EAI 1.0b1 EAI 1.0 Resolved closed
EAI-54 Inconsistencies between text and diagram for EAIMessageContent EAI 1.0b1 EAI 1.0 Resolved closed
EAI-53 The relationship of EAILink to FCMDataLink and FCMControlLink EAI 1.0b1 EAI 1.0 Resolved closed
EAI-52 Lack of use of the MOF Profile EAI 1.0b1 EAI 1.0 Resolved closed
EAI-51 EAIRequestReplyAdapter/EAICallAdapter temporary link EAI 1.0b1 EAI 1.0 Resolved closed
EAI-50 Superclass of EAIAdapter EAI 1.0b1 EAI 1.0 Resolved closed
EAI-49 Deployment of the EAI Configuration EAI 1.0b1 EAI 1.0 Resolved closed
EAI-48 Non-normative examples EAI 1.0b1 EAI 1.0 Resolved closed
EAI-47 Purpose of the CCA Component Library for EAI EAI 1.0b1 EAI 1.0 Resolved closed
EAI-46 Collaboration model: MessageContent core EAI 1.0b1 EAI 1.0 Resolved closed
EAI-45 Derivation of promoted terminal EAI 1.0b1 EAI 1.0 Resolved closed
EAI-44 EAIPrimitiveOperator: Define derivations formally EAI 1.0b1 EAI 1.0 Resolved closed
EAI-21 Missing discussion of promotedTerminals for EAISinks EAI 1.0b1 EAI 1.0 Resolved closed
EAI-20 Missing derivation of the "promotedTerminal" association EAI 1.0b1 EAI 1.0 Resolved closed
EAI-19 Derivation of the "defines" association for EAIPrimitiveOperator EAI 1.0b1 EAI 1.0 Resolved closed
EAI-18 Issues with XML Message Elements EAI 1.0b1 EAI 1.0 Resolved closed
EAI-17 The "languageElement" association vs. the "message" association for EAIPara EAI 1.0b1 EAI 1.0 Resolved closed
EAI-16 Unnamed derived association between an EAITerminal and a source or sink EAI 1.0b1 EAI 1.0 Resolved closed
EAI-15 EAICompoundOperator as a new type EAI 1.0b1 EAI 1.0 Resolved closed
EAI-14 EAIRouter output terminal type EAI 1.0b1 EAI 1.0 Closed; No Change closed
EAI-13 Errors in the FCM4EAI DTD EAI 1.0b1 EAI 1.0 Resolved closed
EAI-12 The class of an operator that is a subclass of a primitive operator EAI 1.0b1 EAI 1.0 Resolved closed
EAI-11 Constraints should be in OCL EAI 1.0b1 EAI 1.0 Resolved closed
EAI-10 Semantic information is poorly organized between the Chapter 6 EAI 1.0b1 EAI 1.0 Resolved closed
EAI-32 The lack of discussion of EAIContentRule EAI 1.0b1 EAI 1.0 Resolved closed
EAI-31 The meaning of "subscriptionModes" EAI 1.0b1 EAI 1.0 Resolved closed
EAI-30 Redundancy of EAIRouterUpdate/EAIBroadcaster with EAISubscriptionOperator/E EAI 1.0b1 EAI 1.0 Closed; No Change closed
EAI-29 Inclusion of the dynamic state "routingTargets" for the EAIRoutingTable EAI 1.0b1 EAI 1.0 Resolved closed
EAI-28 The specification of EAIRouter and EAITimer as compound operators EAI 1.0b1 EAI 1.0 Resolved closed
EAI-27 Inclusion of dynamic state "buffer" and "timingCondition" in metamodel for EAI 1.0b1 EAI 1.0 Resolved closed
EAI-26 Unclear semantic description for EAIPostDater EAI 1.0b1 EAI 1.0 Resolved closed
EAI-25 Inclusion of the dynamic state "buffer" in the metamodel for EAIStream EAI 1.0b1 EAI 1.0 Resolved closed
EAI-24 Missing multiplicity for the "emissionCondition" of an EAIStream EAI 1.0b1 EAI 1.0 Resolved closed
EAI-23 Lack of constraints on the terminals of an EAIStream EAI 1.0b1 EAI 1.0 Resolved closed
EAI-22 Unclear semantic description for EAIStream EAI 1.0b1 EAI 1.0 Resolved closed
EAI-40 IBM CWM products EAI 1.0b1 EAI 1.0 Resolved closed
EAI-39 clarify relationship between EAI, FCM and ECA EAI 1.0b1 EAI 1.0 Resolved closed
EAI-38 Incorrect MOF files EAI 1.0b1 EAI 1.0 Resolved closed
EAI-37 The mapping of the setTimingCondition opeation of a Post Dater EAI 1.0b1 EAI 1.0 Resolved closed
EAI-36 The semantics of Post Dater operators EAI 1.0b1 EAI 1.0 Resolved closed
EAI-35 The semantics of Stream operators EAI 1.0b1 EAI 1.0 Resolved closed
EAI-34 Incorrect description of Figure 8-1 EAI 1.0b1 EAI 1.0 Resolved closed
EAI-33 It is unclear how a message is associated with a topic EAI 1.0b1 EAI 1.0 Resolved closed

Issues Descriptions

what is a 'CCA Component Library'

  • Key: EAI-134
  • Legacy Issue Number: 5385
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    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?

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    See issue 4854 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Relationship between EAIMessageFlow annotations and FCMComposition annotati

  • Key: EAI-133
  • Legacy Issue Number: 5383
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Operators: Wording change

  • Key: EAI-132
  • Legacy Issue Number: 5381
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    Accept change precisely as worded.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify the meaning of refinement relationships

  • Key: EAI-131
  • Legacy Issue Number: 5380
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    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

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    Revise Sections 6.3.9 and 6.3.2.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CAM Type descriptor metamodel: Introduce TDLangElement

  • Key: EAI-138
  • Legacy Issue Number: 5389
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    Section 7.3.3/4: Uses TDLangElement without any introduction

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    Swap order of presentation of TD and TDLang models.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CAM Type Descriptor Stereotypes

  • Key: EAI-137
  • Legacy Issue Number: 5388
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    See issue 5237 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CAM: Introduce products in 'EAI' terms

  • Key: EAI-136
  • Legacy Issue Number: 5387
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    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

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    More text and a diagram in Section 7.2.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 6.5.1.2, bottom p57

  • Key: EAI-135
  • Legacy Issue Number: 5386
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CAM: Sample serialisation: Problems with XMI

  • Key: EAI-145
  • Legacy Issue Number: 5396
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    See issue 5244 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CAM: Title of section 7.3.9

  • Key: EAI-144
  • Legacy Issue Number: 5395
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    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

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    See issue 5243 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CAM TDLangModelElement: Classifier or Element

  • Key: EAI-143
  • Legacy Issue Number: 5394
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    See issue 5237 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CAM: CsourceText clarification

  • Key: EAI-157
  • Legacy Issue Number: 5409
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    Update to 14.3.1.11

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CAM: C User Types

  • Key: EAI-156
  • Legacy Issue Number: 5408
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    See issue 5240 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CAM: C Derivation diagram

  • Key: EAI-155
  • Legacy Issue Number: 5407
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    See issue 5240 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CAM: COBOL Metamodel: Naming consistency

  • Key: EAI-154
  • Legacy Issue Number: 5406
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CAM Language Metamodels: Wording change

  • Key: EAI-153
  • Legacy Issue Number: 5405
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    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?

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    Update Section 14

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Activity Model: Describe how this relates to the EDOC process profile

  • Key: EAI-152
  • Legacy Issue Number: 5404
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Collaboration model: Explain how terminals are wired together

  • Key: EAI-151
  • Legacy Issue Number: 5402
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Explain underscores on names in collaboration diagrams

  • Key: EAI-150
  • Legacy Issue Number: 5401
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    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

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Use of containment in UML Collaboration Diagrams

  • Key: EAI-149
  • Legacy Issue Number: 5400
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    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

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    closed no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CAM TDLang Metamodel diagram changes

  • Key: EAI-142
  • Legacy Issue Number: 5393
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

    {ordered}

    .

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    See issue 5237 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CAM Type descriptor formulas

  • Key: EAI-141
  • Legacy Issue Number: 5392
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    See issue 5237 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CAM InstanceTDBase: add a derived association

  • Key: EAI-140
  • Legacy Issue Number: 5391
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CAM Type descriptor stereotypes: Heading change

  • Key: EAI-139
  • Legacy Issue Number: 5390
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    See issue 5237 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Describe the required properties of terminal-operator associations

  • Key: EAI-148
  • Legacy Issue Number: 5399
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Collaboration model: use UML operation specification property

  • Key: EAI-147
  • Legacy Issue Number: 5398
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Collaboration model: error in text associated with figure 8-1

  • Key: EAI-146
  • Legacy Issue Number: 5397
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Redundant "database" association for an EAIDBTransformer

  • Key: EAI-80
  • Legacy Issue Number: 4966
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

  • Reported: EAI 1.0b1 — Thu, 7 Mar 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Multiplicity of the "transformation" association for an EAITransformer

  • Key: EAI-79
  • Legacy Issue Number: 4965
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

  • Reported: EAI 1.0b1 — Thu, 7 Mar 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    Make the multiplicity "1..1".

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing multiplicity for the "filterCondition" of an EAIFilter

  • Key: EAI-78
  • Legacy Issue Number: 4958
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

  • Reported: EAI 1.0b1 — Thu, 7 Mar 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    Show a multiplicity of "1..1".

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Lack of FCMTerminals for an EAIRequestReplyAdapter

  • Key: EAI-77
  • Legacy Issue Number: 4957
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

  • Reported: EAI 1.0b1 — Thu, 7 Mar 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing constraint on the terminals of an EAIRequestReplyAdapter

  • Key: EAI-76
  • Legacy Issue Number: 4956
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Thu, 7 Mar 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

specifiedReplyTerminal association of EAIRequestFormat is dynamic state dat

  • Key: EAI-75
  • Legacy Issue Number: 4955
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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"

  • Reported: EAI 1.0b1 — Thu, 7 Mar 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Overconstraint on allowed connection to "request" terminal of EAICallAdapte

  • Key: EAI-74
  • Legacy Issue Number: 4954
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Thu, 7 Mar 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    Eliminate the constraint.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The use of FCMTerminals on an EAICallAdapter

  • Key: EAI-73
  • Legacy Issue Number: 4953
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

  • Reported: EAI 1.0b1 — Thu, 7 Mar 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Misplaced constraints on the terminals of an EAICallAdapter

  • Key: EAI-72
  • Legacy Issue Number: 4952
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Thu, 7 Mar 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    List the constraints under the Constraints heading.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The name "EAITargetAdapter"

  • Key: EAI-71
  • Legacy Issue Number: 4951
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

  • Reported: EAI 1.0b1 — Thu, 7 Mar 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    Change the name to "EAISinkAdapter".

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing constraints on the input terminal of an EAITargetAdapter

  • Key: EAI-70
  • Legacy Issue Number: 4950
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

  • Reported: EAI 1.0b1 — Thu, 7 Mar 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing constraint on the output terminal of an EAISourceAdapter

  • Key: EAI-69
  • Legacy Issue Number: 4949
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

  • Reported: EAI 1.0b1 — Thu, 7 Mar 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Lack of semantics for a "false" terminal on an EAIFilter in the metamodel

  • Key: EAI-89
  • Legacy Issue Number: 5225
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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

  • Reported: EAI 1.0b1 — Thu, 18 Apr 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Poor wording of constraint on association rolename of a database resource

  • Key: EAI-88
  • Legacy Issue Number: 5224
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

  • Reported: EAI 1.0b1 — Thu, 18 Apr 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Terminal labeling constraints

  • Key: EAI-87
  • Legacy Issue Number: 5223
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

  • Reported: EAI 1.0b1 — Thu, 18 Apr 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing message content class for timer conditions

  • Key: EAI-86
  • Legacy Issue Number: 4977
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Thu, 7 Mar 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    See issue 4976 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing specification of a table to hold EAIMessageTimerConditions

  • Key: EAI-85
  • Legacy Issue Number: 4976
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Thu, 7 Mar 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    se above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

EAIPublicationTerminal is not needed

  • Key: EAI-84
  • Legacy Issue Number: 4975
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Thu, 7 Mar 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Redundant "filterCondition" association on EAISubscriptionFilter

  • Key: EAI-83
  • Legacy Issue Number: 4973
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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


  • Reported: EAI 1.0b1 — Thu, 7 Mar 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing specification for EAISubscriptionTable

  • Key: EAI-82
  • Legacy Issue Number: 4971
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Thu, 7 Mar 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inclusion of dynamic state in the metamodel for EAIAggregator

  • Key: EAI-81
  • Legacy Issue Number: 4967
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Thu, 7 Mar 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    Remove the association from Figure 6-31.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Update to Convergent Metamodel (Figure 64)

  • Key: EAI-96
  • Legacy Issue Number: 5243
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Fri, 19 Apr 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    Update figure to include missing information.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Update to BMS Metamodel

  • Key: EAI-95
  • Legacy Issue Number: 5242
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Fri, 19 Apr 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    Update model to include missing information.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Update to MFS Metamodel

  • Key: EAI-94
  • Legacy Issue Number: 5241
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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

  • Reported: EAI 1.0b1 — Fri, 19 Apr 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    Update model to include missing information

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Update to C Metamodel

  • Key: EAI-93
  • Legacy Issue Number: 5240
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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

  • Reported: EAI 1.0b1 — Fri, 19 Apr 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    Update model to include missing information

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Update to COBOL Metamodel

  • Key: EAI-92
  • Legacy Issue Number: 5239
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Fri, 19 Apr 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    Update model to include missing information.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Update to TDLang Metamodel

  • Key: EAI-91
  • Legacy Issue Number: 5238
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Fri, 19 Apr 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    Update model to include missing information.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Update to Type Descriptor Metamodel

  • Key: EAI-90
  • Legacy Issue Number: 5237
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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

  • Reported: EAI 1.0b1 — Fri, 19 Apr 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    Update model to include missing information

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Metamodel: Use UML profile for MOF

  • Key: EAI-108
  • Legacy Issue Number: 5346
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    Update section 3.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Modeling Approach: Phrasing of delivery

  • Key: EAI-107
  • Legacy Issue Number: 5345
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    Clarify the introductory wording to chapter 3.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incorrect filenames

  • Key: EAI-106
  • Legacy Issue Number: 5342
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incorrect notation for message arrows in Figure 8-24

  • Key: EAI-105
  • Legacy Issue Number: 5252
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

  • Reported: EAI 1.0b1 — Tue, 23 Apr 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incorrect constraint for aggregators

  • Key: EAI-104
  • Legacy Issue Number: 5251
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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

  • Reported: EAI 1.0b1 — Tue, 23 Apr 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Insufficiency of the metamodel mapping for aggregators

  • Key: EAI-103
  • Legacy Issue Number: 5250
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

  • Reported: EAI 1.0b1 — Tue, 23 Apr 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue: Typographical errors in Figure 8-14 on aggregators

  • Key: EAI-102
  • Legacy Issue Number: 5249
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Tue, 23 Apr 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    Change Figure 8-14.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Diagram the queue for queued sources and sinks

  • Key: EAI-101
  • Legacy Issue Number: 5248
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Tue, 23 Apr 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    seen above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Sources and sinks are called operators in the profile but not the metamodel

  • Key: EAI-100
  • Legacy Issue Number: 5247
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Tue, 23 Apr 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing request format Y9

  • Key: EAI-99
  • Legacy Issue Number: 5246
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Tue, 23 Apr 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    Show Y9 on Figure 8-10.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Adapters are called operators in the profile but not the metamodel

  • Key: EAI-98
  • Legacy Issue Number: 5245
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Tue, 23 Apr 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    See issue 5247 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Update Sample XMI in Section 7.3.11

  • Key: EAI-97
  • Legacy Issue Number: 5244
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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

  • Reported: EAI 1.0b1 — Fri, 19 Apr 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    Update sample to include missing information.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Wording of FCMSource description

  • Key: EAI-120
  • Legacy Issue Number: 5366
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Use 'EAI' qualify references to profiles

  • Key: EAI-119
  • Legacy Issue Number: 5359
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    Update sections 4.2, 4.3 and 8.1.1

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Related activities: Relationship to ebXML and BPML

  • Key: EAI-118
  • Legacy Issue Number: 5358
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    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?

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    Update section 5.5

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CAM/CWM alignment

  • Key: EAI-117
  • Legacy Issue Number: 5357
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    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

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    See issue 5353 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOF compliance

  • Key: EAI-116
  • Legacy Issue Number: 5355
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    Update section 5.1.6.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Update reference to EDOC

  • Key: EAI-115
  • Legacy Issue Number: 5354
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    Update references

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify EAIParameter, EAIMessage

  • Key: EAI-125
  • Legacy Issue Number: 5371
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    Updates to Section 6.3.4

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Reword description of applicability of EAIMessageContent

  • Key: EAI-124
  • Legacy Issue Number: 5370
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    Revise Section 6.3.4

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Constraints on EAITerminal

  • Key: EAI-123
  • Legacy Issue Number: 5369
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    Clarify constraints.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify constraints on EAILink

  • Key: EAI-122
  • Legacy Issue Number: 5368
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    Replace text of constraints section.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Use UML profile for MOF <> stereotype

  • Key: EAI-121
  • Legacy Issue Number: 5367
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    Update figure.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CWM transformations

  • Key: EAI-114
  • Legacy Issue Number: 5353
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Compliance: Consistency of statements about CAM compliance

  • Key: EAI-113
  • Legacy Issue Number: 5352
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    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!

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    Remove compliance points related to Section 15.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Compliance/metamodels: Clarify status of CAM

  • Key: EAI-112
  • Legacy Issue Number: 5350
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    Update Section 4.4

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Need to qualify profile names with EAI prefix

  • Key: EAI-111
  • Legacy Issue Number: 5349
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    Update sections 4.2.1 and 4.3.1

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Compliance/Visualization: Clarification of visualization requirement

  • Key: EAI-110
  • Legacy Issue Number: 5348
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Compliance/Overview: use consistent XMI and MOF levels

  • Key: EAI-109
  • Legacy Issue Number: 5347
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

EAIQueuedInputTerminal: Wording error on constraint

  • Key: EAI-130
  • Legacy Issue Number: 5379
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

EAIQueue: Show association with EAIMessage

  • Key: EAI-129
  • Legacy Issue Number: 5378
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

How is EAIMessageContent.part used?

  • Key: EAI-128
  • Legacy Issue Number: 5374
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    Update Section 6.3.4.3

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Constraints on EAIMessageElement

  • Key: EAI-127
  • Legacy Issue Number: 5373
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

EAIMessagePart

  • Key: EAI-126
  • Legacy Issue Number: 5372
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    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

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Lack of generalization for message content

  • Key: EAI-68
  • Legacy Issue Number: 4948
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Thu, 7 Mar 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing constraints on the input terminal of an EAITargetAdapter

  • Key: EAI-67
  • Legacy Issue Number: 4947
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

  • Reported: EAI 1.0b1 — Thu, 7 Mar 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Wording error in Section 6.3.10.2.2

  • Key: EAI-66
  • Legacy Issue Number: 4896
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

  • Reported: EAI 1.0b1 — Fri, 22 Feb 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The usefulness of EAIMessageFlow in itself

  • Key: EAI-65
  • Legacy Issue Number: 4894
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

  • Reported: EAI 1.0b1 — Fri, 22 Feb 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The "Refinement relationships" stated in the section on queued sources and

  • Key: EAI-64
  • Legacy Issue Number: 4884
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Wed, 20 Feb 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    See issue 5380 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Poor wording on the use of queued terminals with queued sources and sinks

  • Key: EAI-63
  • Legacy Issue Number: 4883
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Wed, 20 Feb 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Poor wording in the discussion of EAIQueues

  • Key: EAI-62
  • Legacy Issue Number: 4882
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

  • Reported: EAI 1.0b1 — Wed, 20 Feb 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistent statements on the use of queued terminals

  • Key: EAI-61
  • Legacy Issue Number: 4881
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

  • Reported: EAI 1.0b1 — Wed, 20 Feb 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

There is no way to specify unbounded EAIQueues

  • Key: EAI-60
  • Legacy Issue Number: 4880
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

  • Reported: EAI 1.0b1 — Wed, 20 Feb 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

There is no way to specify typed EAIQueues

  • Key: EAI-59
  • Legacy Issue Number: 4879
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Wed, 20 Feb 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The "messages" associated with an EAIQueue

  • Key: EAI-58
  • Legacy Issue Number: 4878
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Wed, 20 Feb 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The lack of mention of "faults" for EAIMessageOperations

  • Key: EAI-57
  • Legacy Issue Number: 4877
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Wed, 20 Feb 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The constraint on the parameters of an EAIMessageOperation

  • Key: EAI-56
  • Legacy Issue Number: 4876
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

  • Reported: EAI 1.0b1 — Wed, 20 Feb 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Relationship to CWM XML Schema model

  • Key: EAI-43
  • Legacy Issue Number: 5377
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    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

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    See revised text for issue 5375

  • Updated: Fri, 6 Mar 2015 20:58 GMT

XML Message Elements

  • Key: EAI-42
  • Legacy Issue Number: 5376
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    See discussion for issue 5375

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Conflict with XML production of XML schema

  • Key: EAI-41
  • Legacy Issue Number: 5375
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    <remove section 6.3.4 XML Message Elements>

  • Updated: Fri, 6 Mar 2015 20:58 GMT

specifiedReplyToTerminal" and "specifiedExceptionTarget" associations

  • Key: EAI-55
  • Legacy Issue Number: 4874
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Wed, 20 Feb 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistencies between text and diagram for EAIMessageContent

  • Key: EAI-54
  • Legacy Issue Number: 4872
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Wed, 20 Feb 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    Answered by resolution of Issue 5371

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The relationship of EAILink to FCMDataLink and FCMControlLink

  • Key: EAI-53
  • Legacy Issue Number: 4868
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Wed, 20 Feb 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Lack of use of the MOF Profile

  • Key: EAI-52
  • Legacy Issue Number: 4864
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Wed, 20 Feb 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    See issue 5367 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

EAIRequestReplyAdapter/EAICallAdapter temporary link

  • Key: EAI-51
  • Legacy Issue Number: 4861
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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?

  • Reported: EAI 1.0b1 — Wed, 20 Feb 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Superclass of EAIAdapter

  • Key: EAI-50
  • Legacy Issue Number: 4859
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Wed, 20 Feb 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    All of these adapters should be subclasses of FCMFunction.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Deployment of the EAI Configuration

  • Key: EAI-49
  • Legacy Issue Number: 4857
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Wed, 20 Feb 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Non-normative examples

  • Key: EAI-48
  • Legacy Issue Number: 4855
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Wed, 20 Feb 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    Revise Contents page of part 4.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Purpose of the CCA Component Library for EAI

  • Key: EAI-47
  • Legacy Issue Number: 4854
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Wed, 20 Feb 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    Change text as follows.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Collaboration model: MessageContent core

  • Key: EAI-46
  • Legacy Issue Number: 5403
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    Covered by the resolution to issue 4873

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Derivation of promoted terminal

  • Key: EAI-45
  • Legacy Issue Number: 5384
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    Duplicate of 4897

  • Updated: Fri, 6 Mar 2015 20:58 GMT

EAIPrimitiveOperator: Define derivations formally

  • Key: EAI-44
  • Legacy Issue Number: 5382
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    Covered by the revised text for issue 4892

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing discussion of promotedTerminals for EAISinks

  • Key: EAI-21
  • Legacy Issue Number: 4898
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Fri, 22 Feb 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing derivation of the "promotedTerminal" association

  • Key: EAI-20
  • Legacy Issue Number: 4897
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

  • Reported: EAI 1.0b1 — Fri, 22 Feb 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Derivation of the "defines" association for EAIPrimitiveOperator

  • Key: EAI-19
  • Legacy Issue Number: 4892
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

  • Reported: EAI 1.0b1 — Fri, 22 Feb 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issues with XML Message Elements

  • Key: EAI-18
  • Legacy Issue Number: 4875
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

  • Reported: EAI 1.0b1 — Wed, 20 Feb 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The "languageElement" association vs. the "message" association for EAIPara

  • Key: EAI-17
  • Legacy Issue Number: 4873
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

  • Reported: EAI 1.0b1 — Wed, 20 Feb 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Unnamed derived association between an EAITerminal and a source or sink

  • Key: EAI-16
  • Legacy Issue Number: 4869
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

  • Reported: EAI 1.0b1 — Wed, 20 Feb 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

EAICompoundOperator as a new type

  • Key: EAI-15
  • Legacy Issue Number: 4863
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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?

  • Reported: EAI 1.0b1 — Wed, 20 Feb 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

EAIRouter output terminal type

  • Key: EAI-14
  • Legacy Issue Number: 4862
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Wed, 20 Feb 2002 05:00 GMT
  • Disposition: Closed; No Change — EAI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Errors in the FCM4EAI DTD

  • Key: EAI-13
  • Legacy Issue Number: 4860
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Wed, 20 Feb 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    See resolution for Issue 5343

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The class of an operator that is a subclass of a primitive operator

  • Key: EAI-12
  • Legacy Issue Number: 4858
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

  • Reported: EAI 1.0b1 — Wed, 20 Feb 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Constraints should be in OCL

  • Key: EAI-11
  • Legacy Issue Number: 4856
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Wed, 20 Feb 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    accepted

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Semantic information is poorly organized between the Chapter 6

  • Key: EAI-10
  • Legacy Issue Number: 4853
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

  • Reported: EAI 1.0b1 — Wed, 20 Feb 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The lack of discussion of EAIContentRule

  • Key: EAI-32
  • Legacy Issue Number: 4974
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Thu, 7 Mar 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The meaning of "subscriptionModes"

  • Key: EAI-31
  • Legacy Issue Number: 4972
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Thu, 7 Mar 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Redundancy of EAIRouterUpdate/EAIBroadcaster with EAISubscriptionOperator/E

  • Key: EAI-30
  • Legacy Issue Number: 4970
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

  • Reported: EAI 1.0b1 — Thu, 7 Mar 2002 05:00 GMT
  • Disposition: Closed; No Change — EAI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inclusion of the dynamic state "routingTargets" for the EAIRoutingTable

  • Key: EAI-29
  • Legacy Issue Number: 4969
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Thu, 7 Mar 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The specification of EAIRouter and EAITimer as compound operators

  • Key: EAI-28
  • Legacy Issue Number: 4968
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

  • Reported: EAI 1.0b1 — Thu, 7 Mar 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inclusion of dynamic state "buffer" and "timingCondition" in metamodel for

  • Key: EAI-27
  • Legacy Issue Number: 4964
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Thu, 7 Mar 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Unclear semantic description for EAIPostDater

  • Key: EAI-26
  • Legacy Issue Number: 4963
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

  • Reported: EAI 1.0b1 — Thu, 7 Mar 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inclusion of the dynamic state "buffer" in the metamodel for EAIStream

  • Key: EAI-25
  • Legacy Issue Number: 4962
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Thu, 7 Mar 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing multiplicity for the "emissionCondition" of an EAIStream

  • Key: EAI-24
  • Legacy Issue Number: 4961
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

  • Reported: EAI 1.0b1 — Thu, 7 Mar 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Lack of constraints on the terminals of an EAIStream

  • Key: EAI-23
  • Legacy Issue Number: 4960
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

  • Reported: EAI 1.0b1 — Thu, 7 Mar 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Unclear semantic description for EAIStream

  • Key: EAI-22
  • Legacy Issue Number: 4959
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

  • Reported: EAI 1.0b1 — Thu, 7 Mar 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

IBM CWM products

  • Key: EAI-40
  • Legacy Issue Number: 5356
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    Remove mention of IBM CWM product from text

  • Updated: Fri, 6 Mar 2015 20:58 GMT

clarify relationship between EAI, FCM and ECA

  • Key: EAI-39
  • Legacy Issue Number: 5351
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    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

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    See resolution to issue 4854

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incorrect MOF files

  • Key: EAI-38
  • Legacy Issue Number: 5343
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The mapping of the setTimingCondition opeation of a Post Dater

  • Key: EAI-37
  • Legacy Issue Number: 5230
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

  • Reported: EAI 1.0b1 — Thu, 18 Apr 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The semantics of Post Dater operators

  • Key: EAI-36
  • Legacy Issue Number: 5227
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

  • Reported: EAI 1.0b1 — Thu, 18 Apr 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The semantics of Stream operators

  • Key: EAI-35
  • Legacy Issue Number: 5226
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: EAI 1.0b1 — Thu, 18 Apr 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incorrect description of Figure 8-1

  • Key: EAI-34
  • Legacy Issue Number: 5222
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

  • Reported: EAI 1.0b1 — Thu, 18 Apr 2002 04:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

It is unclear how a message is associated with a topic

  • Key: EAI-33
  • Legacy Issue Number: 4978
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

  • Reported: EAI 1.0b1 — Thu, 7 Mar 2002 05:00 GMT
  • Disposition: Resolved — EAI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT