Smart SOA Platforms in Cloud Computing Architectures

Ernesto Exposito, Codé Diop

• Publisher: Wiley-ISTE
• Year: 2014
• ISBN:
  9781118761694
• Edition: 1
• Topic: Technology & Engineering
• Subtopic: Microelectronics
• Index: Technology & Engineering

This book is intended to introduce the principles of the Event-Driven and Service-Oriented Architecture (SOA 2.0) and its role in the new interconnected world based on the cloud computing architecture paradigm. In this new context, the concept of "service" is widely applied to the hardware and software resources available in the new generation of the Internet. The authors focus on how current and future SOA technologies provide the basis for the smart management of the service model provided by the Platform as a Service (PaaS) layer.

1

ESBay Case Study

To better illustrate the benefits of SOA and cloud computing technologies, the yPBL methodology will be applied to design an adequate solution to a consumer-to-consumer system inspired by the eBay marketplace. In this chapter, the ESBay case study will be introduced and the yPBL inception phase will be applied in order to identify and analyze the system requirements. This analysis will make it possible to start rationalizing the technological solutions that need to be applied in further chapters to satisfy the ESBay system requirements.

1.1. ESBay: use case description

This section is intended to describe the requirements of the project that will be used as the case study driving the yPBL methodology: the ESBay system.

1.1.1. System overview

The ESBay system is intended to provide an online bidding system for new or used products. ESBay is neither a traditional business-to-consumer (B2C) nor a business-to-business (B2B) system. It is rather a consumer-to-consumer (C2C) system. As a consequence, this system could gain an important number of users depending on its future success. Users (actors) of the ESBay system are represented by sellers and buyers. The former post new or used products and the latter submit bids during an established bidding period. At the end of the bidding period, if at least one buyer has submitted a bid with a price equal to or greater than the minimum price specified by the seller, then the buyer is considered as the winner of the product and the payment process can be started. The buyer needs to pay for the product and then he needs to submit the information about the payment. The payment process finishes when the seller confirms the payment. Finally, the delivery process can start. During this final process, the seller needs to send the product and to inform the system about the delivery details as well as to submit the buyer evaluation. The buyer confirms the delivery when the product is received and also submits the seller evaluation.

1.1.2. Functional requirements

The following paragraphs introduce the expected functionalities based on the several processes involved in the ESBay business operations. A kind of user-story approach has been followed to describe each functionality: actor, functionality and rationalization/justification. The functionalities have been classified into three sequential processes: bidding, payment and delivery.

1.1.2.1. Bidding process

– Sellers post products (indicating description, initial price, minimal accepted price and bidding duration) in order to start the bidding process. The product is persisted in a database. The seller account is created and persisted if it is the first time that he/she uses the ESBay system.

– Buyers search for products that are in the bidding process (based on the description and the price). The buyer account is created and persisted if it is the first time that he/she uses the ESBay system.

– Buyers submit bids during the bidding process in order to win the products. Only bids higher than the current product bid will be accepted.

– Potential buyers can submit questions during the bidding process in order to get details about the product (e.g. condition, delivery, etc.)

– Sellers submit responses to the buyers’ questions.

– Buyers obtain a notification when they are the temporal winners of a product.

– Buyers obtain a notification when they are not the temporal winners of the product anymore.

– Buyers obtain a notification when they are the final winners of a product.

– Sellers obtain a notification when the bid is finished indicating who is the winner and the final price or indicating that the bidding has not been successful (no biddings or bidding lower than the minimal accepted price).

– Non-winning bidders need to receive a notification informing they have lost the product.

– At the end of each bidding process, the ESBay system automatically triggers the payment process when there is a winner for the product.

1.1.2.2. Payment process

– The winning bidder receives a notification with the instructions to pay for the product at the beginning of the payment process.

– The winning bidder submits the payment details that are persisted in the database.

– The seller confirms the reception of the payment when he/she has received it. This confirmation is persisted in the database.

– The ESBay system reminds the winning bidder every day if he/she has not submitted the payment details.

– The seller can cancel the payment process if after 15 days he/she has not received the payment.

– At the end of the payment process, the ESBay system automatically triggers the delivery process if the payment has been validated by the buyer.

1.1.2.3. Delivery process

– The seller receives a notification with the instruction to deliver the product at the beginning of the delivery process.

– The seller submits the delivery details and the evaluation of the winning bidder. The information is persisted in the database.

– The winning bidder submits the confirmation of the product reception and the evaluation of the seller and product. This information is also persisted in the database.

– The ESBay system reminds the winning bidder and/or the seller every day if he/she has not submitted the required information.

– The end of the delivery process is achieved when delivery and evaluation details have been submitted.

1.1.3. Other requirements

As previously discussed the ESBay system is intended to deliver consumer-to-consumer services. During an initial phase, the system is supposed to be deployed on a medium size market located in the south of France. An adequate IT infrastructure needs be provided to easily integrate the ESBay’s potentially distributed components. Depending on its success, ESBay will easily be able to incorporate worldwide customers. For this reason, ESBay’s system needs to be designed to be easily redeployed in any IT infrastructure. Moreover, ESBay needs to be designed to facilitate its enhancement by integrating existing B2C or B2B systems (e.g. existing marketplaces). Furthermore, ESBay needs to be ready to respond to the dynamic increase of worldwide demands, while still preserving an acceptable level of performance. Likewise, ESBay has to be designed to facilitate the identification and exploitation of new business opportunities. Furthermore, the system will provide manageability and maintainability support. In order to cope with the complexity of potentially distributed ESBay system instances, the solution has to incorporate self-oriented management in order to reduce human intervention. Furthermore, the system needs to guarantee fundamental security constraints.

1.2. yPBL inception phase

As already described in the previous sections, during the inception phase, the analysis of the ESBay case study needs to be carried out in order to identify functional and non-functional requirements and to obtain an initial overview of potential technologies to be used (technical requirements identification). Likewise, project management activities have to be initiated. In summary, during this phase, the functional, non-functional, technical and process requirements of the ESBay system need to be identified and validated. During the inception phase, a black box approach will be followed; this means that the internal details of the solution implementation will not be considered. Only the solutions that could potentially satisfy functional and non-functional requirements will be identified. These solutions will be explored later during the elaboration phase in the form of cookbooks and recipes. Let us start by analyzing the process requirements that will provide the basis to any project following the yPBL methodology.

1.2.1. Functional requirements

As specified in the yPBL methodology, a use case-driven methodology will be applied to the project specification in order to identify the functional requirements. Figure 1.1 presents the global use case diagram of the ESBay system, identifying the main bidding, payment and delivery processes.

Figure 1.1. ESBay use case diagram

– Bidding process

During the bidding process, the sellers post products to sell and respond to the buyers’ questions (see Figure 1.2). During the process, buyers can submit bids and also questions about the products. Buyers and sellers get notifications via e-mail about the bidding process progression.

Figure 1.2. ESBay bidding process use case diagram

– Payment process

During the payment process, the buyer submits the payment details and the seller confirms the payment (see Figure 1.3). Buyer and seller get notifications via e-mail (e.g. reminds or confirmations) when the payment process is achieved.

Figure 1.3. ESBay payment process use case diagram

– Delivery process

During the delivery process, the seller submits the delivery details and the buyer confirms the delivery (see Figure 1.4). Buyer and seller get notifications via e-mail (e.g. reminders or confirmations) and submit their respective evaluations during the delivery process.

Figure 1.4. ESBay delivery process use case diagram

From the previous use case-driven analysis, the following functional requirements have been identified:

1) Persistency: the system needs to be able to persist data about the sellers, buyers and products during the various business processes (e.g. database capabilities);

2) User notification: the system has to provide messaging capabilities to notify the users about specific business events (e.g. e-mail support);

3) Business process: the system has to provide business process execution capabilities for the different functionalities.

1.2.2. Non-functional requirements

Based on the specification of the ESBay system presented in the Introduction, several non-functional requirements can be identified:

“…During an initial phase, the system is supposed to be deployed on a medium size market located in the south of France. An adequate IT infrastructure needs be provided to easily integrate the ESBay potentially distributed components. Depending on its success, ESBay shall be able to easily incorporate worldwide customers. For this reason, the ESBay system needs to be designed to be easily redeployed in any IT infrastructure. Moreover, ESBay needs to be designed to facilitate its enhancement by the integration of existing Business to Consumers or Business to Business systems (e.g. existing marketplaces). Furthermore, ESBay needs to be ready to respond to the dynamic increase of worldwide demands, while still preserving an acceptable level of performance. Likewise, ESBay has to be designed to facilitate the identification and exploitation of new business opportunities. Furthermore, the system shall provide manageability and maintainability support”. In order to cope with the complexity of potentially distributed ESBay system instances, the solution has to incorporate selforiented management to reduce human intervention. Furthermore, the system needs to guarantee fundamental security constraints.

Following open-source non-functional requirements classifications such as [OPE 13], [IHR 13] and [WIK 13], we can identify the following requirements:

1) Portability: usability of the same software solution in heterogeneous environments. Capacity to be copied, transferred and deployed in multiple system.

2) Integrability: ability for this application to easily fit in as part of a larger system.

3) Interoperability: ability to easily collaborate with other systems/applications in order to exchange/process/understand information.

4) Extensibility: ability of an architecture, design and implementation of a system to actively consider and cater for future change.

5) Availability: capability of a system to stay in an operational condition.

6) Proactivity: capability of a system to acting in advance of a future situation.

7) Manageability: ability of a system in operation to be monitored and controlled.

8) Scalability: ability of a system, network or process to handle a growing amount of work in a capable manner or its ability to be enlarged to accommodate that growth.

9) Self-Manageability: ability of a system in operation to be selfmonitored and self-controlled.

10) Security: level of protection of a system.

1.2.3. Requirements matrix

Based on the previous analysis, the main functional (F) and non-functional (NF) requirements have been identified. The ESBay business-specific functional requirements have been generalized in persistency, notifications and business process support. These functional requirements will not be discussed further in this book, as our main interests are the non-functional requirements that can be identified for developing a smart SOA platform. Figure 1.5 presents the yPBL matrix including the ESBay non-functional requirements previously introduced.

Figure 1.5. Non-functional requirements matrix

In order to satisfy these requirements, several approaches and technological solutions will be discussed in the rest of the book. To better organize the knowledge acquisition and expertise to be developed, we have proposed four complementary solutions:

– SPaaS 1.0: covering the fundamental IT infrastructure non-functional requirements, mainly related to portability, extensibility, manageability, scalability and security of the platform. This solution also integrates specialized strategies in order to achieve self-management capabilities;

– SSOAPaaS 1.0: enhancing SPaaS platform, with the fundamental pillars of the SOA architectures, in order to satisfy integrability, interoperability and extensibility requirements;

– SSOAPaaS 2.0: enriching the SSOAPaaS 1.0 platform with asynchronous communication and event processing capabilities in order to satisfy availability and proactivity requirements;

– SSOAPaaS 3.0: specializing the SSOAPaaS 2.0 platform with advanced monitoring, analysis, planning and execution capabilities in ord...

Table of contents

• Cover
• Contents
• Dedication
• Title Page
• Copyright
• Preface
• Introduction
• 1: Esbay Case Study
• 2: Service-Oriented and Cloud Computing Architectures
• 3: SPAAS 1.0 Cookbook
• 4: SSOAPAAS 1.0 Cookbook
• 5: SSOAPAAS 2.0 Cookbook
• 6: SSOAPAAS 3.0 Cookbook
• Conclusion and Perspectives
• Bibliography
• Index