368 research outputs found

    Distributed, parallel web service orchestration using XSLT

    Get PDF
    ©2005 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE.GridXSLT is an implementation of the XSLT programming language designed for distributed web service orchestration. Based on the functional semantics of the language, it compiles programs into dataflow graphs which can be efficiently executed across a collection of machines in a cluster or grid environment. Calls to web services can be made using the standard function call semantics provided by the language, and occur in parallel using the dataflow model of computation. The programmer is not required to explicitly specify the parallelism, as the details of how programs are scheduled and executed in a distributed environment are abstracted away by the run-time engine. XSLT provides a higher level programming model than many other approaches to web services composition; we explore its use here as a means of easing the task of orchestrating the interactions between services. In addition to the normal XSLT syntax, our system also supports programs written in XSLiTe, an alternative syntax we have developed which uses more concise representations of language constructs, increasing the ease of development, and bringing code readability closer to that of traditional programming languages. Our goal is to ease the construction of applications based on web services composition, such as those used in eScience and other fields in which service oriented architectures are prominent.Peter M. Kelly, Paul D. Coddington, Andrew L. Wendelbor

    Grid service orchestration using the Business Process Execution Language (BPEL)

    Get PDF
    Modern scientific applications often need to be distributed across grids. Increasingly applications rely on services, such as job submission, data transfer or data portal services. We refer to such services as grid services. While the invocation of grid services could be hard coded in theory, scientific users want to orchestrate service invocations more flexibly. In enterprise applications, the orchestration of web services is achieved using emerging orchestration standards, most notably the Business Process Execution Language (BPEL). We describe our experience in orchestrating scientific workflows using BPEL. We have gained this experience during an extensive case study that orchestrates grid services for the automation of a polymorph prediction application

    Compilation of XSLT into dataflow graphs for web service composition

    Get PDF
    Copyright © 2006 IEEEOur current research into programming models for parallel Web services composition is targeted at providing mechanisms for obtaining higher throughput for large scale compute and data intensive programs that delegate part of their computation to services, and making it easier to develop such applications. The ability to invoke multiple service calls at one time on different machines enables different portions of the program to be executed concurrently. We are addressing this through an implementation of an existing functional language, XSLT. Our implementation uses a dataflow execution model, and includes a compiler to build dataflow graphs from XSLT source code. This paper describes the execution model used to obtain parallelism and compose Web services, as well as the compilation process used to create the dataflow graphs. Our aim with this paper is to present the design of our system and demonstrate that XSLT provides a suitable model for distributed execution and parallel composition of Web services.Peter M. Kelly, Paul D. Coddington, and Andrew L. Wendelbor

    SOA based web service adaptation in enterprise application integration

    Get PDF
    Enterprise Application Integration (EAI) is a permanent need since various information systems are employed at companies. Numerous standard systems must be aligned to new business processes. There are participant systems older than 10 years, and others developed only 1-2 years ago. This implicates a wide technological variance making the integration problem a real challenging issue. The widespread of the Service Oriented Architecture (SOA) seems to be one of the most promising approaches in EAI. Although this is already supported by solid technology and tools, deploying executable processes, predicting and optimizing their non-functional performance is still an open issue. In this paper we propose a technological solution for the adaptation of standard enterprise services into SOA integration scenarios providing support for applying data transformation to bridge data incompatibilities. To evaluate our approach three other possible solutions are designed and implemented. An in detailed analytic and experimenta l comparison of the approaches is also presented

    XML Integrated Environment for Service-Oriented Data Management

    Get PDF
    The proliferation of XML as a family of related standards including a markup language (XML), formatting semantics (XSL style sheets), a linking syntax (XLINK), and appropriate data schema standards have emerged as a de facto standard for encoding and sharing data between various applications. XML is designed to be simple, easily parsed and self-describing. XML is based on and support the idea of separation of concerns: information content is separated from information rendering, and relationships between data elements are provided via simple nesting and references. As the XML content grows, the ability to handle schemaless XML documents becomes more critical as most XML documents do not have schema or Document Type Definitions (DTDs). In addition, XML content and XML tools are often required to be combined in effective ways for better performance and higher flexibility. In this research, we proposed XML Integrated Environment (XIE) which is a general-purpose service-oriented architecture for processing XML documents in a scalable and efficient fashion. The XIE supports a new software service model that provides a proper abstraction to describe a service and divide it into four components: structure, connection, interface and logic. We also proposed and implemented XIE Service Language (XIESL) that can capture the creation and maintenance of the XML processes and the data flow specified by the user and then orchestrates the interactions between different XIE services. Moreover, XIESL manages the complexity of XML processing by implementing an XML processing pipeline that enables better management, control, interpretation and presentation of the XML data even for non-professional users. The XML Integrated Environment is envisioned to revolutionize the way non-professional programmers see, work and manage their XML assets. It offers them powerful tools and constructs to fully utilize the XML processing power embedded in its unified framework and service-oriented architecture

    mREST Interface Specification

    Get PDF
    mREST is an implementation of the REST architecture specific to the management and sharing of data in a system of logical elements. The purpose of this document is to clearly define the mREST interface protocol. The interface protocol covers all of the interaction between mREST clients and mREST servers. System-level requirements are not specifically addressed. In an mREST system, there are typically some backend interfaces between a Logical System Element (LSE) and the associated hardware/software system. For example, a network camera LSE would have a backend interface to the camera itself. These interfaces are specific to each type of LSE and are not covered in this document. There are also frontend interfaces that may exist in certain mREST manager applications. For example, an electronic procedure execution application may have a specialized interface for configuring the procedures. This interface would be application specific and outside of this document scope. mREST is intended to be a generic protocol which can be used in a wide variety of applications. A few scenarios are discussed to provide additional clarity but, in general, application-specific implementations of mREST are not specifically addressed. In short, this document is intended to provide all of the information necessary for an application developer to create mREST interface agents. This includes both mREST clients (mREST manager applications) and mREST servers (logical system elements, or LSEs)

    Enforcing reputation constraints on business process workflows

    Get PDF
    The problem of trust in determining the flow of execution of business processes has been in the centre of research interst in the last decade as business processes become a de facto model of Internet-based commerce, particularly with the increasing popularity in Cloud computing. One of the main mea-sures of trust is reputation, where the quality of services as provided to their clients can be used as the main factor in calculating service and service provider reputation values. The work presented here contributes to the solving of this problem by defining a model for the calculation of service reputa-tion levels in a BPEL-based business workflow. These levels of reputation are then used to control the execution of the workflow based on service-level agreement constraints provided by the users of the workflow. The main contribution of the paper is to first present a formal meaning for BPEL processes, which is constrained by reputation requirements from the users, and then we demonstrate that these requirements can be enforced using a reference architecture with a case scenario from the domain of distributed map processing. Finally, the paper discusses the possible threats that can be launched on such an architecture

    Service Orchestration on a Heterogeneous Cloud Federation

    Get PDF
    During the last years, the cloud computing technology has emerged as a new way to obtain computing resources on demand in a very dynamic fashion and only paying for what you consume. Nowadays, there are several hosting providers which follow this approach, offering resources with different capabilities, prices and SLAs. Therefore, depending on the users' preferences and the application requirements, a resource provider can fit better with them than another one. In this paper, we present an architecture for federating clouds, aggregating resources from different providers, deciding which resources and providers are the best for the users' interests, and coordinating the application deployment in the selected resources giving to the user the impression that a single cloud is used
    • 

    corecore