Holiday reservation application specified through our service model
As stated in our CBSE'12 paper, due to lack of place, we were not able to describe some examples. For a better understranding of the mappings presented in the paper, one can find on this web page these missing examples.
To illustrate our approach, we use an example of specification for a vacation reservation application. This application contains four main kinds of elements:
We will specify this application using each of the three models presented above: by services, by components and by agents. These three specifications can illustrate our semantic mapping rules: each model can be obtained as the mapping of one of the two other ones, according to our mapping rules.
We use our own dedicated graphical syntax for each model (see the legend on each figure).
Some details are not presented on the figures in order to not overload them, like the roles names for interactions, the sets of operations associated with service points or the cardinalities over an interaction (except the cardinalities of " 1 / * " for the internal interactions of HotelChain, presented to show complex interactions as detailed later; The other interactions are considered by default with the cardinality of " 1 / 1 ").
In the three specifications, the elements (an element is then a service, a component, an agent or a group according to the specification of the application via the service, component or agent model) have identical goals and functionalities or at least similar ones. The four elements can be decomposed on two internal parts, each part managing one of the main actions for a client (Client): the first part deals with flight and hotel accommodation offers, and the second part manages the payment for a flight or a hotel room reservation. Thus, the client contains two elements or two services associated with these two actions in the three specifications. In the same logic, the travel agency (TravelAgency) contains an element for queries (SearchVacationOffer) and another one to validate the reservations (ReserveVacation). The airline company (AirlineCompany) uses also the same logic. The last element, the hotel chain (HotelChain) is a bit different: internally, the hotel chain manages several hotels (InternalHotel) through a particular Management} element that aims to dispatch the interactions and requests of a client (coming from the travel agency) to its different internal hotels. This is done through a high-level interaction (represented in service and component sides by a protocol and / or connector). Each hotel has two internal functionalities too: one for requests of information and the other for reservations.
In this section, in addition to the above complete specification examples, we give more details on some mapping examples, following the structure of the Section 3 of the paper.
The following figure illustrates an example of the mappings between a primitive service associated with two service points (and then two sets of operations) in part (a), a primitive component with the two equivalent services (containing the same two sets of operations) in part (b) and in part (c), an agent realizing two interactional and functional roles (still associated with the same two sets of operations).
The following figure shows how a basic interaction of RPC/RMI on the service side (a) is mapped onto the same basic interaction on the component side (b) and onto a communication of basic protocol type on the agent side (c).
Concerning complex interactions, the following figure shows a protocol on the service side (a) is mapped onto a connector (realizing the same protocol) on the component side (b) and onto a coordination or a negotiation element (realizing the same protocol) on the agent side (c).
As explained in the paper, concerning the hierarchical structures, there is a problem on the agent side as it is limited to only two levels: agents contained in groups. The following figure illustrates the mappings in this context: a composite service (resp. component) containing two internal primitive services (resp. primitive components) is mapped onto a group of two agents.
One way to overcome this hierarchical problem is to use shared agents between different groups to represent the structural levels of an organization. If an agent member of a group of level n is also member of the group of level n+1, then it can be considered as the representing element of the group of the lower level and all the interactions between the two levels must be managed by this agent. The following figure shows an example of such principles: a composite component (on the left) with three levels of composition is mapped onto two groups of agents (on the right) where a dedicated and shared agent (named AB) has been added to be the representing agent between the group associated with the B composite component and the group associated with the A composite component in which B is contained.
We present here two examples of mapping variants. The first one consists in not transforming systematically a composite (resp. primitive) element into a composite (resp. primitive) element of another model when internal elements are not interacting among each other. The following figure shows such an example: on part (a), a composite service contains two primitive services. This composite service is mapped onto a primitive component containing two primitive services or a single agent containing two interactional roles.
A second variant consists, on the component side, to prefer using a primitive component connector instead of a connector to map a complex interaction of the service or agent side. The following figure shows a protocol on the service side, on part (a), that is mapped onto a pritimive connector component on the component side, on part (b). One can note that the service points of the connector components are the same that on the components that it connects, but in a symetric way (a required service point becomes provided and vice-versa).
