Service Oriented Architecture Modeling Language Avatar
  1. OMG Specification

Service Oriented Architecture Modeling Language — All Issues

  • Acronym: SoaML
  • Issues Count: 106
  • Description: All Issues
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
SOAML-35 loading the profile into Eclipse (v3.4, with EMF 2.4.0 and UML2 2.2.0) - error SoaML 1.0 SoaML 1.0.1 Resolved closed
SOAML-34 The definition of "service" should be refined SoaML 1.0 SoaML 1.0.1 Resolved closed
SOAML-33 specification is inconsistent in capitalization regarding defining stereotypes and utilizing the stereotypes in examples SoaML 1.0 SoaML 1.0.1 Resolved closed
SOAML-32 SoaML: Rename ServicePoint and RequestPoint for SOA Harmonization SoaML 1.0b1 SoaML 1.0 Resolved closed
SOAML-23 SoaML Issue - Service Interface applied to class and interface SoaML 1.0b1 SoaML 1.0 Resolved closed
SOAML-22 SoaML: Figures 24 and 25 are missing their CollaborationUse and role bindings SoaML 1.0b1 SoaML 1.0 Resolved closed
SOAML-18 MessageType Content Constraints SoaML 1.0b1 SoaML 1.0 Resolved closed
SOAML-20 SoaML: MotivationElement shouldn't be a stereotype SoaML 1.0b1 SoaML 1.0 Resolved closed
SOAML-19 ServiceInterface Notation SoaML 1.0b1 SoaML 1.0 Resolved closed
SOAML-13 SoaML: Capability Exposure is not defined SoaML 1.0b1 SoaML 1.0 Resolved closed
SOAML-12 SoaML: The distinction between participant and ParticipantArchitecture Participants is unclear SoaML 1.0b1 SoaML 1.0 Resolved closed
SOAML-17 MessageType Signal issue SoaML 1.0b1 SoaML 1.0 Resolved closed
SOAML-16 Issue regarding MessageType display for DataTypes SoaML 1.0b1 SoaML 1.0 Resolved closed
SOAML-14 SoaML: Bullet and numbered lists are missing from the responses to requirements section SoaML 1.0b1 SoaML 1.0 Resolved closed
SOAML-15 SoaML: SoaML should be published in Open Document Format SoaML 1.0b1 SoaML 1.0 Resolved closed
SOAML-11 SoaML Issue: Participant aggregation SoaML 1.0b1 SoaML 1.0 Resolved closed
SOAML-21 Compliance level is needed SoaML 1.0b1 SoaML 1.0 Resolved closed
SOAML-27 Attachment and the attribute mimeType SoaML 1.0b1 SoaML 1.0 Resolved closed
SOAML-26 Clarify relationship of Port::isService with ServicePoint and RequestPoint SoaML 1.0b1 SoaML 1.0 Resolved closed
SOAML-31 There is no convenient way to summarize what services a participant produces and consumes SoaML 1.0b1 SoaML 1.0 Resolved closed
SOAML-30 SoaML: Examples in Annex B and Annex C need to be updated SoaML 1.0b1 SoaML 1.0 Resolved closed
SOAML-29 SoaML: Milestone::value has inconsistent multiplicity SoaML 1.0b1 SoaML 1.0 Resolved closed
SOAML-28 SOAML: Provide icons for some SoaML stereotypes SoaML 1.0b1 SoaML 1.0 Resolved closed
SOAML-25 ServiceArchitecture SoaML 1.0b1 SoaML 1.0 Resolved closed
SOAML-24 SoaML : SoaML Trademark SoaML 1.0b1 SoaML 1.0 Resolved closed
SOAML-6 SoaML Issue: Expose class specification (Capabilities profile) SoaML 1.0b1 SoaML 1.0 Resolved closed
SOAML-5 SoaML/UPMS Issue - Collaboration class specification SoaML 1.0b1 SoaML 1.0 Resolved closed
SOAML-4 SoaML Issue: Use of RequestPoint with bi-directional services SoaML 1.0b1 SoaML 1.0 Resolved closed
SOAML-10 SoaML Issue: ServicePoint description out of alphabetical order. SoaML 1.0b1 SoaML 1.0 Resolved closed
SOAML-9 SoaML Issue: Port Direction SoaML 1.0b1 SoaML 1.0 Resolved closed
SOAML-8 SoaML Issue: Component as a superclass of Participant SoaML 1.0b1 SoaML 1.0 Resolved closed
SOAML-7 SoaML Issue: Alphabetic placement of the Port class specification SoaML 1.0b1 SoaML 1.0 Resolved closed
SOAML11-73 Figure 95 uses UML ports without UML semantics SoaML 1.0b1 open
SOAML11-72 Figure 95 extends activity execution semantics SoaML 1.0b1 open
SOAML11-74 Title: Figure 95 uses instance keyword instead of part SoaML 1.0b1 open
SOAML11-68 Ports on ServiceInterfaces SoaML 1.0.1 open
SOAML11-67 ParticipantArchitecture has been replaced by ServicesArchitecture SoaML 1.0.1 open
SOAML11-66 ServiceInterface extends UML Interface SoaML 1.0.1 open
SOAML11-70 Figures 34, 51, and others use UML interface realization without UML semantics SoaML 1.0b1 open
SOAML11-69 Section: Executive Overview SoaML 1.0b1 open
SOAML11-62 Category and CategoryValue SoaML 1.0 open
SOAML11-61 metamodel XMI does not contain the classes CapabilityRealization and CapabilityExposure which are shown in Figure 9.7 SoaML 1.0 open
SOAML11-64 Classes Service and Request SoaML 1.0 open
SOAML11-63 No values are specified for the XMI namespace URI or prefix SoaML 1.0 open
SOAML11-65 Various stereotype attributes should have multiplicity 0..1 in the SoaML profile SoaML 1.0 open
SOAML11-71 SoaML Issue: Participant Architecture SoaML 1.0b1 open
SOAML11-28 Figure 81: Service contract SoaML 1.0 open
SOAML11-27 Figure 78: Participant architecture SoaML 1.0 open
SOAML11-22 Figure 44: Specification SoaML 1.0 open
SOAML11-25 Figure 51: Interfaces SoaML 1.0 open
SOAML11-24 Figure 50: Service interface SoaML 1.0 open
SOAML11-31 Figure 84: [CBC4] comment and stereotypes SoaML 1.0 open
SOAML11-30 Figure 83: [CBC3] comment SoaML 1.0 open
SOAML11-29 Figure 82: Service contract SoaML 1.0 open
SOAML11-23 Figure 49: Service contract SoaML 1.0 open
SOAML11-32 Figure 85: [CBC5] comment and service interfaces SoaML 1.0 open
SOAML11-33 Figure 86: Interfaces SoaML 1.0 open
SOAML11-26 Figure 56: Interface SoaML 1.0 open
SOAML11-41 second bullet under the Scope section (ptc/2009-12-10) SoaML 1.0 open
SOAML11-40 Figure 96: Specification SoaML 1.0 open
SOAML11-47 09-12-09 SoaML 1.0 Beta 2 figure 78 p. 135 SoaML 1.0 open
SOAML11-46 09-12-09 SoaML 1.0 Beta 2 Figure 20 p. 38 SoaML 1.0 open
SOAML11-44 09-12-09 SoaML Beta 2 Fig 18 p. 36 SoaML 1.0 open
SOAML11-43 09-12-09 SoaML 1.0 beta 2 Figure 78 p. 135 SoaML 1.0 open
SOAML11-38 Figure 92: Specification SoaML 1.0 open
SOAML11-37 Figure 91: Interface SoaML 1.0 open
SOAML11-45 09-12-90 SoaML 1.0 Beta 2 ServiceInterface Constraint [1] p. 94 SoaML 1.0 open
SOAML11-36 Figure 89: Interface SoaML 1.0 open
SOAML11-35 Figure 88: Interfaces SoaML 1.0 open
SOAML11-42 CSC missing as submitter SoaML 1.0 open
SOAML11-39 Figure 93: Interfaces SoaML 1.0 open
SOAML11-34 Figure 87: Interface SoaML 1.0 open
SOAML11-1 wrong figure in the document SoaML 1.0 open
SOAML11-8 Capabilities SoaML 1.0 open
SOAML11-3 Use of the service interface to define Participants SoaML 1.0 open
SOAML11-2 Figure 3: Interface SoaML 1.0 open
SOAML11-7 Figure 16: Request port SoaML 1.0 open
SOAML11-6 Figure 15: Request port SoaML 1.0 open
SOAML11-4 Figure 5: Service and request ports SoaML 1.0 open
SOAML11-5 Figure 8: Request port SoaML 1.0 open
SOAML11-52 There are several (seven to be precise) cases where {subsets} relationships are represented in the XMI as Constraints SoaML 1.0 open
SOAML11-51 RedefinableTemplateSignature is not part of MOF so should be removed from the metamodel SoaML 1.0 open
SOAML11-50 09-12-09 SoaML 1.0 Beta 2 figure 93 p. 149 SoaML 1.0 open
SOAML11-49 09-12-09 SoaML 1.0 Beta 2 figure 83 p. 141 SoaML 1.0 open
SOAML11-48 09-12-09 SoaML 1.0 Beta 2 figure 79 p. 136 SoaML 1.0 open
SOAML11-55 MotivationRealization.implementingClassifier should {redefine client}. SoaML 1.0 open
SOAML11-54 Service::protocol redefines Port::type so ServiceInterface::service should redefine typedElement. SoaML 1.0 open
SOAML11-58 The references to the elements in the UML metamodel do not use the xmi:ids that are in the normative UML XMI file SoaML 1.0 open
SOAML11-57 Several properties are private not public as required by MOF SoaML 1.0 open
SOAML11-53 BMMIntegration the property MotivationRealization.realizedMotivation {subsets supplier}. SoaML 1.0 open
SOAML11-59 In the metamodel XMI the class Attachment has two Generalization elements both targeting Property SoaML 1.0 open
SOAML11-60 Class Milestone and Expose SoaML 1.0 open
SOAML11-56 Several Associations and Properties are not named, as required by MOF SoaML 1.0 open
SOAML11-10 Figure 22: Interfaces (same as figure 21) SoaML 1.0 open
SOAML11-9 Figure 21: Interfaces SoaML 1.0 open
SOAML11-14 7.1.5 Consumer: Examples SoaML 1.0 open
SOAML11-13 Figure 25: Service port SoaML 1.0 open
SOAML11-20 Figure 41: Specification SoaML 1.0 open
SOAML11-12 Figure 24: Service port SoaML 1.0 open
SOAML11-11 Figure 23: Interfaces and Service port. SoaML 1.0 open
SOAML11-19 Figure 40: Specification SoaML 1.0 open
SOAML11-18 Figure 39: Interfaces SoaML 1.0 open
SOAML11-17 Figure 37: Interfaces SoaML 1.0 open
SOAML11-15 Figure 34: Interfaces and [CBC1] SoaML 1.0 open
SOAML11-21 7.1.14 Provider: Examples SoaML 1.0 open
SOAML11-16 7.1.8 Expose: [GBE2] comment SoaML 1.0 open

Issues Descriptions

loading the profile into Eclipse (v3.4, with EMF 2.4.0 and UML2 2.2.0) - error

  • Key: SOAML-35
  • Legacy Issue Number: 13305
  • Status: closed  
  • Source: Peraton ( Brad Kizzort)
  • Summary:

    I have tried loading the profile into Eclipse (v3.4, with EMF 2.4.0 and UML2 2.2.0), but it fails when I try to define the profile with ad/08-11-03.xmi Eclipse errors when invoking UML Editor|Profile|Define... Derived feature needs:RequestPoint should be made transient and volatile. Derived feature capabilities:ServicePoint should be made transient and volatile. Processed feature base_Collaboration:Collaboration as a duplicate of inherited feature 'base_Collaboration:Collaboration'.

  • Reported: SoaML 1.0 — Mon, 19 Jan 2009 05:00 GMT
  • Disposition: Resolved — SoaML 1.0.1
  • Disposition Summary:

    This issue was resolved by other changes. Actions taken: Closed, no change

  • Updated: Sat, 7 Mar 2015 21:10 GMT

The definition of "service" should be refined

  • Key: SOAML-34
  • Legacy Issue Number: 13925
  • Status: closed  
  • Source: Agile Enterprise Design ( Mr. Fred A. Cummins)
  • Summary:

    The definition of "service" should be refined. In several places a service is defined as an offer of value. Instead it should be defined as value delivered. The value is delivered to satisfy a need of one party by another party that has the necessary capability

  • Reported: SoaML 1.0 — Thu, 7 May 2009 04:00 GMT
  • Disposition: Resolved — SoaML 1.0.1
  • Disposition Summary:

    In Section 7.1.7, first paragraph, change
    "To do so, services provide functional capabilities that when implemented and used to provide some real-world effect that has value to potential producers and consumers."
    To
    "To do so, service providers have functional capabilities that, when implemented and used, provide some real-world effect that has value to potential consumers."
    Section 7.3.14, in row 4 of the table under semantics, replace
    "The detailed specification of an interaction providing value as part of a service including "
    With
    "The detailed specification of an interaction providing value as a service including "
    Annex B, row 10, Real World Effect, right column, replace
    "Defined as Effect. Comprises the out-come of the service, and is how it delivers value to its consumers. "
    With
    "Defined as Effect. Comprises the out-come of performance of the service, and is the value delivered."

    Resolution: Resolved

  • Updated: Sat, 7 Mar 2015 21:06 GMT

specification is inconsistent in capitalization regarding defining stereotypes and utilizing the stereotypes in examples

  • Key: SOAML-33
  • Legacy Issue Number: 13189
  • Status: closed  
  • Source: Northrop Grumman ( Mr. Darin J. Supel)
  • Summary:

    The specification is inconsistent in capitalization regarding defining stereotypes and utilizing the stereotypes in examples. Most stereotypes begin with a capitalized letter, however many do not. The group should follow the style guidelines defined by the UML: "The first letter of an applied stereotype should not be capitalized." - UML 2.1.2 Superstructure, Section 18.3.8.

  • Reported: SoaML 1.0 — Mon, 22 Dec 2008 05:00 GMT
  • Disposition: Resolved — SoaML 1.0.1
  • Disposition Summary:

    resolved

  • Updated: Sat, 7 Mar 2015 21:06 GMT

SoaML: Rename ServicePoint and RequestPoint for SOA Harmonization

  • Key: SOAML-32
  • Legacy Issue Number: 14067
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    There has been a coordinated effort to begin harmonizing TOG, OASIS and OMG SOA standards to reduce confusion and fragmentation in the marketplace. That harmonization has taken two forms: 1) positioning the types of standards (reference models, ontologies, reference architectures and metamodels) relative to each other along with some guidance about how to use the different standards and 2) starting from where the standards are aligned, an agreement to explore future collaboration in the context of each organizations process to further align the standards by reducing the gaps, overlaps and accidental inconsistencies.

    A particular SOA alignment issue that we have struggled with for some time is the use of the term Service. Part of the common agreement that appears to exist around the standards is that there are four fundamental things about a "service" that have to be defined in an SOA:

    1. A definition of what the service is, what interfaces are provided and required, the operations, their preconditions, post conditions, service data parameters, and any protocols for using the operations. In SoaML, this is defined by a combination of the ServiceContract and ServiceInterface along with Interface, Operation and other things from UML.

    2. Who provides and consumes the service. This is Participant in SoaML.

    3. What services the participants provide and consume. These are the ServicePoints and RequestPoints in SoaML, typed by ServiceInterfaces.

    4. How the services are actually carried out. These are the ownedBehaviors or parts (through delegation) of a Participant that provide methods for the service operations, perhaps invoking service operations through request points in order to perform the service.

    The term Service is used more or less consistently across the OASIS RM, TOG SOA Ontology and TOG SOA RA. The SoaML ServicePoint and RequestPoint also align well with the use of the term Service in these other standards. ServicePoint and RequestPoint should be renamed to Service and Request to simplify SoaML, better align with these other standards, and better highlight the key component of SOA.

  • Reported: SoaML 1.0b1 — Thu, 9 Jul 2009 04:00 GMT
  • Disposition: Resolved — SoaML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 20:59 GMT

SoaML Issue - Service Interface applied to class and interface

  • Key: SOAML-23
  • Legacy Issue Number: 13818
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Cory Casanave)
  • Summary:

    SoaML specifies the use of the <<ServiceInterface>> stereotype on both classes and interfaces. In the case of ServiceInterface applied to a class there is a specific and potentially complex set of model elements that are required to complete the service interface specification (the class will, at minimum, realize and use UML interfaces and may have parts). When ServiceInterface is applied to a UML interface there is a different set of model elements (operations and receptions) – as a result there is a different structure and expectation of how each is specified. The unifying point is that they can both be used as the type of a ServicePoint or RequestPort. These two “flavors” of ServiceInterface are confusing to the user and inconsistently specified in the documentation. The documentation does not differentiate how to specify each flavor of ServiceInterface and is inconsistent about the base class for <<ServiceInterface>>.

    Either different stereotypes should be used (perhaps <<Provider>> & <<Consumer>> on interfaces per other issues) or the documentation should clearly distinguish <<ServiceInterface>>Class and <<ServiceInterface>>Interface.

  • Reported: SoaML 1.0b1 — Sat, 21 Mar 2009 04:00 GMT
  • Disposition: Resolved — SoaML 1.0
  • Disposition Summary:

    No Data Available

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

SoaML: Figures 24 and 25 are missing their CollaborationUse and role bindings

  • Key: SOAML-22
  • Legacy Issue Number: 13725
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:



    The ShippingService ServiceInterface in Figure 24 should contains a collaboration use and role bindings for the ShippingContract ServiceContract. The Manufacture participant in Figure 25 should not relaize the Manufacture Archtiecture, rather it should contain a collaboration use of the Manufacturer Architecture represented as a collaboration.

  • Reported: SoaML 1.0b1 — Mon, 16 Mar 2009 04:00 GMT
  • Disposition: Resolved — SoaML 1.0
  • Disposition Summary:

    No Data Available

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

MessageType Content Constraints

  • Key: SOAML-18
  • Legacy Issue Number: 13528
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Cory Casanave)
  • Summary:

    Summary:
    A common and best practice pattern is to use portions of an abstract information model in messages. Due to the following constraint this is not allowed:

    [4][1] All ownedAttributes of a MessageType must be PrimitiveType, DataType, ValueObject, or another MessageType or a reference to one of these types.
    If followed, this constraint would require the complete information model to be <<MessageType>> or the information model to be remodeled as message types - both of these alternatives are unworkable and undesirable.
    Suggested Resolution: Remove the constraint and make it part of the semantics of <<MessageType>> that any attributes or aggregated elements are passed by value.
    Abstract information models will, invariably, have references. It should be up to the PSM mapping how references are handled. Of course on the web, references will be URIs.

  • Reported: SoaML 1.0b1 — Thu, 19 Feb 2009 05:00 GMT
  • Disposition: Resolved — SoaML 1.0
  • Disposition Summary:

    Remove the ownedAttributes constraint of message type.

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

SoaML: MotivationElement shouldn't be a stereotype

  • Key: SOAML-20
  • Legacy Issue Number: 13652
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    SoaML BMM integration has stereotype MotivationElement extending NamedElement. This was so all BMM subclasses of MotivationElement would inherit the name property and the ability to own comments. However, when integrating a BMM profile with SoaML, any BMM stereotype (e.g., Goal) would be able to be applied to any NamedElement. This is not the intent as BMM elements should only extend a particular UML metaclass, such as Artifact for example. Abstract stereotype MotivationElement should not extend any metaclass.

  • Reported: SoaML 1.0b1 — Mon, 2 Mar 2009 05:00 GMT
  • Disposition: Resolved — SoaML 1.0
  • Disposition Summary:

    No Data Available

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

ServiceInterface Notation

  • Key: SOAML-19
  • Legacy Issue Number: 13545
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    ServiceInterfaces require a different notation on diagrams that is dependent on what it’s underlying UML metatype is. The issue relates to the fact that a ServiceInterface can extend a Class or an Interface.

    When you drop a ServiceInterface onto a diagram you cannot tell if the ServiceInterface is really a Class or an Interface. This is a problem when you consider that a Class can have provided/required Interface but an Interface cannot. From a users perspective the two will look identical on a diagram and they won’t be able to tell why they’re not allowed to do what they’re trying to do. Some sort of notational difference would resolve this

  • Reported: SoaML 1.0b1 — Mon, 23 Feb 2009 05:00 GMT
  • Disposition: Resolved — SoaML 1.0
  • Disposition Summary:

    No Data Available

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

SoaML: Capability Exposure is not defined

  • Key: SOAML-13
  • Legacy Issue Number: 13347
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    SoaML defines an Expose dependency that allows a service interface to expose a capability realized by a participant. This stereotype is not defined in the specification.

  • Reported: SoaML 1.0b1 — Tue, 27 Jan 2009 05:00 GMT
  • Disposition: Resolved — SoaML 1.0
  • Disposition Summary:

    Duplicate of 13335

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

SoaML: The distinction between participant and ParticipantArchitecture Participants is unclear

  • Key: SOAML-12
  • Legacy Issue Number: 13346
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    In UML2, a <<specification>> Component (or EncapsulatedClassifier) is a specification of the overall structure and behavior that realizing Components are required to implement. This is similar to the distinction between Interface and realizing Classes in UML and Java, but allows the specification to also define ports, parts and behaviors as well as operations.

    <<ParticipantArchitecture>> in SoaML appears to support the same separation of specification from realizing participants. SoaML should clarify the similarities or differences between these two concepts.

  • Reported: SoaML 1.0b1 — Mon, 26 Jan 2009 05:00 GMT
  • Disposition: Resolved — SoaML 1.0
  • Disposition Summary:

    ParticipantArchitecture has been removed from the specification, so this overlap no longer exists. Closed no Change

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

MessageType Signal issue

  • Key: SOAML-17
  • Legacy Issue Number: 13527
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Cory Casanave)
  • Summary:

    The requirements for message type match almost exactly with the requirements for signal, yet <<MessageType>> can not be applied to signal which requires yet another model element be created to wrap it. Having message types as signals is the most natural representation for an async protocol as these do not require "wrapping" the messages in operations.
    Suggested Resolution: Allow <<MessageType>> to be applied to <<Signal>>

  • Reported: SoaML 1.0b1 — Thu, 19 Feb 2009 05:00 GMT
  • Disposition: Resolved — SoaML 1.0
  • Disposition Summary:

    No Data Available

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

Issue regarding MessageType display for DataTypes

  • Key: SOAML-16
  • Legacy Issue Number: 13406
  • Status: closed  
  • Source: Auxilium Technology Group ( John Butler [X] (Inactive))
  • Summary:

    When a stereotype extends a metaclass with a keyword such as DataType, the stereotype name should be displayed in separate guillemets close to the keyword stereotype. This means Figure 26 should show “<<dataType>> <<messageType>>” when the element is a DataType.

  • Reported: SoaML 1.0b1 — Mon, 2 Feb 2009 05:00 GMT
  • Disposition: Resolved — SoaML 1.0
  • Disposition Summary:

    Resolution: Closed, no change

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

SoaML: Bullet and numbered lists are missing from the responses to requirements section

  • Key: SOAML-14
  • Legacy Issue Number: 13350
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Somehow the bullets and numbers in the formatting in the responses to requirements section were removed.

  • Reported: SoaML 1.0b1 — Thu, 29 Jan 2009 05:00 GMT
  • Disposition: Resolved — SoaML 1.0
  • Disposition Summary:

    This issue seems to have been resolved in the creation of the Beta document. However, any remaining issues can be addressed as editorial changes that will be made during the final editing on the specification, especially during the conversion to an odf file.

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

SoaML: SoaML should be published in Open Document Format

  • Key: SOAML-15
  • Legacy Issue Number: 13351
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    The SoaML FTF should create the document on Open Document Format to allow the use of freely available open source editors.

  • Reported: SoaML 1.0b1 — Thu, 29 Jan 2009 05:00 GMT
  • Disposition: Resolved — SoaML 1.0
  • Disposition Summary:

    This will be done as an editorial made during the final editing on the specification to ensure no formatting issues result from the conversion. This has been tried a number of times and appears to be easily done.

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

SoaML Issue: Participant aggregation

  • Key: SOAML-11
  • Legacy Issue Number: 13340
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James J. Odell)
  • Summary:

    The two aggregation associations coming off Participant are shown as shared in Figure 18, but as composite in Figure 59. The text seems to be no real help in deciding which is right. For consistency, this should be changed tp composite.

  • Reported: SoaML 1.0b1 — Sun, 25 Jan 2009 05:00 GMT
  • Disposition: Resolved — SoaML 1.0
  • Disposition Summary:

    These associations have been removed in response to another issue.

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

Compliance level is needed

  • Key: SOAML-21
  • Legacy Issue Number: 13717
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    UPDM would like to reuse SoaML, however, UPDM is based on UML4SysML, and SoaML is using Collaborations, which is outside UML4SysML. A compliance level is needed in SoaML that would have use only UML4SysML.

  • Reported: SoaML 1.0b1 — Fri, 6 Mar 2009 05:00 GMT
  • Disposition: Resolved — SoaML 1.0
  • Disposition Summary:

    closed no change

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

Attachment and the attribute mimeType

  • Key: SOAML-27
  • Legacy Issue Number: 13975
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Gorka Benguria)
  • Summary:

    Attachment has an attribute mimeType in the profile picture and in the semantic section of the attachment, but it does not appear in the attributes section, and does not appear in the metamodel

  • Reported: SoaML 1.0b1 — Tue, 9 Jun 2009 04:00 GMT
  • Disposition: Resolved — SoaML 1.0
  • Disposition Summary:

    The attribute definition was missing.

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

Clarify relationship of Port::isService with ServicePoint and RequestPoint

  • Key: SOAML-26
  • Legacy Issue Number: 13935
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    How does the Port “isService” attribute that’s in the UML 2.2 specification relate to SoaML ServicePoint and RequestPoint? This seems like something that might conflict/help the SoaML specification.

    Port::isService is a convention supported by UML that recognizes upward, client-facing services a component might have as distinguished from downward services or requests that are used for implementation purposes and are not intended to be of interest to perspective clients. It is used to distinguish ports that the consumers are expected to be interested in from those that are public, but are mostly concerned with the implementation of the component through interaction with lower-level service providers. This is still useful and valid for SoaML - although it would be a bit strange for a RequestPoint to have isService=ture - but this is simply saying that the RequestPoint is involved in the client-facing value chain, and not something that is just about the implementation of the participant. This needs to be clarified in the SoaML submission.

  • Reported: SoaML 1.0b1 — Mon, 18 May 2009 04:00 GMT
  • Disposition: Resolved — SoaML 1.0
  • Disposition Summary:

    In section 7.1.16 Port, add the following paragraph to the end of the Semantics section:
    Port::isService is a convention supported by UML that recognizes upward, client-facing services a component might have as distinguished from downward services or requests that are used for implementation purposes and are not intended to be of interest to perspective clients. It is used to distinguish ports that the consumers are expected to be interested in from those that are public, but are mostly concerned with the implementation of the component through interaction with lower-level service providers. All these ports are either service or request points, but isService is intended to distinguish those that would be involved in a client-facing value chain, and not something that is about the implementation of the participant or something provided for the detailed implementation of some other participant.
    Resolution: Resolved

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

There is no convenient way to summarize what services a participant produces and consumes

  • Key: SOAML-31
  • Legacy Issue Number: 14440
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    SoaML uses service and request ports to indicate what services a participant provides and consumes. But many other SOA modeling approaches such as Archimate, TOGT SOA Reference Architecture, and the IBM SOMA method show more summary views indicating components that realize and use services without indicating the details of what port the service is actually provided or consumed on.

    UML2 derives the provided and required interfaces of a component from the interfaces the component realizes and uses directly, as well as the ones it realizes and uses indirectly through the types of its owned ports. SoaML should extend this to include provided and required services based on service and request ports typed by a ServiceInterface. It should be possible to view the Participant as realizing the provided ServiceInterfaces and using the required ServiceInterfaces to provide a high-level overview of the relationship between the definition of a service and the compoents that provide and consume them.

  • Reported: SoaML 1.0b1 — Wed, 30 Sep 2009 04:00 GMT
  • Disposition: Resolved — SoaML 1.0
  • Disposition Summary:

    The relationship between port types, ports and encapsulated classifiers is under discussion for future changes in UML. SoaML should not introduce modeling notation extensions that may create additional confusion or result in possible inconsistencies.

    These high-level overviews can also be supported using Capabilities.

    Discussion:

    Actions taken: Closed, no change

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

SoaML: Examples in Annex B and Annex C need to be updated

  • Key: SOAML-30
  • Legacy Issue Number: 14230
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    These sections do not reflect changes that were adopted in FTF ballots.

  • Reported: SoaML 1.0b1 — Thu, 27 Aug 2009 04:00 GMT
  • Disposition: Resolved — SoaML 1.0
  • Disposition Summary:

    These sections non-normative and duplicate other information that is in the specification. They are included to provide a more complete, end-to-end example in one place.

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

SoaML: Milestone::value has inconsistent multiplicity

  • Key: SOAML-29
  • Legacy Issue Number: 14229
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    The multiplicity for Milestone::value is [*] in figure 20 and [0..1] in the Associations subsection of 7.1.14. Which is it?

  • Reported: SoaML 1.0b1 — Thu, 27 Aug 2009 04:00 GMT
  • Disposition: Resolved — SoaML 1.0
  • Disposition Summary:

    No Data Available

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

SOAML: Provide icons for some SoaML stereotypes

  • Key: SOAML-28
  • Legacy Issue Number: 14226
  • Status: closed  
  • Source: International Business Machines ( Mr. Gary Johnston)
  • Summary:

    would like to raise the following as an issue for consideration by the SoaML folks: SoaML should provide icons for some of its stereotypes in addition to the keywords themselves. This would enable tools that can utilize profile-provided icons to display SoaML stereotyped elements distinctly and would help avoid tool providers making up their own (likely different) icons. The attached ZIP file contains an HTML page with a table that shows suggestions. Corresponding (and appropriately larger) shape images (not included herein) should also be included.

  • Reported: SoaML 1.0b1 — Thu, 27 Aug 2009 04:00 GMT
  • Disposition: Resolved — SoaML 1.0
  • Disposition Summary:

    The following icons were provided by IBM.

    Stereotype Icon Comments
    Agent Like Component decorated with a small Actor-like figure.
    Capability Like Class decorated with a small "ring for service" figure.
    Participant Like Component decorated with a small "ring for service" figure.
    Request Like Port extended on the right with a lollipop that suggests "requires".
    Service Like Port extended on the left with a lollipop that suggests "provides".
    ServiceContract Intended to suggest a contract decorated with a small "ring for service" figure.
    ServicesArchitecture Like Collaboration decorated with a small "ring for service" figure.

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

ServiceArchitecture

  • Key: SOAML-25
  • Legacy Issue Number: 13871
  • Status: closed  
  • Source: THALES ( Jerome Lenoir)
  • Summary:

    the ServiceArchitecture is definition The high-level view of a Service Oriented Architecture that defines how a set of participants works together, forming a community, for some purpose by providing and using services.
    It's not really set of participants but a set of roles which will be play by participants. I'm not sure that we need to type the role by participant.
    Can we add a Particpant*S*Architecture stereotype that extends Class to show an architecture of participants with connectors(ServiceChannel), this architecture of Participants containing the ServiceArchitecture(collaborationUse) and the Participants playing the role within the serviceArchitecure.

  • Reported: SoaML 1.0b1 — Thu, 16 Apr 2009 04:00 GMT
  • Disposition: Resolved — SoaML 1.0
  • Disposition Summary:

    No Data Available

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

SoaML : SoaML Trademark

  • Key: SOAML-24
  • Legacy Issue Number: 13819
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Cory Casanave)
  • Summary:

    The SoaML logo should display ™ and should be registered as a trademark of OMG.

  • Reported: SoaML 1.0b1 — Sat, 21 Mar 2009 04:00 GMT
  • Disposition: Resolved — SoaML 1.0
  • Disposition Summary:

    The trademark has been added.

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

SoaML Issue: Expose class specification (Capabilities profile)

  • Key: SOAML-6
  • Legacy Issue Number: 13335
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James J. Odell)
  • Summary:

    The Expose class in the Capabilities profile (Figure 21) has no class Class Description. If the class is not needed, remove it; if it is needed, add a Class Description

  • Reported: SoaML 1.0b1 — Sun, 25 Jan 2009 05:00 GMT
  • Disposition: Resolved — SoaML 1.0
  • Disposition Summary:

    The content for the stereotype was inadvertently left out of the specification.

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

SoaML/UPMS Issue - Collaboration class specification

  • Key: SOAML-5
  • Legacy Issue Number: 13334
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James J. Odell)
  • Summary:

    The Collaboration class in the Contacts profile (Figure 17) has no class Class Description. If the Collaboration class is not needed, remove it; if it is needed, add a Class Description

  • Reported: SoaML 1.0b1 — Sun, 25 Jan 2009 05:00 GMT
  • Disposition: Resolved — SoaML 1.0
  • Disposition Summary:

    see pages 81 - 83 of ptc/2009-12-08 for details

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

SoaML Issue: Use of RequestPoint with bi-directional services

  • Key: SOAML-4
  • Legacy Issue Number: 13332
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Cory Casanave)
  • Summary:

    Where there is a bi-directional service that has 2 service contracts as is expressed in the SoaML examples, RequestPoint can not be used since it would invert the interfaces of the service interface that already represents the consumer. This is confusing with respect to the fundamental SOA concepts of a service provider and consumer – since the provider and consumer role can no longer be determined from the model semantics. It is also a source of errors as it would be natural to use RequestPoint for the consumer.

    A set of changes could address this issue as well as make the provider/consumer roles more evident:

    1. Instead of having the types of roles in a service contract the service interfaces, make the types of these roles the UML interfaces. Have a single service interface; only for the provider, and then use RequestPoint to “invert” this single service interface. This style works well for most cases, but not for nary or composite service contracts. For composite service contracts the service interfaces would still have to be the type of the roles (so it can have ports). For nary service contracts multiple service interfaces will still be required. The change to the specification would be to specify interfaces as the “normal” type of a service contract roles and spell out the edge cases. The examples should also be changed. The style used currently in the examples would still be supported.

    2. In support of nary service contracts the RequestPoint stereotype should expose “direction” as does the SoaML meta model.

    3. Add optional “Provider” and “Consumer” stereotypes for service contract roles. The notation for these stereotypes should propagate to the interfaces and ports so the provider/consumer relationship is clear. Support an optional notation of an arrow in roles and ports to indicate the direction.

  • Reported: SoaML 1.0b1 — Sat, 24 Jan 2009 05:00 GMT
  • Disposition: Resolved — SoaML 1.0
  • Disposition Summary:

    see pages 43 - 80 of ptc/2009-12-08 for details

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

SoaML Issue: ServicePoint description out of alphabetical order.

  • Key: SOAML-10
  • Legacy Issue Number: 13339
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James J. Odell)
  • Summary:

    The ServicePoint description in the metamodel on p72 is out of alphabetical order. It should precede ServicesArchitecture on p92. Maybe you should check the whole list .

  • Reported: SoaML 1.0b1 — Sun, 25 Jan 2009 05:00 GMT
  • Disposition: Resolved — SoaML 1.0
  • Disposition Summary:

    Revised Text: Same text moved in alphabetical order
    Actions taken: Moved in alphabetical order

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

SoaML Issue: Port Direction

  • Key: SOAML-9
  • Legacy Issue Number: 13338
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James J. Odell)
  • Summary:

    The Port in the metamodel (figure 59) has “direction” and has a Port Direction class. Yet the profile description does not indicate or include either of these. Either the Profile should be fixed or the Metamodel.

  • Reported: SoaML 1.0b1 — Sun, 25 Jan 2009 05:00 GMT
  • Disposition: Resolved — SoaML 1.0
  • Disposition Summary:

    see pages 43 - 80 of ptc/2009-12-08 for details

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

SoaML Issue: Component as a superclass of Participant

  • Key: SOAML-8
  • Legacy Issue Number: 13337
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James J. Odell)
  • Summary:

    The metamodel in Figure 59 (ServiceInterfaces and Participants) specifies that Component and Class are superclasses of Participant; but the Service profile (Figure 18) omits Component (as it should). Remove Component from metamodel.

  • Reported: SoaML 1.0b1 — Sun, 25 Jan 2009 05:00 GMT
  • Disposition: Resolved — SoaML 1.0
  • Disposition Summary:

    Component has been removed as a superclass in changes for issues 13334 and 13338.

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

SoaML Issue: Alphabetic placement of the Port class specification

  • Key: SOAML-7
  • Legacy Issue Number: 13336
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James J. Odell)
  • Summary:

    The stereotype Description for Port needs to be moved just before Property — to maintain alphabetical order. (Currently, it appears before the MesageType description.)

  • Reported: SoaML 1.0b1 — Mon, 26 Jan 2009 05:00 GMT
  • Disposition: Resolved — SoaML 1.0
  • Disposition Summary:

    resolvrd

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

Figure 95 uses UML ports without UML semantics

  • Key: SOAML11-73
  • Legacy Issue Number: 14924
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Figure 95 isn't explained very well, but from other conversations it
    seems to assume partitions representing ports have (references to)
    external objects as runtime values, where the external objects are the
    ones at the other end of the connector coming into the port from
    outside. This is assumed so the invocation actions can send these
    external objects operation calls based on the partitions they are in (
    the partitions represent port properties, which means the runtime value
    of the ports must be the runtime input values of invocation actions in
    the partition).

    However, ports are composite properties, see constraint [2] on ports,
    which means external objects that are values of ports would be deleted
    with when the runtime owner of the port is. For example, deleting a
    buyer object would delete the seller object at runtime. In addition,
    it would be a very rare user of UML that would assume an externally
    connected port connector had as its value the object at the other end
    of the connector. This is very far from UML, with significant
    unintended consequences.

    soaML could define an extension of UML for port partitions to give the
    semantics of InvocationAction:onPort with input pin targeting "self".
    Then the operation calls would go through the port represented by the
    partition to the external object.

  • Reported: SoaML 1.0b1 — Wed, 6 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 95 extends activity execution semantics

  • Key: SOAML11-72
  • Legacy Issue Number: 14923
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Figure 95 isn't explained very well, but from other conversations it
    seems to assume the runtime target of invocation actions can be derived
    from the the partition. While port/part partitions require the target
    input of invocation actions to be the runtime value of a specific
    property represented by the partition, they do not have the execution
    semantics to assign the value. This could be described in soaML as an
    extension of UML semantics. Probably affected by next issue.

  • Reported: SoaML 1.0b1 — Wed, 6 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Title: Figure 95 uses instance keyword instead of part

  • Key: SOAML11-74
  • Legacy Issue Number: 14922
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Figure 95 uses instance keyword, which isn't defined in UML. The
    figure isn't explained well, but perhaps it could use the part
    keyword, or extend UML with a port keyword

  • Reported: SoaML 1.0b1 — Wed, 6 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Ports on ServiceInterfaces

  • Key: SOAML11-68
  • Legacy Issue Number: 18244
  • Status: open  
  • Source: Gebhart Quality Analysis (QA) 82 ( Michael Gebhart)
  • Summary:

    My issue concerns Figure B.9 ("Relating services architecture as service contracts").

    Even though this is a very good illustration, I want to discuss the Ports attached to the ServiceInterfaces. For example, "Buyer" has two Ports, one of type "Orderer" and one of type "InvoiceReceiver" (btw. typed wrong).

    In the entire document there is no explanation about Ports on ServiceInterfaces. In the describing paragraph of this Figure we can find this sentence:

    "These service interfaces each have two ports because Purchasing Service is a compound service contract - the service interfaces have a port for each nested service: OrderService & InvoicingService, respectively."

    In my opinion the purpose of this information is not clearly described to the reader.

    If we also take Figure B.5 into consideration that is also part of this scenario: This is nothing you will implement, because it is not possible to realize it. A service interface ("Seller") cannot be broken down into several internal service interfaces as part of an implementation. What the reader has to understand is, that we are working with different kinds of abstraction within the document.

    The first is the (de-)composition of participants. A participant is composed of other participants. But the service interface remains the same and maybe is realized by an orchestration of other services.

    The second one is the abstraction of service contracts, thus service interfaces. This is not an abstraction concerning the realization of a service, it is an abstraction concerning the entire scenario. That is, what we have in this case.

    After thinking about the Ports on the ServiceInterfaces for a while, I came to the following conclusion that should be added (correct me if I am wrong):

    Whilst the decomposition of Participants is something hidden from the service consumer, the decomposition of service contracts is something that is visible and has to be known by the consumer as it is part of the scenario. First I found the Ports on the ServiceInterface kind of strange as this is some information I would expect to be hidden by the consumer. But it is important. The consumer has to know that when he wants to use this service on this level of abstraction he has to call the following more concrete services. Maybe the describing service interfaces can be further broken down. So with this information it is possible to refine the interaction between consumer and provider that is not equivalent to a refinement of realizing participants. In case of the participants the service consumer does not care about it. But for example (as in the scenario of the specification) the Manufacturer wants to interact with the Dealer he cannot do this on the abstract level. He has to use the refinements of the service interfaces until there is no further refinement possible and use these service interfaces / contracts as interaction.

    So, in my opinion it has to be clarified, why the Ports are attached to the ServiceInterface. Reason: To let the external service consumer know about the (more) concrete service interface he has to call in order to interact with the service provider correctly.

    Regards,

  • Reported: SoaML 1.0.1 — Fri, 2 Nov 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

ParticipantArchitecture has been replaced by ServicesArchitecture

  • Key: SOAML11-67
  • Legacy Issue Number: 18243
  • Status: open  
  • Source: Gebhart Quality Analysis (QA) 82 ( Michael Gebhart)
  • Summary:

    On Page 67:

    "A ServicesArchitecture or ParticipantArchitecture may then be used to model the requirements for a collection of
    participants that provide and consume services defined with service contracts."

    On Page 109:

    Figure B.5 shows a ParticipantArchitecture.

    There is no ParticipantArchitecture any longer.

  • Reported: SoaML 1.0.1 — Fri, 2 Nov 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

ServiceInterface extends UML Interface

  • Key: SOAML11-66
  • Legacy Issue Number: 18242
  • Status: open  
  • Source: Gebhart Quality Analysis (QA) 82 ( Michael Gebhart)
  • Summary:

    According to the introduction of SoaML we have to distinguish between simple interfaces and ServiceInterfaces (see page 8). Simple interfaces are UML Interfaces and ServiceInterfaces are UML Classes with further details. In the examples (e.g. page 11) the simple interfaces do not have any stereotypes applied.

    However, on page 34 when the UML profile is introduced, ServiceInterface extends not only UML Class but also UML Interface. I do not see any reason for this unless simple interfaces as UML Interfaces also should have the stereotype "ServiceInterface" applied. Also the XMI describes that the stereotype "ServiceInterface" can be applied to UML Interfaces.

    As simple interfaces are also some kind of service interfaces, maybe it is the right way to apply the stereotype to all simple interfaces too.

  • Reported: SoaML 1.0.1 — Fri, 2 Nov 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figures 34, 51, and others use UML interface realization without UML semantics

  • Key: SOAML11-70
  • Legacy Issue Number: 14925
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Figures 34, 51, and others use UML interface realization notation
    (hollow headed arrowhead, dashed line) but has an external protocol on
    the tail of the arrow, rather than an implementation of the interface
    (ie, methods for the operations defined in the interface).

  • Reported: SoaML 1.0b1 — Wed, 6 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Executive Overview

  • Key: SOAML11-69
  • Legacy Issue Number: 13194
  • Status: open  
  • Source: MITRE ( R.S. Johnson)
  • Summary:

    Participants may also delegate service implementations to parts in their internal structure which represent an assembly of other service participants connected together to provide a complete solutions, perhaps specified by, and realizing a services architecture. verb noun agreement "to provide a complete solutions,... should read "to provide complete solutions" or "to provide a complete solution"

  • Reported: SoaML 1.0b1 — Wed, 31 Dec 2008 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Category and CategoryValue

  • Key: SOAML11-62
  • Legacy Issue Number: 16075
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    In the metamodel XMI, Category inherits from RAS, whereas Figure 9.8 has it inheriting from NodeDescriptor inheriting from Artifact. Likewise CategoryValue

  • Reported: SoaML 1.0 — Fri, 4 Mar 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

metamodel XMI does not contain the classes CapabilityRealization and CapabilityExposure which are shown in Figure 9.7

  • Key: SOAML11-61
  • Legacy Issue Number: 16074
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The metamodel XMI does not contain the classes CapabilityRealization and CapabilityExposure which are shown in Figure 9.7. They don’t appear in the Profile either. It would seem the latter is replaced by the Expose class based on the discussion of Figure 6.23.

  • Reported: SoaML 1.0 — Fri, 4 Mar 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Classes Service and Request

  • Key: SOAML11-64
  • Legacy Issue Number: 16077
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Classes Service and Request each define a property called ‘protocol’; however they also inherit from Port which, in L3, has a property ‘protocol’ of type ProtocolStateMachine. The new properties are therefore invalid (they cannot be redefinitions since the property type: ServiceInterface is not conformant with ProtocolStateMachine).

  • Reported: SoaML 1.0 — Fri, 4 Mar 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

No values are specified for the XMI namespace URI or prefix

  • Key: SOAML11-63
  • Legacy Issue Number: 16076
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    No values are specified for the XMI namespace URI or prefix

  • Reported: SoaML 1.0 — Fri, 4 Mar 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Various stereotype attributes should have multiplicity 0..1 in the SoaML profile

  • Key: SOAML11-65
  • Legacy Issue Number: 18142
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Specification: Service oriented architecture Modeling Language (SoaML) Specification (formal/12-03-01)

    Subclause: 6.4.2 Attachment, 6.4.8 MessageType

    The attributes of the stereotypes Attachment (encoding and mimeType) and MessageType (encoding) are shown as having 0..1 multiplicity (which seems to be correct) in the textual descriptions for the stereotypes in the specification document, but have multiplicity 1..1 in the profile model XMI (and in Figure 6.2.7). The multiplicities for the attributes of Attachment and MessageType should be changed to 0..1 in the normative XMI.

  • Reported: SoaML 1.0 — Fri, 5 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

SoaML Issue: Participant Architecture

  • Key: SOAML11-71
  • Legacy Issue Number: 13333
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Cory Casanave)
  • Summary:

    Since a participant architecture must be the architecture of a participant the Participant Architecture stereotype should specialize the participant stereotype. Currently both stereotypes must be applied independently.

  • Reported: SoaML 1.0b1 — Sat, 24 Jan 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 81: Service contract

  • Key: SOAML11-28
  • Legacy Issue Number: 15342
  • Status: open  
  • Source: SINTEF ( Brian Elvesæter)
  • Summary:

    The roles in the service contract should be typed by either a <<Consumer>> interface or <<Provider>> interface - not a <<ServiceInterface>>. This figure reflects and older version of the standard and must be updated.

  • Reported: SoaML 1.0 — Thu, 1 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 78: Participant architecture

  • Key: SOAML11-27
  • Legacy Issue Number: 15341
  • Status: open  
  • Source: SINTEF ( Brian Elvesæter)
  • Summary:

    <<ParticipantArchitecture>> is no longer a part of the standard.

  • Reported: SoaML 1.0 — Thu, 1 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 44: Specification

  • Key: SOAML11-22
  • Legacy Issue Number: 15336
  • Status: open  
  • Source: SINTEF ( Brian Elvesæter)
  • Summary:

    See issue 15333: Here <<specification>> is introduced and <<Participant>> is used on the implementation (realization). The relationship between <<specification>> and <<Participant>> is not clear to me in the specification. I would argue that a <<Participant>> can be seen as a logical system component that represents a specification, which can be further decomposed into a set of Participants (in the case you want to specify lower-level/participant-level services architectures) or components (design of software components).

  • Reported: SoaML 1.0 — Thu, 1 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 51: Interfaces

  • Key: SOAML11-25
  • Legacy Issue Number: 15339
  • Status: open  
  • Source: SINTEF ( Brian Elvesæter)
  • Summary:

    The interfaces should be stereotyped <<Consumer>> and <<Provider>>.

  • Reported: SoaML 1.0 — Thu, 1 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 50: Service interface

  • Key: SOAML11-24
  • Legacy Issue Number: 15338
  • Status: open  
  • Source: SINTEF ( Brian Elvesæter)
  • Summary:

    ServiceInterface is a sterotype on a Class and not an Interface. The <<ServiceInterface>> stereotyped should be changed to <<Provider>>.

  • Reported: SoaML 1.0 — Thu, 1 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 84: [CBC4] comment and stereotypes

  • Key: SOAML11-31
  • Legacy Issue Number: 15345
  • Status: open  
  • Source: SINTEF ( Brian Elvesæter)
  • Summary:

    [CBC4] comment should be deleted. Interfaces missing proper stereotypes.

  • Reported: SoaML 1.0 — Thu, 1 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 83: [CBC3] comment

  • Key: SOAML11-30
  • Legacy Issue Number: 15344
  • Status: open  
  • Source: SINTEF ( Brian Elvesæter)
  • Summary:

    [CBC3] comment should be deleted.

  • Reported: SoaML 1.0 — Thu, 1 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 82: Service contract

  • Key: SOAML11-29
  • Legacy Issue Number: 15343
  • Status: open  
  • Source: SINTEF ( Brian Elvesæter)
  • Summary:

    Same as issue 15342: The roles in the service contract should be typed by either a <<Consumer>> interface or <<Provider>> interface - not a <<ServiceInterface>>. This figure reflects and older version of the standard and must be updated.

  • Reported: SoaML 1.0 — Thu, 1 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 49: Service contract

  • Key: SOAML11-23
  • Legacy Issue Number: 15337
  • Status: open  
  • Source: SINTEF ( Brian Elvesæter)
  • Summary:

    The Collaboration Use should NOT be stereotyped <<ServiceContract>>. This is NOT part of the standard. Ports are missing <<Service>> and <<Request>> stereotypes.

  • Reported: SoaML 1.0 — Thu, 1 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 85: [CBC5] comment and service interfaces

  • Key: SOAML11-32
  • Legacy Issue Number: 15346
  • Status: open  
  • Source: SINTEF ( Brian Elvesæter)
  • Summary:

    [CBC5] comment should be deleted. Use of service interface is not according to the latest spec.

  • Reported: SoaML 1.0 — Thu, 1 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 86: Interfaces

  • Key: SOAML11-33
  • Legacy Issue Number: 15347
  • Status: open  
  • Source: SINTEF ( Brian Elvesæter)
  • Summary:

    The interfaces should be stereotyped <<Consumer>> and <<Provider>>

  • Reported: SoaML 1.0 — Thu, 1 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 56: Interface

  • Key: SOAML11-26
  • Legacy Issue Number: 15340
  • Status: open  
  • Source: SINTEF ( Brian Elvesæter)
  • Summary:

    nterface Scheduling should be stereotyped <<Provider>>.

  • Reported: SoaML 1.0 — Thu, 1 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

second bullet under the Scope section (ptc/2009-12-10)

  • Key: SOAML11-41
  • Legacy Issue Number: 15391
  • Status: open  
  • Source: Thematix Partners LLC ( Mr. James J. Odell)
  • Summary:

    In the second bullet under the Scope section (ptc/2009-12-10), it reads”

    “· Specifying services including the functional capabilities they provide, what capabilities consumers are expected to provide , the protocols or rules for using them, and the service information exchanged between consumers and providers.”

    Shouldn't it be "...what capabilities providers are expected to provide [or support]..." or possibly "...what capabilities consumers are expecting [to receive]..."?

  • Reported: SoaML 1.0 — Mon, 2 Aug 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 96: Specification

  • Key: SOAML11-40
  • Legacy Issue Number: 15354
  • Status: open  
  • Source: SINTEF ( Brian Elvesæter)
  • Summary:

    Same as issue 15333: Here <<specification>> is introduced and <<Participant>> is used on the implementation (realization). The relationship between <<specification>> and <<Participant>> is not clear to me in the specification. I would argue that a <<Participant>> can be seen as a logical system component that represents a specification, which can be further decomposed into a set of Participants (in the case you want to specify lower-level/participant-level services architectures) or components (design of software components).

  • Reported: SoaML 1.0 — Thu, 1 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

09-12-09 SoaML 1.0 Beta 2 figure 78 p. 135

  • Key: SOAML11-47
  • Legacy Issue Number: 15783
  • Status: open  
  • Source: Naval Undersea Warfare Center ( Richard Funk)
  • Summary:

    There is no such thing in the profile described in this document as a <<ParticipantArchitecture>> stereotype. Perhaps this stereotype was removed in this version of the specification? Also in this diagram, I believe the payer role binding should be changed to invoicer, considering figure 75 on page 133.

  • Reported: SoaML 1.0 — Mon, 25 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

09-12-09 SoaML 1.0 Beta 2 Figure 20 p. 38

  • Key: SOAML11-46
  • Legacy Issue Number: 15777
  • Status: open  
  • Source: Naval Undersea Warfare Center ( Richard Funk)
  • Summary:

    Remove the slash in front of the dealer part name. According to 09-09-09 UML 2.3 Super structure p. 188 this notation applies only to an instance specification.

  • Reported: SoaML 1.0 — Fri, 22 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

09-12-09 SoaML Beta 2 Fig 18 p. 36

  • Key: SOAML11-44
  • Legacy Issue Number: 15775
  • Status: open  
  • Source: Naval Undersea Warfare Center ( Richard Funk)
  • Summary:

    The <<uses>> dependency between Seller and Purchaser is pointing in the wrong direction. According to Figure 17 on page 35, step 3 in the interaction diagram shows that the Seller sends the Delivery message to the Purchaser, and not the other way around. The Purchaser never sends any messages directly to the Seller.

  • Reported: SoaML 1.0 — Fri, 22 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

09-12-09 SoaML 1.0 beta 2 Figure 78 p. 135

  • Key: SOAML11-43
  • Legacy Issue Number: 15767
  • Status: open  
  • Source: Anonymous
  • Summary:

    I believe the accounting participant should play the invoicer role, not
    the payer role (see Figure 75 p. 133).

  • Reported: SoaML 1.0 — Tue, 19 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 92: Specification

  • Key: SOAML11-38
  • Legacy Issue Number: 15352
  • Status: open  
  • Source: SINTEF ( Brian Elvesæter)
  • Summary:

    Same as issue 15333: Here <<specification>> is introduced and <<Participant>> is used on the implementation (realization). The relationship between <<specification>> and <<Participant>> is not clear to me in the specification. I would argue that a <<Participant>> can be seen as a logical system component that represents a specification, which can be further decomposed into a set of Participants (in the case you want to specify lower-level/participant-level services architectures) or components (design of software components).

  • Reported: SoaML 1.0 — Thu, 1 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 91: Interface

  • Key: SOAML11-37
  • Legacy Issue Number: 15351
  • Status: open  
  • Source: SINTEF ( Brian Elvesæter)
  • Summary:

    Apply <<Provider>> stereotype.

  • Reported: SoaML 1.0 — Thu, 1 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

09-12-90 SoaML 1.0 Beta 2 ServiceInterface Constraint [1] p. 94

  • Key: SOAML11-45
  • Legacy Issue Number: 15776
  • Status: open  
  • Source: Naval Undersea Warfare Center ( Richard Funk)
  • Summary:

    Existing text:

    [1] All parts of a ServiceInterface must be typed by the Interfaces realized or used by the ServiceInterface.

    Recommended text:

    [1] All typed parts of a ServiceInterface must be typed by the Interfaces realized or used by the ServiceInterface.

    Existing text implies that all parts must be typed, which is not true, if Figure 52 on page 99 is correct. The orderer role in Figure 52 (ShippingService) has no type. It would appear that the constraint should apply only to those parts that have a type, and not all parts in general.

  • Reported: SoaML 1.0 — Fri, 22 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 89: Interface

  • Key: SOAML11-36
  • Legacy Issue Number: 15350
  • Status: open  
  • Source: SINTEF ( Brian Elvesæter)
  • Summary:

    Apply <<Provider>> stereotype.

  • Reported: SoaML 1.0 — Thu, 1 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 88: Interfaces

  • Key: SOAML11-35
  • Legacy Issue Number: 15349
  • Status: open  
  • Source: SINTEF ( Brian Elvesæter)
  • Summary:

    The interfaces should be stereotyped <<Consumer>> and <<Provider>>.

  • Reported: SoaML 1.0 — Thu, 1 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

CSC missing as submitter

  • Key: SOAML11-42
  • Legacy Issue Number: 15392
  • Status: open  
  • Source: Thematix Partners LLC ( Mr. James J. Odell)
  • Summary:

    Once again, CSC has been omitted as a submitter. Please re-add to the copyright and Acknowledgements.

  • Reported: SoaML 1.0 — Mon, 2 Aug 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 93: Interfaces

  • Key: SOAML11-39
  • Legacy Issue Number: 15353
  • Status: open  
  • Source: SINTEF ( Brian Elvesæter)
  • Summary:

    Apply correct stereotypes to the interfaces.

  • Reported: SoaML 1.0 — Thu, 1 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 87: Interface

  • Key: SOAML11-34
  • Legacy Issue Number: 15348
  • Status: open  
  • Source: SINTEF ( Brian Elvesæter)
  • Summary:

    Apply <<Provider>> stereotype.

  • Reported: SoaML 1.0 — Thu, 1 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

wrong figure in the document

  • Key: SOAML11-1
  • Legacy Issue Number: 15135
  • Status: open  
  • Source: Thematix Partners LLC ( Mr. James J. Odell)
  • Summary:

    Subject: FW: SoaML Beta 2 question - v2 - bis
    Date: Fri, 12 Mar 2010 16:35:37 -0500
    X-MS-Has-Attach: yes
    X-MS-TNEF-Correlator:
    Thread-Topic: SoaML Beta 2 question - v2 - bis
    thread-index: AcrCGzfTouMfZVwkYEGlviuBN+fz/AAAZoigAACYR7EAAxmX4AAAEg7w
    From: "Cory Casanave" <cory-c@modeldriven.com>
    To: <soaml-ftf@omg.org>

    Note that there is a wrong figure in the document, see below.

    --------------------------------------------------------------------------------

    From: Cory Casanave
    Sent: Friday, March 12, 2010 4:35 PM
    To: 'James Odell'
    Cc: Ed Seidewitz
    Subject: RE: SoaML Beta 2 question - v2 - bis

    The first figure should be:

    However the doc numbers don’t match - the FTF report doc is 09-11-14

    --------------------------------------------------------------------------------

    From: James Odell email@jamesodell.com
    Sent: Friday, March 12, 2010 3:04 PM
    To: Cory Casanave
    Subject: Re: SoaML Beta 2 question - v2 - bis

    In the downlodable doc, it’s Figs 15 and 16; on SoaML.docx, it Figs 17 and 18.

    -Jim

    On 3/12/10 2:48 PM, "Cory Casanave" indited:

    Jim,
    Which document are you looking at ? In SoaML.docx this is not figure a6.
    -Cory

    --------------------------------------------------------------------------------

    From: James Odell email@jamesodell.com
    Sent: Friday, March 12, 2010 2:36 PM
    To: Cory Casanave
    Subject: SoaML Beta 2 question - v2

    Cory,

    Sorry, I included the wrong images on the last one.
    Now, Figs 15 and 16 are identical, but the text describing Fig 16 does not jibe with figure. Can you tell me what Fig 16 should look like?

    Thanks,

    Jim

    Real Fig. 15

    Real Fig. 16

  • Reported: SoaML 1.0 — Fri, 12 Mar 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Capabilities

  • Key: SOAML11-8
  • Legacy Issue Number: 15322
  • Status: open  
  • Source: SINTEF ( Brian Elvesæter)
  • Summary:

    On page 40 it is stated that "Capabilities represent an abstraction of the ability to affect change" and there is a lot of explanation why modelling capabilities makes sense on what I perceive to be the business perspective on an SOA.On page 63 it is stated that "Alternatively, Capabilities may realize ServiceInterfaces using standard UML Realization. This approach is somewhat different in that it says that the Service Interface is a "specification" and the Capability "implements" this specification."In my view here the concept "capability" is used on two different abstraction levels: 1) abstract business view, and 2) IT implementation view. This should be avoided!

  • Reported: SoaML 1.0 — Thu, 1 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Use of the service interface to define Participants

  • Key: SOAML11-3
  • Legacy Issue Number: 15317
  • Status: open  
  • Source: SINTEF ( Brian Elvesæter)
  • Summary:

    The Participant Manufacturer should be a stereotyped <<Participant>> Class and not a Component.

  • Reported: SoaML 1.0 — Thu, 1 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 3: Interface

  • Key: SOAML11-2
  • Legacy Issue Number: 15316
  • Status: open  
  • Source: SINTEF ( Brian Elvesæter)
  • Summary:

    The Scheduling interface should be stereotyped <<Provider>>.

  • Reported: SoaML 1.0 — Thu, 1 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 16: Request port

  • Key: SOAML11-7
  • Legacy Issue Number: 15321
  • Status: open  
  • Source: SINTEF ( Brian Elvesæter)
  • Summary:

    The request port for the Shipping Request on Manufacturer is not typed. (This is the same figure as Figure 15).

  • Reported: SoaML 1.0 — Thu, 1 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 15: Request port

  • Key: SOAML11-6
  • Legacy Issue Number: 15320
  • Status: open  
  • Source: SINTEF ( Brian Elvesæter)
  • Summary:

    The request port for the Shipping Request on Manufacturer is not typed. (This is the same figure as Figure 8).

  • Reported: SoaML 1.0 — Thu, 1 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 5: Service and request ports

  • Key: SOAML11-4
  • Legacy Issue Number: 15318
  • Status: open  
  • Source: SINTEF ( Brian Elvesæter)
  • Summary:

    The service and request ports are not typed. They are only named to give impression that they are typed.

  • Reported: SoaML 1.0 — Thu, 1 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 8: Request port

  • Key: SOAML11-5
  • Legacy Issue Number: 15319
  • Status: open  
  • Source: SINTEF ( Brian Elvesæter)
  • Summary:

    he request port for the Shipping Request on Manufacturer is not typed.

  • Reported: SoaML 1.0 — Thu, 1 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

There are several (seven to be precise) cases where {subsets} relationships are represented in the XMI as Constraints

  • Key: SOAML11-52
  • Legacy Issue Number: 16065
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    There are several (seven to be precise) cases where

    {subsets}

    relationships are represented in the XMI as Constraints rather than using the subsettedProperty association.

    In fact one of the Constraints does not have a constrainedElement.

    There are also two cases where

    {redefines}

    is represented by a Constraint in the XMI.

    However many of these have other problems (see other issues).

  • Reported: SoaML 1.0 — Fri, 4 Mar 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

RedefinableTemplateSignature is not part of MOF so should be removed from the metamodel

  • Key: SOAML11-51
  • Legacy Issue Number: 16064
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    RedefinableTemplateSignature is not part of MOF so should be removed from the metamodel

  • Reported: SoaML 1.0 — Fri, 4 Mar 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

09-12-09 SoaML 1.0 Beta 2 figure 93 p. 149

  • Key: SOAML11-50
  • Legacy Issue Number: 15786
  • Status: open  
  • Source: Naval Undersea Warfare Center ( Richard Funk)
  • Summary:

    Activity parameter node for customerInfo is of the wrong type. It should be type Customer, not processPurchaseOrder, to match the signature of the prochasePurchaseOrder operation in the Purchasing interface.

  • Reported: SoaML 1.0 — Mon, 25 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

09-12-09 SoaML 1.0 Beta 2 figure 83 p. 141

  • Key: SOAML11-49
  • Legacy Issue Number: 15785
  • Status: open  
  • Source: Naval Undersea Warfare Center ( Richard Funk)
  • Summary:

    Judging from the rest of the figures in this system I think the AcceptEventActions in this diagram should be modeled as SendSignalActions, instead. The interfaces that define the associated receptions don't appear to be related to these swim lanes as receptions, but rather they appear to be sent by these swim lanes.

  • Reported: SoaML 1.0 — Mon, 25 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

09-12-09 SoaML 1.0 Beta 2 figure 79 p. 136

  • Key: SOAML11-48
  • Legacy Issue Number: 15784
  • Status: open  
  • Source: Naval Undersea Warfare Center ( Richard Funk)
  • Summary:

    The text describing this figure implies that there should be participant swim lanes on this diagram, but there are none. Recommend adding the missing swim lanes. The reader might guess that there is a single swim lane for the OrderProcessing participant, and that this activity is 'owned' by the ManufacturerComponent, or that this activity is actually owned entirely by the OrderProcessing participant, but this is not apparent from the parts of the model shown. The latter context seems more likely, given the form of the activity, but mention of swim lanes in the text seems to contradict this, so the end result is confusion.

  • Reported: SoaML 1.0 — Mon, 25 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

MotivationRealization.implementingClassifier should {redefine client}.

  • Key: SOAML11-55
  • Legacy Issue Number: 16068
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    MotivationRealization.implementingClassifier should

    {redefine client}

    .

  • Reported: SoaML 1.0 — Fri, 4 Mar 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Service::protocol redefines Port::type so ServiceInterface::service should redefine typedElement.

  • Key: SOAML11-54
  • Legacy Issue Number: 16067
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Service::protocol redefines Port::type so ServiceInterface::service should redefine typedElement. Likewise ServiceInterface::request

  • Reported: SoaML 1.0 — Fri, 4 Mar 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

The references to the elements in the UML metamodel do not use the xmi:ids that are in the normative UML XMI file

  • Key: SOAML11-58
  • Legacy Issue Number: 16071
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The references to the elements in the UML metamodel do not use the xmi:ids that are in the normative UML XMI file. So they do not work

  • Reported: SoaML 1.0 — Fri, 4 Mar 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Several properties are private not public as required by MOF

  • Key: SOAML11-57
  • Legacy Issue Number: 16070
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Several properties are private not public as required by MOF

  • Reported: SoaML 1.0 — Fri, 4 Mar 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

BMMIntegration the property MotivationRealization.realizedMotivation {subsets supplier}.

  • Key: SOAML11-53
  • Legacy Issue Number: 16066
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    In BMMIntegration the property MotivationRealization.realizedMotivation

    {subsets supplier}

    . However MotivationElement is not a UML metaclass so by definition does not subclass uml:Element so cannot be a valid target for the inherited Dependency::supplier property. Thus the subsetting is invalid. If that is removed, however, as a subclass of Dependency it leaves the mandatory supplier property empty and so any model will inherently be invalid.

  • Reported: SoaML 1.0 — Fri, 4 Mar 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

In the metamodel XMI the class Attachment has two Generalization elements both targeting Property

  • Key: SOAML11-59
  • Legacy Issue Number: 16072
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    In the metamodel XMI the class Attachment has two Generalization elements both targeting Property

  • Reported: SoaML 1.0 — Fri, 4 Mar 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Class Milestone and Expose

  • Key: SOAML11-60
  • Legacy Issue Number: 16073
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Class Milestone appears in the XMI file and the Profile Mapping but not in the Metamodel section of the specification. Likewise Expose

  • Reported: SoaML 1.0 — Fri, 4 Mar 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Several Associations and Properties are not named, as required by MOF

  • Key: SOAML11-56
  • Legacy Issue Number: 16069
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Several Associations and Properties are not named, as required by MOF

  • Reported: SoaML 1.0 — Fri, 4 Mar 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 22: Interfaces (same as figure 21)

  • Key: SOAML11-10
  • Legacy Issue Number: 15324
  • Status: open  
  • Source: SINTEF ( Brian Elvesæter)
  • Summary:

    The Shipping and ScheduleProcessing interfaces should be stereotyped <<Provider>>.Also as stated above (issue 7) the concept of Cability as written in the standard is ambiguous as it has two different semantics whether seen from the business perspective or the IT perspective. I would personally only use the concept on the business level, thus a Capability should not be able to realize a ServiceInterface. The standard should clarify the ambiguity of the concept and choose one consistent meaning. I suggest restricting the Capability concept to the business perspective only. Thus, a ServiceInterface (IT perspective) exposes a Capability (business perspective).

  • Reported: SoaML 1.0 — Thu, 1 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 21: Interfaces

  • Key: SOAML11-9
  • Legacy Issue Number: 15323
  • Status: open  
  • Source: SINTEF ( Brian Elvesæter)
  • Summary:

    The Shipping and ScheduleProcessing interfaces should be stereotyped <<Provider>>.Also as stated above (issue 7) the concept of Cability as written in the standard is ambiguous as it has two different semantics whether seen from the business perspective or the IT perspective. I would personally only use the concept on the business level, thus a Capability should not be able to realize a ServiceInterface. The standard should clarify the ambiguity of the concept and choose one consistent meaning. I suggest restricting the Capability concept to the business perspective only. Thus, a ServiceInterface (IT perspective) exposes a Capability (business perspective).

  • Reported: SoaML 1.0 — Thu, 1 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

7.1.5 Consumer: Examples

  • Key: SOAML11-14
  • Legacy Issue Number: 15328
  • Status: open  
  • Source: SINTEF ( Brian Elvesæter)
  • Summary:

    The figures in the examples subsection are missing captions. The request ports on Dealer are not typed. One has only be named to give impression that it is typed, and the other is not named at all.

  • Reported: SoaML 1.0 — Thu, 1 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 25: Service port

  • Key: SOAML11-13
  • Legacy Issue Number: 15327
  • Status: open  
  • Source: SINTEF ( Brian Elvesæter)
  • Summary:

    The service port Orders on Manufacturer is missing the <<Service>> stereotype.

  • Reported: SoaML 1.0 — Thu, 1 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 41: Specification

  • Key: SOAML11-20
  • Legacy Issue Number: 15334
  • Status: open  
  • Source: SINTEF ( Brian Elvesæter)
  • Summary:

    See issue 15333 : Here <<specification>> is introduced and <<Participant>> is used on the implementation (realization). The relationship between <<specification>> and <<Participant>> is not clear to me in the specification. I would argue that a <<Participant>> can be seen as a logical system component that represents a specification, which can be further decomposed into a set of Participants (in the case you want to specify lower-level/participant-level services architectures) or components (design of software components).

  • Reported: SoaML 1.0 — Thu, 1 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 24: Service port

  • Key: SOAML11-12
  • Legacy Issue Number: 15326
  • Status: open  
  • Source: SINTEF ( Brian Elvesæter)
  • Summary:

    Stereotype on port should be changed from <<ServicePoint>> to <<Service>>.

  • Reported: SoaML 1.0 — Thu, 1 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 23: Interfaces and Service port.

  • Key: SOAML11-11
  • Legacy Issue Number: 15325
  • Status: open  
  • Source: SINTEF ( Brian Elvesæter)
  • Summary:

    See issue 15323 above (regarding Figure 21). Furthermore, the stereotype on the ShippingService port on the Shipper should be changed from <<ServicePoint>> to <<Service>>.

  • Reported: SoaML 1.0 — Thu, 1 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 40: Specification

  • Key: SOAML11-19
  • Legacy Issue Number: 15333
  • Status: open  
  • Source: SINTEF ( Brian Elvesæter)
  • Summary:

    Here <<specification>> is introduced and <<Participant>> is used on the implementation (realization). The relationship between <<specification>> and <<Participant>> is not clear to me in the specification. I would argue that a <<Participant>> can be seen as a logical system component that represents a specification, which can be further decomposed into a set of Participants (in the case you want to specify lower-level/participant-level services architectures) or components (design of software components).

  • Reported: SoaML 1.0 — Thu, 1 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 39: Interfaces

  • Key: SOAML11-18
  • Legacy Issue Number: 15332
  • Status: open  
  • Source: SINTEF ( Brian Elvesæter)
  • Summary:

    The interfaces are missing the <<Consumer>> and/or <<Provider>> stereotypes.

  • Reported: SoaML 1.0 — Thu, 1 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 37: Interfaces

  • Key: SOAML11-17
  • Legacy Issue Number: 15331
  • Status: open  
  • Source: SINTEF ( Brian Elvesæter)
  • Summary:

    The interfaces should be stereotyped <<Provider>>.

  • Reported: SoaML 1.0 — Thu, 1 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 34: Interfaces and [CBC1]

  • Key: SOAML11-15
  • Legacy Issue Number: 15329
  • Status: open  
  • Source: SINTEF ( Brian Elvesæter)
  • Summary:

    Interfaces are missing <<Consumer>> and <<Provider>> stereotypes. [CBC1] comment should be deleted.

  • Reported: SoaML 1.0 — Thu, 1 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

7.1.14 Provider: Examples

  • Key: SOAML11-21
  • Legacy Issue Number: 15335
  • Status: open  
  • Source: SINTEF ( Brian Elvesæter)
  • Summary:

    Example figure is missing a caption. The ports are not typed nor stereotyped.

  • Reported: SoaML 1.0 — Thu, 1 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

7.1.8 Expose: [GBE2] comment

  • Key: SOAML11-16
  • Legacy Issue Number: 15330
  • Status: open  
  • Source: SINTEF ( Brian Elvesæter)
  • Summary:

    [GBE2] comment should be deleted.

  • Reported: SoaML 1.0 — Thu, 1 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT