UML Profile for Enterprise Application Integration Avatar
  1. OMG Specification

UML Profile for Enterprise Application Integration — Open Issues

  • Acronym: EAI
  • Issues Count: 11
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Descriptions

Incorrect MOF files

  • Key: EAI-159
  • Legacy Issue Number: 5344
  • Status: open  
  • Source: Adaptive ( Mr. 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
  • Updated: Mon, 9 Mar 2015 03:20 GMT

Placement of the constraint on the contents of an EAIMessageFlow

  • Key: EAI-158
  • Legacy Issue Number: 4895
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

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

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

  • Reported: EAI 1.0b1 — Fri, 22 Feb 2002 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Perception of the role of the reference to a metadata repository

  • Key: EAI-9
  • Legacy Issue Number: 5544
  • Status: open  
  • Source: Anonymous
  • Summary:

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

  • Reported: EAI 1.0b1 — Thu, 18 Jul 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Concept of an adapter vs. a connector is only causing confusio

  • Key: EAI-3
  • Legacy Issue Number: 5538
  • Status: open  
  • Source: Anonymous
  • Summary:

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

  • Reported: EAI 1.0b1 — Thu, 18 Jul 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Errors in the text of constraints on compound operators

  • Key: EAI-2
  • Legacy Issue Number: 5253
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

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

    Recommendation:
    Make the above corrections

  • Reported: EAI 1.0b1 — Tue, 23 Apr 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing constraint on the FCMOperation invoked by an EAICompoundOperator

  • Key: EAI-1
  • Legacy Issue Number: 4893
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

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

    Recommendation:
    Add the following constraints to EAICompoundOperator.

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

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

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

  • Reported: EAI 1.0b1 — Fri, 22 Feb 2002 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

extensions

  • Key: EAI-5
  • Legacy Issue Number: 5540
  • Status: open  
  • Source: Anonymous
  • Summary:

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

  • Reported: EAI 1.0b1 — Thu, 18 Jul 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

There is no concept of "Management" within the specification

  • Key: EAI-4
  • Legacy Issue Number: 5539
  • Status: open  
  • Source: Anonymous
  • Summary:

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

  • Reported: EAI 1.0b1 — Thu, 18 Jul 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

There is no concept of process integration

  • Key: EAI-8
  • Legacy Issue Number: 5543
  • Status: open  
  • Source: Anonymous
  • Summary:

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

  • Reported: EAI 1.0b1 — Thu, 18 Jul 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

To promote "flow" is overly simplistic

  • Key: EAI-7
  • Legacy Issue Number: 5542
  • Status: open  
  • Source: Anonymous
  • Summary:

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

  • Reported: EAI 1.0b1 — Thu, 18 Jul 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

metamodel for bindings

  • Key: EAI-6
  • Legacy Issue Number: 5541
  • Status: open  
  • Source: Anonymous
  • Summary:

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

  • Reported: EAI 1.0b1 — Thu, 18 Jul 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT