SOAML — SoaML Issue: Use of RequestPoint with bi-directional services

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