Implementation of a SOA-Based Service Deployment ... - Springer Link

Implementation of a SOA-Based Service Deployment Platform with Portal* Chao-Tung Yang**, Shih-Chi Yu, Chung-Che Lai, Jung-Chun Liu, and William C. Chu Department of Computer Science, Tunghai University, Taichung, 40704 Taiwan [email protected], [email protected], [email protected], [email protected]

Abstract. In this paper we propose a Service Oriented Architecture to provide a flexible and serviceable environment. SOA comes up with commercial requirements; it integrates many techniques over ten years to find the solution in different platforms, programming languages and users. SOA provides the connection with a protocol between service providers and service users. After this, the performance and the reliability problems are reviewed. Finally we apply SOA into our Grid and Hadoop platform. Service acts as an interface in front of the Resource Broker in the Grid, and the Resource Broker is middleware that provides functions for developers. The Hadoop has a file replication feature to ensure file reliability. Services provided on the Grid and Hadoop are centralized. We design a portal, in which users can use services on it directly or register service through the service provider. The portal also offers a service workflow function so that users can customize services according to the need of their jobs. Keywords: SOA, Service, Hadoop, Resource Broker.

1 Introduction According to development of Grid Computing, we can improve efficiency in the Grid by resource monitoring and job scheduling, and distributing resouce in multiple grids[1,6]. But when the Grid grows rapidly, its configuration becomes more complicated and it is more difficult to manage resources, so we use Service Oriented Architecture[2] to provide more flexibility to deploy our resources. In the user side, users can use service just like a function call, and also combine services to complete their work by our portal[3]. When we get more and more service requests, we need to deal with the problem of service management and various data formats in our portal. To solve this problem, we develop a service to convert data from one format to the other. The data converter is implemented as a component in our system, for example, in a medical application we convert the clinical data to an international data format[4]. *

This work is supported in part by the National Science Council, Taiwan R.O.C., under grants no. NSC 99-2218-E-029-001 and NSC 98-2218-E-029-004. ** Corresponding author. T.-h. Kim et al. (Eds.): FGCN 2010, Part I, CCIS 119, pp. 227–236, 2010. © Springer-Verlag Berlin Heidelberg 2010

228

C.-T. Yang et al.

To be more compatible with Business Process Execution Language (BPEL) [11] we also implement functions to get the loading information on the service provider nodes by grid monitoring, and adjust the workflow of jobs according to the loading information. In tradition, security was designed for a group. P. Mazzoleni et al. propose a schema to access control in each machine node[5]. In our portal we adopt a security token schema. In this work, we implement a Service Oriented Architecture platform with service providers that can register services in our portal and design service workflows, users can use services by browsers in the portal, or get service description document to call service. Our portal can also dynamically generate BPEL documents according to loadings of machines in the Grid. In Section 2 we review the related techniques and background. In Section 3 we introduce the architecture and flowchart. Section 4 shows experiments and results, and finally Section 5 concludes this paper.

2 Resource Broker The main layers of our system architecture include SOA web portal, Services, Grid portal, Resource broker, and Grid nodes.We use a Resource Broker for a computational grid to discover and utilizegrid resources, and make job submission decisions by comparing job requirements with grid resources. The Resource Broker’s primary task is to compare user requests and resource information provided by the Information Service.After an appropriate assignment scheme is chosen, Grid resources are assigned and the Scheduler submits the job for execution. The results are then collected and returned to the Resource Broker, which records them in the Information Center database via the Information Service Agent. Users can view the results through the Grid portal.The system architecture includes five layers: SOA web portal, Service, Grid portal, Resource broker, Grid nodes. ResourceBroker is used to distribute resource and do job scheduling. It is important for monitoring and resource distribution and resource brokers use this information and their algorithm to do job scheduling. In the grid we use NWS[15, 16, 17,18] to aggregate each node’s CPU loading, memory usage and network bandwidth. We use Globus to do job scheduling. The Globus toolkit[16] is middleware that implements WSRF, which includes OGSA OGSI integration. The Globus toolkit functions include resources monitor manager, file transfer (GridFTP), file manager, data security (GIS), and monitoring and discovery system (MDS) to aggregate information, register service[16], etc.

3 Medical Grid Medicare Grid, a grid based one-Health system [7, 8, 9, 10, 17], fulfills a practical future medical scenario for next twenty years. It uses grid and peer-to-peer technology to integrate all the computing and storage resources, and base on it, medical data exchange mechanisms has been developed.Those data form a data warehouse to support the data mining techniques that extract valuable information for medical decision support and future research.

Implementation of a SOA-Based Service Deployment Platform with Portal

229

Medical Grid establishes from individuals, families, and hospital physicians to have a complete medical service mechanism, in order to improve the ways we are treated in a hospital nowadays. It can not only take care of the old, handicapped persons or anyone who need long-term medical care but also decrease the opportunity of accidents and prevent from diseases such as cardiovascular diseases taking place. Moreover, it can reduce the expense of medical insurance system and create better life for all human beings. This system consists of one medical data exchange and sharing platform. It allows any person in any place for medical treatment, and it also keeps a complete patient record to provide physicians knowledge of the patient’s medical history in order to provide complete medical services. It uses data mining technology and methods to offer the provision of medical decision in the grid platform. Depending on personal medical information, we can carry out follow-up medical analysis (such as medication, medical diagnosis and care) to further reduce medical expenditures.

4 Integration of Resource Broker with SOA Service Portal Combination of elements of SOA typically include: software components, services, and flow. When the hospital or enterprise face an external request, the external flow is responsible for the definition of steps of the requirements of treatment. Services of specific steps, including all program components and software components are responsible for the implementation of programs. We use the characteristics of SOA, and resource brokers (Resource Broker) for the combination of resource brokers going through the portal to access the grid (Medicare Grid) system. The channels of control have shown high-level interactions between various entities, components, resources, and human participants. We identify the following modules in our portal: z

z

z

z

Resource Status: Its main function is to let users inspect the machines status when users create jobs, so they can choose the right machines according to their needs. The users choose one or more nodes and send requests to the Information Service, which finds the information and returns it in a sorted list. The information type includes hostname and machine status. Job Submission: The users can submit job into the Workflow Engine by the SOA middleware, and then will be allocated to the grid environment to use computing machines by the resource broker (RB). TMT/CDA Converter: In general, information of the personal health record may be scattered in a variety of medical institutions because of different medical problems, to gather the personal health information on to the network for data exchange and integration, we need to edit the scattered information in a standard format. We use international standards, the Health Level 7, for the exchange of information integration. Handset service: We use the SOAP protocol as intermediate nodes; and kSOAP library, a SOAP web service, is used to connect with handset devices.

SOA Portal provides a user authentication feature. After passing authentication, users can search services. Service providers can register their services on the portal

230

C.-T. Yang et al.

and the portal can parse the WSDL document to get the service operation point user can access service through the portal or get the service information and access the service by itself in the user’s browser. We have implemented this technique by java script. Figure 1 shows the flowchart of the portal.It is described in detail as below. 1. SOA components will be imported from time to time and update on web services. The service’s Web Services Description Language (WSDL) is released on the SOA web portal for users to search. 2. User initiates session with portal by selecting required modeling resources and ‘planning’experiments with the resources. On the SOA web portal, the user can search for suitable services and resources. 3. User obtains authorization through VO and authorization service. 4. User gets service of WSDL document. 5. WSDL of the service allows users to be connected to the Internet through the SOA components, and to invoke service. 6. The SOA portal based on the SOA technology contacts Resource Broker to request resources (remote/local services or database) on the Medical Grid and P2P network. SOA component will submit tasks to the resource broker. 7. Resource broker submits the tasks to the Medical Grid or P2P network in order to achieve the goal. 8. Results are visualized on the users’ desktop through the Web browser. Figure 2 shows an expand view of the service model, in which the portal uses the Grid via the resource broker, accesses the P2P service network as well as Hadoop. To combine all these features in a model, first we need to design an interface by using

Fig. 1. Flowchart of SOA portal

Implementation of a SOA-Based Service Deployment Platform with Portal

231

Fig. 2. Expanded view of the architecture

SOA, and then the portal can access these resources by calling service with the SOAP protocol [8, 9].For example, when the user wants to access the grid service, the portal will call the resource broker that manages Medicare Grid, and then the resource broker uses the grid protocol to complete the job [10, 14]. In Hadoop, there is also an interface providing TMT clinical data service, and it has three backup data files and adopts the load balance technique. We have implemented following features: the TMT Convert Service to convert medical data, the Job Submission Service to send job to the resource broker, the Register Service for service providers to register services into our portal, the WSDL Parser Service to parse WSDL documents for registering service, the Database Access Service to save or read data into the database for registering service, the User Authentication Service to authenticate users, and the Monitoring Service to monitor grid’s node and so its data can be used for load balancing. All these services are packed into the portal and they services can be used to complete work of users.The service provided by Hadoop is the TMT clinical data service. Figure 3 shows a clinical document list. We choose Hadoop because it has a nice backup schema, as shown in Figure 4, and we also can use the mapReduce to do statistics of information of the clinical data.To use service we adopt kSOAP2 library in our portal. The portal also includes workflow schema, and BPEL documents are automatically generated to be compatible with the portal.

232

C.-T. Yang et al.

5 Experimental Results We compare the latency time of job submissions between personal computers (PC) and handset devices. The latency time is measured as the time spent when a job submitted from the user to the resource broker until a “true” message is returned to the user. The latency time of the handset device is found to be 3 times higher than that of PC, since the handset devices use wireless network for communication and use the SOAP protocol on the android system.

Fig. 3. TMT clinical data service on Hadoop

Fig. 4. Multiple backup copies on Hadoop

Implementation of a SOA-Based Service Deployment Platform with Portal

233

We also test service load balancing with the portal, and analyze the relation between machines when various amounts of requests occur. The testing program is used to calculate pi by using the Gregory’s Series formula: pi/4 = 1/1 - 1/3 + 1/5 - 1/7 +..., or

(−1) k k = 0 2k + 1 ∞

π = 4∑

We first deploy this program into each machine to test its computing ability. In Figure 5, the service interface displays invocation of a program to calculate pi in the html format. The calculation loops is 1 billion iterations, and the execution time is 9 seconds. Note that the precision is only within 8 digits, because of the ancient formula.

Fig. 5. Display on the service interface of a program to calculate pi Table 1. List of machines Machine name Otakus Beta3 Beta4 Beta5

CPU Core2 Quad Q9550 Opteron 246 Opteron 246 Opteron 2212

CPU clock 2.83GHz 2GHz 2GHz 2GHz

cores 4 2 2 4

In the first experiment we test ability of each machine. These data can be used for service load balancing by the portal. As listed in Table 1, the experimental environment includes four machines, one for service workflow, portal, and dispatch service requests, the others for computing pi. Otakus handles portal dispatch service requests to the other machines, and gathers loading information from each machine. From

234

C.-T. Yang et al.

Figure 6, since Beta5 and Otakus are quad core machines, their execution time is less than that of the two core machines, Beta3 and Beta4. In the computing mode, Beta5 is the fastest, so the portal service request dispatch will send more jobs to Beta5.

Fig. 6. Test of machine computing ability

In the second experiment we test ability of one machine versus that of three machines. The test setting is machine Beta5 versus a group of three machines Beta3+Beta4+Beta5, and fifty requests are sent to calculate the value of pi. As expected, the computing time will reduce dramatically in the three machines group, as shown in Figure 7.

Fig. 7. Ability of one machine, Beta5, versus that of three machines, Beta3+Beta4+Beta5

In the third experiment we send various amounts of requests to test the portal. Figure 8 shows that when the amount of requests increases to be 8 times, the increase of the execution time is less than it.In the fourth experiment we analyze distribution of the service requests. As shown in Figure 9, since machineBeta5 is fastest, about half of service requests are sent to it. In this way, load balancing is achieved by the portal.

Implementation of a SOA-Based Service Deployment Platform with Portal

235

Fig. 8. Execution time due to various requests

Fig. 9. Distribution of service requests

References 1. Yang, C.-T., Chen, S.-Y.: A Multi-Site Resource Allocation Strategy in Computational Grids. In: Wu, S., Yang, L.T., Xu, T.L. (eds.) GPC 2008. LNCS, vol. 5036, pp. 199–210. Springer, Heidelberg (2008) 2. Kart, F., Miao, G., Moser, L.E., Melliar-Smith, P.M.: A Distributed e-Healthcare System Based on the Service Oriented Architecture. In: IEEE International Conference on Services Computing, pp. 652–659 (2007) 3. Oh, S.-C., Lee, D., Kumara, S.R.T.: Effective Web Service Composition in Diverse and Large-Scale Service Networks. IEEE Transactions on Service Computing 1, 15–32 (2008) 4. Hong, S.-P.: An exchange system for medical information based on hl7/cda 5. Mazzoleni, P., Crispo, B., Sivasubramanian, S., Bertino, E.: “Efficient integration of finegrained access control and resource brokering in grid. The Journal of Supercomputing archive 49, 108–126 (2009)

236

C.-T. Yang et al.

6. Yang, C.-T., Chen, S.-Y., Chen, T.-T.: A Grid Resource Broker with Network BandwidthAware Job Scheduling for Computational Grids. In: Cérin, C., Li, K.-C. (eds.) GPC 2007. LNCS, vol. 4459, pp. 1–12. Springer, Heidelberg (2007) 7. Sain, M., Bhardwaj, S., Lee, H., Chung, W.-Y.: Architecture of Personal Healthcare Information System in Ubiquitous Healthcare. In: Lee, Y.-h., Kim, T.-h., Fang, W.-c., Ślęzak, D. (eds.) FGIT 2009. LNCS, vol. 5899, pp. 157–164. Springer, Heidelberg (2009) 8. Alboaie, L., Buraga, S.C., Felea, V.: TELEMON – an SOA-based e-Health System.Designing the Main Architectural Components. In: 2010 IEEE 24th International Conference on Advanced Information Networking and Applications Workshops, WAINA 2010, pp. 557–56 (2010) 9. Wang, J., Crawl, D., Altintas, I.: Kepler + Hadoop: A General Architecture Facilitating Data-Intensive Applications in Scientific Workflow Systems. In: Conference on High Performance Networking and Computing Proceedings of the 4th Workshop on Workflows in Support of Large-Scale Science (2009) 10. Fortuna, C., Mohorcic, M.: Dynamic composition of services for end-to-end information transport. IEEE Wireless Communications 16, 56–62 (2009) 11. Baresi1, L., Guinea, S., Nano, O., Spanoudakis, G.: “Comprehensive Monitoring of BPEL Processes. IEEE Internet Computing archive 14, 50–57 (2010) 12. Kim, J., Lee, S., Halem, M., Peng, Y.: Semantic Similarity Analysis of XML Schema Using Grid Computing. In: IEEE International Conference on Information Reuse & Integration, IRI 2009, pp. 57–62 (2009) 13. Cooper, I., Walker, C.Y.: The Design and Evaluation of MPI-Style Web Services. IEEE Transactions on Services Computing 2, 197–209 (2009) 14. Ziyaeva, G., Choi, E., Min, D.: Content-Based Intelligent Routing and Message Processing in Enterprise Service Bus. In:International Conference on Convergence and Hybrid Information Technology, ICHIT 2008, pp. 245–249 (2008) 15. Grit, L.E.: Broker Architectures for Service-oriented Systems (2005) 16. Krefting, D., Bart, J., Beronov, K., Dzhimova, O., Falkner, J., Hartung, M., Hoheisel, A., Knochf, T.A., Lingner, T., Mohammed, Y., Peter, K., Rahm, E., Sax, U., Sommerfeld, D., Steinke, T., Tolxdorff, T., Vossberg, M., Viezens, F., Weisbecker, A.: MediGRID: Towards a user friendly secured grid infrastructure. Future Generation Computer Systems 25, 326–336 (2009) 17. Casteleiro, M.A., Des, J., Prieto, M.J.F., Perez, R., Paniagua, H.: Executing medical guidelines on the web: Towards next generation healthcare 22, 545–551 (2009) 18. Bosin, A., Dessi, N., Pes, B.: Extending SOA paradigm to E-Science environments. In: Future Generation Computer Systems (2010), doi:10.1016/j.future.2010.07.003