Issues for Mailing list of the UML Profile and Metamodel for Services (SoaML) Finalization Task Force

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

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

Issue 13189: specification is inconsistent in capitalization regarding defining stereotypes and utilizing the stereotypes in examples
Issue 13305: loading the profile into Eclipse (v3.4, with EMF 2.4.0 and UML2 2.2.0) - error
Issue 13332: SoaML Issue: Use of RequestPoint with bi-directional services
Issue 13334: SoaML/UPMS Issue - Collaboration class specification
Issue 13335: SoaML Issue: Expose class specification (Capabilities profile)
Issue 13336: SoaML Issue: Alphabetic placement of the Port class specification
Issue 13337: SoaML Issue: Component as a superclass of Participant
Issue 13338: SoaML Issue: Port Direction
Issue 13339: SoaML Issue: ServicePoint description out of alphabetical order.
Issue 13340: SoaML Issue: Participant aggregation
Issue 13346: SoaML: The distinction between participant and ParticipantArchitecture Participants is unclear
Issue 13347: SoaML: Capability Exposure is not defined
Issue 13350: SoaML: Bullet and numbered lists are missing from the responses to requirements section
Issue 13351: SoaML: SoaML should be published in Open Document Format
Issue 13406: Issue regarding MessageType display for DataTypes
Issue 13527: MessageType Signal issue
Issue 13528: MessageType Content Constraints
Issue 13545: ServiceInterface Notation
Issue 13652: SoaML: MotivationElement shouldn't be a stereotype
Issue 13717: Compliance level is needed
Issue 13725: SoaML: Figures 24 and 25 are missing their CollaborationUse and role bindings
Issue 13818: SoaML Issue - Service Interface applied to class and interface
Issue 13819: SoaML : SoaML Trademark
Issue 13871: ServiceArchitecture
Issue 13925: The definition of "service" should be refined
Issue 13935: Clarify relationship of Port::isService with ServicePoint and RequestPoint
Issue 13975: Attachment and the attribute mimeType
Issue 14067: SoaML: Rename ServicePoint and RequestPoint for SOA Harmonization
Issue 14226: SOAML: Provide icons for some SoaML stereotypes
Issue 14229: SoaML: Milestone::value has inconsistent multiplicity
Issue 14230: SoaML: Examples in Annex B and Annex C need to be updated
Issue 14440: There is no convenient way to summarize what services a participant produces and consumes
Issue 14922: Title: Figure 95 uses instance keyword instead of part
Issue 14923: Figure 95 extends activity execution semantics
Issue 14924: Figure 95 uses UML ports without UML semantics

Issue 13189: specification is inconsistent in capitalization regarding defining stereotypes and utilizing the stereotypes in examples (soaml-ftf)

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.

This is an editorial change that can be made when the final changes to the specification are applied.

The issue of whether to follow the guidelines or not was discussed many times and the conclusion of the submitters and FTF task force members of SoaML and others was to use stereotype names that match the name of the stereotype in the Profile.

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

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.

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

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 stereotype Description for Port needs to be moved just before Property — to maintain alphabetical order.  (Currently, it appears before the MesageType description.)

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.

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.

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 .

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.

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. 

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.

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

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

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.

"datatype" is a keyword, not a stereotype. Typically when a stereotype is applied to an element described using a keyword, the keyword is no longer needed and may be suppressed. Alternatively tools could choose to show "datatype, MessageType".

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

The message type stereotype will be able to be applied to signal.  In the meta model, a subtype of signal will be created, called "MessageSignal".

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.

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

UML2 shows an Interface using the Classifier notation with a "interface" keyword. This keyword can be included with the "ServiceInterface" keyword if desired. However, when a simple interface is used to type a ServicePoint or RequestPoint, the "ServiceInterface" stereotype is not required
 
Resolution: Closed no change

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.

MotivationElement does not even have to be a stereotype, it only needs to be an abstract class, just like in BMM. Any stereotype in a BMM profile would specialize MotivationElement as well as extend some UML metaclass.

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.

The UPDM finalization task force team has agreed to replace its services modeling capabilities with SoaML. This will be based on a Mapping I created between UPDM services modeling and SoaML:
UPDM 	SoaML 	Notes 
Performer (Class)	Participant (Class)	Performer will need to inherit from Participant
Service (Port)	ServicePoint (Port)	Will use ServicePoint directly Constraints need to be added 
Request (Port)	RequestPoint (Port)	Will use RequestPoint directly
ServiceInterface (Class)	ServiceInterface (Class)	Will use ServiceInterface directly Constraints need to be added 
Capability (Class)	Capability (Class)	Will use Capability directly Constraints need to be added 
ExposesCapability (Dependency)	Expose (Dependency)	Will use Expose directly
ResouceConnector (Connector)	ServiceChannel (Connector)	ResourceConnector will need to inherit from ServiceChannel
UPDM will use ElementImport to import the SoaML stereotypes they wish to reuse. This eliminates the need to create a specific SoaML compliance point that has a subset of the extensions needed by UPDM. We could do that, but this is not a sustainable solution as other standards that want to use a different subset would require another unique compliance point making compliance ineffective and model interchange difficult.
The resolution to UML2 Issue 12833: "Clarification on use of Profiles" clarifies the meaning of package and element import indicating the imported public elements are in the namespace of the importing package and can therefore be used similar to model elements defined directly in that package. We all agreed this was the best approach for reusing elements from other models.
UPDM will extend the SoaML stereotypes as needed to address their specific needs.

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.

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.

This is duplicate of 13545. UML2 provides a "interface" keyword to distinguish Classifier notation for an Interface. SoaML "ServiceInterface" is not required for simple one-way service interactions that have no protocol. The spec specifically calls out this simple case a number of times in the introduction. 
This issue is also further addressed by the resolution to issue 13338: Port Direction.

Resolution: Duplicate of 13545

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

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.

Resolution: 
The way the services architecture shows how a set of participants works together is by showing their roles in the services architecture collaboration.  For this reason it is required that the participants type the roles.

Revised Text: 
Actions taken: Closed, no change.

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

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. 
  

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

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.

OASIS SOA Reference Model defines Service as:
A service is a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description.  A service is provided by an entity - the service provider -  for use by others, but the eventual consumers of the service may not be known to the service provider and may demonstrate uses of the service beyond the scope originally conceived by the 
provider. 

A service is accessed by means of a service interface (see Section 3.3.1.4), where the interface comprises the specifics of how to access the underlying capabilities.  There are no constraints on what constitutes the underlying capability or how access is implemented by the service provider.  Thus, the service could carry out its described functionality through one or more a and/or manual processes that themselves could invoke other available services.  
TOG SOA Ontology
Service is the core concept of this ontology. It is a concept that is well-understood in practice, but is not easy to define. The ontology is based on the following definition, which was developed by The Open Group Service-Oriented Architecture (SOA) Work Group:
"A service is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit; provide weather data, consolidate drilling reports). It is self-contained, may be composed of other services, and is a "black box" to its consumers."
Other current definitions include:
·	"A mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description" (from the [OASIS SOA] Reference Model)
·	"A capability offered by one entity or entities to others using well-defined 'terms and conditions' and interfaces" (from the [OMG SoaML] Specification)
Within the normal degree of precision of the English language, these definitions are not contradictory; they are stressing different aspects of the same concept.
A service has a provider, may have multiple consumers, and produces one or more effects (which have value to the consumers). The providers and consumers are actors. The classes and properties corresponding to these concepts are illustrated in Error! Reference source not found.. The Actor class and the provides and consumes properties are defined in Section Error! Reference source not found.. The Effect class and the has effect property are defined in Section Error! Reference source not found.
TOG SOA Reference Architecture
Services themselves have a contract element and functional element.  The contract defines what the service does for consumers, while the functional element implements what a service contracts to provide.  The service contract is integrated with the underlying functional element through a component which provides a binding. This model addresses services exposing capabilities implemented through legacy assets, new assets, services composed from other services or infrastructure services.

This layer contains software components, each of which provide the implementation or "realization" for a service, or operation on a service; hence the name Service Component. Service components reflect the definition of the service they represent, both in its functionality and its quality of service.  They "bind" the service contract to the implementation of the service in the operational systems layer.  Service components are hosted in containers which support a service specification.

This layer contains the contracts that bind the provider and consumer. Services are offered by service providers and are consumed by service consumers (service requestors).
 
SoaML
A service is an offer of value to another through a well defined interface and available to a community (which may be the general public).  A service results in work provided to one by another.
Fred Cummins's expanded definition:
A dictionary style definition:
Service (noun) 1a:The work or action performed by one that serves <gives good and quick ~> (Webster), b: the occurrence of work or action provided to a particular consumer <provided a ~>.  2a: a facility supplying some public demand <a bus ~> (Webster), b: organizational entity that offers the capability to perform defined types of work or action for consumers <an accounting ~>.
An expanded explanation:
1a: The work or action performed by one that serves <gives good and quick ~> (Webster).
This refers to the value delivered by a service provider without reference to a particular consumer or performance of the work or action.  So we may say John provides a shoe repair service, something that he does over and over again.
1b: the occurrence of a unit of work or action provided to a particular consumer <provided a ~>.
This refers to work or action provided (or intended to be provided) to a specific consumer.  So we may say Jane received a service from John when he repaired her shoes.  Note that Jane may return with another pair of shoes for another shoe repair service.
2a: a facility supplying some public demand <a bus ~> (Webster).
This refers to a capability to perform a type of work or action.  We may refer to a bus service (defines a capability typical of metropolitan areas), or the bus service of Detroit.
2b: organizational entity that offers the capability to perform defined types of work or action for consumers <an accounting ~> Syn provider, service unit.
All of these definitions of Service are reasonably consistent although each tends to abstract some concepts of service and illuminate others. However, these definitions often don't distinguish between the definition of a service, the provision and use of services by participants, and the activities used to carryout the service. These are all considered different aspects of service and are reflected in the different definitions Fred provided above. The OpenGroup SOA Ontology mixes all three together in its definition of service as a kind of activity that is provided and consumed by actors. This has the odd characteristic that the consumer of a service is explicitly coupled to how the provider performs the service as they are one and the same. TOG SOA Ontology also does not distinguish between class an instance for Actor or Activity, rather it relies the difference being clear from the context. This may be sufficient for an Ontology, but doesn't work well in a metamodel or runtime environment where classes and instances, and definitions and usages of activities are very different. A key point the SOA Ontology does make is that each service can only be provided by a single actor. Another actor can provide a service defined by the same service interface, but that is considered a different service. This distinction highlights the idea that services exist in the context of actors that provide and consume them, and that existence is separate from the interfaces that define the service. There is ongoing discussion with the OpenGroup to also separate service from the activities that carry them out in order to further decouple the actors.

These various definitions are also consistent with the definition of ServicPoint and RequestPoint in SoaML where they emphasize the actual service provided by one participant and consumed by another rather than the definition of the service, or the actual activities used to carry it out. However, in the context of an SOA, the architecture is not determined by either the definition of the services, or the activities used to carryout the services. Rather the architecture is primarily established by the services that participants provide and consume, and how they are connected together to do so in order to provide the services, exchange the value, accomplish goals, etc. As a result, ServicePoint and RequestPoint should be renamed to Service and Request in order to be more consistent with other standards, to highlight the important aspect of participants providing and consuming services, and to simplify the profile.
In summary: 
(Note: this summary text, along with the text in the "Port Direction & Design Pattern Issues" of ballot-2 (issues 13332, 13334, 13338, 13545, and 13725) has been included in the update to section 7 SoaML UML Profile Specification, subsection Executive Overview in response to issue 13189).

A Service is a feature of a Participant that represents work, information, or action the Participant offers to other Participants, is capable of performing on their behalf, having some specified outcome or real-world effect, and potentially involving an exchange of value.
The definition/specification of, or interface to a service is specified by a ServiceInterface which defines the operations, events, information and interaction protocols that are involved in the service. Participants providing the service are expected to perform the service as specified by the ServiceInterface and Participants consuming the service are expected to use the service as specified by the ServiceInteface.

One or more ServiceInterfaces may also be combined in a ServiceContract which can further specify and constrain related services provided and consumed by Participants.
A Participant provides a service through a "Service" Port and consumes service through a "Request" Port. Service and request ports define the features representing services provided and consumed by participants and provide a mechanism to enable access to those services as defined by their service interfaces. 
Interactions between service and request ports occur over a ServiceChannel in a manner consistent with protocols, constraints and policies as specified by the service interfaces.
A Participant implements its provided services either through delegation to its parts representing capabilities or resources required to perform the service or other participants having the required capabilities and resources, through requests for services from others, through the methods of the service operations, or through actions that respond to received events. The implementation of the service must be consistent with the operations, protocols and constraints of specified by the ServiceInterface.

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 multiplicity for Milestone::value is [*] in figure 20 and [0..1] in the Associations subsection of 7.1.14. Which is it? 

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

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. 
  

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

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