Tipología de los territorios rurales andaluces

In this section, we report on our efforts for the creation and evaluation of a working implementation of the proposed system.

o System setup

As already discussed and shown in Fig.2.12, every elementary service is composed at least by two main components that are the Interface and the Business Logic layers, and can also include the Device Communication layer. These have been implemented using the open source framework Axis2 and Tomcat from the Apache Software Foundation, and the software Spring. The business logic layer is constituted by all the code for the realization of the logic behind the methods implementation.

Each method published by the web interface is translated into a list of specific procedures that are implemented using the Java language. The services communicate with the physical devices thanks to the Device Communication Layer: this one offers a complete set of primitives that map the most important functionalities of the device. All WS are deployed and run over an application server, which allows for reaching each WS by means of the HTTP protocol. The logic behind the creation and the management of complex services belonging to the Complex services layer can be expressed in terms of workflows of business processes. A workflow can be represented using a standard language. According to our philosophy to follow the SOA requirements, we have chosen the BPEL (Business Process Execution Language) language.

It defines business processes using an XML based language but does not define a graphical representation of processes or provide any particular design methodology for processes.

Finally, each business process has inputs, method and outputs and so, also the workflow exports a web-service interface, which belongs to the transport interfaces layer. We have implemented all the elementary services listed in Fig.2.11 and conducted experiments specifically with reference to the following elementary services and the corresponding WS: TrafficMapper, LSPPathCreation, NetworkPrevisioning, CommandSending, KPIValidation and the Proxy.

o Experiments

To evaluate the limits and potentialities of the proposed approach, we have set up a simple test architecture connecting aworkstation running a Remote Procedure Call (RPC) client and a server running all the WSs. Besides, thanks to a Virtual Private Network connection, this architecture can reach a DS-TE network hosted in the ISP Tiscali test lab, as shown in Fig.2.13. Herein, we refer to the experiments that have been performed with use-case 1 of Table 1, which implements the activation of a traffic delivery service in a single domain with guaranteed QoS, and whose workflow is shown in Fig.2.14. Similar results have been obtained with the other use-cases. Specifically, in these experiments we wanted to analyze the impact of implementing a complex service with distributed elementary services instead of a monolithic system implementation. With this simple architecture, two test scenarios have been conducted.

Figure 2.14. Workflow implementation of use-case 1 in Table II (UML sequence diagram)

Figure 2.13. An example of Web Services functioning and correspondent SOA technologies used

The first scenario is aimed at analyzing only the performance of the elementary services composition process, without involving real devices so that this test does not include the use of any WP. It means that in the workflow shown in Fig.2.14 we have skipped the call of the Proxy WS. Following the SOA style, our system must be composed only by stateless services. Anyway, a network is not completely stateless: the creation of LSPs or parameters setting determines some different states, which need to be stored.

Accordingly, the creation of a new service into a working network cannot neglect the current network state. In our implementation, we introduced the LSPRepository service, which is interrogated and refreshed during the LSP creation; in addition, we also introduced a Network-topology and a Network-link-usage repository in our architecture. We don’t create any other service that collects data from physical devices, e.g. using SNMP traps [60]. The connection rate is controlled using a traffic shaper running in another server to simulate network traffic load; all the management traffic is tagged and differentiated from the data traffic, so that it is not affected by congestion and excessive packet delays. The aim of this test architecture is to study the execution time requested by the workflow shown in Fig.2.14, at different WS aggregation levels. The aggregation level specifies how many elementary services, and so their correspondent WS, are combined together inside the same WS.

Reducing the aggregation level, we may distribute the single elementary service in different servers, giving the administrator the flexibility to better distribute the load among several servers according to the traffic generated by each elementary service.

With regard to Figs 2.14 and 2.15, with an aggregation level 1, the client calls each different elementary WSs by sending a different SOAP message request to the server. With the aggregation level 2, the client calls two generic WSs running into the server: each one of these, in turn, call two elementary

Figure 2.15. Execution time of the workflow of Fig 2.14 with different WS aggregation levels

WSs. With the aggregation level 3, the client calls a generic WS, that in turn calls three elementary WSs, and the remaining elementary service. Finally, with the aggregation level 4, the client calls only one generic WS, which makes four calls to elementary services, all running into the same server.

The simulations show a decreasing execution time as the number of WS aggregating level increases, as expected. Indeed, the total execution time is composed by the sum of transmission time and processing time: with low values of bandwidth, also considering that there is only one hop between the client and the server, the transmission time has more importance that the latter. This choice permits not to consider the processing time, which is related to the internal server load and to its internal features. Results show the tradeoff between the WS separation and the WS aggregation. Separation makes possible to have a more flexible architecture, deployable in a distributed system as a geographical network but with the disadvantage of bigger transmission times. Aggregation provides a less flexible but faster system, where the network transmission time has a reduced influence and the system management is concentrated in a single node with a single point-of-failure.

The second test introduces the use of the WS proxy and its final result is the setting of MPLS commands over physical devices. The reference workflow is again the one in Fig.2.14 and this time we also call the Proxy WS to send the commands to the transport infrastructure. In Fig.2.16 the cumulative response time of the workflow execution is shown. The plots have similar shapes, rescaled due to various bitrates allowed over the network by the traffic shaper. It can be clearly noted the high delay introduced by the execution of the Command-Sending WS, which creates the connections to physical devices invoking the WP. Accordingly, the CommandSending service, that in turn calls the WP, essentially needs more time with respect to other WS for two reasons: the former is related to the delay introduced by the Internet, the latter is due to the access and configuration time of physical devices. In the worst case, the total execution time requires roughly 3 seconds.

Figure 2.16. Cumulative response time of workflow shown in Fig 2.14.