DOCSLIB.ORG

Appendix 1 a Survey Ofproducts

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Appendix 1 a Survey Ofproducts Appendix 1 A Survey ofProducts We provide here a brief survey of products, based on the classification provided in Chapter 2 in the topic "Technology Architecture". We focus on middleware, and "go out" into development environments where applicable. Then we look at systems management. Components of the technology architecture that are not specific to the distributed application are mentioned in passing. Middleware SQL -based Middleware Standards Provides the transport for SQL calls and calls to stored procedures from the client. There are two basic approaches: • Embedded SQL (ESQL). ISO standard for embedding SQL in programming languages. Needs a precompiler; needs to know the target database at development time. • Call-level interfaces: API (Application Programming Interface). Calling program executes SQL at run time; no precompiler needed. De jure standard: SQL Access Group (SAG) CLI. De facto standard: • Microsoft ODBC (Open Database Connectivity): SAG CLI with extensions; • IDBC (Java Database Connectivity) is an emerging contender. Product Examples Call-level interfaces: ODBC, IDBC • ODBC: a Microsoft product, it enables access to different databases. Provides a call-level interface to the application (client). Supports a number of the popular databases (provides standard SQL plus specific extensions). However, support for some advanced features such as event triggering, coordination between different databases and switching between different access methods is questionable. 217 218 Distributed Applications Engineering • JDBC: a set ofJava classes that allows the connection ofJava code to relational databases. It includes support to connect to databases, and provides SQL operations on the data and metadata. There are four types ofJDBC drivers: • Type 1: JDBC-ODBC bridge, translates JDBC to ODBC calls • Type 2: Java to native API, converts JDBC calls into client API calls for a given database • Type 3: net protocol- all Java driver: • Type 4: native protocol- all Java driver Gateways: EDAlSQL, Open Client + Omni SQL Gateway • EDAlSQL: A product from Information Builders; provides an integrated data model comprising of different physical databases, in addition to ODBC type capabilities. Part of a suite of products that also offer transaction and messaging services. • Open Client + Omni SQL Gateway: from Sybase; similar to EDAlSQL; it offers vendor and location transparency. Translates Transact SQL to the relevant SQL dialect. Other:DRDA • DRDA: an IBM product; designed for data transfers between different "heavy duty" databases at the back end. Complementary to others. Pros and Cons ofSOL -based Middleware • Essentially SQL, so it ties calling programs to the particular SQL dialect. • It presents a two-tier image, since the calls are built and passed on to the server. With procedural SQL, however, it is possible to include some application capabilities at the server side. Product Sets Using SOL -based Middleware Oracle Cooperative Development Environment 2 Product ArchComp Comments Oracle CASE Application Upper CASE (data and process modelling) plus code development generation (Forms, Reports, SOL) Oracle Forms Application Main application development tool; both client and development server. Blocks of code "triggered" by events and forms events PUSOL Application Procedural Language (Ada-like); it packages SOL development statements. Execution of a statement block: the stored procedure (at server) may be called, packaged and submitted across the network, or executed locally at the client sending a DB call over the wire. SQL*NetV2 Integration Supports TCP/IP, DECNet, LU6.2, SPXlIPX, etc. service Mechanism that supports communication between client and server application components. Appendix 1: A Survey of Products 219 Oracle Transparent Integration Access to other databases Gateways service Oracle Call-level Integration Allows access to 3GLs, DCE tools, etc. Interfaces and Service precompilers Objects for OLE Integration New interfacing technology, supporting service multithreading and access of mUltiple databases. Supports OLE, Active X Oracle 7 Information See databases Oracle 8 management Sybase System 10 Product ArchComp Comments Client Application No specific product. Through Open Client API, enables development development access to a variety of client development tools Transact-SQL Application Sybase's language for DB access and stored development procedures (e.g. of Oracle's PUSQL) Open client Integration Provides an API for a number of client development service tools/environments Omni SQL Integration Gateways to a variety of relational DBs; converts Gateway + Open service Transact SQL to SQL of target DB. Through Open server server, provides access to non-relational M/F sources (CiCS/IMS applications) Connection Systems Management of the administration and security of the Manager management DB gateways SQL Server 10 Information See databases management Informix New Era Product ArchComp Comments Window Painter, Application Offers an object-oriented component-based New Era language, development application development environment. It uses a Application Builder database application 00 language. Web enabled, it supports OLE, Active X and Java code generation Inform ix-Net Integration Similar to SQL * Net; connects to Informix database service Connections to other DBs possible through ODBC or EDNSQL Informix Dynamic Information See databases On-Line Server management RPC-Type Middleware Standards DCE (Distributed Computing Environment): Developed by OSF, a consortium of vendors, it has been implemented on a major vendor environment - HP, DEC, IBM, etc. DCE is a standard, as well as a product. 220 Distributed Applications Engineering Product Examples DCE consists of a set of services, some or all of which can be used: • communication service: RPC; • naming service; • directory service; • security service; • time service; • distributed file service. DCE is open, standards-based, robust, suitable for complex, mission-critical applications. However, it has not had the anticipated take-up, arguably because its API contains approximately 600 calls and is difficult to learn and use. Native DCE does not support transactions. If transaction processing is needed, it is necessary to use a distributed transaction processing monitor, e.g. Encina, on top of DCE. Increasingly, other distributed computing products are using DCE services in their infrastructure, e.g., IBM's OLTP (On Line Transaction Processing) system CICS/6000 and DFS Web (DCE-based WWW security). DTP Monitors Like other middleware, DTP monitors provide the "glue" for communication between clients and servers in a distributed environment; in addition, they provide transactional integrity, server optimization and balancing. Therefore, they are useful for heavy operational processing systems that need to operate in a distributed fashion. Standards XlOpen's XT (between application and transaction monitor) and distributed transaction coordination XA (between transaction monitor and database) Product Examples • AT & T's Top End: AT & T (NCR) transaction processing for UNIX environments; • IBM CICS/6000: DTP in all IBM, plus HP-UX and Digital Unix environments; • Tuxedo: Developed by AT&T, now marketed by BEA. In addition to Tuxedo, BEA provides a suite of different types of middleware products; • Encina: DTP environment; flexible and feature rich. It is also complex; runs on top ofDCE; • ACMSxp: from Digital. An evolution from ACMS TP, it runs on top of DCE. It provides COBOL and C development platforms. DTP Monitors: Pros and Cons • Except perhaps for Encina, they offer an easier alternative to DCE for communication between distributed c1ients and servers. • Ensure transactional integrity, and offer access, location, and concurrency transparency. Appendix 1: A Survey of Products 221 • Support transactions in heterogeneous databases and two-phase commit protocol. • Offer program-to-program services, such as access and location, data representation, RPC, client/server connections. • Require APIs to client and server environments. Therefore, they usually work with a limited number platforms and products. • Good choice for heavy Transaction Processing environments and where transaction integrity and recovery are paramount. Object Brokers Standards • OMG (Object Management Group) CORBA: CORBA (Common Object Request Broker Architecture) is a standards specification by OMG, that specifies how distributed objects can work together. Unlike OSF's DCE, OMG did not develop technology, but left the implementation to vendors adhering to the standard. • CORBA 1.1 (1991): IDL and APIs for client and server objects within a specific ORB (Object Request Broker) implementation. Also, provision of static and dynamic invocation of remote methods. • CORBA 2.0 (1995): The CORBA 2.0 specification includes a mandatory protocol, Internet Inter-ORB Protocol (HOP), which is designed to enable objects and applications to interoperate over a network with other OMG CORBA 2.0 applications. It also includes support for languages other than C, asynchronous messaging, transactions, and interfaces to products such as Tuxedo, Encina, etc. Product Examples • Forte: Forte is an object-oriented development environment that automates the deployment of an application into a specific distributed environment. In the process, Forte partitions the application into desktop components and a set of server components, each of which can be re used by multiple applications. It is possible to manually override the default
Load more

Recommended publications
  • Derivation of the Required Elements for a Definition of the Term Middleware
    Rochester Institute of Technology RIT Scholar Works Theses 2002 Derivation of the required elements for a definition of the term middleware Maya Mathew Follow this and additional works at: https://scholarworks.rit.edu/theses Recommended Citation Mathew, Maya, "Derivation of the required elements for a definition of the term middleware" (2002). Thesis. Rochester Institute of Technology. Accessed from This Thesis is brought to you for free and open access by RIT Scholar Works. It has been accepted for inclusion in Theses by an authorized administrator of RIT Scholar Works. For more information, please contact [email protected]. Derivation of the Required Elements for a Definition of the Term Middleware By Maya Mathew Thesis submitted in partial fulfillment ofthe requirements for the degree ofMaster ofScience in Information Technology Rochester Institute ofTechnology B. Thomas Golisano College Of Computing and Information Sciences May 2002 - 1 - Rochester Institute of Technology B. Thomas Golisano College Of Computing and Information Sciences Master of Science in Information Technology Thesis Approval Form Student Name: Maya Mathew Thesis Title: Derivation of the Required Elements for a Definition of the Term Middleware Thesis Committee Name Signature Date Prof. William Stratton Chair Prof. Andy Phelps ?-/ z /qL-.-- Committee Member I I :-.P.:...::ro~f.~J~e;.:..:.ff...::L:.:::a.=..:sk~y ~ 17, d-fIoJ--. Committee Member ~ Thesis Reproduction Permission Form Rochester Institute of Technology B. Thomas Golisano College Of Computing and Information Sciences Derivation of the Required Elements For a Definition of the Term Middleware I, Maya Mathew, hereby grant permission to the Wallace Library of the Rochester Institute of Technology to reproduce my thesis in whole or in part.
    [Show full text]
  • Eeeeett., '1 H-{6'~-H~-4Ttf1ete
    ~eeeeett., '1 H-{6'~-H~-4ttf1ete ommission Delegation European C ~~;;~ street, NW ~ JANVIER 199 7 '1W&Shin.gton, DO 2 Message de Monsieur E. BRACKENIERS . 3 COMMUNICATIONS . 5 STB INFO ................................................ 7 INFORMATIONS DU CENTRE DE CALCUL ....................... 18 ARTICLES . Translation Centre for the bodies of the European Union ............... 21 . La signature électronique . 22 . SNet - les fondations ........................................ 26 . INTRANET- Application architectures ............................ 27 . INTRANET - Application development tools ........................ 35 . Migration "Nouvelle plate-forme technologique" en site pilote à la DI ...... 44 . D'autres questions/réponses sur le projet 11Next Technological Platform" ..... 46 . New information technologies applied to statistics .................... 49 . SDTvista - vos originaux, nos traductions, des références intéressantes ...... 52 . Chaîne des SIC Outils logistiques ................................ 57· ORGANISATION ........................................... 61 TABLEAUX DE BORD . Budget informatique . 64 . Ressources humaines . 65 . Projets d'infrastructure ....................................... 67 . Formation ................................................ 68 LISTE DES PRODUITS ....................................... 72 COMITES 1 GROUPES DE TRAVAIL ............................ 91 -' CALENDRIER ............................................. 92 ~,---------------------------------------------------------~ lj C.E. 1 Direction Informatique
    [Show full text]
  • Distributed Communication Methods and Role-Based Access Control For
    Distributed Communication Methods and Role*Based Access Controi for Use in Heaith Care Applications Joseph Poole John Barkley Kevin Brady Anthony Cincotta Wayne Salamon U.S. DEPARTMENT OF COMMERCE Technology Administration National Institute of Standards and Technology Gaithersburg, MD 20899 QC 100 .U56 NIST NO. 5820 1996 if 1 •t r i I i j •? f Distributed Communication Methods and Roie-Based Access Controi for Use in Health Care Appiications Joseph Poole John Barkley Kevin Brady Anthony Cincotta Wayne Salamon U.S. DEPARTMENT OF COMMERCE Technology Administration National Institute of Standards and Technology Gaithersburg, MD 20899 April 1996 U.S. DEPARTMENT OF COMMERCE Michael Kantor, Secretary TECHNOLOGY ADMINISTRATION Mary L. Good, Under Secretary for Technology NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY Arati Prabhakar, Director Abstract The use of software in the health care industry is becoming of increasing importance. One of the major roadblocks to efficient health care is the fact that important information is distributed across many sites. These sites can be located across a significant area. The problem is to provide a uniform mechanism to integrate this information. This paper documents the results of an investigation into the suitability of several different distributed access mechanisms. Five methods were examined: the Common Object Request Broker (CORBA), Object Linking and Embedding (OLE), remote procedure call (RPC), remote database access (SQL/RDA) and Protocol Independent Interfaces (PH, we specifically examined sockets). These mechanisms were compared with regard for use in health care applications. In particular, the following capabilities were compared: • Ease of use by the developer • Class of applications for which the technology is particularly effective in developing • Security capabilities • Protocols utilized • Performance of the transport mechanism.
    [Show full text]
  • Class and Objects in C++ 193–278
    OBJECT-ORIENTED PROGRAMMING C++ SIMPLIFIED OBJECT-ORIENTEDOBJECT-ORIENTED PROGRAMMINGPROGRAMMING C++C++ SIMPLIFIEDSIMPLIFIED By HARI MOHAN PANDEY Assistant Professor Computer Engineering Department NMIMS University Mumbai (Maharashtra) UNIVERSITY SCIENCE PRESS !N)MPRINTOF,AXMI0UBLICATIONS0VT,TD "E.'!,U2U ∑ #(%..!)∑ #/#(). ∑ '57!(!4) ∑ (9$%2!"!$ *!,!.$(!2∑ +/,+!4! ∑ ,5#+./7 ∑ -5-"!) ∑ 2!.#() ∑ NEW DELHI ).$)! 53! '(!.!∑ +%.9! OBJECT-ORIENTED PROGRAMMING C++ SIMPLIFIED © by Laxmi Publications (P) Ltd. All rights reserved including those of translation into other languages. In accordance with the Copyright (Amendment) Act, 2012, no part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording or otherwise. Any such act or scanning, uploading, and or electronic sharing of any part of this book without the permission of the publisher constitutes unlawful piracy and theft of the copyright holder’s intellectual property. If you would like to use material from the book (other than for review purposes), prior written permission must be obtained from the publishers. Typeset at ABRO Enterprises, Delhi First Edition: 2015 ISBN 978-93-81159-50-7 Limits of Liability/Disclaimer of Warranty: The publisher and the author make no representation or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties. The advice, strategies, and activities contained herein may not be suitable for every situation. In performing activities adult supervision must be sought. Likewise, common sense and care are essential to the conduct of any and all activities, whether described in this book or otherwise. Neither the publisher nor the author shall be liable or assumes any responsibility for any injuries or damages arising herefrom.
    [Show full text]
  • Teradata Call-Level Interface Version 2 Reference for Channel-Attached Systems
    Teradata Call-Level Interface Version 2 Reference for Channel-Attached Systems Release 13.10 B035-2417-020A February 2010 The product or products described in this book are licensed products of Teradata Corporation or its affiliates. Teradata, BYNET, DBC/1012, DecisionCast, DecisionFlow, DecisionPoint, Eye logo design, InfoWise, Meta Warehouse, MyCommerce, SeeChain, SeeCommerce, SeeRisk, Teradata Decision Experts, Teradata Source Experts, WebAnalyst, and You’ve Never Seen Your Business Like This Before are trademarks or registered trademarks of Teradata Corporation or its affiliates. Adaptec and SCSISelect are trademarks or registered trademarks of Adaptec, Inc. AMD Opteron and Opteron are trademarks of Advanced Micro Devices, Inc. BakBone and NetVault are trademarks or registered trademarks of BakBone Software, Inc. EMC, PowerPath, SRDF, and Symmetrix are registered trademarks of EMC Corporation. GoldenGate is a trademark of GoldenGate Software, Inc. Hewlett-Packard and HP are registered trademarks of Hewlett-Packard Company. Intel, Pentium, and XEON are registered trademarks of Intel Corporation. IBM, CICS, RACF, Tivoli, and z/OS are registered trademarks of International Business Machines Corporation. Linux is a registered trademark of Linus Torvalds. LSI and Engenio are registered trademarks of LSI Corporation. Microsoft, Active Directory, Windows, Windows NT, and Windows Server are registered trademarks of Microsoft Corporation in the United States and other countries. Novell and SUSE are registered trademarks of Novell, Inc., in the United States and other countries. QLogic and SANbox are trademarks or registered trademarks of QLogic Corporation. SAS and SAS/C are trademarks or registered trademarks of SAS Institute Inc. SPARC is a registered trademark of SPARC International, Inc. Sun Microsystems, Solaris, Sun, and Sun Java are trademarks or registered trademarks of Sun Microsystems, Inc., in the United States and other countries.
    [Show full text]
  • Database Administration Guide for SAP on IBM Db2 for Linux, UNIX, and Windows Company
    Administration Guide | PUBLIC Document Version: 2.5 – 2021-09-23 Database Administration Guide for SAP on IBM Db2 for Linux, UNIX, and Windows company. All rights reserved. All rights company. affiliate THE BEST RUN 2021 SAP SE or an SAP SE or an SAP SAP 2021 © Content 1 Introduction................................................................7 1.1 Document History............................................................ 8 1.2 Naming Conventions..........................................................10 2 Administration Tools and Tasks.................................................12 2.1 Administration Tools..........................................................12 2.2 Administration Tasks..........................................................13 3 Architectural Overview.......................................................16 3.1 SAP Application Server for ABAP.................................................16 3.2 SAP Application Server for Java..................................................17 3.3 Db2 Components............................................................18 3.4 Db2 Client Connectivity........................................................19 4 User Management and Security................................................ 21 4.1 SAP System Users and Groups...................................................21 Access Authorizations for Db2 Directories and Database-Related Files....................25 4.2 Role-Based Security Concept for Database Users..................................... 27 Database Roles for
    [Show full text]
  • Welcome to Discussion on Ingres Code Architecture
    Welcome to discussion on Ingres Code Architecture. In this presentation we will discuss the • Various components of Ingres database, • Their interrelationship and • Their code architecture. 1 To an Ingres user, an Ingres database stores and retrieves data based on an SQL query. For example here is a screen shot of Ingres Terminal monitor session connected to database testdb. Here we wish to retrieve the details of all employees in a company. We enter our SQL query <Click To Animate > “Select * from emp” The database server processes the query <Click to Animate> 2 We obtain the results of our query. To understand the code architecture of Ingres. <Click Here> let us examine how Ingres processes this query <Click Here> 3 1. The Query is processed by Global Communications facility which communicates the data and results between the terminal monitor to the DBMS server. <Click Here to Animate> 2. The DBMS server and its associated processes process the query and send the results to the client through GCF. <Click Here to Animate> 3. Broadly categorizing we can summarize the code into • User interface facilities • Connectivity and Communications • DBMS server • And Utility libraries to interact with Operating system. 1. Ingres has several kinds of user interface for example 1. Embedded SQL precompiler for programmatic operations of database. 2. Ingres applications like, SQL Terminal Monitor, Query by forms (QBF), Report by Forms (RBF), VISION etc. 3. We have Ingres Internet Commerce (ICE) for web deployment. These user interfaces and others can be commonly grouped as Front End for Ingres. • Similarly in connectivity tools we have • Java Database connectivity (JDBC) driver • Open Database connectivity driver (ODBC) driver • Dot Net Data provider • Open API a C api to Ingres etc.
    [Show full text]
  • Reassessing Client/Server Tools and Technologies Lawrence K
    Previous 4-04-40 Reassessing Client/Server Tools and Technologies Lawrence K. Cooper John S. Whetstone Payoff Client/server computing has not yet realized its promise of faster applications development, reduced maintenance costs, and enterprise scalability. This article's review of client/server technologies from the perspective of whether they cause developers to focus more on the tool than on the business problem helps IS and business managers appreciate what each technology can and cannot do. Understanding that client/server computing is more a concept than a technology is key to the proper evaluation of the tools and strategies flooding the marketplace. Introduction During the past 10 years, client/server architecture and technologies have been hailed as spelling the demise of the mainframe-centric view of computing. Corporations purchased PC by the truckload and bought myriad development tools, languages, and frameworks for developers and users alike. Products with descriptions such as GUI-builders, front ends, gateways, back ends, middleware, and glue flooded the client/server marketplace. Applications were supposed to be able to be developed faster and maintenance costs were supposed to decrease. Clearly this has not been the case: Client/server computing has proven to be both a boon and a bust. Although it provides more flexibility, it requires more computing resources, faster networks, and higher maintenance. According to a recent Gartner study, client/server computing costs often exceed mainframe-centric computing by up to 70%. Client/server computing also poses an abundance of data security problems. Current technologies are at a middle stage between the rigorous structures of mainframes and the total openness implicit in many of the new architectures.
    [Show full text]
  • The US Government's Open System Environment Profile OSE/1 Version
    C NIST Special Publication 500-21 Computer Systems APPLICATION PORTABILITY PROFILE Technology (APP) The U.S. Government's U.S. DEPARTMENT OF COMMERCE Technology Administration Open System Environment Profile National Institute of Standards and Technology OSE/1 Version 2.0 Nisr NAT L !NST."OF STAND i TECH R.I.C. llllllllllllllllllll NIST PUBLICATIONS AlllDM QEETfll APPLICA TION PORTABILITYPROFILE j)JT)) The U S. Government's ^ k^Open System Environment IL Profile OSE/1 Version 2.0 -QG 100 .U57 #500-210 1993 7he National Institute of Standards and Technology was established in 1988 by Congress to "assist industry in the development of technology . needed to improve product quality, to modernize manufacturing processes, to ensure product reliability . and to facilitate rapid commercialization ... of products based on new scientific discoveries." NIST, originally founded as the National Bureau of Standards in 1901, works to strengthen U.S. industry's competitiveness; advance science and engineering; and improve public health, safety, and the environment. One of the agency's basic functions is to develop, maintain, and retain custody of the national standards of measurement, and provide the means and methods for comparing standards used in science, engineering, manufacturing, commerce, industry, and education with the standards adopted or recognized by the Federal Government. As an agency of the U.S. Commerce Department's Technology Administration, NIST conducts basic and applied research in the physical sciences and engineering and performs related services. The Institute does generic and precompetitive work on new and advanced technologies. NIST's research facilities are located at Gaithersburg, MD 20899, and at Boulder, CO 80303.
    [Show full text]
  • MLS DBMS Interoperability Study*
    MLS DBMS Interoperability Study* Rae K. Burns, AGCS, Inc. Yi-Fang Koh, Raytheon Electronic Systems ESC/AXS, Building 1704, Hanscom AFB, MA 01731 burns/[email protected] Interoperability among heterogeneous databases is a fundamental requirement of many emerging Department of Defense (DoD) systems. Often these systems also have requirements for Multilevel-Secure (MLS) operation, where data is labeled to reflect its sensitivity level (e.g., UNCLASSIFIED, SECRET, etc.). The Air Force Rome Laboratory MLS Database Management System (DBMS) Interoperability Study has surveyed the available Commercial- Off-The-Shelf (COTS) products supporting interoperability and tested several of them in a multilevel environment. We selected representative products and implemented test scenarios in the ESC/AXS Security Products Transition Analysis Facility (STAF). Our test environment included three commercial MLS DBMS products (Trusted ORACLE7, Informix Online/Secure, and Sybase Secure SQL Server) on several different MLS Operating System (OS) platforms. We also employed “system high” platforms running standard versions of the DBMS and OS products. We successfully moved data to and from the MLS databases using different COTS interoperability solutions. This paper describes our testing efforts and summarizes the lessons learned. 1. Introduction The Multilevel Secure Database Management System Interoperability Study was initiated by Air Force Rome Laboratory to expedite the transition of trusted database technology into operational Air Force C4I environments. The overall goal of the study is twofold: 1) To examine the theoretical basis for heterogeneous trusted database interoperability, identify issues, and transition findings to the communities involved in future development (vendors, DoD users, and applicable standards groups). 2) To develop demonstrable examples of database interoperability that illustrate the advantages of MLS DBMS products in support of Air Force operational requirements for multilevel security.
    [Show full text]
  • Dr. Douglas Craig Schmidt
    Dr. Douglas Craig Schmidt Cornelius Vanderbilt Professor of Engineering [email protected] Department of Electrical Engineering & Computer Science (TEL) 615-294-9573 Vanderbilt University (FAX) 615-343-7440 Nashville, TN 37203 (WEB) www.dre.vanderbilt.edu/∼schmidt/ Educational Background • Ph.D. Computer Science, summer 1994, University of California, Irvine Dissertation: \An Object-Oriented Framework for Experimenting with Alternative Process Archi- tectures for Parallelizing Communication Subsystems." Co-advisors: Dr. Tatsuya Suda and Dr. Richard W. Selby. • M.S. Computer Science, summer 1990, University of California, Irvine, specializing in software engineering. • M.A. Sociology, summer 1986, College of William and Mary, Williamsburg, Virginia Thesis: \A Statistical Analysis of University Resource Allocation Policies." Advisor: Dr. Michael A. Faia. • B.A. Sociology, summer 1984, College of William and Mary, Williamsburg, Virginia. Professional Experience 1. 7/1/18 { present: Associate Provost of Research Development and Technologies Develop cohesive and sustainable information technology (IT) services to advance research and scholarship across Vanderbilt's ten schools and colleges; develop scalable storage and processing solutions by leveraging on-campus and cloud data storage services, as well as creating big data research cores and core-related services; and implement NIST 800-171 compliant IT services. 2. 8/1/18 { present: Co-Director of the Vanderbilt Data Science Institute Facilitate highly innovative research and education initiatives that build on Vanderbilt University's current strengths, promote new collaborations, and establish a cohesive institutional framework that embraces Vanderbilt's diverse campus, while establishing the university as a leader in data science research and education. 3. 2/17 { present: Cornelius Vanderbilt Professor of Engineering Received an endowed chair in recognition of my scholarship, intellect, and leadership in the field of computer science and computer engineering.
    [Show full text]
  • Embedded SQL Precompiling Embedded SQL Call Level Interface
    Embedded SQL Call level interface (CLI) Extract from C program: An application programming interface (API), i.e.itprovides a set of EXEC SQL BEGIN DECLARE SECTION; function calls. short DEPT, DNO; In the SQL standards wor ld, ‘‘CLI’’means ‘‘not Embedded SQL’’ char NAME[26]; EXEC SQL END DECLARE SECTION; (which is also referred to as and API). main() •aclean separation between the application programand SQL. { GetInput(&DEPT); EXEC SQL DECLARE C1 CURSOR FOR •building a programissimpler ; no preprocessor (although calls to SELECT ENAME, DEPTNO FROM EMP WHERE DEPTNO = :DEPT; the DBMS runtime librar y are the same). EXEC SQL OPEN C1 while (SQLCODE == 0) { EXEC SQL FETCH C1 INTO :NAME, :DNO •debugging is simpler;you debug your own code rather than code } generated byaprecompiler. EXEC SQL CLOSE C1 } Precompilers from different vendors will produce different code. Graham Kemp,University of Aberdeen Graham Kemp,University of Aberdeen Precompiling Embedded SQL Programming models for relational systems The precompiler and DBMS interact in severalways: What if wewant to change the DBMS that our application uses? Embedded SQL •The DBMS parser checks the syntax of the SQL statements. Requires compiling application programusing newDBMS vendor’s precompiler.Wemight not have the source code (e.g. ‘‘shr ink- •The DMBS checks the semantics of the SQL statements (table wrapped’’applications). and column names are correct, data types of host language variables are correct, etc.) Vendor-specific API Requires changing the source code to use the newDBMS vendor’s •Ifthe SQL statements are OK, optimise them to produce an API, and recompiling with the newDBMS vendor’slibrar ies.Again, access plan, which is stored in the database.
    [Show full text]