Docstoc

Rapport

Document Sample
Rapport Powered By Docstoc
					Forside.
Introduction
In this assignment we want to gain practical experience with the business modeling language Choreography
and the eclipse plug-in PI4SOA, which we will be using to model a concrete business scenario.

Choreography is defined in the [reference], and is developed with the intend to help model business
models that follow concretely defined scenarios. The power of Choreography is that you can make smaller
Choreographies that model basic interactions and from these, develop advanced models, much more
complicated than each individual choreography (Kavantzas, Burdett, Ritzinger, Fletcher, & Lafon, 2004).

It has been made a standard by the W3C.


Analysis
The purpose of the assignment is to model a specific business case. We chose one of the suggested cases
from the course web-page (Glenstrup & Carbone, 2009), namely the Auction House. The purpose of this
business case is to model an online Auction House that involves 4 participants: A buyer, a seller, the auction
house itself and a 3rd party broker. As this was very loosely described we had to define a set of
requirements, which will be the main part of this section. They are mainly based on the online tutorials that
can be found on eBay (Missing Reference!!), but simplified quite a bit. Before defining the requirements,
we need to give a set of assumptions about our model.

Assumptions
These are our assumptions:

       Security is of no concern, but we do need to be able to identify participants.
       No handling of race conditions.
       Only the most basic item information.
       No extra fees.
       Complete trust between buyer and seller.
       An auction for an auction item ends, when a certain maximum price for the item has been
        exceeded.
       More?

Requirements
As mentioned we have four different roles in our business case, which we will explain here:

       Seller: A client that places auction items for sale on the Auction House (service)
       Buyer: A client that wishes to bid on auction items and perhaps pay for one.
       Auction House: A service that offers various options to clients, for instance selling items, bidding on
        items, etc.
       Broker (3rd party): A service that can be used by a client to transfer money between accounts.

We have defined the following three sub-business cases for the overall business case:
   1. Seller puts item for sale
   1.1. A sell request must contain the following information: user ID of seller, start price, max price, item
       name, item description and a broker account ID of the seller.
    1.2. The Auction House must reply with a response message, containing the user ID and a status
        indicating whether the auction item was accepted or rejected.
    1.3. If the item was accepted an item ID is assigned to the item

    2. Buyer places bid for item
    2.1. A bid request must contain the following information: user ID of buyer, item ID and bid.
    2.2. The Auction House will validate the request. There are four different response types depending on
        the outcome of the validation: The auction is closed; the bid is lower than the current highest bid;
        the bid is higher than the current highest bid and lower than max price; the bid is higher than max
        price. The response contains the following information: user ID of buyer and a status.
    2.3. If the bid is valid it is stored along with any other existing bids on the item.

    3. The final bid has been placed and buyer opts to pay for the item
    3.1. Buyer sends a pay request to the Auction House. The request must contain the following
         information: user ID and broker account ID of buyer.
    3.2. The Auction House sends a pay request to the Broker that must contain the following information:
         user ID and account ID of buyer, account ID of seller and the amount to transfer.
    3.3. The Broker checks if the buyers account balance is higher than the amount. It then replies to the
         Auction House with a response message containing the user ID of buyer and a status indicating
         success or failure depending on the balance check.
    3.4. If the payment was a failure the Auction House replies to the Buyer with a response message
         containing user ID of buyer and a status. If it was a success the Auction House closes the auction for
         the specific item and replies to the Buyer with a response message containing use ID of buyer and
         status.

Race conditions
Although we stated as an assumption that we do not deal with race conditions, because we don’t have the
time we still feel we should mention how this could be done.

In our case several issues can arise from the situation, where two buyers concurrently bid on the same
item. This is because the item is not locked for updates, which allows two buyers to concurrently modify
bids on the item. To prevent this problem we could lock the relevant item as soon as we receive a bid
request and unlock it when we are eventually done and block any other concurrent bid requests on the
same item. Of course this is not very efficient and could be made more efficient if we had a database with
transaction facilities.


Choreography Descriptions
From the analysis we did in the previous sections, we can now start to define our choreographies.

To create a choreography, one first needs to define the Roles and their relationships. These we identified
in our analysis in the previous section. Once the Roles and relationships are defined we need to define
some base types that are used to identify for a variety of different things. Among other things it defines
what messages there will be sent from the different roles. It also helps define the channels that are used in
sending messages between the roles.

When the base types have been defined the choreography flow can be defined. Again we can use the
analysis from the previous section to help us in how the flow should look. The Choreography consists of a
vertical flow where you can attach various activities, representing actions done by the different
participants. You can also change the flow of the choreography by using ‘Grouping Constructs’, which
basically allows you to introduce things like loops, conditionals and choices. Things that will break the linear
flow of things.

Of the different activities the one called Activity is worth mentioning. This is basically what is used to define
a communication between two roles. For each activity we need to define various information, like who is
communicating with whom, and what kinds of messages that are being sent or received.

We now use the things we found in our analysis, to construct our Choreography.

The first attempt we made had both the buyer and the seller together in the same Choreography. We
started the choreography with the seller making requests for putting items for sale. Then followed the
buyer, that tried to place bids on an item in stored in the auction house. We quickly realized that we had
misunderstood how the choreography, which was further backed up by the fact, that we discovered that
testing with anything else than just one client would not be possible. As we also mentioned in our analysis,
both the buyer and the seller are clients in our scenarios.

This made us realize that we had the wrong understanding of what choreographies really where. The main
reason for trying to put the buyer and the seller in the same choreography was that we thought of the
choreographies as protocols where you could define a series of events that might happen at some point,
and not, as we realized later, modeled actual events, happening in a certain sequence. Once we realized
this, we split the buyer and seller into their own choreographies.

Seller Choreography
From the analysis we saw that the seller is a small part in our model, but nevertheless an important one. If
the seller doesn’t place items for sale, our buyers won’t have anything to buy.

Buyer Choreography
Once the seller choreography is done, we can start working on the buyer choreography. This is more
advanced, since we will be talking with two different services, the auction house service and the broker
service. We discovered how the message flow should be during our analysis, and now we just need to
implement it in the choreography. As with the seller choreography, the client initiates the flow, by sending
a bid request for a specific item. In this request the buyer must include information regarding which item to
place the bid on, and the amount the bid is on. These informations are stored in variables in the
choreography, which is done to make these values accessible to the other parties in the choreography.

From here on, the choreography can choose between four different paths. The branching depends on the
amount of the bid given, and whether the auction is already closed, or still running. Three of the paths are
not very interesting, either the bid is too low, the bid is the highest given so far, but haven’t reached the
maximum price defined, or the auction is closed. Either way a reply is simply sent back to the buyer, with a
status of the request.

On the other hand, if the bid given is the bid that closes the auction, interesting things happen. The first
thing that happens is that a reply is made by the auction house, telling that the auction is done. This will tell
the buyer, that payment information should be sent back to the auction house, so that money can be
transferred from the buyer to the seller. The buyer makes a new request to pay for the item sending his
broker account information to the auction house. The auction house, which already knows the sellers
broker account information, gathers the relevant information and sends the whole thing in a pay request
message to the broker. Once the broker receives the pay request from the auction house, it stores the
information in variables in the choreography. When that is done, the broker validates the transfer request,
meaning that the accounts should be available and the account should hold enough money to be able to
make the transfer. If one or the other conditions fail, the broker will respond back to the auction house,
that the transfer was not possible, who in turn will forward this message back to the buyer, and the
choreography ends.

If the transfer is possible, it is done, and the broker will reply the auction house that the transfer has been
made. Once confirmation has been received on the auction house side, the bid will be committed to the
database, and a positive response to the buyers pay request will be sent back to the buyer.

The two places where a conditional decides which way the choreography should flow, we have used the
structures Conditional surrounded by a choice in the choreography flow.

As with the seller choreography flow, we have identified two different requests. A few requires data, that
will not be available through the choreography, and for those we have made a data file, that contains this
information. The other messages uses a message handler, that will build messages using parameters given
by the requester.

Experiences
During our work with the choreographies…


Evaluation
In this section we will try and give our evaluation of choreography and in particular our thoughts on the
plug-in PI4SOA. This will include an evaluation of choreography as a technology used to model business
cases, as done in our analysis, but also our thoughts on PI4SOA as a tool to help implement a choreography
flow.

Choreography
The first thing we noticed while getting to know choreography was that the learning curve was very steep.
The documentation lacked somewhat, although we during the course of our rapport managed to dig out
most of the answers. However we often encountered places in the documentation, where information had
not been written or where subjects were not touch on at all.

Further we missed examples that could show how the choreography should be used in practice. We found
some examples, but either they were very complicated, or very simple. We missed the famous golden
middleway.

PI4SOA
PI4SOA is an eclipse plug-in that has been developed by various people and documentation can be found at
(Pi Calculus for SOA, 2009). It is a plug-in for eclipse to aid building choreographies.
We have been told that work on this has been discontinued, but we will still wish to point out some faults
that could have been improved, or which gave us grieves during the development.


Practical Experiences


Conclusion



Bibliography
Glenstrup, A. J., & Carbone, M. (2009). Course projects. Retrieved from Advanced Mobile and Distributed
Systems-E2009: https://blog.itu.dk/SAMD-E2009/course-projects/

Kavantzas, N., Burdett, D., Ritzinger, G., Fletcher, T., & Lafon, Y. (2004). Web Services Choreography
Description Language Version 1.0. Retrieved from http://www.w3.org/TR/2004/WD-ws-cdl-10-20041217/

Pi Calculus for SOA. (2009). Retrieved from http://sourceforge.net/apps/trac/pi4soa/wiki




Appendix
Appendix A - Use case scenarios
First we will define the preconditions for all our use cases. For all scenarios we have an auction house
database containing the following data:

User ID    Item name                Item description    Start price        Max price    Sellers broker
                                                                                        account ID
1          Lenovo ThinkPad T63    High quality          2000               10000        1
                                  laptop, slightly
                                  used
Our broker database contains the following data:

                                Account ID             Amount
                                1                      2000
                                2                      15000
                                3                      9950
                                4                      12000
All scenarios have two buyers, Bob and Alice, one auction house, eBayLight and one broker, PayPalLight.
They are all run with the “Simulate and execute” command in PI4SOA, selecting the AuctionHouse and
Broker services for execution.
Valid scenario
This scenario tests whether our choreography sends the correct messages, depending on the contents of
the message and the state of the auction item in question. It explores all the possible branches in our
choreography and supports the following use case:

   1. Bob sends a BidRequest for the auction item with a price that is higher than the current highest bid
       and lower than the max price.
   2. eBayLight replies with a (fault) BidResponse, saying that the max price has not been reached
   3. Alice sends a BidRequest for the auction item with a price that is lower than the current highest
       bid.
   4. eBayLight replies with a (fault) BidResponse, saying that the current highest bid has not been
       reached.
   5. Alice sends a BidRequest for the auction item with a price that is higher than the max price.
   6. eBayLight replies with a BidResponse, saying that the max price has been reached.
   7. Alice sends a BuyerPaymentRequest containing a broker account id.
   8. eBayLight sends a AuctionHousePayRequest to PayPalLight containing Alice’s broker account id, the
       account id of the seller and the amount to transfer.
   9. In this case there is not enough money on Alice’s account, so PayPalLight replies with a (fault)
       AuctionHousePayResponse, saying that the payment failed.
   10. eBayLight replies to Alice, saying that the payment failed. The bidding on the auction item is not
       committed.
   11. Steps 5 and 6 are repeated.
   12. Alice sends a BuyerPaymentRequest containing another broker account id.
   13. eBayLight sends a AuctionHousePayRequest to PayPalLight containing Alice’s broker account id, the
       account id of the seller and the amount to transfer.
   14. In this case there is enough money on Alice’s account, so PayPalLight makes the transfer and replies
       with a AuctionHousePayResponse, saying that the payment succeeded.
   15. eBayLight replies to Alice, saying that the payment succeeded. The bidding on the auction item is
       committed and closed.
   16. Bob sends a BidRequest for the auction item with a price, that is higher than the current highest bid
       (and max price).
   17. eBayLight replies with a (fault) BidResponse, saying that he auction for this item is closed.

As it can be seen from the picture our choreography works as intended.
Invalid scenario 1




This scenario tests a use case, where Alice tries to issue a payment request for the auction item, but she
should not be allowed to purchase it:

[Steps 1 to 4 are the same as in the valid scenario]

    5. Alice sends a BuyerPaymentRequest containing her broker account id.
    6. eBayLight sends a AuctionHousePayRequest to PayPalLight containing Alice’s broker account id, the
       account id of the seller and the amount to transfer.
    7. There is enough money on Alice’s account, so PayPalLight makes the transfer and replies with a
       AuctionHousePayResponse, saying that the payment succeeded.
    8. eBayLight replies to Alice, saying that the payment succeeded. The bidding on the auction item is
       committed and closed.

This scenario fail, because Alice tries to issue a payment request to the auction house after having received
a (fault) BidResponse, saying that the current highest bid has not been reached. This is unexpected
according the choreography and thus the scenario simulator throws an
“org.pi4soa.service.OutOfSequenceMessageException”.
Invalid scenario 2




This scenario tests a use case, where Alice tries to pay for an item, which fails (due to lacking funds on
Alice’s account) at PayPalLight, which tells this to eBayLight, which in turn tells Alice that the payment
succeeded:

[Steps 1 and 2 are the same as the previous use cases]

    3. Alice sends a BidRequest for the auction item with a price that is higher than the max price.
    4. eBayLight replies with a BidResponse, saying that the max price has been reached.
    5. Alice sends a BuyerPaymentRequest containing a broker account id.
    6. eBayLight sends a AuctionHousePayRequest to PayPalLight containing Alice’s broker account id, the
       account id of the seller and the amount to transfer.
    7. In this case there is not enough money on Alice’s account, so PayPalLight replies with a (fault)
       AuctionHousePayResponse, saying that the payment failed.
    8. eBayLight replies to Alice, saying that the payment succeeded.

This scenario fail, because eBayLight tries to send a positive response to Alice in step 8, which does not
follow the protocol of the choreography, that says this should be a negative response.
Concurrent scenario




This simple scenario tests a use case, where Bob bids on an item before Alice, but Alice gets her reply first,
thereby cheating Bob:

    1. Bob sends a BigRequest for the auction item with a price higher than the current highest bid and
       lower than max price.
    2. Alice does the same.
    3. eBayLight replies to Alice with a BidResponse, saying that the max price has been reached.
    4. eBayLight replies to Bob with a (fault) BidResponse, saying that the auction is closed.

This should not be allowed to happen and we have explained in the analysis section, how to prevent it from
happening.

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:26
posted:11/20/2011
language:English
pages:11