Data integration using service composition in data service middleware

Transcription

1 SECURITY AND COMMUNICATION NETWORKS Security Comm. Networks 2014; 7: Published online 10 December 2013 in Wiley Online Library (wileyonlinelibrary.com)..925 RESEARCH ARTICLE Data integration using service composition in data service middleware Sofien Gannouni, Mutaz Beraka and Hassan Mathkour* Computer Science Department, College of Computer and Information Sciences, King Saud University, Riyadh, Saudi Arabia ABSTRACT Service-oriented computing has emerged as the state-of-the-art distributed computing model for loosely coupled servicecentric business applications. Specifically, service-oriented computing techniques allow organizations to compose Web services. Indeed, the organizational capacity to compose Web services has received much interest, particularly with respect to supporting business-to-business or enterprise application integration. In this paper, we present a system that proposes to adopt service composition as a new approach to integrate data from various data sources. We specify the business process description language as well as the service composition engine that supports the proposed language. We also present different strategies for executing a composite data service call. Copyright 2013 John Wiley & Sons, Ltd. KEYWORDS data integration; service composition; parallel processing; GPU; data service composition engine; data service composition language *Correspondence Hassan Mathkour, Computer Science Department, College of Computer and Information Sciences, King Saud University, Riyadh, Saudi Arabia. mathkour@ksu.edu.sa 1. INTRODUCTION Up to 70% of time spent to develop applications that integrate data from different data sources is concentrated on accessing distributed data [1].Over the past decade, three main approaches have been developed to integrate heterogeneous remote data sources: enterprise application integration (EAI); extract, transform, and load (ETL); and enterprise information integration (EII). These approaches implement a variety of techniques and mechanisms to simplify the process of data integration. Enterprise application integration allows applications to communicate and exchange reliable messages, transactions, and data with each other using standard interfaces [2]. EAI supports integration at four levels: the user interface level, the methods level, the application level, and the data level. At the data level, EAI supports integration by using data propagation techniques. Data are copied from one location to another [2]. If the original data source is updated, then an event-driven technique propagates the modifications asynchronously or synchronously to the target system [2]. EAI is usually employed for real-time operational business transaction processing. Extract, transform, and load is designed to process a very large amount of data, which are stored into data sources and data warehouses [3]. ETL uses a consolidation approach to data integration [4]; it extracts and captures data from multiple data sources, transforms the data into a uniform format, and then integrates them into a target data source. If the original data source is updated, then the extraction and capture of changes are performed either in schedule-driven mode (i.e., pull mode) or in eventdriven mode (i.e., push mode) [2]. Enterprise information integration provides a single virtual interface to access uniformly heterogeneous data sources [2,3]. This approach integrates both data and information levels, and it also addresses enterprise applications [5]. Regarding data integration, EII uses the data federation approach by building a single virtual schema, called a global schema, that integrates all of the data source schemas. Users or applications submit queries on the virtual global schema to a federation engine. The federation engine decomposes the queries into sub-queries, submits them to the appropriate data sources, and receives and integrates the sub-results into a global result, which is then sent back to the application or the user [2]. The data service approach is the most widely used approach for data sharing today [6]; it uses service-oriented architecture principles to provide uniform access to heterogeneous and autonomous data sources. The data service approach supplies a data service layer (DSL) to be used as a mechanism for masking heterogeneity between data 2134 Copyright 2013 John Wiley & Sons, Ltd.

2 S. Gannouni, M. Beraka and H. Mathkour Data integration through service composition in DSM sources such as databases (DBs), files, or spreadsheets, and it makes them available as Web services (WS), such as representational state transfer WS [1]. The main advantage of this approach is that it reduces the complexity involved in developing new applications that access data from several data sources. Data service middleware [7] allows users to share data in a peer-to-peer environment. Organizations can use DSM to discover existing heterogeneous data sources, to ensure uniform access to these sources, and to save time during the development of new business applications by enabling the integration of existing data sources through service composition. DSM exports different and heterogeneous data sources as data services, and as such, the data integration process becomes a service composition problem. The remainder of this paper is organized as follows: Section 2 reviews the related literature. Section 3 overviews the main DSM architecture. Section 4 describes the phases involved in exporting a data source as a data service. Section 5 introduces the service composition language proposed by DSM, and it describes the different execution plans in the related composite data service call. Finally, it specifies the architecture of the data service composition engine (DSCE), which is responsible for generating and running business processes. Section 6 describes how the integration process is accelerated by using a graphical processing units (GPU)-based parallel implementation of the join operation. Section 7 evaluates the performance of different execution strategies of a composite data service call. 2. RELATED WORK During the past decade, much research effort has been dedicated to the development of prototypes using a data service approach. The most widely known prototypes are the following: Edge Server Data Service [8] is a distributed data service scheme that integrates a DSL and network data management technologies to allow users at different locations to access data efficiently. WSO2 [9] is software built upon WSO2 Carbon, which is a lightweight high-performance platform for making data stored in data sources available as WS. WSO2 uses Axis2 as the underlying simple object access protocol (SOAP) processing engine [9]. WSO2 supports relational databases, comma separated values files, and Microsoft Excel files. In addition, WSO2 addresses security issues by using WS-security standards and enhances reliability by using the WS-reliable messaging standard [9]. DBProxy [X3] is a data replication system that maintains and replicates business application data over the network. In DBProxy, both client queries and business back-end data are partially cached in one or more proxies. Client queries can be executed on the local database of the server. AquaLogic Data Service Platform designs and maintains data service layers [10 13]. AquaLogic Data Service Platform provides a declarative technique to create and implement data services for composite applications within an enterprise. IBM WebSphere commerce is a commercial software used to build and integrate business applications across multiple computing platforms [14,15]. This software includes several components and tools that facilitate the development and deployment of applications on the IBM WebSphere Application Server. WebSphere uses a data services layer to provide access to heterogeneous data sources independently of their physical scheme. The main purpose of the data services layer is to provide an interface, called a data service façade, to access data. This interface is used to transform data that are extracted from a data source into collections of Java objects that are then implemented as physical data objects [14,15]. Oracle Application Service and Database (DB) is geared at users of the Oracle application server [16], allowing Oracle users to avail their databases as WS and to access them using those services. Axis2 POJO creates classes to make databases available as WS [17]. Developers manually write the process to create databases and make them available as WS. 3. OVERVIEW OF DATA SERVICE MIDDLEWARE Data service middleware enables the sharing of data in a peer-to-peer environment [7]. DSM allows non-expert users to export their heterogeneous local data sources (e.g., relational DB, excel files, comma separated values files, and generic XML files) as WS call data services. These data services are generated by DSM based on data source schemas. A call to a data service will retrieve specific data from a specific user s data source. Using the published data services, DSM users can access to one another s data. They can then integrate data from different data sources by aggregating their corresponding data services into a new data service. Figure 1 depicts the DSM architecture. Profile Publisher Data-Services Composition Engine SOAP Msg. Handler API Data Consumer Data Discovery UDDI Registry Client Data Provider Data Service Layer Figure 1. Main architecture of data service middleware. Security Comm. Networks 2014; 7: John Wiley & Sons, Ltd. 2135

3 Data integration through service composition in DSM S. Gannouni, M. Beraka and H. Mathkour Data service middleware is composed of the following components [7]: Profile publisher (PP): The PP is responsible for creating and updating the profile of a peer. Only users with profiles are allowed to use DSM. Data provider (DP): The DP is responsible for generating data services according to the user s data source scheme, deploying the generated data services on an application server, and publishing them in a universal description, discovery, and integration (UDDI) registry. Data discovery (DD): The DD is responsible for discovering data services based on a user s search criteria. Data consumer (DC): The DC is responsible for invoking the operations of data services. DSL: The DSL provides access to the local data sources (e.g., excel files, XML data, and relational DB). DSCE: DSCE allows users to specify new business processes that integrate existing endpoints. DSCE is also responsible for interpreting a business process and generating the XML result of its invocation. UDDI registry client: This client offers basic UDDI functionalities. SOAP Msg handler (SMH): SMH is responsible for reading, writing, sending, and receiving SOAP messages. Moreover, it is responsible for parsing SOAP XML responses to extract embedded data. 4. DATA SOURCES AS DATA SERVICES As mentioned earlier, DSM allows the export of any user s data source as a data service that is generated and deployed by the DP under the application server. Moreover, the DP publishes a description of this data service in a UDDI registry. Figure 2 shows the different phases that are required to export a data source as a data service. To clarify each phase of this process, consider a DB called King Saud University (KSU), which contains the following two tables: Student(id, name, degree) Course(id, name, credithour) In phase one, the parameters of the user s DB as well as the selected tables and their corresponding attributes are specified. At this point, the two tables of the KSU DB mentioned earlier and all of their attributes should have been selected. The general description of the KSU DB obtained in phase one is represented in Table I. In the second phase, the DP defines the XML data service descriptor based on information on the KSU DB, such as the service name, its description, and relevant binding information. This description will be used later to publish the data service in the UDDI registry. In the third phase, the DP generates an Enterprise Java Bean module that includes all of the files that are associated with the generated data service of the KSU DB. The generated module has the same name as its corresponding DB and is considered as the development directory of the data service. This module contains the data service class of the corresponding DB, the build.xml file, and the set of imported classes that are required to establish the connection with the DB and perform queries and retrieving data. In the fourth phase, the DP utilizes the Ant tool to generate the corresponding artifacts of the Enterprise Java Bean module by invoking the build.xml file of this module. Figure 3 shows the structure of the KSU module and its corresponding generated artifacts. At this moment, the KSU module is ready to be deployed under the application server. In the fifth phase, the DP publishes the generated data service in the UDDI registry using the XML data service description. The data service is now ready to be discovered and invoked by other users. 5. DATA INTEGRATION IN DATA SERVICE MIDDLEWARE Data integration is a valuable functionality that enables on-demand data extraction from multiple heterogeneous Figure 2. Exporting a data source as a data service Security Comm. Networks 2014; 7: John Wiley & Sons, Ltd.

4 S. Gannouni, M. Beraka and H. Mathkour Data integration through service composition in DSM Table I. Publishing information for the King Saud University database. Property Database name Data service name URL of WSDL Exported data Data service methods Input parameters Output parameters Value KSU KSU 1- Student 2- Course 1- get_student_id() get_student_ ID_WithID_NotEqual(int) get_student_ ID_WithID_Less(int) get_student_ ID_WithID_Greater(int) get_student_ ID_WithID_Between(int, int) get_student_ ID_WithName_Like(String) get_student_ ID_WithName_NotLike(String) get_student_ ID_WithDegree_Like(String) get_student_ ID_WithDegree_NotLike(String) get_student_name() get_student_ Name_WithName_Like(String) get_student_ Name_WithName_NotLike(String) get_student_ Name_WithID_Equal(int) get_student_ Name_WithID_NotEqual(int) get_student_ Name _WithID_Less(int) get_student_ Name _WithID_Greater(int) get_student_ Name _WithID_Between(int, int) get_student_ Name _WithDegree_Like(String) get_student_ Name _WithDegree_NotLike(String) get_student_degree() get_student_ Degree_WithDegree_Like(String) get_student_ Degree_WithName_NotLike(String) get_student_ Degree_WithID_Equal(int) get_student_ Degree_WithID_NotEqual(int) get_student_ Degree _WithID_Less(int) get_student_ Degree _WithID_Greater(int) get_student_ Degree _WithID_Between(int, int) get_student_ Degree _WithName_Like(String) get_student_ Degree _WithName_NotLike(String) get_student_alldata() 2- get_course_id() get_course_id_withid_notequal(int) get_course_name() get_course_name_withname_like(string) get_course_credithour() get_course_credithour_withcredithour_notequal(int) get_course_data() 3- executegenericquery(string query) getcolumndatatype(string tabname, String attname) The input parameters are specified All of the methods return XMLResult:String (i.e., the result of the query is converted into XML format). data sources. Unlike existing systems, DSM supports such feature but accomplishes it through service composition. DSM allows the aggregation of a set of data services into a business process, interprets the description of the business process, invokes the specified methods of the aggregated data services, and gathers and integrates the sub-results into a global result. In this section, we describe the service composition language Security Comm. Networks 2014; 7: John Wiley & Sons, Ltd. 2137

5 Data integration through service composition in DSM S. Gannouni, M. Beraka and H. Mathkour For illustration, the following sample code shows the general form of a business process with DSCL. Figure 3. Structure of the King Saud University Enterprise Java Bean module. that is adopted by DSM as well as the service composition engine that supports this language Overview of the data service composition language Web services composition is a process-oriented approach that develops relatively simple processes for aggregating WS into business processes. The proposed language for service composition called Data services composition language (DSCL) extends the business process execution language and is described with a DSCL grammar. Parsing a DSCL program of a described business process will retrieve data from the data sources that correspond to the aggregated services and will combine them into a single global result that is represented in XML format. Data service composition language fully supports control flow and data flow. The building blocks of a business process are activities. There are primitive activities, such as invoke>, and structured activities, which manage the overall process flow and the order of primitive activities. Variables and partners are the other important elements of DSCL. Variables are used for exchanging data between activities, and partners represent the parties that interact during the process Data service composition language activities Primitive activities. Primitive activities are used to define a simple business process. Table II describes the various primitive activities of DSCL Structured activities. Structured activities are used to define a complex business process by defining the order of the primitive activities. These activities exactly specify the execution steps of the business process. Table III describes the structured activities Data service composition engine Data service middleware specifies a DSCE that is responsible for parsing the DSCL business processes and interpreting their internal business logic. The result of the execution of a DSCL business process is an XML document Security Comm. Networks 2014; 7: John Wiley & Sons, Ltd.

6 S. Gannouni, M. Beraka and H. Mathkour Data integration through service composition in DSM Table II. Data service composition language primitive activities. Activity Description <invoke> This activity specifies that the process invokes other data services. <receive> This activity specifies that the process must wait until the client calls the operation echo. <reply> This activity specifies that the process has to send the message in the variable request to the client. <assign> This activity specifies how the process manipulates data variables. <throw> This activity is used to throw and handle exceptions when they occur. (This feature is not yet supported). <wait> This activity specifies that the process has to wait for some time. Table III. Data service composition language structured activities. Tag <sequence> <flow> <while> <join> Description This activity specifies a sequence of activities, which defines the order of invocations of a set of activities. This activity is used to define the flow of parallel invocations of a set of activities. Used to define a loop. This activity specifies that the results of the aggregated services are joined using a joincondition. The results of the aggregated data services are merged (using the UNION relational operator) by default Data service composition engine plans. During a service composition process, DSM provides a list of published data services under the UDDI registry as well as their respective methods. On the basis of the user s choices and requirements, DSCE generates and executes the business process and returns the global result. The user can make the generated business process permanent by deploying it under the application server and publishing its description under the UDDI registry for further use. During the execution of a composite business process, DSCE invokes every data service that is aggregated in the business process by using appropriate SOAP messages and obtaining their corresponding SOAP responses. As shown in Figure 4, DSCE performs these calls either in a sequential way or in parallel. Suppose that a composite data service call involves two data services, DS1 and DS2, which retrieve data from back-end data sources DB1 and DB2, respectively. Without any optimization, DS1and DS2 are executed sequentially, as shown in Figure 4(a). However, an optimal way to execute DS1 and DS2 is to run them in parallel, as shown in Figure 4(b). This method has improved the performance of DSCE especially when the number of data services increases. a: Sequential execution of a composite data service call. b: Parallel execution of a composite data service call. Figure 4. Two different execution plans for a composite data service call. Data service composition engine supports two strategies for the parallel execution of a composite data service. The first strategy is shown in Figure 5(a) and involves invoking the aggregated data services DS1 and DS2 and inserting their sub-results into a local DBMS in parallel using a parallel CPU multi-threading framework. Then, the subresults are joined using a local DBMS. Finally, all of the temporal data are removed from the local DBMS. The second strategy aims to accelerate the data integration process by using a GPU toolkit and then performing the join operation in parallel on the GPU. As presented in Figure 5(b), the second strategy involves deploying DS1 and DS2 in parallel. Then, the sub-results are loaded into the memory of the GPU toolkit, and the join operation is performed in parallel on the GPU. Finally, the GPU toolkit memory is freed Data service composition engine architecture. As described in Figure 6, DSCE has the following two main components: DSCE application programming interface: This interface is used by the other components of DSM to interact with DSCE. Call level interface: This interface allows any published composite/non-composite data service to be called. Descriptor loader: This component is responsible for downloading the descriptor of the called data service from the UDDI registry. Business process generator: This component is responsible for composing and aggregating a set of selected data services across a single business process based on a list of selected endpoints and the methods inside these endpoints. The result of this task is a new composite data service that is written using DSCL. Execution plan generator: This component is responsible for parsing the structured activities of the business process (i.e., the composite data source) and creating the activities precedence graph, which specifies the execution order of the aggregated data services that were called. This component generates a sequential execution plan for the business process. Security Comm. Networks 2014; 7: John Wiley & Sons, Ltd. 2139

7 Data integration through service composition in DSM S. Gannouni, M. Beraka and H. Mathkour a: Performing the join operation on a local DBMS. b: Running the join operation in parallel using a GPU toolkit. Figure 5. Two strategies to perform the parallel execution of a composite data service call. Execution plan interpreter: This component is responsible for (i) parsing the optimized execution plan, (ii) extracting the required information about this process, and (iii) executing the logic of the DSCL business process by performing the remote methods in parallel or a sequential way based on the activities precedence graph. The interpreter uses the SOAP message handler (Section 2) to invoke the remote data services. Sequential invocation: This component offers the ability to perform a set of invocation activities in a DSCL business process in a sequential mode. Parallel invocation: This component provides the ability to perform a set of invocation activities in a DSCL business process in parallel. Figure 6. Architecture of data service composition engine. Execution plan optimizer: This component is responsible for transforming the sequential execution plan into a parallel execution plan according to the parallel processing capabilities of the user machine. The execution plan optimizer reorders the activities precedence graph to benefit from multi-core microprocessors as well the GPU technology while executing the invocation activities of the business process. Moreover, this component replaces all of the calls to various methods of the same data service with a call to the data service execute GenericQuery(), which is associated with that same data service. This makes it possible to avoid performing join operations on the user s machine that could be performed on the target data source Properties of data integration in data service middleware Data integration based on service composition in DSM has the following properties: Ability to perform an invocation of more than one data service per request: Data can be obtained from multiple data sources and then merge or join the results based on peer demands. Dynamic and flexible service composition: Dataservices can be composed specifically to gain a holistic understanding about data integration. Clear separation is also made between the composition logic and the aggregated data services. This type of service composition does not need to specify partner links and services at design time. Standard business process description language: DSCE parses and interprets the standard DSCLbased grammar Security Comm. Networks 2014; 7: John Wiley & Sons, Ltd.

8 S. Gannouni, M. Beraka and H. Mathkour Data integration through service composition in DSM Standard service description and invocation: DSCE uses the WSDL standard to interact with data services through their WSDL interfaces, and it uses the SOAP standard to invoke those services by sending and receiving SOAP messages. Various data integration strategies and execution plans: The result of the invocation is merged on the basis of the user s join constraints. We accelerate this feature by using a CPU parallel multi-threading framework and a GPU toolkit. The choice of which strategy is based on the user s machine capabilities. 6. GRAPHICAL PROCESSING UNITS BASED PARALLEL IMPLEMENTATION OF THE JOIN OPERATION The GPU-based parallel implementation of the join operation aims to accelerate the data integration process by using a GPU toolkit and then performing the join operation in parallel on the GPU. The major challenge of the GPU-based implementation of the parallel join operation is to accommodate the GPU memory limitation for processing large tables. The set of join operations to be performed are represented as a binary tree where leafs are operations that join data of base tables and the nodes are operations that join results of sub-nodes. The operations are performed in the same order as they appear in the post-order depthfirst binary tree traversing method. Parallelism is obtained by running all the operations of the same level simultaneously using a bottom-up approach starting from the leaf level up to the root level. The number of joins to be performed simultaneously is less or equal than (n/2 + 1), where n is the total number of join operations to be performed. As such, we optimized the number of join operations to be performed simultaneously, and consequently, we decreased the number of tables to be uploaded into the GPU memory. Indeed, only tables that are going to be processed by the join operations are loaded into the GPU memory. At every level, we create dynamically GPU threadblocks, which are performing the join operations of this level simultaneously. As shown in Figure 7, every thread-block is responsible for a join operation. As depicted in Figure 8, a thread-block is composed of a set of threads organized as a two dimension grid. As described in Figure 9, every thread T(i,j) of a GPU thread-block is responsible of joining the i th partition of the first table (the first operand of the join operation) with the j th partition of the second table (the second operand of the join operation). Indeed, the tables of the join operation are decomposed into partitions with equal rows number. The number of partitions of the first table of the join operation is equal to number of lines of the grid of threads of the thread-block. The number of the partitions of the Figure 7. Graphical processing units thread-blocks for a simultaneous execution of the join operation of the same level. Figure 8. Organization of threads inside graphical processing units thread-blocks. second table of the join operation is equal to the number of columns of the grid of threads of the thread-block. One of the main concerns of the GPU technology is the memory limitation. In order to fix this issue, the following actions have been taken: (1) Minimize the size of data to be uploaded per tuple into the GPU: For each row, only the index of the tuple and the value of the key attributes required for the join operations are uploaded into the GPU memory. Whereas the attribute values that are not involved in the join operations are not loaded into the GPU. As such, the number of tuples that could be uploaded simultaneously into the GPU memory is increased. (2) Sort the tuples of each table based on the key attributes. This will prevent from joining tuples that yield empty result. (3) Decompose each partition of each table into chunks that fit into the GPU memory. The join of two tables is obtained by processing corresponding chunks. For every chunk, we memorized the lowest and the highest key values. These key values prevent from joining two chunks that yield empty set. Security Comm. Networks 2014; 7: John Wiley & Sons, Ltd. 2141

9 Data integration through service composition in DSM S. Gannouni, M. Beraka and H. Mathkour Figure 9. Association between threads and data partitions. Figure 10. Description of the experiments. 7. EXPERIMENTS AND RESULTS As described earlier, we adopted two strategies to run a composite data service call in parallel. We compared the results of the implementation of these strategies. The first strategy was implemented using MySQL server 6.0 as a local DBMS to perform the join operation. The second strategy was implemented on the NVIDIA Quadro GPU using the CUDA 5.0 toolkit. We performed three experiments. First, we compared the performance of a two-table join operation on the MySQL server to our GPU-based parallel implementation of a two-table join operation. The inner rectangle (in blue) in Figure 10 represents this first experiment. Next, we compared the performance of the entire integration process for the results from two data services using both strategies. The outer square (in gray) in Figure 10 represents the second experiment. The third experiment is the same as the first one, except that it joined three tables. Table IV. Results from the two-table join operation. Number of rows per table Execution time in milliseconds Graphical processing units implementation MySQL Security Comm. Networks 2014; 7: John Wiley & Sons, Ltd.

10 S. Gannouni, M. Beraka and H. Mathkour Data integration through service composition in DSM Figure 11. Comparison between MySQL and our graphical processing units (GPU) based implementation of a two-table join operation. Figure 13. Comparison between the MySQL and graphical processing units (GPU) based implementations of a three-table join operation. experiment showed that the GPU implementation provides a very attractive framework for improving relational DB operations. Figure 11 plots the results from the first experiment. Figure 12 shows the performance comparison between the entire process (i.e., loading the sub-results to the GPU/MySQL, performing the join operation, and removing the temporal data from the GPU/MySQL) of joining two tables using MySQL and the GPU-based implementation. The third experiment showed that the difference between the GPU-based and MySQL implementations increased with the number of tables. Indeed, as shown in Table V, the time, in milliseconds, for the GPU implementation to run the join operation on three tables of 1000 rows each was 750% faster than for MySQL. Figure 13 plots the results of this experiment. Table V. Results from the three-table join operation. Execution time in milliseconds Figure 12. Comparison between MySQL and graphical processing units (GPU) based implementations of a two-table join operation (the entire process). We ran the two-table join operation on tables that had the same number of rows. We progressively increased the size of the tables and recorded the average execution time for each strategy. Table IV shows the time, in milliseconds, for the GPU and MySQL implementations. This first Number of rows per table Graphical processing units implementation MySQL Security Comm. Networks 2014; 7: John Wiley & Sons, Ltd. 2143

11 Data integration through service composition in DSM S. Gannouni, M. Beraka and H. Mathkour 8. CONCLUSION This paper has presented an overview of a service-oriented middleware called DSM. DSM allows the users to export their data sources as data services. These data services enable uniform access to remote and heterogeneous data sources. DSM specifies a data service composition language called DSCL, which extends the BPEL standard language to include join and union operators. By using this language, users can aggregate various data services into a business process. A business process is generated and executed by a component called the DSCE. We have presented different execution strategies for a given composite data service call. A composite data service can be executed sequentially or in parallel. The decision to adopt one of these execution strategies for a given business process is based on the parallel processing capabilities of the user s machine. The parallel execution of a composite data service call is accelerated with a GPU toolkit. A comparison of join operation using our proposed GPU-based implementation versus the MySQL implementation shows that the performance of the data integration process could be improved using the GPU technology. ACKNOWLEDGEMENT This work was supported by the Research Center of College of Computer and Information Sciences, King Saud University. The authors are grateful for this support. REFERENCES 1. Goundar K, Singh S, Ye XF. An investigation into concurrency control mechanisms in data service layers, 2007; White C. Data integration: using ETL, EAI, and EII tools to create an integrated enterprise, BI Research, Nov., Halevy AY, Ashish N, Bitton D, et al. "Enterprise information integration: successes, challenges and controversies," in Proceedings of SIGMOD Conference, pages , Wu T. EII -ETL -EAI What, why, and how!, Ziegler P, Dittrich KR. Data integration problems, approaches, and perspectives. In Conceptual Modeling in Information Systems Engineering, Krogstie J, Opdahl AL, Brinkkemper S (eds). Springer: Berlin, 2007; Bloomberg J, Goodson J. Best practices for SOA: building a data services layer, SOA World Magazine, Vol. 8, issue 5, June Gannouni S, Beraka M, Mathkour H. DSM: a data service middleware for sharing data in peer-to-peer computing environments. International Journal of Innovative Computing, Information and Control (IJICIC) 2012; 8(11): Yin R, Ye X. An efficient data service layer, Proceedings of the 11th International Conference on Parallel and Distributed Computing, Applications and Technologies, Pages: Rubasinghe S, Anandagoda A, WSO2 data services, White paper, (2008). 10.CareyM.Datadeliveryinaserviceorientedworld: the BEA AquaLogic data services platform, Proceedings of the 2006 ACM SIGMOD international conference on Management of data, Pages: BEA AquaLogic. BEA AquaLogic data services platform, aldsp/docs25/. 12. BEA AquaLogic. Architecture of BEA AquaLogic, docs20/concepts/arch.html# AquaLogic Concepts and Architecture. Concepts and architecture, E13171_01/alsb/docs30/concepts/introduction.html. 14. IBM WebSphere. WebSphere commerce, www-01.ibm.com/software/genservers/commerce/wcbe/ index.html. 15. IBM WebSphere Overview. WebSphere commerce product overview, infocenter/wchelp/v6r0m0/index.jsp?topic=/com.ibm. commerce.developer.doc/concepts/csdsoa.htm. 16. Oracle. Developing database Web services, otndnld.oracle.co.jp/document/products/as10g/101300/ B25221_03/web.1013/b14434/devdbase.htm. 17. Deepal Jayasinghe. Exposing a database as a Web service, March 21, 2008, last modified December 23, /Exposing-a-Database-as-a-Web-Service.htm Security Comm. Networks 2014; 7: John Wiley & Sons, Ltd.