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,

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.

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.