Issues for UML profiles for EAI Finalization Task Force

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

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

Issue 4893: Missing constraint on the FCMOperation invoked by an EAICompoundOperator
Issue 5253: Errors in the text of constraints on compound operators
Issue 5344: Incorrect MOF files
Issue 5538: Concept of an adapter vs. a connector is only causing confusio
Issue 5539: There is no concept of "Management" within the specification
Issue 5540: extensions
Issue 5541: metamodel for bindings
Issue 5542: To promote "flow" is overly simplistic
Issue 5543: There is no concept of process integration
Issue 5544: Perception of the role of the reference to a metadata repository

Issue 4893: Missing constraint on the FCMOperation invoked by an EAICompoundOperator (uml-eai-ftf)

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)

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

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.

 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

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

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

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

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.

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

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