EXÁMENES PARACLÍNICOS

The UML activity diagram and BPMN [128] are the common notations used for BPEL4WS process modeling. A proposal for UML Profile for BPEL4WS [18] uses old BPEL 1.0 specification and UML 1.4, but provides guidelines on how to map BPEL4WS processes to UML activity diagrams. Also, a UML 2.0 profile for BPEL4WS have been proposed [17]. Ruokonen et al., in [113], presents a

Table 7.1: Information represented by resources of Holiday Booking REST CWS

Resource Information

1- collection_bookings Gives a list of all the bookings

2- booking Gives detail of a specific booking

3- Pay Tells whether the booking payment is being processed

by the payment service or not

4- Paid Tells if a booking is paid or not

5- pRelease Tells if the payment of the booking is

released to the hotel or not

6- WaitingPRelease Tells whether a payment release is being

processed by the payment service or not

7- ConfirmHPRelease Tells if the payment release is confirmed

to the hotel

8- hotelCheck Tells if the booking is being processed by

the hotel for its confirmation

9- hotelConfirm Tells if the booking is confirmed by the hotel

10- WaitingCheckIn Tells if the booking is waiting

for user check in

11- CheckInConfirm Tells if the user has checked in or not

12- cancel Tells if the booking is canceled

13- WaitingRefund Tells if the booking is being processed

by the payment service for refund

Figure 7.2: Resource Model for HF Composite RESTful Web Service

UML-based approach for creating BPEL4WS flavored activity models, which enable generation of executable BPEL4WS descriptions. By combining existing works, we aim at proposing modeling constructs, given as UML activity diagram, for BPEL-REST processes.

7.4.1 Scenario Models

Our target is to model a RESTful process for Holiday Booking composite REST web service using the static structure of the service defined in the resource model shown in Figure 7.2. We start with a set of sequence diagrams that show a number of interactions with the composite service. A sequence diagram shows the object interactions using time-oriented visualization [103]. We call these scenario models. We require that the modeler sketches simple example scenarios illustrating required behavior of the process. This set of scenario may not (but can) contain all the possible execution scenarios. For the details of this approach presented by Ruokonen et al. readers are referred to [113]. Some exemplary process scenarios for our approach are presented in Figure 7.3. Here, BookingH is a process, which is to be implemented as a RESTful composite service. BookingH uses two external RESTful services: PaymentService and hotelService. In Figure 7.3 (top), a customer invokes the composite service BookingH and pays for it. When the customer pays, BookingH invokes the partner service, PaymentService. The service

returns a payment confirmation by invoking the PUT method on paid resource of BookingH. In the scenario shown in the bottom of Figure 7.3, BookingH composite service invokes the partner hotel service, hotelService, for booking confirmation. In case, the hotel service confirms the room booking, BookingH service waits for user check in. When the user checks in, BookingH invokes the payment service to release the payment to the hotel that was withheld. When the payment service confirms the release of the payment, BookingH marks that payment for the booking has been released. It, then, also invokes a POST on confirm resource of the hotel service to mark it as paid.

7.4.2 Process Model

From the scenario models, we want to create a process description, which im- plements these scenarios. We aim at a process model, which is compatible with BPEL-REST process language. For process modeling, we chose UML activity diagram that are used to model the flows in a process [125]. To construct the pro- cess model, we model BookingH service’s view on the conversation. This means messages sent and received by the BookingH service. Send message events in a sequence diagram present invocations in an activity diagram and receive message events means that the process receives an operation call.

In Figure 7.4, a workflow-oriented model for Holiday Booking process is shown as an activity diagram. The following listing presents how UML activity model constructs are used to model BPEL-REST processes. Pautasso [102] proposes four activities to invoke a REST web service from the process, i.e., HTTP invocations get, put, post, and delete. Thus,

• Method invocations are modeled as a call behavior action (stereotype << get>>, << put >>, << post >>, << delete >> respectively). A call behavior action in UML activity diagram invokes an activity or a state machine [125].

Request handlers receive the request invoked on the composite service and perform the corresponding tasks. The request handlers in BPEL-REST are defined for each resource and stem from the REST uniform interface principle. Thus, onPut,onGet,onPost, and onDelete request handlers are mapped to activities as follows:

• onPut is modelled as a call behavior action (stereotype << onPut >>) • onGet is modelled as a call behavior action (stereotype << onGet >>) • onPost is modelled as a call behavior action (stereotype << onPost >>) • onDelete is modelled as a call behavior action (stereotype << onDelete >>) • respond is modelled as a call behavior action (stereotype << respond >>) • sequence is modelled as a control flow

Unlike onMessage activities in BPEL4WS, RESTful message handlers can have internal structure and thus they could be also modeled as structured activities,

which contain a respond activity and possibly some other if-else structures. On the other hand, onPut and respond could be modeled as a pair of simple activities, which has a potential sequence of activities between them. The same applies of course to other message handlers. As a modeling restriction, links across activities, which belong to different message handlers are not allowed. A resource in an activity model, would be modeled as a structured activity, which contains all the message handlers it supports. However, our target is to simply model the workflow, which models the desired behavior, in the activity diagram.

The process model defines the workflow of the composition process. In order to look at the web service composition from the viewpoint of how different resource attributes change and the conditions of method invocations, we model the web service composition with UML state machine in the next section.