99 research outputs found

    Security mechanisms for legacy code applications in GT3 environment

    Get PDF
    There are many legacy code applications that cannot be run in Grid environment without significant modifications. To avoid re-engineering of legacy code, we developed the Grid Execution Management for Legacy Code Architecture (GEMLCA) that enables deployment of legacy code applications as Grid services. GEMLCA is an OGSI Grid service layer that supports submitting jobs, getting their results and status back. Security requirements are essential to any Grid application to preserve the confidentiality and integrity of data. To meet these requirements the GT3 security model was implemented in GEMLCA. The paper introduces GEMLCA and how Grid Security Infrastructure (GSI) components have been added to GEMLCA in order to enable secure execution of jobs in Grid. The paper also presents how a legacy code traffic simulator was transformed into a Grid service using GEMLCA and gives some simulation results

    Two ways to Grid: the contribution of Open Grid Services Architecture (OGSA) mechanisms to service-centric and resource-centric lifecycles

    Get PDF
    Service Oriented Architectures (SOAs) support service lifecycle tasks, including Development, Deployment, Discovery and Use. We observe that there are two disparate ways to use Grid SOAs such as the Open Grid Services Architecture (OGSA) as exemplified in the Globus Toolkit (GT3/4). One is a traditional enterprise SOA use where end-user services are developed, deployed and resourced behind firewalls, for use by external consumers: a service-centric (or ‘first-order’) approach. The other supports end-user development, deployment, and resourcing of applications across organizations via the use of execution and resource management services: A Resource-centric (or ‘second-order’) approach. We analyze and compare the two approaches using a combination of empirical experiments and an architectural evaluation methodology (scenario, mechanism, and quality attributes) to reveal common and distinct strengths and weaknesses. The impact of potential improvements (which are likely to be manifested by GT4) is estimated, and opportunities for alternative architectures and technologies explored. We conclude by investigating if the two approaches can be converged or combined, and if they are compatible on shared resources

    Automatic deployment of interoperable legacy code services

    Get PDF
    The Grid Execution Management for Legacy Code Architecture (GEMLCA) enables exposing legacy applications as Grid services without re-engineering the code, or even requiring access to the source files. The integration of current GT3 and GT4 based GEMLCA implementations with the P-GRADE Grid portal allows the creation, execution and visualisation of complex Grid workflows composed of legacy and nonlegacy components. However, the deployment of legacy codes and mapping their execution to Grid resources is currently done manually. This paper outlines how GEMLCA can be extended with automatic service deployment, brokering, and information system support. A conceptual architecture for an Automatic Deployment Service (ADS) and for an x-Service Interoperability Layer (XSILA) are introduced explaining how these mechanisms support desired features in future releases of GEMLCA

    Performance impact of the grid middleware

    Get PDF
    The Open Grid Services Architecture (OGSA) defines a new vision of the Grid based on the use of Web Services (Grid Services). The standard interfaces, behaviors and schemes that are consistent with the OGSA specification are defined by the Open Grid Service Infrastructure (OGSI). Grid Services, as an extension of the Web Services, run on top of rich execution frameworks that make them accessible and interoperable with other applications. Two examples of these frameworks are Sun’s J2EE platform and Microsoft’s .NET. The Globus Project implements the OGSI Specification for the J2EE framework in the Globus Toolkit. As any J2EE application, the performance of the Globus Toolkit is constrained by the performance obtained by the J2EE execution stack This performance can be influenced by many points of the execution stack: operating system, JVM, middleware or the same grid service, without forgetting the processing overheads related to the parsing of the communication protocols. In the scope of this chapter, all this levels together will be referred to as the grid middleware. In order to avoid the grid middleware to become a performance bottleneck for a distributed grid-enabled application, grid nodes have to be tuned for an efficient execution of I/O intensive applications because they can receive a high volume of requests every second and have to deal with a big amount of invocations, message parsing operations and a continuous task of marshaling and unmarshalling service parameters. All the parameters of the system affecting these operations have to be tuned according with the expected system load intensity. A Grid node is connected to to other nodes through a network connection which is also a decisive factor to obtain a high performance for a grid application. If the inter-node data transmission time overlaps completely the processing time for a computational task, the benefits of the grid architecture will be lost. Additionally, in many situations the content exchanged between grid nodes can be considered confidential and should be protected from curious sights. But the cost of data encryption/decryption can be an important performance weak that must be taken into account. In this chapter we will study the process of receiving and executing a Grid job from the perspective of the underlying levels existing below the Grid application. We will analyze the different performance parameters that can influence in the performance of the Grid middleware and will show the general schema of tasks involved in the service of an execution request.Postprint (author’s final draft

    Analysis of current middleware used in peer-to-peer and grid implementations for enhancement by catallactic mechanisms

    Get PDF
    This deliverable describes the work done in task 3.1, Middleware analysis: Analysis of current middleware used in peer-to-peer and grid implementations for enhancement by catallactic mechanisms from work package 3, Middleware Implementation. The document is divided in four parts: The introduction with application scenarios and middleware requirements, Catnets middleware architecture, evaluation of existing middleware toolkits, and conclusions. -- Die Arbeit definiert Anforderungen an Grid und Peer-to-Peer Middleware Architekturen und analysiert diese auf ihre Eignung fĂŒr die prototypische Umsetzung der Katallaxie. Eine Middleware-Architektur fĂŒr die Umsetzung der Katallaxie in Application Layer Netzwerken wird vorgestellt.Grid Computing

    The Lattice Project: A Multi-model Grid Computing System

    Get PDF
    This thesis presents The Lattice Project, a system that combines multiple models of Grid computing. Grid computing is a paradigm for leveraging multiple distributed computational resources to solve fundamental scientific problems that require large amounts of computation. The system combines the traditional Service model of Grid computing with the Desktop model of Grid computing, and is thus capable of utilizing diverse resources such as institutional desktop computers, dedicated computing clusters, and machines volunteered by the general public to advance science. The production Grid system includes a fully-featured user interface, support for a large number of popular scientific applications, a robust Grid-level scheduler, and novel enhancements such as a Grid-wide file caching scheme. A substantial amount of scientific research has already been completed using The Lattice Project

    Proof-of-Concept Application - Annual Report Year 1

    Get PDF
    In this document the Cat-COVITE Application for use in the CATNETS Project is introduced and motivated. Furthermore an introduction to the catallactic middleware and Web Services Agreement (WS-Agreement) concepts is given as a basis for the future work. Requirements for the application of Cat-COVITE with in catallactic systems are analysed. Finally the integration of the Cat-COVITE application and the catallactic middleware is described. --Grid Computing
    • 

    corecore