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.

No Data Available

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.

No Data Available

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.

No Data Available

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.

Remove the ownedAttributes constraint of message type.

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.

No Data Available

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

No Data Available

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.

Duplicate of 13335

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.

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

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

No Data Available

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.

Resolution: Closed, no change

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

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.

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

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.

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.

These associations have been removed in response to another issue.

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.

closed no change

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

The attribute definition was missing.

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.

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

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.

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

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

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.

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

No Data Available

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.

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.

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.

No Data Available

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

The trademark has been added.

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

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

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

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

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.

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

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 .

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

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.

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

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.

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

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

resolvrd

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.

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.

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

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

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"

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.