Distributed Nodes

The following section describes, how the package deployer can be used to start the packages for different tenants on different hosts. This allows to share the load which emerges in a domain with many nodes. In section 5.3.5.5 theexternal node launcher is already mentioned. This service can be hosted on any amount of systems. Theexternal node launcher provides the same operations to start and stop nodes as the package deployer does. Therefore, the same implementation is used to start and stop nodes in a new JVM. Figure 5.13 shows two different hosts which both run the nodes of a tenant specific package. Host two additionally runs a fixed node. All nodes belong to the same application.

Figure 5.13.: Distributed Execution of Nodes

5 Prototype

This allows to distribute instances of tenant specific packages. Instances that are shared by many tenants cannot be distributed this way. They always reside on one specific host. So all tenant specific packages will call the same instance.

In addition to the possibility to balance the load, tenants may choose to host their tenant specific package on their own infrastructure. For example this can be useful for security reasons.

6. Scenario

As a example, a scenario is described. It consists of a simple store. Certainly this store is provided as a SaaS application as described in this thesis. This allows to recapitulate all steps which are needed to create such an application. The section describes the devel- opment of the store as a SCA application along with the annotation of the components with multi-tenancy patterns. The implementation of the scenario is part of this diploma thesis. It can be deployed and started using the package deployer. For the development of the scenario, the extended editor is used. As a basis, the store sample of the tuscany distribution is extended.

The features of the shop are the following:

• The store provides a web interface.

• The store lists the products along with a price.

• The products are stored in a XML-based format.

• A currency converter allows to use different currencies.

• The store provides the possibility to calculate a discount for students.

• A mail is sent after a purchase was completed.

6.1. Components

As a first step, the necessary components are identified. Every component is listed along with its properties, services and references. Furthermore the implementation type and the utilized multi-tenancy pattern is named. A list of configuration options describe the customizable elements of a component. The bindings, which are used for the particular references and services, are only described where it is necessary. One can inspect the whole composite file of this scenario at G. To provide an overview, the figure below shows the application’s diagram. This diagram is created using the extended editor.

6 Scenario

Figure 6.1.: Diagram of the Simple-Store Scenario

6.1.1. Store

This is the most significant component which provides the web interface. To display the website, the Store component has to call two other components. The first one is the Catalog component to receive the products and prices. And the second one is the ShoppingCart component to provide the products a customer already added. Once a purchase is committed, the Store component calls the StoreOwnerMailer component. It informs the shop owner.

6 Scenario

Component Assembly

Properties title (the title of the store) Implementation widget (Javascript, HTML)

Services A HTTP binding provides the web interface. References Catalog (get products)

ShoppingCart/Cart (get shpping cart content) ShoppingCart/Total (get total price)

ShoppingCart/DiscountSetter (set type of the customer to student or non-stutdent)

StoreOwnerMailer/Mailer (send a mail to the store owner) Table 6.1.: Assembly of the Store Component within the Scenario

Multi-Tenancy Pattern The Store component needs to be configured with the multiple instances pattern. This is because every tenant needs a separate website. By setting the binding’s URI to /store, the shop becomes available at an address which is build up by the URI of the node that hosts the store (Example: http://localhost:8000/store). Fur- thermore the multiple instances pattern allows the SCA propertytitle to be configured on a per tenant basis.

Configuration Options

• The value of the SCA propertytitle is configurable. Therefore, a variability point has to be set to the respective description in the composite file of the simple store.

6.1.2. Catalog

This component is used to retrieve the products from a products file. It also calculates the prices, using the CurrencyConverter.

6 Scenario

Component Assembly

Properties currencyCode (for example EUR or USD) Implementation Java

Services Catalog (provides products)

References CurrencyConverter (used to calculate prices)

Table 6.2.: Assembly of the Catalog Component within the Scenario

Multi-Tenancy Pattern The Catalog component uses the single configurable instance pattern. This is necessary, because every shop owner has to configure its own products. The products file has to be marked as a configurable element in the implementation mapping file.

Configuration Options

• The value of the SCA propertycurrencyCode is configurable.

• The products file can be configured to the needs of the store owner.

6.1.3. CurrencyConverter

The CurrencyConverter component converts a price to a particular currency. All prices must be basically supplied in USD. A currency code then defines the currency to which a price has to be translated.

Component Assembly Implementation Java

Services CurrencyConverter (translate a price)

Table 6.3.: Assembly of the CurrencyConverter Component within the Scenario

Multi-Tenancy Pattern The CurrencyConverter uses the single instance pattern. This is due to the fact, that it is not dependent on any tenant context. So all tenants can use the same instance.

6 Scenario

Configuration Options

• The pattern of the CurrencyConverter component is configurable. Some tenants might not want to share the same instance with other tenants. Therefore, they can choose to use the multiple instances pattern.

6.1.4. ShoppingCart

This component manages the shopping cart during the stay of a customer. Therefore, it provides several services to get information about the purchase. Furthermore the Shop- pingCart component saves the information whether a customer stated to be a student or not.

Component Assembly Implementation Java

Services Cart (provide shopping cart)

Total (calculate the total price of a purchase)

DiscountSetter (set the type of a customer to student or non- student)

References DiscountCalculator

Table 6.4.: Assembly of the ShoppingCart Component within the Scenario

Multi-Tenancy Pattern The ShoppingCart component uses the multiple instances pat- tern. This is due to the fact, that for this shopping cart implementation, every shop needs its own shopping cart. Otherwise products from different shops would get mixed up.

Configuration Options Nothing is configurable.

6.1.5. DiscountCalculator

The DiscountCalculator enables to determine a certain reduction on the price, referring to the specific customer status. If the customer is a student, the price is modified by a value that is stored in a BPEL variable.

6 Scenario

Component Assembly Implementation BPEL

Services Discount (calculate modified price)

Table 6.5.: Assembly of the DiscountCalculator Component within the Scenario

Multi-Tenancy Pattern The DiscountCalculator component is configured with the multiple instances pattern. This is necessary, because the implementation needs to be changed in order to configure the discount modifier. Therefore, a separate instance for every tenant has to be created.

Configuration

• The value of the BPEL variable which stores the discount modifier is configurable. Therefore, a variability point has to be set to the according element of the BPEL file.

6.1.6. StoreOwnerMailer

This component is used to send a mail to the store owner once a purchase was received. The respective mail address is stored in a component property.

Component Assembly

Properties address (the mail address of the store owner) Implementation Java

Services Mailer (send purchase information to the store owner)

Table 6.6.: Assembly of the StoreOwnerMailer Component within the Scenario

Multi-Tenancy Pattern The StoreOwnerMailer is configured with the single config- urable instances pattern. This pattern is used, because the mail address of the store owner needs to be configurable on a per tenant basis. Furthermore it is not necessary to modify the components implementation. So a multiple instances component is not required.

6 Scenario

Configuration

• The value of the SCA variable which holds the address of the store owner is con- figurable.

• The whole component can be removed from the composite file, if a tenant does not want to receive mails.