Issue 13194: Section: Executive Overview
Issue 13333: SoaML Issue: Participant Architecture
Issue 14925: Figures 34, 51, and others use UML interface realization without UML semantics
Issue 15135: wrong figure in the document
Issue 15316: Figure 3: Interface
Issue 15317: Use of the service interface to define Participants
Issue 15318: Figure 5: Service and request ports
Issue 15319: Figure 8: Request port
Issue 15320: Figure 15: Request port
Issue 15321: Figure 16: Request port
Issue 15322: Capabilities
Issue 15323: Figure 21: Interfaces
Issue 15324: Figure 22: Interfaces (same as figure 21)
Issue 15325: Figure 23: Interfaces and Service port.
Issue 15326: Figure 24: Service port
Issue 15327: Figure 25: Service port
Issue 15328: 7.1.5 Consumer: Examples
Issue 15329: Figure 34: Interfaces and [CBC1]
Issue 15330: 7.1.8 Expose: [GBE2] comment
Issue 15331: Figure 37: Interfaces
Issue 15332: Figure 39: Interfaces
Issue 15333: Figure 40: Specification
Issue 15334: Figure 41: Specification
Issue 15335: 7.1.14 Provider: Examples
Issue 15336: Figure 44: Specification
Issue 15337: Figure 49: Service contract
Issue 15338: Figure 50: Service interface
Issue 15339: Figure 51: Interfaces
Issue 15340: Figure 56: Interface
Issue 15341: Figure 78: Participant architecture
Issue 15342: Figure 81: Service contract
Issue 15343: Figure 82: Service contract
Issue 15344: Figure 83: [CBC3] comment
Issue 15345: Figure 84: [CBC4] comment and stereotypes
Issue 15346: Figure 85: [CBC5] comment and service interfaces
Issue 15347: Figure 86: Interfaces
Issue 15348: Figure 87: Interface
Issue 15349: Figure 88: Interfaces
Issue 15350: Figure 89: Interface
Issue 15351: Figure 91: Interface
Issue 15352: Figure 92: Specification
Issue 15353: Figure 93: Interfaces
Issue 15354: Figure 96: Specification
Issue 15391: second bullet under the Scope section (ptc/2009-12-10)
Issue 15392: CSC missing as submitter
Issue 15767: 09-12-09 SoaML 1.0 beta 2 Figure 78 p. 135
Issue 15775: 09-12-09 SoaML Beta 2 Fig 18 p. 36
Issue 15776: 09-12-90 SoaML 1.0 Beta 2 ServiceInterface Constraint [1] p. 94
Issue 15777: 09-12-09 SoaML 1.0 Beta 2 Figure 20 p. 38
Issue 15783: 09-12-09 SoaML 1.0 Beta 2 figure 78 p. 135
Issue 15784: 09-12-09 SoaML 1.0 Beta 2 figure 79 p. 136
Issue 15785: 09-12-09 SoaML 1.0 Beta 2 figure 83 p. 141
Issue 15786: 09-12-09 SoaML 1.0 Beta 2 figure 93 p. 149
Issue 16064: RedefinableTemplateSignature is not part of MOF so should be removed from the metamodel
Issue 16065: There are several (seven to be precise) cases where {subsets} relationships are represented in the XMI as Constraints
Issue 16066: BMMIntegration the property MotivationRealization.realizedMotivation {subsets supplier}.
Issue 16067: Service::protocol redefines Port::type so ServiceInterface::service should redefine typedElement.
Issue 16068: MotivationRealization.implementingClassifier should {redefine client}.
Issue 16069: Several Associations and Properties are not named, as required by MOF
Issue 16070: Several properties are private not public as required by MOF
Issue 16071: The references to the elements in the UML metamodel do not use the xmi:ids that are in the normative UML XMI file
Issue 16072: In the metamodel XMI the class Attachment has two Generalization elements both targeting Property
Issue 16073: Class Milestone and Expose
Issue 16074: metamodel XMI does not contain the classes CapabilityRealization and CapabilityExposure which are shown in Figure 9.7
Issue 16075: Category and CategoryValue
Issue 16076: No values are specified for the XMI namespace URI or prefix
Issue 16077: Classes Service and Request
Issue 18142: Various stereotype attributes should have multiplicity 0..1 in the SoaML profile
Issue 18242: ServiceInterface extends UML Interface
Issue 18243: ParticipantArchitecture has been replaced by ServicesArchitecture
Issue 18244: Ports on ServiceInterfaces
Issue 13194: Section: Executive Overview (soaml-rtf)
Click here for this issue's archive.
Nature: Clarification
Severity: Minor
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"
Resolution:
Revised Text:
Actions taken:
December 31, 2008: received issue
Issue 13333: SoaML Issue: Participant Architecture (soaml-rtf)
Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Cory B. Casanave, cory-c(at)modeldriven.com)
Nature: Revision
Severity: Minor
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.
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).
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 [mailto: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 [mailto: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
The Scheduling interface should be stereotyped <<Provider>>.
The Participant Manufacturer should be a stereotyped <<Participant>> Class and not a Component.
The service and request ports are not typed. They are only named to give impression that they are typed.
he request port for the Shipping Request on Manufacturer is not typed.
The request port for the Shipping Request on Manufacturer is not typed. (This is the same figure as Figure 8).
The request port for the Shipping Request on Manufacturer is not typed. (This is the same figure as Figure 15).
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!
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).
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).
See issue 15323 above (regarding Figure 21). Furthermore, the stereotype on the ShippingService port on the Shipper should be changed from <<ServicePoint>> to <<Service>>.
Stereotype on port should be changed from <<ServicePoint>> to <<Service>>.
The service port Orders on Manufacturer is missing the <<Service>> stereotype.
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.
Interfaces are missing <<Consumer>> and <<Provider>> stereotypes. [CBC1] comment should be deleted.
[GBE2] comment should be deleted.
The interfaces should be stereotyped <<Provider>>.
The interfaces are missing the <<Consumer>> and/or <<Provider>> stereotypes.
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).
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).
Example figure is missing a caption. The ports are not typed nor stereotyped.
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).
The Collaboration Use should NOT be stereotyped <<ServiceContract>>. This is NOT part of the standard. Ports are missing <<Service>> and <<Request>> stereotypes.
ServiceInterface is a sterotype on a Class and not an Interface. The <<ServiceInterface>> stereotyped should be changed to <<Provider>>.
The interfaces should be stereotyped <<Consumer>> and <<Provider>>.
nterface Scheduling should be stereotyped <<Provider>>.
<<ParticipantArchitecture>> is no longer a part of the standard.
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.
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.
[CBC3] comment should be deleted.
[CBC4] comment should be deleted. Interfaces missing proper stereotypes.
[CBC5] comment should be deleted. Use of service interface is not according to the latest spec.
The interfaces should be stereotyped <<Consumer>> and <<Provider>>
Apply <<Provider>> stereotype.
The interfaces should be stereotyped <<Consumer>> and <<Provider>>.
Apply <<Provider>> stereotype.
Apply <<Provider>> stereotype.
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).
Apply correct stereotypes to the interfaces.
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).
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]..."?
Once again, CSC has been omitted as a submitter. Please re-add to the copyright and Acknowledgements.
I believe the accounting participant should play the invoicer role, not the payer role (see Figure 75 p. 133).
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.
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.
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.
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.
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.
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.
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.
RedefinableTemplateSignature is not part of MOF so should be removed from the metamodel
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).
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.
Service::protocol redefines Port::type so ServiceInterface::service should redefine typedElement. Likewise ServiceInterface::request
MotivationRealization.implementingClassifier should {redefine client}.
Several Associations and Properties are not named, as required by MOF
Several properties are private not public as required by MOF
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
In the metamodel XMI the class Attachment has two Generalization elements both targeting Property
Class Milestone appears in the XMI file and the Profile Mapping but not in the Metamodel section of the specification. Likewise Expose
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.
In the metamodel XMI, Category inherits from RAS, whereas Figure 9.8 has it inheriting from NodeDescriptor inheriting from Artifact. Likewise CategoryValue
No values are specified for the XMI namespace URI or prefix
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).
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.
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.
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.
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,