Secure Grid Service Engineering for Industrial Optimization Problems Tim D¨ ornemann, Steffen Heinzl, Kay D¨ ornemann, Markus Mathes, Matthew Smith, Bernd Freisleben Department of Mathematics and Computer Science, University of Marburg, Hans-Meerwein-Str., D-35032 Marburg, Germany {doernemt, heinzl, doernemk, mathes, matthew, freisleb}@informatik.uni-marburg.de Abstract Many industrial optimization problems require high computational power and hence are ideally executed in a Grid environment. Since the development and configuration of Grid Services – especially the security configurations – is a very complex task, an engineer needs – besides deep knowledge in his/her application domain – knowledge in configuring the Grid middleware. Since setting up the Grid middleware and developing Grid Services is already a burdensome task, security aspects are often neglected, although the data models generated by these optimizations are confidential. Furthermore, easy handling of workflows and collaboration in the development process is desirable. These requirements are illustrated by taking a look at the domain of metal casting. Several tools are introduced which simplify the generation and configuration of Grid Services, particularly the security configuration, and allow the orchestration of services. Keywords: Optimization in Industrial Engineering, Grid Computing, Security, Workflow, Service Orchestration, Service-Oriented Architecture (SOA), Model Driven Development

1

Introduction

Service-oriented Grid computing has gained tremendous interest in various application domains. The paradigm shift to service-orientation in Grid middleware opens the opportunity to use a far more flexible software development approach, namely to compose applications from standard components, promising easier development and modification of Grid applications. Even though, Grid technology has only seen a slow adoption in commercial application domains such as engineering. The inherent complexity of current service-oriented Grid middleware systems – especially when security aspects need to be considered – is still prohibitive for everyday use by an application domain expert who has no background in middleware development, Grid computing or even computer science. Grid Services can be regarded as small entities of functionality to implement parts of the engineering application. Large applications are broken down into several components (Grid/Web Services) which can then be flexibly composed to form new applications. This allows recombining Grid/Web services to different applications and thereby reduces redundancy and increases flexibility. In the domain of Grid and Web Services, this recombination is achieved by using workflow modelling languages. The de-facto standard in the Web Service area is the Business Process Execution Language for Web Services (BPEL4WS [1] for short). Therefore, a workflow composition tool is needed to allow the engineer to model complex simulation and optimization applications as business processes. Furthermore, there is a need to foster collaborative workflow design since modelling requires the knowledge of different domain experts. In this paper, we present an engineering application from the domain of metal casting and discuss which tools are needed to support engineers who often play the roles of developers, administrators, and users to develop and run engineering applications. Emphasis is put on security aspects since engineers often deal with confidential data which might be crucial for their business’ success. The design and implementation of several tools which

simplify the generation and configuration of Grid Services, particularly the security configuration, will be described. Finally, tool support for orchestrating services, developing workflows and collaborative workflow design will be presented. The paper is organized as follows. Section 2 introduces a sample application from the engineering domain to derive requirements concerning tool support. In section 3, a short introduction to the Grid Security Infrastructure (GSI) is given. Sections 4 and 5 present the design and implementation of our Grid Development Tools (GDT) [7] and our workflow composition and execution tools [6, 3]. Related work is discussed in section 6. Section 7 concludes the paper and outlines areas for future work.

2

A Metal Casting Application

In this section, a simplified view on a sample application from an engineering domain is presented to motivate the need for support in the distributed software development and security configuration process of a Grid software system for engineering applications. The concrete use case comes from metal casting, a sub-domain of metal forming. Only those parts relevant to the Grid are briefly sketched; they do not reflect the entire complex field of metal forming. In the metal casting industry, customers’ quality requirements, e.g. allowed tolerances in a casting product’s geometry compared to the specification, are constantly increasing. Therefore, the use of numerical simulation and simulation-based optimization is gaining importance, since the creation of prototypes is prohibitively expensive and time consuming. The benefit of simulated prototyping is constrained by the accuracy of the simulation environment. The creation and use of the simulation application require great expertise in the metal casting domain. Furthermore, applying numerical simulation for this purpose introduces an extremely high demand for computational capacity since a single – sufficiently precise – simulation run typically lasts several hours up to days. Since many small and medium sized engineering enterprises are not capable of acquiring and maintaining high performance computing resources, outsourcing of computational demanding tasks is necessary. Grid computing promises to offer the infrastructural components to realize this outsourcing activity as easy as plugging into the electrical power Grid [5]. However, currently the implementation of a Grid application still requires these firms to involve Grid specialists to adapt and maintain their applications in a Grid environment. To summarize, the utilization of numerical simulation in the casting industry requires a variety of competencies: • knowledge about the physical properties of casting in industrial practice (casting engineer) • modeling a casting engineering process for simulation (casting engineers together with IT specialists) • adapting existing simulation software to the Grid (Grid specialists consulting the casting engineers or the casting engineers themselves) • setting up and maintaining a simulation and/or optimization environment for the engineers’ customers (Grid specialists, casting engineers and their customers) • interpreting a simulation’s result (casting engineer and customer). These required competencies lead to the need of tools that support engineers in developing and configuring Grid Services, middleware, and their security settings. Since many applications for simulation and optimization in the engineering domain already exist, there is a need to “gridify” these existing legacy applications. If the application is not Gridcapable for some reason, it has to be rewritten from scratch. In both cases, the engineer who often develops these applications needs in-depth knowledge of the used Grid middleware to develop and seamlessly integrate the application into the environment. As already

mentioned, a good idea is to break down applications into small units which are then implemented as Web or Grid Services. This allows rapid design and flexible reconfiguration of applications by composing the services to obtain new applications. As a concrete sample scenario, we introduce the engineering process of developing a metal casting model. After deploying the created services (several metal casting services in this case, each providing reusabe parts of the application), an engineer may start with a problem definition which progresses through some iterations of model definition, simulation and refinement. The given problem definition is then modeled as an initial casting process model. This step is often done by a numerical simulation expert. Since this expert is typically located in another company, due to the already mentioned lack of personnel or know-how in small and medium engineering enterprises, it would be helpful to allow collaborative model design. The numerical simulation expert periodically discusses the evolution of the initial model with the casting engineer during the design phase. Both experts have to combine their expertise to successfully define an accurate model for the casting process. To verify the accuracy of the resulting model, it typically is simulated numerically. Therefore, an intuitive tool that allows the collaborative composition of services into more complex sequences is required. Figure 1 shows an example of such a workflow which successively invokes several Grid Services. During this model calibration phase, an optimization expert is also involved in creating model variants. When a single model is calibrated, the optimization of the model begins by automatically generating a number of n new models by varying the parameters in the casting process model. They can be evaluated in parallel, and the results from the simulation runs flow back to the optimization algorithm. This procedure iterates until the optimized casting process meets the requirements set by the casting engineer. The simulation software, which runs n instances in parallel, requires distributed computing resources and therefore suggests the application of Grid technology.

Figure 1: Example optimization workflow.

3

Grid Security Infrastructure

In this section, we will briefly describe the Grid Security Infrastructure (GSI) and the mechanisms it offers to develop secure Grid Services. GSI offers four distinct functions: 1. message protection (signing or encrypting messages) 2. authentication (identifies the caller/sender) 3. authorization (access rights) 4. delegation (performing a task on behalf of a delegator) The Globus Toolkit 4, a very popular Grid middleware, provides these functions by implementing several security specifications. 1. Transport Level Security (TLS) and Message Level Security (WS-Security and WSSecureConversation) as protection mechanism for messages in combination with SOAP. They use XML-Encryption and XML-Signature for message protection. 2. X.509 certificates or username/password token for authentication. 3. Security Assertion Markup Language (SAML) [10] assertions for authorization. 4. X.509 proxy certificates and WS-Trust for delegation. TLS entails SOAP messages conveyed over a network connection protected at the transport level (often HTTPS is used) and provides both message integrity (by signing) and privacy via encryption. Message Level Security specified by the WS-Security standard in combination with the SOAP specification allows to add security related payload (e.g. integrity protection, or encryption) to each message. Another way to provide message level security is described by the WS-SecureConversation specification that allows to establish a secure context with the initial message. Following messages can then be secured using the context. The difference between WSSecurity and WS-SecureConversation is that the latter produces less overhead if several messages are exchanged, does not require the destination host’s public key to be present as a file, and that WS-SecureConversation features credential delegation. Both provide integrity protection, encryption and replay attack protection. GSI supports authentication through X.509 certificates or user name/password and delegation through X.509 proxy certificates and the WS-Trust standard. Delegation allows a client to delegate a X.509 proxy certificate to a service. The target service can then perform tasks on behalf of the user who owns the proxy certificate. This is especially important for running programs on the target host/cluster. Globus uses WS-GRAM (Grid Resource Allocation Manager) to interact with local scheduling systems on clusters and requires delegation to execute tasks as the user given in the proxy certificate. All these security options are configured in Globus by four different configuration files: Client Security Descriptor configures which of the above mentioned security mechanisms should be used for the communication, if delegation is to be used and so on. Only if the server offers different possibilities, the client may choose the desired option. Generally speaking, the client’s settings have to match the settings of the server. The descriptor supports configuring the credentials to be used (key and certificate file), GSISecureMessage, GSISecureConversation and authorization. It does not allow to configure GSITransport (TLS). Service Security Descriptor configures security settings of Grid Services. It is possible to configure the service as a whole or every operation individually. As authentication methods, GSISecureMessage (WS-Security), GSISecureConversation (WS-SecureConversation), and GSITransport (TLS) are supported. When using credentials, a Grid Service may either specify a path to a proxy certificate or a path

to an X.509 certificate and key file. The service may also specify the path to a gridmap file being used to map names found in certificates to local user names (for example used for login) and a run-as mode (specifies under which identity a service method will be executed). Resource Security Descriptor equals the Service Security Descriptor mentioned above, but on a more fine-grained level. It allows to configure the security settings of Grid resources accessed by one or more services. Container Security Descriptor allows to configure container-wide security options as default values for credentials, location of the gridmap file, authorization and other parameters. As already mentioned, GSI’s service security descriptor also supports per-operation security settings allowing to define a different security mechanism for each operation of a service. If no security setting is given for an operation, the service or resource configuration is taken (if present). A resource security descriptor overrides any per-operation security settings and per-operation settings override service level security which again overrides container security settings.

4

Tool Support

Several specific software tools are needed to ease the design and development of Grid Services by engineers. To deduce the required functionalities of these tools, we investigate the duties of a development engineer in the following.

4.1

Service Development

First of all, an engineer has to implement domain-specific services encapsulating application logic. To enable outsourcing of services, it is important to implement services in a middleware-agnostic fashion, i.e. an engineer develops a service regardless of the underlying middleware, since different resource providers may use different middleware platforms. Therefore, a tool is needed to relieve the development engineer from manually writing a lot of middleware-specific code (like Web Service Deployment Descriptors (WSDD) and Web Service Description Language (WSDL)). Thus, the development environment should allow the rapid generation of Grid Services by writing standard, middleware-agnostic code. A first step in this direction is the service creation component of our Grid Development Tools (GDT) [7]. An engineer only has to implement task-related application logic and annotates the service code for a specific target platform. GDT automatically generates all necessary configuration files and returns a deployable Grid Service, as shown in figure 2.

4.2

Credential Management

If security (namely authentication and authorization) is enabled in Grid environments, the invocation of Grid Services becomes much more complicated than without security. To invoke a service at an external resource provider after service deployment, the user has to authenticate himself/herself. This is normally done by providing a proxy certificate which is derived from the X.509 certificate received from the resource provider’s administrator. The user is identified by the certificate’s subject, which consists of five parts: country (C), locality (L), organization (O), organizational unit (OU), and common name (CN). For example, C=DE, L=Marburg, O=University of Marburg, OU=Distributed Systems Group, CN=Mathes identifies one of the authors of this paper. Furthermore, the engineer defines the strength of the key used (512, 1024, 2048, or 4096 bit), certificate lifetime (12, 24, or 36 months) and a passphrase. To ease requesting a X.509 certificate from the administrator, we offer the Certificate Request Creation Tool (CRCT). This tool is used by an engineer to generate a certificate request and to send the request to the administrator via e-mail. Furthermore, the CRCT allows the import of generated certificates and deployment to the correct directories.

Figure 2: General development of a Grid Service using GDT.

4.3

Workflow Composition

Since realistic simulation and optimization processes often consist of several subtasks, an engineer needs a tool to easily model these processes as a workflow. We have chosen the Business Process Execution Language as workflow composition language since it is the de-facto standard in the Web Service domain. It offers a rich vocabular and meets all requirements for modelling scientific workflows. As described in [3], we have slighty extended the BPEL language to ease working with stateful services (i.e. Grid Services). Our extensions have been implemented in the ActiveBPEL workflow enactment engine. To make the development of Grid-enabled workflows as convenient as possible, we have developed an Eclipse-based BPEL designer application [6, 3]. The workflow composition tool provides the ability to adapt to the needs of different groups of developers, allowing Grid middleware experts to inspect and manipulate fine details of a Grid process (high-fidelity editing) while hiding complicated details from application domain experts (low-fidelity editing). To fill the gap between high- and lowfidelity editing, a collection of wizards assigns values to the hidden properties in the model elements, based on certain patterns and heuristics defined for the overall system. Furthermore, the workflow tool allows interactive collaboration between engineers by sharing the process model over network connections. Every change is instantaneously sent to all participants so that online collaboration is possible. An integrated text-chat allows discussing the development process. These features heavily improve the development process and reduce the error rate.

5

Tool Design and Implementation

This section presents the design and implementation of the Grid Development Tools, the Certificate Request Creation Tool and the BPEL workflow editor.

5.1

GDT: Tool Support for the Service Developer

GDT [7] is an integrated development environment for service-oriented Grid applications integrated into the Eclipse platform. Its design is based on a Model Driven Architecture (MDA) approach and eases the creation of services by hiding the complexities of the Grid middleware. GDT consists of several components like a service development tool, a UML editor and a remote debugger. In the following, we will focus on the service development tool.

(a) Refined model hierarchy with separate upper/lower-layer PSM.

(b) Debugging support, model representation and transformation components.

Figure 3: Model representations and transformation in the Grid development tools.

In figure 3(a), the relationship between different model representations and the actual platform specific source code is shown. In a typical MDA approach, software architects start modeling an application in a Platform Independent Model (PIM), often by creating a UML model of the software (upper left corner), which can relatively easily be transformed into a Platform Specific Model (PSM). Actual source code carrying the application logic is often not fully generated from a pure model but rather attached to the structural model of the application and carried on through the different model transformations to the lower level model representations. As an alternative path from the platform independent model, an application may be annotated and used as the input to a transformation tool that generates a platform specific model for the Grid that can then be further transformed into the actual implementation of the Grid Service, carrying the original application logic into the Grid enabled implementation. The different components used to represent and transform models throughout the Grid development tools are shown in figure 3(b). Model transformations (MT) are used to transform the PIM to the upper layer PSM. The transformation from model to source code and from source code to model is done by distinct Code Emitters (CE) and Code Interpreters (CI). The latest additions to the GDT feature wizard-driven generation of a security descriptor (see fig. 4), and automatic generation of security code which is a key requirement for both scientific and commercial applications. As shown in the figure, almost all service security descriptor options, as described in section 3, can be set at this single wizard page, except custom policy decision points (PDPs, parts of the authorization chain) and per-operation security. The per-operation security is configured by adding additional parameters to each of the operation annotations. We do not support custom PDPs because they need additional specific configuration data and implementing classes. A developer with the capabilities to write custom PDPs should also be able to add this configuration to the service configuration himself.

Figure 4: GDT wizard for Service Security Descriptor Creation.

5.2

Certificate Request Creation Tool

The Certificate Request Creation Tool (CRCT) is used by the end user to generate a certificate request and to send the request to the administrator via e-mail (figure 5).

Figure 5: First page of the Certificate Request Creation Tool wizard. The user has to enter his/her Common Name (CN), Organizational Unit (OU), Organization (O). City/Locality (L) and Country (C). Furthermore, the user provides some Crypto Options such as the Key Length, Key Lifetime of the certificate and a Password. Given this information, a certificate request is generated, which can be sent to the administrator. The CRCT has been developed as a plugin for the Eclipse platform. CRCT guides the user through the processes of certificate request creation using a wizard. The wizard performs validity checks and offers pre-configured as well as recently used configurations via drop-down boxes.

5.3

Tool Support for Workflow Composition

The workflow composition tool has been implemented as a plugin for the Eclipse platform. It consists of three layers: the presentation layer, key core layer and the target system layer

Figure 6: Architecture of the BPEL editor (see fig. 6). The presentation layer displays workflows as directed graphs and allows for

drag-and-drop based modifications. It offers several wizards to assist the user in common tasks like, for instance, importing a Grid Service into the workflow which can then used as invocation target. The internal model is held at the core layer which also consists of event handlers and the collaboration component. The workflow collaboration implementation uses facilities provided by the Eclipse Communication Framework (ECF). In order to collaborate, the users of the process editor join a collaboration channel. The node of the collaboration initiator also acts as a coordinator. After joining the collaboration, a new editing partner requests the model from the channel. The initiating partner then serializes the model and transmits it to the newly joining party. The model is then deserialized and used as input for the graphical editor of the new collaboration partner. The underlying communication channel implements a protocol that ensures reliable message transmission to a selected partner or to all communication partners in the channel. Actual update of the distributed model happens by relay of the core layer edit commands upon their execution. The third layer transforms the internal model into valid BPEL code. Another wizard guides the user through this process and collects required deployment information. Fig. 7 shows a screenshot of the developed collaborative workflow composition tool.

Figure 7: Eclipse-based BPEL Editor

6

Related Work

The tools presented in this paper are based upon our previous work on the Grid Development Tools (GDT) [7] and complements them by security functionality. Nakamura et al. [13] and Satoh et al. [14] present a generic approach to define security requirements in service-oriented architectures. It is based on a Security Infrastructure Model (SIM) which holds security information of the underlying platform. An application developer annotates entities in the Platform Independent Model (PIM) using a security qualifier. The annotated PIM and the SIM are combined to generate a WS-Security [12] policy. Since this approach has a generic character, it does not regard subtleties of Grid computing. In particular, the generation of security descriptors for different Grid containers is ignored. The Global Grid Forum (http://www.ogf.org/) has announced the Configuration Description, Deployment, and Lifecycle Management (CDDLM) specification, which consists

of five parts [2, 8, 15, 11, 17]. The specification deals with the secure deployment, configuration, and lifecycle management of Grid Services. Secure service deployment is realized using a portal service and proven web service/Grid Service/XML security mechanisms. Hastings et al. [9] present a tool called Introduce which allows developers to create Grid Service stubs with security features. It does not provide code integration like GDT, so that one has to do the following three steps to develop a Grid Service: (1) Create the project with Introduce; (2) Add the generated files to a project of an IDE or use a text editor to modify the generated files (at least the Grid Service file); (3) Deploy the modified Grid Service with the tool. GDT fully integrates these three steps. Emmerich et. al [4] describe their experience with BPEL in Grid enviroments by means of a case study where they orchestrated Grid Services for the automation of a polymorph prediction application. They describe the reliability, performance and scalability of ActiveBPEL. They conclude that BPEL can be used as a workflow language for Grid Service orchestration and that the ActiveBPEL engine is robust and scales well. Slomiski [16] also investigates to which extend BPEL is feasible for the orchestration of WSRF and OGSI Grid Services. He concludes that BPEL is suitable for the Grid, but he mentiones some unsolved problems like handling large data (data streaming), monitoring and improved security models.

7

Conclusions

In this paper, we have motivated the need of tools for developing, configuring and composing Grid Services. The example from an engineering domain, namely metal casting, showed the importance of developing secure fine-grained Grid Services which can then be orchestrated into more complex applications. We presented GDT, a model-driven tool to develop Grid Services by simply annotating Java classes. Especially security-related features of GDT, such as the creation of service security descriptors, were described. CRCT, a tool to create certificate requests, was also introduced. Furthermore, we explained the need for a collaborative workflow composition tool. Our Eclipse-based implementation of such a tool was briefly described. One direction of future work is the improvement of GDT. At present, the only target platform is Globus Toolkit 4. Assistants for the semi-automatic wrapping of legacy code using Java Native Interface (JNI) is another topic of research. Currently, the BPEL enactment engine does not work with GSI. We are working on leveraging the functionalities of GSI for the ActiveBPEL engine. Furthermore, handling of large data and in particular streaming data (i.e. video data for media studies) is an important topic.

8

Acknowledgements

This work is financially supported by the German Federal Ministry of Education and Research (BMBF) (D-Grid Initiative, InGrid Project).

References [1] Tony Andrews, Francisco Curbera, Hitesh Dholakia, Yaron Goland, Johannes Klein, Frank Leymann, Kevin Liu, Dieter Roller, Doug Smith, Satish Thatte, Ivana Trickovic, and Sanjiva Weerawarana. Business Process Execution Language for Web Services Version 1.1. Microsoft, IBM, Siebel, BEA und SAP, 1.1 edition, May 2003. [2] D. Bell, T. Kojo, P. Goldsack, S. Loughran, D. Milojicic, S. Schaefer, J. Tatemura, and P. Toft. Configuration Description, Deployment, and Lifecycle Management (CDDLM) - Foundation Document, August 2005. [3] Tim D¨ornemann, Thomas Friese, Sergej Herdt, Ernst Juhnke, and Bernd Freisleben. Grid Workflow Modelling Using Grid-Specific BPEL Extensions. In Proceedings of German e-Science Conference 2007, 2007.

[4] Wolfgang Emmerich, Ben Butchart, Liang Chen, Bruno Wassermann, and Sarah L. Price. Grid Service Orchestration using the Business Process Execution Language. volume 3, pages 283–304, September 2005. [5] I. Foster, C. Kesselman, and S. Tuecke. The Anatomy of the Grid: Enabling Scalable Virtual Organizations. In International Journal of High Performance Computing Applications, volume 15, pages 200–222, 2001. [6] Thomas Friese, Smith Matthew, Bernd Freisleben, Julian Reichwald, Thomas Barth, and Manfred Grauer. Collaborative Grid Process Creation Support in an Engineering Domain. In Proc. of the International Conference on High Performance Computing, pages 263–276, 2006. [7] Thomas Friese, Matthew Smith, and Bernd Freisleben. GDT: A Toolkit for Grid Service Development. In Proceedings of the 3rd International Conference on Grid Service Engineering and Management, pages 131–148, 2006. [8] Patrick Goldsack. Configuration Description, Deployment,and Lifecycle Management (CDDLM) - SmartFrog-Based Language Specification, September 2005. [9] Shannon Hastings, Scott Oster, Stephen Langella, David Ervin, Tahsin Kurc, and Joel Saltz. Introduce: An Open Source Toolkit for Rapid Development of Strongly Typed Grid Services. In Journal of Grid Computing. Springer Netherlands, 2007. [10] John Hughes and Eve Maler. Technical Overview of the OASIS Security Assertion Markup Language (SAML) V1.1. http://www.oasisopen.org/committees/download.php/6837/sstc-saml-tech-overview-1.1-cd.pdf, May 2004. [11] S. Loughran. Configuration Description, Deployment, and Lifecycle Management (CDDLM) - Deployment API, March 2006. [12] A. Nadalin, C. Kaler, R. Monzillo, and P. Hallam-Baker. Web Services Security: SOAP Message Security 1.1, 2006. [13] Yuichi Nakamura, Michiaki Tatsubori, Takeshi Imamura, and Koichi Ono. ModelDriven Security Based on a Web Services Security Architecture. In Proceedings of the IEEE International Conference on Services Computing (SCC), pages 7–15, 2005. [14] Fumiko Satoh, Yuichi Nakamura, and Koichi Ono. Adding Authentication to Model Driven Security. In Proceedings of the International Conference on Web Services (ICWS), pages 585–594, 2006. [15] Stuart Schaefer. Configuration Description, Deployment, and Lifecycle Management - Component Model v1.0, March 2006. [16] Aleksander Slomiski. On Using BPEL Extensibility to Implement OGSI and WSRF Grid Workflows. Concurrency and Computation: Practice and Experience, 18(10):pages 1229–1241, 2006. [17] J. Tatemura. Configuration Description, Deployment,and Lifecycle Management (CDDLM) - Configuration Description Language (CDL) Specification, v1.0, August 2006.