Figure 1 illustrates an example of an OrderProcessor Participant that has a purchasing Service and three Requests -- invoicing,
scheduling, and shipping -- that are required to implement this service. The implementation of the purchasing
Service uses the capabilities provided through Services that will be connected to these Requests.
Figure 1. A Participant with multiple RequestPoints
The invoicing Request is typed by the InvoicingService ServiceInterface. The scheduling Request is typed by the Scheduling Interface. This
is an example of a simple Request that specifies simply a list of needs.
It is very important to note that each RequestPoint is typed with exactly the same
type that was applied to the ServicePoint to which the RequestPoint is being connected. This is because the
RequestPoint represents the usage of its type, so what is shown as a provided interface on the RequestPoint actually is
an interface that is being requested, and what is shown as a required interface on the RequestPoint actually is an
interface that the RequestPoint is providing. See RequestPoint (SoaML) for further discussion. The implication is that
the past request point typing practice in UML-based service modeling is obsolete with SoaML.
With pure UML, request ports were typed such that their provided and required interfaces explicitly were the inverse
(the conjugate) of the interfaces on the service port to which a connection was being made. In SoaML-based
modeling, the connecting RequestPoints and ServicePoints are typed with the same ServiceInterface or simple UML
Interface. This is illustrated in Figure 2, where it is seen that types on each of the matched
RequestPoints/ServicePoints are the same -- conjugates are not used here.
Figure 2. ServicePoints and RequestPoints are typed using the same ServiceInterfaces
|