Legacy Issue Number: 18244
Source: Gebhart Quality Analysis (QA) 82 ( Michael Gebhart)
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.
Reported: SoaML 1.0.1 — Fri, 2 Nov 2012 04:00 GMT
Updated: Fri, 6 Mar 2015 20:57 GMT