SaaS Integration for Software Cloud
Feng Liu, Weiping Guo, Zhi Qiang Zhao, Wu Chou
Avaya Labs Research, Avaya Inc.
{fliu1,wguo,zqzhao, wuchou, }@avaya.com
Abstract
Software as a Service (SaaS) has been adopted in a fast pace for applications and services on software clouds. However, the success of SaaS in software cloud cannot obscure the integration challenges faced by developers and enterprise infrastructure IT. Among those challenges, firewall/NAT traversal and security issues often pose a serious bottleneck as enterprises may not be entirely comfortable running mission critical applications outside the corporate firewall. On the other hand, SaaS applications in the cloud need to access enterprise on-premise applications for data exchange and on-on-premises services. The current approaches through opening special pin-holes on firewall or using dedicated VPNs have encountered a number of limitations and drawbacks. This paper presents a Proxy-based firewall/NAT traversal solution for SaaS integration (PASS). It allows SaaS applications to integrate with on-premise applications without firewall reconfiguration, while maintaining the security of on-premise applications. In addition, this approach is platform and application independent, making the SaaS integration seamless. Moreover, PASS is consistent with the enterprise web browsing infrastructure, and it requires little or no change to enterprise firewall/NAT configurations. In this paper we present the architecture of PASS and address SaaS integration challenges in software cloud, such as security/firewall, performance, and scalability. Experimental study based on our implemented system shows that the proposed approach of PASS is promising to resolve firewall/NAT traversal for SaaS integration with on-premise services.
1. Introduction
Software as a Service (SaaS) is defined in [1] as a software application delivery model, where a software vendor deploys and hosts software applications in a multi-tenant (cloud) platform for its customers to operate the application over the Internet as services. In recent years, SaaS has emerged as a new paradigm for software delivery in software cloud, attracting more and more interest from both industry and academia.
Comparing with conventional software, SaaS has some unique features. Instead of being installed on premise, SaaS applications are usually hosted at the service provider’s network, delivered as web applications, and serve as services for multiple tenants. This on-demand and multi-tenant service delivery model is well suited for software cloud, as it does not require the deployment of a large infrastructure at the client's location. On the other hand, SaaS applications can be deployed in a cloud computing environment and accessed through Internet by web browsers. Therefore it eliminates or drastically reduces the upfront commitment of resources. As a consequence, SaaS applications can be deployed with minimal effort and be available in a very short time to a large group of users, and therefore, it makes SaaS model quite attractive to enterprises.
In addition, SaaS employs a single-instance, multi-tenant architecture, allowing multiple customers to share resources without disrupting each other. This centralized hosted service approach makes deploying patches and application upgrades transparent to users. Another important feature of SaaS is the embrace of web services and service oriented architecture (SOA), a fully accepted architectural approach in the industry. Many SaaS platforms expose the applications data and functionalities through the web service interface. This not only allows clients to query/update SaaS applications data programmatically, but also provides a standard mechanism to integrate SaaS applications in the software cloud with enterprise SOA infrastructure.
With the rapid adoption of SaaS, there is a growing demand for enterprises to integrate their SaaS applications with their in-house backend applications (database, ERP, etc.), and this is due to the following facts. First, different customers have different business requirements for its application, but SaaS applications can only provide limited flexibility for customer configuration. Therefore much of the functionality has to be realized outside the SaaS applications. An example is embedding click-to-call feature into the customer relationship management (CRM) applications. While a general CRM application may fit very well with SaaS and be hosted in a software cloud, the call control can only be realized by a separate application (e.g. a PBX) because of its complexity. In this case, a hybrid approach that allows CRM applications to access
call control services implemented outside SaaS would easily solve this problem. However, for security or legal reasons, some sensitive data or business rules must be kept and stored internally, and accessed by the SaaS application only when needed. In addition, business processes are very complicated, and usually require working across multiple applications and services. In above cases, a single SaaS application or services in a software cloud can not meet all the business requirements by its own. To meet the business needs while taking advantage of SaaS and SaaS based services in the software cloud, a business application solution should integrate both on-premise and the SaaS applications.
The adoption of web services and SOA by both SaaS vendors and enterprises has significantly simplified the integration process. However, integrating SaaS applications with on-premise applications can still face serious challenges when it comes to cross enterprise networks and domains. This is because enterprise networks are typically protected by network address translation (NAT) devices and strictly configured firewalls. Usually NAT/firewalls are configured to block all the incoming packets initiated from the public (external) network and open only a limited number of ports for outgoing ones. As a result, all requests sent to on-premise applications from SaaS applications in a publically reachable software cloud will be blocked by the enterprise NAT/firewall.
In this paper, we review the current solutions in Section 2. We study their limitations, and point out some of them may not be feasible for SaaS. We propose a Proxy-based firewall/NAT traversal solution for SaaS integration (PASS) that enables the on-premise services to be consumed by SaaS applications in a software cloud environment without exposing it to the public Internet. Moreover, the proposed PASS solution requires no or minimal firewall reconfigurations and well suited to support the dynamic nature of services-on-demand in SaaS.
The rest of this paper is organized as follows. Section 2 reviews and discusses some related work in this area. SaaS integration challenge in software cloud is further analyzed in Section 3. The architecture of PASS is introduced in Section 4. Section 5 addresses some issues of PASS for firewall/NAT traversal. Experimental results are presented in Section 6, and we conclude the findings of this paper in Section 7.
2. Related work
The firewall/NAT traversal issue in general has been studied for a long time, and the Internet Engineering Task Force (IETF) is one of the organizations heavily involved in this. Many standards and proposals have been proposed
[2][3][4][5]. However, most of works are targeted for voice over IP (VoIP) scenarios, and not on web services and SaaS, which are very different from the case of VoIP.
The most widely adopted approach to solve firewall/NAT traversal problem is to expose the on-premise applications to public networks and software clouds. This is usually achieved by changing the network firewall configuration to allow the incoming traffic from SaaS applications to pass through, or by deploying a reverse proxy in the DMZ to route the traffic to the internal applications. Since enterprise security architecture can be very sophisticated, such an approach usually involves significant amount of work, and it can become exorbitant as the number of services and applications grows. In addition, the current IT infrastructure does not support the dynamic nature of SaaS applications that are critically needed for software cloud. This is because new services will be added or deleted at an on-demand basis. On the other hand, some enterprises may not have the infrastructure and dedicated IT skills to manage the large amount of integration demands from SaaS applications and developers. Requiring these enterprises to implement and support such integration will eventually drive them away from adopting SaaS solutions.
From customers’ perspective, SaaS applications are usually extensions of their existing internal on-premises business applications, and the way to integrate with SaaS applications should be the same as that to integrate with any other premise applications. Exposing such on-premise applications to external networks will not only be unnecessary, but also introduce security risks..
Virtual private network (VPN) is another solution to address the issue in cloud computing. A CloudNet is proposed in [14] to integrate on-premise applications with cloud applications. The projects VIOLIN [15] and Virtuoso [16] also address the similar issue. Those solutions focus on the Infrastructure as a Service (IaaS) case, e.g. EC2. However, unlike IaaS, where the user has full control of the virtual machine, SaaS users don’t have the access to the machine. Furthermore, they usually share the same running SaaS application instance with other tenants. It would be extremely difficult if not impossible for SaaS vendors to deploy and maintain multiple different VPN endpoints in this scenario.
A two-way web services router gateway (TARGET) is proposed for two-way web service interaction crossing enterprise domain and firewall [7]. With TARGET, web service clients and web service servers can interact with each other bi-directionally, even if they are in disparate networks, with different network infrastructure and different NAT/firewall configurations. However, it has some limitations, as it requires applications to be aware of the existence of TARGET, and to support WS-Addressing standard. In addition, TARGET requires the manipulation of the WSDL files of the services, which makes it difficult
to deploy. It may not scale to large SaaS or software cloud deployment as it requires each application to install a client in order to access or to be accessed by other applications.
Microsoft’s AppFabric Service Bus is another solution to provide secure connection between the enterprise and the cloud [17]. It is very similar to TARGET as both utilize an intermediary for relay. However, it is a platform dependent solution.
3. SaaS integration and firewall/NAT
traversal
Web services have become a widely adopted interface for service integration in SaaS. SaaS applications usually expose their data, metadata, services, and other functions through web services, so that they can be discovered, queried, and updated by on-premise applications. In addition, web services are often provided as a mechanism to invoke the services which are outside the SaaS applications [13] or reside in different service cloud.
This integration of SaaS and software cloud can be broken down into the following three categories.
1) The SaaS application is a component of the whole business process. In this case, the core business application, which runs within the enterprise network, queries and updates data stored in the SaaS application.
2) The SaaS application is the business process engine. In this case, most of business logic is executed in the SaaS application, and it queries on-premise applications for data or services. The click-to-call application is one such example.
3) The combination of the above two scenarios. In this case, SaaS applications obtain enterprise data, business rules or other services from on-premise applications and systems, where on-premise applications query SaaS applications for data.
Fig. 1 illustrates how the enterprise firewall/NAT affects the integration of SaaS and software cloud with on-premise applications. SaaS applications are hosted on SaaS platform that can be accessed from Internet. On-premise applications run within the corporate network and are behind the corporate firewall/NAT. The firewall/NAT prevents SaaS applications from accessing on-premise applications in two aspects. First, the location (or the URL) of the on-premise application is only valid inside the enterprise network, and it is not routable in public networks. Secondly, the firewall is usually configured to allow only the outbound traffic while block all the incoming traffic. Consequently, requests sent by SaaS applications from the external cloud to the on-premise application, will be stopped at firewall.
For the first category of integration, as the web services are initiated from on-premise applications to SaaS
applications hosted outside of the firewall/NAT, it is usually allowed by the firewall policy, and the integration can be done directly. For the rest two categories, firewall/NAT will block all the web service requests sent from SaaS applications, and the integration cannot be achieved unless some special means are taken.
Figure 1. Requests from SaaS application are blocked One alternative to the second category is to change the integration pattern to avoid direct accessing on-premise applications from SaaS applications. Instead, we can let the on-premise application to push the data to SaaS applications at a regular interval or whenever the data changes. As all the web services are initiated from inside and on-premise in this case, this will be allowed by the firewall/NAT. The obvious problem of this approach is that it is not scalable as pushing data can be computationally and network intensive when data changes frequently especially if mass data is transferred. In addition, it is not suitable for SaaS applications that require accessing on-premise services on an ad-hoc basis, as described in above mentioned click-to-call example. It also cannot handle the case where SaaS applications need to synchronize data with on-premise applications in real time. As large amount of internal enterprise data may end up being pushed outside of enterprise boundaries, security and online data storage can become serious roadblocks.
Based on the analysis above, a firewall/NAT traversal solution for SaaS integration has to: 1) resolve the internal URL and map it into a routable address; 2) support the inbound web service requests from particular SaaS applications; 3) be transparent to SaaS applications; and 4) require no or minimum change to firewall/NAT configuration without compromising enterprise network security.
4. PASS
In this section, we present a Proxy-bAsed firewall/NAT traversal Solution for SaaS (PASS) integration based on the analysis in Section 3.
4.1. Proxy-based approach
A PASS system consists of two types of components: PASS Server (PS) and PASS Agent (PA). In a typical deployment scenario as shown in Fig. 2, a PS is usually deployed in a public network, such as in the DMZ zone of
the SaaS provider. Each customer deploys a PA inside its own enterprise network, near on-premise applications.
Figure 2. PASS deployment
Some key concepts and modules of PASS are described as follows.
• A secure broker architecture for firewall traversal. PASS employs PS to relay the communication between the SaaS platform and the on-premise applications. The communication between PA and PS is through a secured tunnel initiated from inside the enterprise network to the outside, so that most of firewalls do not block this outgoing traffic. Once this special secure tunnel is established, SaaS applications can send requests to enterprise applications through the tunnel.
• A special router for NAT traversal. Instead of routing the message sent from SaaS application directly to the destination (which is not routable), the special router re-directs the message into the corresponding tunnel. Once the request is forwarded to the inside the enterprise network, it becomes routable.
• Proxy-based approach making it transparent to SaaS applications. The PASS is exposed as an HTTP(S) proxy to SaaS applications. To send requests to the destination through PASS, SaaS application only needs to configure its HTTP (S) client to use PASS as its outbound proxy. No change is needed for on-premise applications as long as it provides a web or web service interface.
4.2. PASS Agent
PASS Agent is the client side component of the PASS system. From the perspective of on-premise applications, PA acts like a reverse proxy which routes requests to on-premise applications. However, unlike a regular reverse proxy, PA is installed inside the enterprise network, and only receives requests from PS. A communication channel must be established between PA and PS prior to any data exchange. Figure 3 shows the logic architecture of a PA.
• Tunnel module. This module is responsible for establishing the tunnel with PS and keeping the tunnel alive. The tunnel negotiation is accomplished via SSL over TCP. Once the tunnel is setup, the tunnel module can
receive data from the tunnel and process accordingly before sending it to the service dispatcher.
Figure 3. PASS Agent Architecture
• Service dispatcher: The service dispatcher is a special reverse proxy which receives messages only from the tunnel module. The difference is that it doesn’t need to do any reverse address mapping. Once upon receipt of a message, it examines the original service destination (URL) from the header, and queries the registered service database by the service URL. If a matched service is found, it forwards the request to the on-premise application in the same local network. Note that the service dispatcher only serves registered services that the enterprise intends to expose to SaaS applications. Requests to other applications, which are not registered, will be denied. In fact, a request to unregistered service will never reach the PA as it will be dropped by the PS at the DMZ. Even if the PS forwards unregistered service requests to the PA, the request will be rejected by service dispatcher. This protects on-premise applications from unsolicited requests.
• Registration module. In order for a SaaS application to access an on-premise service, the enterprise administrator registers the accessible on-premise services to the PASS. The registration module provides a web interface for administrators to perform this task on-demand. The registered service will be added to PA’s database as direct service. Meanwhile, this module also synchronizes the service registration with the PASS server. For security purpose, during the synchronization, the PA must present its certificate to PS over HTTPS for authentication.
4.3. PASS server
The PASS server is the intermediary to bridge the communication from SaaS applications to enterprise on-premise applications. Its architecture is illustrated by Figure 4.
• Tunnel server. The tunnel server authenticates and manages tunneling with multiple PASS agents. It usually listens on firewall-friendly port (for example, port 443) established during tunnel creation. For every established tunnel, PS assigns an ID for its identification. Once the tunnel is established, it can be used by the PS to forward service requests to PA.
$GPLQLVWUDWLRQ6HUYHU 3UR[\ 5HJLVWHUHG 6HUYLFH 5RXWLQJ(QJLQH 3$666HUYHU 6DD6 $SS :HE LQWHUIDFH 3$ ,QWHUIDFH 7XQQHO6HUYHU 3$L 3$Q 3$
Figure 4. PASS Server Architecture
• Proxy module. This module handles HTTP(S) protocols and provides a standard web proxy interface for SaaS applications in the software cloud, such as using default proxy port 8000. It receives the outbound requests from SaaS applications and hands them over to the routing engine. The access to the proxy module is strictly controlled such that only the traffic from SaaS applications is allowed.
•
Routing engine. This is a core component in a PASS server (PS). PS maintains a dynamic routing table with service URL and channel ID pair as its entry. Upon receipt of service request, the engine will look up its routing table by the service URL, and find the next hop address which is a tunnel ID in this case. The routing engine then forwards the request to a TA through the corresponding tunnel. For no-matched service request, the routing engine will reject it immediately. Therefore, requests to unregistered services will be stopped at the PASS server.• Registration server. The registration server provides two interfaces. One is a secured web interface through which administrators can manage PASS agents and services. The other interface is for PA’s registration module to synchronize services. This interface is different from a general web interface in that it requires client’s certificate by which PASS agents are authenticated. The registered service and agents will be stored in a database. In the actual implementation, a run-time copy is pushed to the routing engine for performance enhancement.
4.4. Work flow
Deployment of PASS is easy, as it is consistent with the current web access infrastructure. On the software cloud side, the SaaS application should be configured to use PS as the outbound proxy in order to send requests to on-premise applications. There are some common practices on how to configure this, such as setting JVM parameters or via configuration files. However, the preferred configuration setting should be per-request based. This is due to the following considerations. (1) SaaS server usually is one running instance serving multiple tenants where each tenant can come from different organization or enterprise. A global setting could advertently affect other tenants or applications and therefore, it must be constrained. (2) even for the same tenant, different applications may have different requirements on how to send outbound messages. Therefore, the proxy setting should be restricted to be local and specific to a particular tenant’s application in SaaS and software cloud environment.
On the customer side, an on-premise service needs to be registered on PASS to make it available to SaaS applications. The general process would consist of the following steps:
(1) PA initiates and establishes a tunnel channel with PS.
(2) Following the successful channel setup, the administrator of PA register a service to PS. (3) Once the service is registered both on PA and PS,
the SaaS application can invoke this service through the PASS in the following manner:
a. SaaS application sends the request to PS which acts as a web proxy, e.g. using via proxy setting in the HTTP (S) client.
b. The PS routes the SaaS application’s request by looking up its service registration database against the requested service URL. If a match is found and the tunnel to the corresponding PA is active, PS forwards the request to PA over the existing tunnel.
c. Upon receiving the data from the tunnel, the tunnel module in PA verifies the integrity of data, and sends it to the service dispatcher. d. The service dispatcher of PA checks whether
the requested service is registered locally or not. If registered, it forwards the request to the service host; otherwise, the request will be dropped.
e. After receiving the service response from the on-premises application server, PA sends it back through the same path to the SaaS application.
5. Analysis and Discussion
In this section, we discuss how PASS addresses the firewall/NAT traversal issues and security concerns in addition to other challenges for SaaS and software cloud integration.
5.1. Security
Security is one of the main concerns that an enterprise may not be willing to expose its services to the outside cloud. PASS is designed to address this requirement and lower the cost and overhead of a seamless integration. In particular, service access security is addressed and enhanced in PASS at multiple levels based on a secure broker architecture that is consistent with the infrastructure of web.
• Transport level security in PASS. Strict security mechanisms are used during its connection establishment. First, the hand-shake is accomplished via TLS over TCP to secure communication between PA and PS. Secondly, mutual authentication is enforced, in which not only the PS authenticate the PA that intends to establish connection, but the PA is required to check and verify the PS identification. A secure tunnel between a PA to a PS can be established only if both authentications succeed. Thirdly, a certificate-based authentication is implemented in PASS. The PA’s identification is embedded in its certificate. During the negotiation, PA must present its certificate to PS, so that PS can extract the ID from the certificate and authenticate the PA. The same rule also applies when PA authenticates PS. The data within the tunnel is encrypted and signed to guarantee the integrity and the hop-to-hop security of the data.
• Message level security. PASS supports both HTTP and HTTPS based message. When HTTPS is used, the PASS will guarantee its end-to-end security characteristic between the service requester (SaaS application) and the service provider (on-premises application server). The application data is never touched or decrypted by the PASS components, as the HTTPS session is established end-to-end directly between the SaaS application and the on-premise application.
• Service level security. Since the on-premise services are not directly exposed to the internet, firewall/NAT will block any attempt to access them from outside. The only path to access the service is through PS. PS allows only authenticated and authorized PASS agent to establish a tunnel with it, thus further enhances the security.
• PS is deployed as a standard server in SaaS provider’s network, and thus all the security measures can be taken to guard against general attacks. In addition,
access to the proxy interface of PS is also controlled that only SaaS applications can use it as their outbound proxy.
• PA is unlikely to be attacked as it is located inside the enterprise network and behind the enterprise firewall/NAT. As a result, in-house applications accessible through PASS are protected.
5.2. Performance
Performance and system throughput are key factors for a solution such as PASS, as scalability and latency issues are often the bottlenecks in SaaS integration. To improve the throughput, we implemented a thread pool at both tunnel and proxy level. Upon system startup, a certain number of worker threads are created and ready for serving. After a connection session is terminated, the used thread will be returned to the pool for later usage. In addition, a connection pool is implemented between a PASS agent and on-premises application servers. Multiple communication channels can be established based on the actual configuration.
5.3. Scalability
The scalability issue in PASS is addressed from two aspects. First a single PS can be used by different SaaS applications to send out requests to different on-premise applications. Only one PASS agent is needed to serve multiple applications in the same enterprise network domain. Second aspect is the tunnel multiplexing. One tunnel can enclose multiple data flows, which allows multiple applications to share a single tunnel.
5.4. Web and web service support
As web service is the most adopted interface for SaaS integration and HTTP(S) are commonly used for web service invocation, the support for HTTP(S) becomes a must. PASS is capable of fully supporting both protocols of HTTP and HTTPS. Moreover, its proxy-based and decoupled architecture allows extension for new protocol.
5.5. Dynamic service management
One issue of opening pinholes on firewall for SaaS integration is that the firewall rules have to be re-written and re-implemented for new services. PASS resolves this problem by dynamic service management. A service can be added and removed on-demand, and no change is required for SaaS application and on-premise systems, nor the firewall/NAT. Any change will be applied to PASS and take into effect immediately without restarting servers.
6. Experimental
results
A PASS system has been implemented using C/C++/java based on the architecture described in section 4. Experiments were conducted to evaluate the performance of the PASS system with regard to processing time and throughput. It is compared with the case where a reverse proxy is deployed for integration, as it is a populous approach used in SaaS integration despite the deficiencies.
6.1. Experimental tests in lab environment
6.1.1. Testing environment and experiments setup The lab setup is shown in Fig. 5. The test client, PS, PA, the reverse proxy, and the test server were all set on the same subnet of the Gigabit Ethernet LAN. All were equipped with Gigabit Ethernet cards and running Linux CentOS 5. In this environment, the network latency can be ignored, so that we can focus on the system performance and overhead.
In the test of both cases, the test client acted as the SaaS application, and the test server simulated an on-premise application. Apache JMeter 2.3.1 [10] was used as the test tool and Apache HTTD 2.2.8 [11] was installed and configured as the reverse proxy.
Figure 5. Test configuration
In the PASS test case, JMeter was configured to use PS as its web proxy to send requests to the test server via HTTPS. In the reverse proxy case, JMeter was set to send requests to the reverse proxy via HTTPS, and then the request is forwarded to the test server over HTTP.
The hardware specifications are listed as follows. • PA and PS: Intel P4 CPU (3.0GHz), 2GB RAM. • Test Server: Intel Xeon CPU (3.4GHz), 2GB
RAM.
• Test client: Intel P4 CPU (2.0GHz), 2GB RAM. • Reverse Proxy Server: Intel P4 CPU (3.0GHz),
2GB RAM.
6.1.2. Performance comparison
Fig. 6 depicts the performance of PASS with regard to the average round-trip time (RTT) vs. the number of simultaneous requests.
Figure 6. RTT comparison
In this experiment, the test client sent requests to the test server, and we calculated the average round trip time over all requests. The test was repeated multiple times by spawning different number of threads on the same test client.
Compared to the reverse proxy setting, one more component (e.g. PA) is deployed in the PASS case. Therefore, the overall RTT in PASS was longer than the reverse proxy case. Under light system load (for example, below 75 threads), the difference between PASS and reverse proxy was below 30 ms (~30%). When the system was heavily loaded, the gap increased slightly.
Figure 7. Throughput comparison 6.1.3. Throughput comparison
The throughput comparison is shown in Figure 7. The throughput is relatively flat with the increase of the number of threads. Note that the absolute value may not
be very useful in this case as the page size is approximately 8KByte. We are more interested in the difference between PASS and the reverse proxy under the same testing setting.
6.2. System performance using real data
In this experiment, we evaluate the PASS performance using real world data. A PASS system was deployed at the data center. A web service server was deployed within the data center which could be accessed directly via PASS.
Two PAs were deployed in two different networks (Verizon FiOS and Optimum Online respectively). The two test clients sent requests to the test server through the different PAs, and the average RTT was calculated.
For comparison, a separate test was conducted in which the test client sent requests directly to the test server without going through PASS.
As shown in Table 1, PASS has an average overhead of 60~80ms, depending on the type of the network.
Verizon FiOS Optimum Online Direct Access 414 489
PASS 494 539
Overhead 80 60
Table 1. RTT direct access vs. PASS
7.
Conclusion
This paper presents a proxy-based firewall/NAT traversal solution for SaaS integration for software cloud. Comparing with the existing approaches, this solution requires no or minimum configuration change on firewall or NAT. It employs a specialized secure tunnel to address firewall issue, and uses s special routing table that maps the service destination with the corresponding tunnel, thus it avoids the NAT issue. In addition to the seamless integration and usability, PASS provides an improved solution and framework to many critical SaaS integration challenges, such as security issues, scalability, multi-tenancy, management, and performance. We implemented and tested a working system based on PASS architecture. The experimental study shows that PASS solution is feasible and advantageous for SaaS integration in Software cloud.
8.
Reference
[1] Software & Information Industry Association, “Backgrounder: Software as a Service", February 2001
[2] Session Traversal Utilities for (NAT) (STUN),
http://tools.ietf.org/html/draft-ietf-behave-rfc3489bis-15
[3] Traversal Using Relays around NAT (TURN),
http://tools.ietf.org/html/draft-ietf-behave-turn-07
[4] Interactive Connectivity Establishment (ICE),
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-19.txt
[5] Requirements from SIP (Session Initiation Protocol) Session Border, http://www.ietf.org/internet-drafts/draft-ietf-sipping-sbc-funcs-05.txt
[6] BizTalk Connectivity Services
http://biztalk.net/Connectivity.aspx
[7] Feng Liu, Gesen Wang, Wu Chou, Li Li, “TARGET: Two-way Web Service Router Gateway”, Proc. IEEE International Conference on Web Services, July 2006.
[8] Gianpaolo Carraro, Fred Chong, “Software as a Service (SaaS): An Enterprise Perspective”, Microsoft, October 2006
[9] Joseph Ottinger, “Software as a Service Integration via Mule”, http://mule.mulesource.org/
[10] Apache JMeter,http://jakarta.apache.org/jmeter/
[11] Apache HTTD,http://httpd.apache.org/
[12] Apache Tomcat,http://tomcat.apache.org/
[13]https://wiki.apexdevnet.com/index.php/Web_Services _API
[14] T. Wood, P. Shenoy, A. Gerber, K. Ramarkrishnan, J. Merwe, “The case for enterprise-ready virtual private clouds”. Workshop on Hot Topics in Cloud
Computing (HotCloud'09), June 2009 [15] P. Ruth, J. Rhee, D. Xu, R. Kennell, and S.
Goasguen. Autonomic live adaptation of virtual computational environments in a multi-domain infrastructure. In ICAC ’06: Proceedings of the 2006 IEEE International Conference on Autonomic Computing, Washington, DC, USA, 2006. [16] A. Sundararaj and P. Dinda. Towards virtual
networks for virtual machine grid computing. In VM’04: Proceedings of the 3rd conference on Virtual Machine Research And Technology Symposium, 2004.
