Service Composition System in Consideration of the ... - SERSC

2 downloads 63 Views 380KB Size Report
the web service composition, the e-Engineering framework can be operated in an .... system memory size (physical + virtual) in MBytes, Hs denotes the hard disk ...
International Journal of Software Engineering and Its Applications Vol. 4, No. 1, January 2010

Service Composition System in Consideration of the Characteristics of Engineering Services Jai-Kyung Lee1, Seong-Whan Park1, Moohyun Cha1, Seung Hak Kuk2, and Hyeon Soo Kim2,* 1

Korea Institute of Machinery and Materials 171 Jang-dong, Yuseong-gu, Daejeon 305-343, Rep. of Korea {jkleece, swpark, mhcha}@kimm.re.kr 2 Dept. of Computer Science and Engineering, Chungnam Nat’l Univ. 220 Gung-dong, Yuseong-gu, Daejeon 305-764, Rep. of Korea {triple888, hskim401}@cnu.ac.kr *Corresponding author Abstract The product development in mechanical industry can be modeled as an engineering process defined on the collaboration of various engineering services. An e-Engineering framework aims to integrate engineering services and mediate them, so as to promote collaboration within the context of product development. The collaboration of engineering services is very similar to a business process, in terms of web service composition. By using the web service composition, the e-Engineering framework can be operated in an open environment, and provide better engineering services to its users. However, the existing web service composition methodology shows some limitations when dealing with engineering services. This paper presents a service composition system for the engineering services in consideration of their characteristics. Keywords: Service Composition, Engineering Process, QoS, BPEL.

1. Introduction In the areas of automotive, railway vehicle, shipbuilding and other mechanical industry the development process of a complex product can be modeled as an engineering process defined on the collaboration of various engineering services, and the facilitation of the efficient exchange of information between them [1]. To provide such collaboration, an integrated and collaborative engineering environment (called e-Engineering framework) is constructed by KIMM (Korea Institute of Machinery and Materials). The e-Engineering framework provides flexible integration and automation of an engineering process in a distributed environment [2]. The collaboration of the engineering services within the framework, the engineering process, and the service compositions are very similar to the processing of the business logic in e-business environments. Thus the service compositions can be realized by Web service compositions. By introducing Web service compositions into the e-Engineering framework, we expect that the framework can be operated in an open environment, and provide better engineering services. To process the collaboration of engineering service using web service composition, the modeling power of BPEL (Business Process Execution Language) is sufficient for the representation of the scientific workflow [3]. However, BPEL does not allow for the

53

International Journal of Software Engineering and Its Applications Vol. 4, No. 1, January 2010

modeling of the non-functional characteristics of service (Quality of Service, QoS). A study for extending BPEL to express QoS [4,5] and QoS-based web service composition [6,7] cannot cover the non-functional characteristics of an engineering service, which is usually related to numerical analysis. In this paper, we propose a web service composition system for the e-Engineering framework. We analyze the characteristics of the engineering service, and propose an extended BPEL system for the framework.

2. An e-Engineering Framework and the engineering process The e-Engineering framework was designed as a distributed system with a 3-tier structure. It consists of a presentation layer that enables users (designer, project builder, etc.) to access the system to define, manage, monitor and perform the engineering projects, a business processing layer that performs the business processes for solving engineering problems, and an engineering resource layer that includes a number of engineering software used to obtain concrete solutions to the problems. The Web services technologies are applied to integrate and utilize the engineering resources effectively [2]. The engineering process is modeled as a sequential or parallel workflow that consists of the engineering services (CAD modeling, structural analysis, dynamics analysis, and others) necessary to solve engineering problems. Each engineering service generally is modeled using mechanical engineering software (for instance, CATIA, NASTRAN, ANSYS, and etc). Figure 1 shows the typical procedure of durability analysis from CAD Modeling. This procedure had been applied to an automobile suspension module in our previous work [2], and was rearranged into four engineering services: XMbr_Task1, XMbr_Task2, XMbr_Task3 and XMbr_Task4. Each engineering service is executed with the appropriate mechanical engineering software. Figure 2 depicts the model of the engineering process in the framework, and Table 1 shows the engineering services and engineering software used for each service.

Figure 1. Procedure of durability analysis

Figure 2. Engineering Process of durability analysis

54

International Journal of Software Engineering and Its Applications Vol. 4, No. 1, January 2010

Table 1. Engineering Services and used S/W Sequence

Service name

Functions

Engineering S/W

1

XMbr_Task1

CAD modeling

CATIA V5

2

XMbr_Task2

Pre-processing for CAE

MSC.Patran 2005

3

XMbr_Task3

Structural analysis

MSC.Nastran 2005

4

XMbr_Task4

Durability analysis

MSC.Fatigue 2005

The request via the web service is processed by mechanical engineering software in the engineering service. Engineering software often has some trouble communicating directly with the web service, because they are usually legacy system with peculiar interfaces of their own. Thus, there should be a uniform type of interfacing mechanism that can play the role of a gateway to the engineering software. Figure 3 depicts the internal structure of engineering service in the framework. The engineering service supports a multi-services environment, that is, it manages all services provided by a host together. To achieve this, a job manager that can handle multiple jobs is added. A driver module plays the role of an interface for the engineering software, activating the engineering software upon the receipt of a service request. Its function is to prepare the engineering model, run the software, and return the results.

Figure 3. Internal structure of engineering service

3. Characteristics of Engineering Service Compared with conventional web services, engineering services have long execution duration and are sensitive to the execution environment. These make the selection of engineering services with the same functionality more important. In the e-Engineering framework most of the engineering services perform the analysis works in the mechanical engineering problem. Thus they deal with diverse numerical methods. In this paper, numerical methods are roughly classified into three types: linear equation, time-integration and non-linear equation. Table 2 shows the typical application areas, the features, and the factor that govern the performance.

55

International Journal of Software Engineering and Its Applications Vol. 4, No. 1, January 2010

Table 2. Classification of numerical methods Linear equation Typical application

Structural analysis, fatigue analysis, noise analysis.

Features

Dimension of problem space (array) is large, but solution is computed at once.

Performance factor

Memory-bound

Time-integration Dynamics analysis, computational fluid dynamics analysis, crash analysis. Dimension of problem space (array) is small, but computation of solution is proportional to time history and time interval. CPU-bound

Non-linear equation Kinematic analysis

Solution is computed by iteration and the linear equation is computed at each step of iteration CPU-bound & memorybound

The characteristics of the engineering service mean that it is possible to predict the service size, and whether it is restricted in terms of CPU or memory according to the numerical analysis method used. If the service composition designer knows the characteristics of the engineering service participating in service composition, QoS-based service selection is possible, and this enables the maintenance of the quality goal of service composition. To explain the characteristics of engineering services, engineering problems in product development used in the framework are analyzed. Two numerical methods described in Table 2 are selected for experiments and measured. Here, only their memory and CPU usage are presented for discussion. Only their memory and CPU usage by time are presented here for discussion, and it should be noted that there are other factors that influence performance. One of the characteristics not covered by this paper, for example, is the size of I/O, which can be affected by the size of storage and the network speed to send the results to the user. Figure 4 shows the results of measurement in the execution of the linear equation method for the structural analysis. The needed memory size is 1002 MB. If there is not sufficient physical memory (less than 1002MB), execution times can be consumed by page fault. This fact means that this is a memory-bounded service. Since the ratio of maximum CPU usage to average CPU usage is 0.36, this service is not CPU-bound.

(a) Memory usage by time

(b) CPU utilization (user time) by time

Figure 4. Measurement results from example of linear equation

56

International Journal of Software Engineering and Its Applications Vol. 4, No. 1, January 2010

(a) Memory usage by time

(b) CPU utilization (user time) by time

Figure 5. Measurement results from example of time-integration

Figure 5 shows the results of measurement in the execution of the time-integration method for the dynamics analysis. Since the needed memory size is 10.5 MB, the memory size is less relevant. However the ratio of the maximum CPU usage to an average CPU usage is 0.84, this fact means that this service is CPU-bound. To reflect the characteristics of engineering services, they are expressed in the form of constraint and selection specification by the designer. The constraint specification describes the minimum requirement of the execution environment to satisfy the QoS requirement of the service. For example, in order to process the engineering service in Figure 4, the environmental constraint requires at least 1002 MB of memory to avoid bottlenecks on performance. The selection specification describes the preference of selection for getting better performance, lower cost, or preferable QoS, when the service candidates satisfy the constraint specification. For example, the engineering service in Figure 5 requires very high CPU usage. So, if there are multiple candidates for the service, the one with a higher CPU capacity is preferable. Previous studies related to the QoS-based web service compositions have already introduced QoS attributes to serve as preference criteria for selecting from the candidates with the same functionality [6,7]. We have chosen some of these for the engineering service.  Execution time: It is defined as the required time to execute the service.  Execution cost: It represents the expense to be paid in using the service. It is computed by multiplying the execution time by the use rate of the service.  Capacity: It represents the number of service requests that are handled at the same time.  Service use rate: It is the cost of the service.  Reputation: It is the average ranking of individual users about the service.  Availability: It is computed as the ratio of service uptime to total service time.  Reliability: We compute reliability by using the ratio of successful service execution to total service requests. By considering the characteristics of the engineering service, we add the service context QoS attribute to the QoS model of engineering service. The service context QoS attribute represents the engineering service’s environment at the time of the service request, and it has terms for CPU, memory, storage, network speed, use rate, and etc. The service context QoS attribute is divided into two groups as follows:

57

International Journal of Software Engineering and Its Applications Vol. 4, No. 1, January 2010

 Static service context (SSC) QoS group is defined as , where U denotes the use rate of service, C denotes CPU capability in MOps/Sec, Ms denotes the system memory size (physical + virtual) in MBytes, Hs denotes the hard disk size in MBytes, and B denotes the network bandwidth in MB/Sec.  Dynamic service context (DSC) QoS group is defined as , where Md denotes the available system memory size in MBytes, PMd denotes the size of available physical memory in MBytes, Hd denotes the available hard disk size in MBytes, N denotes the network delay in ms, and S denotes the current service capacity. The two groups are classified according to when their information is provided. The service context QoS attribute is used to describe the selection and constraint specification. Table 3 shows the classification of service context QoS attribute. Table 3. Classification of service context QoS attribute Constraint Specification Static

Dynamic

U(use rate of service) Ms(memory capacity) Hs(hard disk size) Md(available memory) Hd(available hard disk size) S(current service capacity)

Selection Specification U(use rate of service) B(network bandwidth) C(CPU capability) Md(available physical memory) N(network delay) S(current service capacity)

4. Proposed service composition system 4.1. System architecture Figure 6 shows the architecture of the proposed system. The QoS-based web service orchestration system extends the existing BPEL system (in figure 6, denoted by the white box) using QoS Service, QoS Broker, and QoS Registry. BPEL engine invokes the QoS Broker when QoS-based service selection is needed. QoS Registry manages the QoS information of the system. The QoS Service attached to the atomic service or the service composition provides the QoS information of the service.

Figure 6. Architecture of Service Composition System

58

International Journal of Software Engineering and Its Applications Vol. 4, No. 1, January 2010

 Classification of QoS attributes For the computation of the QoS value, QoS attributes are classified into three categories: static, dynamic, and statistical. Static QoS attributes are fixed at registration time, and are immutable unless the service changes. Dynamic QoS attributes are those that are changeable during the lifetime of service. Statistical QoS attributes are computed based on the history of QoS attributes. Table 4 shows the classification of QoS attributes. Table 4. Classification of QoS attributes QoS name

Type CS Use rate Static O CPU capability Static X System memory Static O Hard disk size Static O Network bandwidth Static X Available system memory Dynamic X Available physical memory Dynamic X Available hard disk size Dynamic O Network speed Dynamic X Current service capacity Dynamic O Execution time Dynamic X Execution cost Dynamic X Availability Statistical O Reliability Statistical O Execution time Statistical O Note. CS: Constraint Specification, whether used or not SS: Selection Specification, whether used or not

SS O O X X O O O X O O X X O O O

 Identification of users Users are categorized as follows: service provider, orchestration designer (in BPEL, Business Expert), and service requester (in BPEL, End User/Application). A service provider offers atomic services used in composition. An orchestration designer creates a business process (in BPEL, Process flow template) and composes services composition using Business Process Modeler (in BPEL, BPEL Designer). A service requester makes a request to the Orchestration Engine (in BPEL, BPEL Engine) for a composited service.  System usage scenario The usage scenario of a system is divided into three steps: the registration step of atomic service is similar to the registration of the conventional web service, except that the QoS Service also is registered to UDDI, and it sends static QoS information in Table 4 to QoS Broker. In the modeling step of service composition, the orchestration designer defines a control flow of engineering service, the functional aspect of the engineering process, and creates the business process using modeling elements of BPEL. The designer should describe not only the interface of the service but also the QoS-based selection of service. Section 4.2.1 explains how to describe the QoS-based selection of service. The runtime step of service composition can be initiated when the service requester invokes the Orchestration Engine. The Orchestration Engine performs its function by processing the business process. When the Orchestration Engine finds the activity represented QoS-based selection, the QoS Broker is called. The detailed steps for selecting services are shown in Section 4.2.2.

59

International Journal of Software Engineering and Its Applications Vol. 4, No. 1, January 2010

4.2. Proposed methods The whole procedure can be summarized as follows: The orchestration designer specifies the non-functional characteristics of each atomic service at the modeling stage of service composition. At the runtime stage of service composition, the QoS Broker performs the selection of service among the candidates 4.2.1. The modeling of composition: In order to express the QoS-based web service composition, the activity which stands for the selection of web services in BPEL is extended. Extended activity has the tag to denote QoS-based service selection. Figure 7 shows the structure of the proposed BPEL modeling. The tag consists of and tag. QoS name Relational Operator Constraint value of QoS ... QoS name Weighted value of QoS ...

Figure 7. Structure of proposed BPEL model

The is used for constraint specifications of service. It can contain multiple tags, to denote each constraint specification. The has three sub-tags: , , and . The represents the QoS attribute listed in Table 4, and the is the relational operator: EQ, NE, GT, LT, GE, and LE. The represents the value as a constraint. Figure 8 shows an example of the constraint specification for the service in Figure 4. The needed memory size of the service is 1002 MB, so the constraint of the available physical memory is specified on tag. The second tag shows the service designer want to get a reliable service and thinks this is the constraint of the service.

60

International Journal of Software Engineering and Its Applications Vol. 4, No. 1, January 2010

Available Physical Memory GT 1002 Reliability GT 0.9

Figure 8. Examples of the constraint specification

The tag is used for selection specifications of service. Multiple tags can be used for selection specification. The has two sub-tags: and . The is the same one in constraint specification. The represents the weight value of each QoS attribute, and the sum of the values in should be 1. Figure 9 shows the example of the selection specification for the service in Figure 5. The service designer prefers to get a higher CPU capability than a large amount of memory because the service is CPU-bound. CPU Capability 0.9 Available Physical Memory 0.1

Figure 9. Examples of the selection specification

4.2.2. The registration, modeling, and execution of composition: Before creating the QoS-based web service composition, service provider registers atomic services. Figure 9 shows the registration process of atomic web services. First the service provider publishes the web services to the UDDI registry. It is same process to register the general web services. Then the service provider registers the QoS information into QoS Broker. The QoS Broker manages two type of the QoS information. One is static information and the other is dynamic information. The former cannot be changed after the register but the latter can be changed dynamically during the execution of the services. The static information is registered and managed in the QoS Broker. The QoS repository manages the dynamic information.

61

International Journal of Software Engineering and Its Applications Vol. 4, No. 1, January 2010

QOS repository

UDDI

QOS Broker

1. Publish Service & QOS Service

2. Register Static QOS info.

WS

QOS Service

Service Provider

Figure 9. Registration stage of atomic service

After the registration of atomic services, an orchestration designer creates the composite services with them. The designer can specify the selection and constraint specification with QoS information to select the optimal services. After finishing the modeling, the business process is saved as the BPEL and registered into the UDDI registry. Figure 10 shows the modeling stage of the services composition. 2-1. Set Binding Info. 2-2. Specif y Constraint Sepecification 2-3. Specif y Selection Function

UDDI

4. Publish Business Process & QOS Service

Business Process : Process flow template (BPEL) 1. Create Business Process

QOS repository

2. Modeling Business Process

QOS Service

5. Register Static QOS info.

3. Save Business Process

QOS Broker

Business Process Modeler : BPEL Designer (BPEL) Orchestration Designer : Business Expert (BPEL)

Figure 10. Modeling stage of service composition

If the tag in activity is found during execution of the engineering process, the orchestration engine calls the QoS Broker with the service’s interface information. The runtime stage of service composition is shown in Figure 11 and the algorithm for QoS-based service selection is described from step 11 to step 19.

62

International Journal of Software Engineering and Its Applications Vol. 4, No. 1, January 2010

Figure 11. Runtime stage of service composition

5. Related Researches Many studies [4-7] for QoS-based service composition have assumed that the execution cost and execution time of a service can be estimated, or that the history of these values can be used as values for quality of service, and have used these as a criterion of selection and comparison of services. However, the e-Engineering framework uses engineering services, such as parts of QoS attributes, with characteristics that cannot be expressed as conventional web services. Regarding the selection of web service, [8] has proposed that the consideration of resources is required, as it affects the quality of service. The system context information of the service requester, such as processor load, memory usage, and network bandwidth should be maintained at the time of service request. The service provider’s contextual information is not dealt with, and it does not address service composition. In the consideration of the service provider’s environment, the use of a limited resource raises the cost of the service [9], and it does not consider the failure of service due to the resources.

63

International Journal of Software Engineering and Its Applications Vol. 4, No. 1, January 2010

6. Conclusion and future work 6.1. Conclusion The proposed QoS-based web service composition enables the composition of engineering services and efficient product development that satisfies the limitations of time, cost, and other QoS attributes. Thus, the collaboration of engineering processes can be processed in a more efficient manner, and the reduction of time and cost for product development can be achieved in a range of industries. Moreover, the proposed system can be applied to web service composition in other application areas, where the characteristics of atomic service cannot be expressed in its QoS. 6.2. Future work Future work will be devoted to the analysis of numerical methods not covered by this paper, and the survey of engineering services that perform non-numerical analysis, such as CAD and some types of user-interactive S/W. In addition, the relationships of QoS within atomic services will be dealt with. In this paper, they are treated separately, but in actuality they are closely linked. For example, failure of service execution affects the reliability and availability (QoS) of service. Another work to be studied is the selection of service composition among several candidate ones having same functionality but different nonfunctional characteristics. In this paper, we concentrate on only the selection of atomic services but future work will be extended to the selection of service composition consisted of engineering services.

Acknowledgement This work was carried out with the financial support of the Small & Medium Business Administration of Korea.

References [1] L. Wang, W. Shen, H. Xie, J. Neelamkavil, and A. Pardasani, “Collaborative conceptual design—state of the art and future trends”, Computer-Aided Design, vol.23, no.13, Elsevier, 2002. pp.981-996. [2] S.H. Kuk, H.S. Kim, J.K. Lee, S.H. Han and S.W. Park, "An e-Engineering Framework Based on ServiceOriented Architecture and Agent Technologies", Computers in Industry, vol.59, no.9, Elsevier, 2008, pp.923935. [3] A. Akram, D. Meredith, and R. Allan, "Evaluation of BPEL to scientific workflows," Proc. of the 6th IEEE Int’l Symp. on Cluster Computing and the Grid, 2006, pp.269-274. [4] F. Baligand, D.L. Botlan, T. Ledoux, and P. Combes, "A language for quality of service requirements specification in web services orchestrations", LNCS 4652, Springer-Verlag, 2007, pp.38-49. [5] G. Canfora, M.D. Penta, R. Esposito, F. Perfetto, and M.L. Villani, "Service composition (re)binding driven by application-specific QoS", LNCS 4652, Springer-Verlag, 2007, pp.141-152. [6] L. Zeng, B. Benatallah, A. H. Ngu, M. Dumas, J. Kalagnanam, and H. Chang, “QoS-Aware Middleware for Web Services Composition”, IEEE Transactions on Software Engineering, vol.30, no.5, 2004, pp.311–327. [7] M. C. Jaeger, G. R.-Goldmann, and G. Muhl, “QoS Aggregation for Service Composition using Workflow Patterns”, Proc. of the 8th Int’l Enterprise Distributed Object Computing Conf. (EDOC’04), 2004. pp.149– 159. [8] J. Day and R. Deters, "Selecting the best web service", Proc. of the Conf. of the Centre for Advanced Studies on Collaborative Research, 2004, pp.293-307. [9] V. Tosic, K. Patel, and B. Pagurek, "WSOL – Web Service Offerings Language", LNCS 2512, SpringerVerlag, 2002, pp.57-67.

64

International Journal of Software Engineering and Its Applications Vol. 4, No. 1, January 2010

Authors Jai-Kyung Lee is a senior researcher at the Korea Institute of Machinery and Materials. His research interests include software architecture for integrated engineering framework, services composition, engineering workflows, and virtual reality in engineering fields. He received his Bachelor (1995) and Master's (1997) degrees from Ajou University and his Doctor degree (2008) from Chungnam National University, Korea. He is a member of IEEE, ACM, KIISE, and SCCE.

Seong-Whan Park is a principal researcher at the Korea Institute of Machinery and Materials. His research interests include CAD-CAE interface, agent based integrated engineering framework, workflow design, PDM, digital mock-up, virtual manufacturing, optimization, and etc. He received his Bachelor (1983) and Master's (1985) degrees from Seoul National University, Korea and his Doctor degree (1996) from Hiroshima University, Japan. He is a member of KSME, SCCE, SNAK, and KSOE. Moohyun Cha received the BS degree from POSTECH (Pohang University of Science and Technology) and the MS degree from KAIST. Currently, he is working as a senior researcher at Korea Institute of Machinery & Materials). His research interests include various VR (virtual reality) applications for engineering and training and computer graphics &data processing for very large engineering data set Seung Hak Kuk is a PhD student at Chungnam National University, Korea. He is a member of the Software Engineering and Application laboratory. His research interests include software engineering, software testing, software architecture, service-oriented architecture, and web services. He received his Bachelor (2004) and Master's (2006) degrees from Chungnam National University. He is a member of KIISE and KIPS.  

 

Hyeon Soo Kim is a professor at Chungnam National University (CNU), Korea. He works for Department of Computer Science and Engineering at CNU. His current research areas include Software Engineering (Software Testing, Software Architecture, Software Maintenance, Software Reengineering), Distributed Computing (J2EE/EJB, .NET, Web service, service-oriented architecture). He received the BS degree (1988) from Seoul National University (SNU), Korea, and the MS (1991) and the PhD degree (1995) from Korea Advanced Institute of Science and Technology (KAIST), Korea. He is a member of KIISE and KIPS.

65

International Journal of Software Engineering and Its Applications Vol. 4, No. 1, January 2010

66