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.