Collaborative Grid Process Creation Support in an ... - CiteSeerX

Collaborative Grid Process Creation Support in an Engineering Domain Thomas Friese1 , Matthew Smith1 , Bernd Freisleben1 Julian Reichwald2 , Thomas Barth2 , Manfred Grauer2 1

2

Dept. of Mathematics and Computer Science, University of Marburg Hans-Meerwein-Str., D-35032 Marburg, Germany {friese,matthew,freisleb}@informatik.uni-marburg.de Information Systems Institute, Faculty of Economics, University of Siegen H¨ olderlinstr. 3, D-57068 Siegen, Germany {reichwald,barth,grauer}@fb5.uni-siegen.de

Abstract. The software development process for many real-world applications requires many experts from different domains to cooperate. This is especially true for applications which are to be deployed in a distributed and heterogeneous environment such as the service-oriented Grid. In this paper, we present a collaborative synchronized Grid process creation environment for the service-oriented Grid, in which experts from different engineering and IT domains can interactively work on a single application process model, to quickly and efficiently design applications spanning multiple problem domains. An example application from the engineering domain of metal forming is presented and the enabling technologies are discussed.

1

Introduction

Service-oriented Grid computing has gained tremendous interest in various application domains. Many of those applications stem from an academic environment and have traditionally been designed as monolithic solutions that are hard to adapt, even to slight changes in the application requirements. Required adaptations must be implemented by programmers specialized both in Grid middleware and the applications. The paradigm shift to service-orientation in Grid middleware opens the possibility 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. We see two main reasons for this slow adoption: On the one hand, the inherent complexity of current service-oriented Grid middleware systems is still prohibitive for everyday use by an application domain expert who has no background in middleware development, Grid computing or even computer science. On the other hand, an engineering solution to a concrete problem is often a team effort undertaken by a number of involved engineers, and other

non-IT personnel. Current support for collaborative software development is often limited to the use of CVS, email and conference calls. Such methods offer only limited support to ease the entry of engineers not trained in formal software development processes into the Grid. The Business Process Execution Language for Web Services (BPEL) [16] has gained much attention and broad adoption for composition of component based business applications. The focus of the BPEL language is to enable the composition of basic web services into more complex applications. Its popularity in the business application domain makes BPEL very promising and interesting for process creation in the Grid domain, since many process execution, management and creation tools are expected to be developed in the future or are even currently under development. In this paper, we present an engineering application from the domain of metal forming and discuss how a novel collaborative Grid process creation environment is used to support engineers in their Grid application development process. The resulting process representation of the engineering Grid application is executed by a Grid enabled BPEL process execution engine. The visualization of the process in our distributed process editor helps to bridge the gap between Grid application developers and domain experts by allowing them to interactively refine the target application from a high level perspective down to the actual executable code. A Grid extension to the BPEL language is proposed and implemented to facilitate easy parallel execution of BPEL tasks in the Grid. The term process is used in four different connotations throughout this paper. First, the actual collaboration of engineers to solve a given engineering problem is referred to as the engineering process. This paper describes a tool to support the software development process that leads to the creation of a Grid application. This Grid application is based on a process description, referred to as a Grid process. The Grid process describes the orchestration of basic component services into a more complex application. Finally, the actual activities during the production of a cast metal part are referred to as casting process. The paper is organized as follows. After an overview of related work in section 2, a sample scenario from an engineering domain (casting as a sub-domain of metal forming) is introduced in 3. The design and implementation of a collaborative Grid process editor that supports the software development process for Grid experts and domain experts is presented in section 4. Section 5 describes the collaborative development of the Grid application for the metal casting sample scenario. Section 6 concludes the paper and outlines areas for future work.

2

Related Work

Supporting business processes with software systems and especially serviceoriented architectures realized with web services have received considerable attention in both academia and industry. Several other research projects try to cope with similar subjects in related fields.

The Geodise project [24, 20] focuses on optimization, design and fluid dynamics, especially in aerodynamics. Its main goal is to provide a distributed problem solving environment (PSE) for engineers working in the mentioned fields by utilizing e.g. MATLAB and adding Grid functionality to it. Although first Geodise implementations were based on the Globus Toolkit version 2, the core Geodise Toolbox is now part of the managed program of the Open Middleware Infrastructure Institute (OMII) [17]. A Grid-enabled problem solving environment for engineering design where distributed parties are able to collaborate has been introduced by Goodyer et al. [11]. The system makes use of the gViz Library [4] which allows collaborative visualization on the Grid and provides the user to start Grid jobs on Globus Toolkit based hosts. The main focus is put on collaborative application steering and result visualization of given simulation problems. The P-GRADE Portal [18] aims to be a workflow-oriented computational Grid portal, where multiple clients can collaboratively participate in design, development and execution of a workflow, and multiple Grids may be incorporated in the workflow execution. The P-GRADE Portal is based on the Globus Toolkit version 2 for file transfer operations and job execution, the workflow execution is done by a proprietary implementation. P-GRADE neither uses Grid service and business process standards such as BPEL, nor does the proposed collaborative editing approach support real time collaboration on a process in an on-line meeting style. The GridNexus Project [5] is a GUI for workflow creation based on Ptolemy II and JXPL, a XML scripting language based on Lisp, which it uses as a Grid foundation. It allows a very fine grained algorithm design (right down to the arithmetic operations) to be integrated with Grid service interactions, raising the complexity of the resulting workflow. GridNexus does not allow the collaborative creation of workflows nor does it support business standards such as BPEL. The mentioned software systems are examples for the large variety of problem solving environments, collaborative Grid application systems and collaborative workflow development systems. However, none of the mentioned systems provides both a problem solving environment for engineering problems as well as sophisticated support for the collaborative software development process for Grid applications and their execution in a service-oriented Grid environment. Collaboration support often relies on out-of-band collaboration and synchronization techniques such as exchanging e-mail or CVS like server based communication.

3

Sample 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 process of a Grid software system for engineering applications. The concrete use case comes from 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. For more information regarding the complexity

involved in collaborative engineering particularly in the field of metal forming and casting, the reader is referred to e.g. [15, 23]. 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 simulationbased 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. Both 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. 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 sumarize, 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) – 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 requirements lead to a software platform which enables the integration of the aforementioned competencies and resources during the software design process. Since most of the possible users of simulation in the casting industry are small to medium enterprises (SME), lacking at least one of the requirements, the Grid software platform must be able to facilitate both renting computational resources on demand as well as the collaborative involvement of Grid experts, casting engineers and their customers. As a concrete sample scenario, we introduce the engineering process of collaborative development of a metal casting model. From a software development point of view, the Grid relevant development cycle starts with a problem definition, expressed by the casting engineer and progresses through some iterations of model definition, simulation and refinement. The given problem definition is then modeled as an initial casting process model by a numerical simulation expert. Usually, this expert is located in another company due to the already

mentioned lack of personnel or know-how in small and medium engineering enterprises. 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 numerically simulated. The results must be reviewed and compared to knowledge about real casting processes held by the casting engineer. If this first simulation run does not match reality, the model needs to be calibrated and further model variants are created by the simulation expert and the casting engineer. 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. In the next section, we will introduce a tool to support the different actors in collaboration during the software development process for the final Grid application allowing them to perform their engineering process for a concrete casting process model. This development process brings together domain experts from different engineering domains and IT experts from the Grid domain.

4

Collaborative Grid Process Creation Support

The main goal for a tool that supports collaborative Grid process creation is to enable developers with only limited expertise in distributed application development or programming for the Grid to create applications. Ideally, it should enable domain experts without a computer science background to construct applications as solutions to their domain specific problems that utilize the available Grid resources. In our example descibed above, it is the Grid application supporting the engineering process by providing distributed simulation and optimization functionality. In the service-oriented Grid, the application consists of Grid services as the basic components and a process description defining their orchestration to provide functionality for numerical simulation and optimization. In the sample application, the casting engineer, the numerical simulation expert and the Grid expert are the parties who collaborate to create the required Grid process. The two engineering domain experts define and discuss a high level application flow before involving the Grid expert who identifies and implements the necessary Grid components and adapts the high level process definition to the pecularities of the Grid.

4.1

Design of the Grid Process Editor

Two main considerations drive the design of our proposed Grid process editor as a tool supporting fast development of Grid application from a high level perspective: It should provide 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). Furthermore, a Grid process editor should foster collaboration among experts in a distributed environment. Ideally, it should support synchronized collaborative work (i.e. same-time, different-place collaboration [8]) on the process under development, building on the underlying communication infrastructure. The overall design of our Grid process editor is based on a model driven approach. Figure 1(a) shows a conceptual overview of the core components of the collaborative Grid process editor. A core model that can be shared among networked nodes is used to represent a concrete process that in turn is presented to the user through a view component with a corresponding controller, allowing for editing operations. A target system mapping defines the transition into actually executable code for a concrete process execution environment. The model sharing component propagates changes of the model to other editors currently acting on the same shared model. This model sharing component must also be able to lock the process model to prevent local modification when a distributed coordination protocol requires this locking operation.

(a) Design overview showing the component and layer separation.

(b) Internal dependencies between target system mapping (TSM), core model and presentation contributions.

Fig. 1. Overall design of the collaborative process editor.

The field of process execution for the Grid is a rapidly evolving field. Currently, there is no standard for the expressive power of the core process models that everyone agrees upon. This lack of a common standard and the greater flexibility in implementing new constructs lead to the choice of the internal design

shown in figure 1(b). We chose the BPEL language for the core process standard since there is currently no Grid process execution standard but BPEL is the defacto standard in the business process execution environment. Implementations of a process execution target system may extend the core model and provide their contributions to the model and view components corresponding to their newly introduced constructs. 4.2

Implementation of the Grid Process Editor

The previously introduced overall design has been used to implement a graphical process editor for the Globus Toolkit 4 based MAGE [21] platform. The implementation of this process editor is based on the Eclipse Graphical Editing Framework (GEF) [10] for the presentation layer and the Eclipse Communication Framework (ECF) [9] for the model sharing component. Core Model. There are three basic types of elements in the core process model. The base class of every model element is the class Element. Two direct descendants of this base class are ContainerElement and Connection. Containers may directly contain other model elements. An example for such a container is the Sequence class that represents a BPEL sequence of activities. Sub-classes of the connection class are used to represent links between activities in the process, such as the links between activities in a BPEL Flow (a flow is not ordered like a sequence but a collection of activities that are executed based on transition conditions). A globally unique ID [13] is assigned to every element in the process model, allowing to uniquely identify the elements even across different nodes sharing a single process model through the model sharing component. Conceptually, every element of the process model represents a collection of attributes. The Element class implements the IPropertySource interface allowing the Eclipse platform to directly display the attribute values of a selected model element in the standard property view. The root element of every proces model based on this meta-model implementation is an instance of the Process class. Every model element implements the IPropertySource interface. It defines operations to retrieve a list of IPropertyDescriptors and access methods to set the value of a particular property or to get a property value from the model element. As a means of selectively displaying certain element properties, the core process model allows to select a set of filter rules on the model instance. Before returning the result list in the implementation of the getPropertyDescriptors operation, the list is filtered by a PropertyVisibilityFilter filter that removes every property descriptor defined in the exclusion list defined for the element. The property access methods of the element still provide access to filtered attributes, allowing wizards that automate tasks for the user full access to every element and property of the process model. The model needs to be serialized and deserialized for storage and transmission. Serialization of the model elements is handled by proxy classes that implement the serialization capability for the core model elements. The proxy classes

handle storage of the model elements, therefore, they are referred to as storage proxies. Every storage proxy instance holds a reference to an associated model object. A storage proxy instance for a concrete instance of a model element can be obtained from a factory that receives the model element object in the proxy creation request and constructs or returns the associated proxy instance. Storage proxies for child objects of a container model element are constructed recursively. The default implementation of the storage proxy elements implement the methods toDOMElement and fromDOMElement in the IStorageProxy interface. These methods return or interpret a tree of XML elements representing the elements and connections in the process model. The structure of the resulting XML elements and attributes is governed by the concrete implementation of the IStorageProxy instances returned by the proxy factory. Similar to the regular serialization implementation for simple storage of the process model, a concrete target system mapping implementation may perform serialization of the model into the required process representation by providing another proxy factory. The basic serialization implementations queries all elements for their unfiltered properties and serializes them into attributes and child elements, enabling storage and retrieval of the complete model information. Target System Mapping. A target system mapping for the MAGE process execution environment has been implemented as a second set of storage proxies with a corresponding factory. This MAGE process execution engine is based on the ActiveBPEL [1] engine and introduces additional Grid specific concepts such as a Grid-For-Each (GFE) construct. This construct supports the very common case of carrying out a number of calculations on a separation of the input parameter domain. It encapsulates discovery of computational resources, splitting of input parameters, collecting and merging of execution results. Contributions to the core BPEL model, view and controller components of the process editor have been implemented to represent the Grid specific extensions supported by the MAGE process execution engine. The storage proxy implementation for the process model element in the MAGE target system mapping handles creation of all necessary process descriptions, deployment descriptors and WSDL artifacts needed for the process execution engine. The GFE enables non-Grid experts to easily model the parallel execution of tasks in the Grid, since it hides the complexity of discovering nodes, deploying the services, splitting the parameter range and executing the services. The engineers only need to configure the GFE to a certain parameter range and define the single node process, the rest is done by the MAGE process execution environment. Providing such high level constructs representing complex yet common tasks in the Grid is a vital step towards enabling the use of the Grid for non-Grid experts. Presentation Layer. The process editor contributes an implementation of a graphical editor as its presentation layer implementation. Its purpose is to provide a graphical representation of the process model to the user that visualizes

the process structure and lets the user add, remove and rearrange components, connect them and edit the properties associated with the process activities and other elements. Visualization of the process model elements is handled by corresponding view elements, editing of the underlying model is performed by edit parts associated with the model elements. The Eclipse platform abstracts the source of an operation as a request, actual modification of the model elements is then performed by a Command retrieved from the target edit part. During an editing operation, the edit part also displays feedback (such as drag handles for move and resize operations) through the view elements to the user. Edit parts do not handle editing directly, rather they delegate editing to edit policies associated with the part. Before returning a command or signaling approval to an edit request, the core model is queried for any edit locks set on the model by the model sharing component. An Eclipse workbench window shows a so called perspective that is a collection of multiple views on the workspace of the user or currently selected elements. The process editor uses the properties view in addition to the graphical representation of the process model. The properties of a particular model element are accessible to the user through a tree that allows editing of the individual properties. The set of visible properties is determined by the previously described view filters. Every view on a model element is updated if a property change occurs due to a user interaction or a change received from the model sharing component. This mechanism automatically integrates with the property view provided by the Eclipse platform. Additionally, a property visibility filtering mechanism has been implemented for the editor. This allows to adjust the level of detail in the view presented to different groups of users. Model Sharing. The model sharing implementation of the process editor uses facilities provided by the Eclipse Communication Framework (ECF) [9]. In order to collaborate, the users of the process editor join a collaboration channel (access protection to the channel may be set up by the collaboration initiator). The node of the collaboration initiator also acts as a coordinator to the collaboration. 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 edit commands upon their execution. For this purpose, every command is derived from a BaseCommand class that triggers serialization of the command and transmission to other connected editors in its execute method, if the editor is connected to a channel. Every command implementation is required to call its super classes execute method to ensure

transmission of the command. Every command implements the IAdaptable interface and returns a serializable and transmissible version of the command to the model sharing component that transmits the command to other editors in the channel. References to model elements are encoded using the globally unique identifier of the element. This model sharing enables the different actors in the application design, development and usage phases to collaboratively work on the same process model, each editing the model part which belongs to their area of expertise, while at the same time being able to look at the big picture and get instant feedback from colleagues.

5

Collaborative Development of the Sample Application

As a first step towards the optimization process, the casting engineer and numerical simulation expert join a collaborative process design session using the distributed process editor described above. The distributed process editor allows users to join the collaboration and create, delete, connect and move basic activities concurrently. This interaction may be augmented by audio or videoconferencing giving the participants an on-line meeting room environment for their collaborative work. Figure 2(a) shows a snapshot of the distributed process editor with the minimal core process for the Grid application being worked on. The ability to concurrently edit the process model is a critical element in the overall development process since communication difficulties between the different experts can be quickly identified and solved. As stated before, they rely on cooperation to apply their combined expertise to design an application that can support the engineering process in a satisfactory manner. After finishing an initial sketch of the ideal application workflow from their domain perspective, they involve a Grid expert to help them adapt their process to the Grid environment and identify the necessary component services for their Grid process. The Grid expert will introduce infrastructural requirements such as service discovery and infrastructure management into the purely application oriented workflow of the domain experts. As a result of this second step, a process for the Grid application and the specification of the required component services can be used by the Grid expert to implement or select the basic components. A basic skeleton implementation of the required services can be automatically generated using a model driven service generator [19, 22] leading to fast availability of the component services. For the metal casting sample application, the following two services were identified and implemented: The Distributed Polytop Service. This service is an implementation of the distributed polytop optimization algorithm [2] (DPA) which belongs to the class of direct search methods. It has its roots in the Complex algorithm [3], a predecessor of the Nelder-Mead Simplex [14]. The DPA was designed regarding efficiency and scalability in distributed systems.

(a) Screenshot of the graphical distributed process editor window displaying the metal casting process.

(b) Visualization window showing a simplified model of a casted gas turbine blade.

Fig. 2. Development and application environment: distributed process editor and engineering application.

During its runtime, it requires an a priori unknown number of evaluations of both an objective function and corresponding constraint functions, in this case calculated by the metal casting simulation software CASTS [12]. The service has to save its state each time an evaluation request occurs, and it passes the data set which is to be evaluated to the process execution engine instead of directly invoking the simulation service. Considering these conditions, the service was implemented by utilizing the Web Service Resource Framework (WSRF 3 ), which allows the creation of stateful web service resources. Apart from a service operation which allows a client to set necessary parameters needed by the polytop algorithm, the only Grid service operation iterate(IterateRequest) takes care of starting and restarting the algorithm at the appropriate position - according to its internal state and according to the input data inside the IterateRequest data structure. A resulting data set is returned immediately after invoking the operation, telling the process execution engine if further evaluations are needed or if the polytop algorithm reached a predefined stop condition. The Casts Service. The main purpose of this service is to wrap the metal casting legacy software CASTS as a Grid service. However, the Casts Service does not only provide a service-wrapped version of CASTS, but it also takes care of the following operations: It is capable of modifying the input model of the casting process according to a set of parameters passed to the service. This parameter set is the input received from the distributed polytop algorithm.The service executes the CASTS legacy application on a number of different execu3

http://www.globus.org/wsrf/

tion platforms. In this case, a 128 node cluster computer with two 64Bit AMD Opteron CPUs and 2GB main memory per node was utilized, leading the execution subsystem to incorporate the local resource manager Torque [7] and the scheduling system Maui [6]. The execution state of a cluster job is monitored and exposed by the Casts Service. The execution subsystem is highly modularized so that the service also works on single workstations without local queuing/scheduling. The service also provides functionality to evaluate the simulation result (which is done by CritCASTS, a legacy software system bundled with CASTS) and determining the objective function value as well as the constraint function values. Utilization of WS-GRAM 4 for running CASTS jobs in a Grid service wrapped command line was inappropriate due to the complexity of the internal tasks of the Casts Service. The chosen approach of a custom wrapper service exposes the necessary information and results much cleaner to the process execution engine. Using WS-GRAM would have required to create a sophisticated shell script as a CASTS wrapper and the inclusion of logic in the Grid application process for parsing the output of WS-GRAM, which truly belongs into the Casts Service. The concurrent execution of many simulations has been modeled using the Grid-For-Each construct, a Grid specific extension of the BPEL language. The GFE construct neatly encapsulates details of the concurrent execution in the simulation tasks, keeping middleware complexity from the domain experts. An overall view of this collaborative and distributed development scenario is shown in figure 3. The grey zones mark the network domains of the different experts, they are geographically distributed, and their collaboration takes place via the shared and synchronized process model. The distributed collaborative process editor allows them to synchronously edit the model and directly see the operations of other connected partners.

6

Conclusions

In this paper, we introduced a collaborative process creation environment in which experts from different engineering and IT domains can interactively work on a single synchronized Grid process model, to quickly and efficiently design complex applications spanning multiple problem domains. We demonstrated the feasibility of our approach using an engineering application for metal casting. A new BPEL construct the Grid-For-Each (GFE) was used to facilitate the adoption of Grid computing in the engineering community. The GFE can be used to transparently split an input value set into distinct parameter ranges, distribute processing jobs over multiple Grid nodes and then collect and merge the results. The application process is executed by a Grid enabled BPEL process execution engine, which takes care of most of the Grid specific operations required to execute an application in the Grid. The visualization of the application process in our distributed process editor helps to bridge the gap between Grid application 4

http://www.globus.org/toolkit/docs/4.0/execution/wsgram/

Fig. 3. Overview of the collaborative process creation scenario for the metal casting application.

developers and domain experts by allowing them to interactively refine the target application from a high level perspective down to the actual executable code. The resulting process model is very flexible allowing a standard application core to be easily adopted to new problems, which is a common requirement in the engineering field. Future work includes the extension of the collaborative process creation environment by further BPEL constructs to ease the distributed application development and include utilities and wizards to further speed up the time to market for legacy applications. Furthermore, the integration of a video conferencing software into the platform would also increase the productivity of the development environment without having to rely on external video conferencing solutions.

Acknowledgements This work is partially supported by the German Ministry of Education and Research (BMBF) (D-Grid Initiative, In-Grid Project), Siemens AG (Corporate Technology, M¨ unchen) and IBM (Eclipse Innovation Grant). We would like to thank J¨ urgen Jakumeit of ACCESS Materials + Processes for his involvement in the design process of the Grid Casts application.

References 1. ActiveBPEL, LLC. ActiveBPEL - BPEL Execution Engine. http://www. activebpel.org. 2. T. Barth. Verteilte L¨ osungsans¨ atze f¨ ur simulations-basierte Optimierungsprobleme. Wissenschaftlicher Verlag Berlin, 2001. 3. M. Box. A New Method of Constrained Optimization and a Comparison with Other Methods. Computer Journal, 8:42–52, 1965.

4. K. Brodlie, D. Duce, J. Gallop, M. Sagar, J. Walton, and J. Wood. Visualization in Grid Computing Environments. Proceedings of IEEE Visualization, pages 155–162, 2004. 5. J. L. Brown, C. S. Ferner, T. C. Hudson, A. E. Stapleton, R. J. Vetter, T. Carland, A. Martin, J. Martin, A. Rawls, W. J. Shipman, and M. Wood. GridNexus: A Grid Services Scientific Workflow System. International Journal of Computer Information Science, 6:72–82, 2005. 6. clusterresources.com. Maui Cluster Scheduler. http://www.clusterresources. com/pages/products/maui-cluster-scheduler.php. 7. clusterresources.com. Torque Resource Manager. http://www.clusterresources. com/pages/products/torque-resource-manager.php. 8. F. Cosquer, P. Ver´ıssimo, S. Krakowiak, and L. Decloedt. Support for Distributed CSCW Applications. In Distributed Systems, volume 1752, pages 295–326. Springer, 2000. 9. eclipse.org. Eclipse Communication Framework (ECF). http://www.eclipse. org/ecf. 10. eclipse.org. Graphical Editing Framework. http://www.eclipse.org/gef. 11. C. Goodyer, M. Berzins, P. Jimack, and L. Scales. A Grid-Enabled Problem Solving Environment for Parallel Computational Engineering Design . Advances in Engineering Software, 37:439–449, 2006. 12. G. Laschet, J. Neises, and I. Steinbach. Micro-Macrosimulation of Casting Processes. 4ieme ´ecole d’´et´e de Mod´elisation num´erique en thermique, 1998. 13. P. Leach, M. Mealling, and R. Salz. A Universally Unique IDentifier (UUID) URN Namespace. IETF RFC 4122, 2005. http://www.ietf.org/rfc/rfc4122.txt. 14. J. Nelder and R. Mead. A Simplex Method for Function Minimization. Computer Journal, 7:308–311, 1965. 15. T. Nguyen and V. Selmin. Collaborative Multidisciplinary Design in Virtual Environments. In Proceedings of the 10th International Conference on CSCW in Design., pages 420–425, Nanjing, China, 2006. 16. Oasis WSBPEL TC. Web Services Business Process Execution Language Version 2.0 - draft, December 2005. 17. omii.ac.uk. Open Middleware Infrastructure Institute (OMII). http://www.omii. ac.uk/. 18. G. Sipos and P. Kacsuk. Collaborative Workflow Editing in the P-GRADE. Proceedings of the MicroCAD, 2005. 19. M. Smith, T. Friese, and B. Freisleben. Model Driven Development of ServiceOriented Grid Applications. In Proc. of the International Conference on Internet and Web Applications and Services, pages 139–146, Guadeloupe, 2006. IEEE Press. 20. W. Song, Y.-S. Ong, H.-K. Ng, A. Keane, S. Cox, and B. Lee. A Service-Oriented Approach for Aerodynamic Shape Optimization Across Institutional Boundaries. Proceedings of ICARCV, 2004. 21. The Distributed Systems Group, Univ. of Marburg, Germany. The Marburg Ad Hoc Grid Envrionment - MAGE. http://ds.informatik.uni-marburg.de/MAGE. 22. The Distributed Systems Group, University of Marburg, Germany. Grid Development Tools for Eclipse. http://ds.informatik.uni-marburg.de/MAGE/gdt. 23. S. Woyak, H. Kim, J. Mullins, and J. Sobieszczanski-Sobieski. A Web Centric Architecture for Deploying Multi-Disciplinary Engineering Design Processes. In Proceedings of the 10th AIAA/ISSMO Multidisciplinary Analysis and Optimization Conference, Albany, New York, USA, 2004. 24. G. Xue, W. Song, S. Cox, and A. Keane. Numerical Optimization as Grid Services for Engineering Design. Journal of Grid Computing, 2(3):223–238, 2004.