Example: ServicesArchitecture (SoaML)
We illustrate the general structure of a ServicesArchitecture, and also illustrate how ServicesArchitectures, ServiceContracts, Participants, and ServiceInterfaces relate to each other.
Relationships
Main Description

Figure 1 illustrates a services architecture involving three participants (dealer, mfg, and shipper) and three services (Purchasing Service, Ship Status, and Ship). Each service is modeled using a CollaborationUse that is typed as the ServiceContract which is associated with the service. 

Figure 1.  A ServicesArchitecture involving three participants and three services. Note: the purpose of the dealer network architecture is to establish the financially related services between dealers and manufacturers such that any dealer can do business with any manufacturer.

 

This services architecture shows how a community of dealers, manufacturers, and shippers can work together. Each party must provide and use the services specified in the architecture. If they do, they will then be able to participate in this community. This "B2B" SOA specifies the roles of the parties and the services they provide and use without specifying anything about who they are, their organizational structure, or internal processes. No "controller" or "mediator" is required as long as each agrees to the service contracts.

By specifying a ServicesArchitecture, we can understand the services in our enterprise and communities in context and recognize the real (business) dependencies that exist between the participants. The purpose of the services architecture might also be specified as a comment. Each participant in a ServicesArchitecture must have a port that is compatible with the roles played in each ServiceContract role it is bound to.

Figure 2 serves to illustrate how the different elements in a ServicesArchitecture are related (the red lines are illustrative only and have no UML meaning).

Figure 2.  Relations between the elements that compose a ServicesArchitecture

  

The diagram shows the "trace" between a service architecture through the participants and their service points to the service contract that defines the service interfaces for each of the service points. What the above shows is that the Dealer and Manufacturer are participants in a "Dealer Network Architecture" in which the dealer plays the role of the "buyer" in the "Purchasing Service" and the "Manufacturer" plays the role of the seller in the same service. Participating in these services requires that they have service ports defined on the participant type - these are the ports on "Dealer" and "Manufacturer" types. These ports have a ServiceInterface type defined in the "Purchasing Service" contract. 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: Ordering Service & Invoicing Service, respectively.

Refer to the ServiceContract (SoaML) example for further discussion of the Ordering Service service contract and compound service contracts.