Proposal of Adaptation of Legacy C/C++ Software to Grid Services

1. Proposal of Adaptation of Legacy C/C++ Softwareto Grid Services Bartosz Baliś, Marian Bubak,Michał Węgiel, Roland Wismüller Institute of Computer Science, AGH Kraków ACC CYFRONET AGH Technical University Munich

2. Outline • Migration to grid services technology and challenges involved • Grid environment requirements • The state of the art • The proposed architecture and its components • Scenarios: initialization, method invocation and destruction • Security, scalability and other aspects characteristic of grid computing • Project status and future work

3. Motivation and challenges • Legacy software • typically represents large-scale corporate investments that cannot be discarded • high-quality and validated programs • Cost-effective migration to grid services technology • without re-design, re-development and re-deployment of the existing software • tool-supported, semi-automated process • universal and systematic methodology

4. Grid requirements • Grid service • web service that provides a set of well-defined interfaces and that follows specific conventions • Extensions introduced by Open Grid Services Infrastructure • lifetime management (factories, explicit and soft-state destruction) • dynamic and stateful service instances (methods and attributes) • reliable and secure invocation (authentication and authorization)

5. The state of the art • Related work is present both in scientific and commercial settings • Lack of comprehensive solutions • Existing approaches • concentrate on web services technology • fail to satisfy grid services requirements • omit architectural considerations • introduce numerous limitations (inflexibility, insecurity etc.)

6. The proposed architecture three major components potentially in different locations backend host execution environment service client SOAP SOAP legacy code wrapper set of grid services any language C/C++/Fortran any language hides interaction with backend host encapsulates legacy interface

7. Components: service container hosting environment registry keeps track of backend hosts which registered to participate in computations one per service permanentservices factory proxy factory instance transient services proxy instance service inaccessible to client service accessible to client

8. Components: service container hosting environment responsible for creation of the corresponding instances one per service registry permanentservices factory proxy factory instance transient services proxy instance service inaccessible to client service accessible to client

9. Components: service container hosting environment directly called by client, provides externally visible functionality one per client registry permanentservices factory proxy factory instance transient services proxy instance service inaccessible to client service accessible to client

10. Components: service container hosting environment registry responsible for mediation between backend host and service client one per client permanentservices factory proxy factory instance transient services proxy instance service inaccessible to client service accessible to client

11. Components: backend host permanent process one per host backend host master process creates responsible for host registration and creation of slave processes slave process exploits legacy software

12. Components: backend host backend host master process creates transient process one per client slave process responsible for request translation and direct cooperation with legacy software exploits legacy software

13. Scenarios: initialization step 1 master process registers backend host and subscribes to notifications about the appearance of subsequent clients backend host service container client master process registry subscribes factory legacy software proxy factory

14. Scenarios: initialization step 2 client connects to factory in order to create new service instance for its exclusive usage backend host service container client master process registry invokes creates factory legacy software proxy factory instance

15. Scenarios: initialization step 3 upon creation service instance contacts proxy factory in order to create new proxy instance backend host service container client master process registry factory creates legacy software proxy factory invokes instance proxy instance

16. Scenarios: initialization step 4 service instance invokes registry which notifies one of the registered master processes about a pending client backend host service container client notifies master process registry factory invokes legacy software proxy factory instance proxy instance

17. Scenarios: initialization step 5 the selected master process creates slave process which subscribes to notifications about the client method calls backend host service container client creates master process registry slave process factory legacy software proxy factory instance subscribes proxy instance

18. Scenarios: method invocation step 1 client’s method call on the created instance is forwarded to the corresponding proxy instance backend host service container client master process registry slave process factory invokes legacy software proxy factory instance invokes proxy instance

19. Scenarios: method invocation step 2 proxy instance notifies the associated slave process of the method call and the underlying legacy code is invoked backend host service container client master process registry calls slave process factory legacy software proxy factory instance notifies proxy instance

20. Scenarios: method invocation step 3 slave process supplies the obtained results to proxy instance which enables the called method to return backend host service container client master process registry slave process factory legacy software proxy factory returns instance invokes proxy instance

21. Scenarios: destruction step 1 instance forwards destruction request to proxy instance which sends the appropriate notification to slave process backend host service container client master process registry explicit destruction request or instance lifetime expiry slave process factory legacy software proxy factory instance notifies invokes proxy instance

22. Scenarios: destruction step 2 slave process terminates its execution and instances are garbage collected by container shortly afterwards backend host service container client master process registry slave process factory legacy software proxy factory instance proxy instance

23. Security • Authentication • X.509 certificates:identity can be assigned both to users and hosts • Authorization • for external services (accessible to users) • based on user certificates • access granted to clients eligible to use a particular service • for internal services (inaccessible to users) • based on host certificates • access granted to machines eligible to register in the context of a particular service

24. Scalability • Actual processing is delegated to backend hosts • Service instances residing in the container do not consume excessive resources • Backend hosts volunteer to accept tasks only when their load is reasonable(automatic load balancing) • high responsiveness to temporal peaks in utilization (on demand computing) • support for resource reservation (quality of service)

25. Other features • No modifications of legacy code are required • Programs and libraries can remain where they were initially installed • No open ports on backend hosts are introduced since they act as service clients • Central administration: all services belonging to one VO can be hosted and managed in one place • Independence of particular hosting environment implementation

26. Other features • Flexible and dynamic configuration • processes are not bound to backend hosts • they can change their locations even during execution (job migration) • Delegated control • no need to check which host is ready and most suitable for a task at the specified point in time • robustness in case of configuration change or component failure • finer-grained participation policy

27. Project status and future work • As a proof of concept the presented solution was partially implemented • project: adaptation of OCM-G grid application monitoring system to grid services • used tools: gSOAP package, Globus Toolkit 3.0 • Future work • more test cases • performance measurement • development of tools faciliatating the usage of the proposed framework