DOCSLIB.ORG

Scripting Openwsman Server Plugins

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Scripting Openwsman Server Plugins November 17-21, 2008, Santa Clara Marriott, Santa Clara, CA Scripting Openwsman server plugins Klaus Kämpf <[email protected]> Motivation • Management instrumentation is not sexy • CIM learning curve • Writing CIM providers is complex Easy remote access to services 2 Instrumentation wishlist • Single protocol • Single daemon • Single open port • Firewall friendly • Easy to code • Interoperable 3 Properties of WS-Management • Management of Resources – Universal resource identifiers • Generic semantics on resources • Transport interface • There's more than just WS-CIM openwsman • Open source implementation of WS- Management • Client and Server • Server architecture is plugin based • Includes (WS-)CIM plugin openwsman plugins • Plugins handle resources • Resources are accessed by their universal resource identifier (URI) • URI = namespace + classname + keys • namespace + class prefix identify plugin • Plugins provide endpoints for resource operations Openwsman Architecture HTTP Server openwsmand Listen Authorize Dispatch Endpoints Endpoints WS-Enumeration InvokeEndpoints Enumerate Identify Pull Release WS-Transfer Create WS-Eventing Delete Subscribe Get Unsubscribe Put Renew 7 Plugins • Simple C interface • See my MDC2007 presentation “Web Service Management Application Enablement” • Goal: Write plugins in scripting language 8 Motivation • Make the developers life easier • Scripting language – Edit-Run vs. Edit-Compile-Link-Run • Use the tools best fitted to the task • Drastically reduce code size • Let developers focus on instrumentation • Leverage dynamic scripting languages • Portability 9 Design goals • Support most popular scripting languages – Python, Ruby, Perl, ... • Object orientation – Reduce parameters – Leverage exceptions • Reuse openwsman client bindings – Add server bindings • Consistent API – Similar code across scripting languages 10 How it was done • Use a code generator (SWIG) • Reuse of generic code • Similar 'look&feel' across languages • Small language dependent layer SWIG Simplified Wrapper and Interface Generator SWIG SWIG is an interface compiler that connects programs written in C and C++ with scripting languages such as Perl, Python, Ruby, and more. SWIG: Motivation • Building more powerful C/C++ programs • Portability • Make C libraries 'object oriented' • Rapid prototyping and debugging • Systems integration • Construction of scripting language extension modules SWIG: About • Homepage: http://www.swig.org • Available for – Linux – Unix (AIX, HP-UX, Solaris, ...) – Macintosh OS-X/Darwin – Windows 95/98/NT/2000/XP/Vista • History Initially started in July, 1995 at Los Alamos National Laboratory. First alpha release: February, 1996. Latest release: April 7, 2008. SWIG-1.3.35 • Active development 3-4 releases per year SWIG: Languages Allegro Common Lisp CFFI (Common Lisp) CLisp Octave Chicken (Scheme) MzScheme SWIG – How does it work ? wsman.h C header SWIG – How does it work ? wsman.h C header %module wsman wsman.i %include "wsman.h" Interface description SWIG – How does it work ? cmpi.h SWIG C header cmpi.i Interface description SWIG – How does it work ? wsman.h SWIG C header wsman_wrap.c Binding code wsman.i Interface description wsman.py (Python code) SWIG – How does it work ? wsman.h SWIG C header wsman_wrap.c Binding code wsman.i Interface description Compiler wsman.py (Python code) wsman_wrap.so Target language module SWIG - Usage Example: Python test.py import pywsman SWIG - Usage Example: Python test.py pywsman.py import pywsman SWIG - Usage Example: Python test.py pywsman.py wsman_wrap.so import pywsman SWIG - Usage Example: Python test.py pywsman.py wsman_wrap.so import pywsman client = Client(“http://localhost”) options = ClientOptions() doc = client.identify( options ) Result • Target language module • Access to openwsman data structures • Access to openwsman manipulation functions • Data wrappers ( C <-> target language) • Missing: openwsman plugin API swig-plugin.c • Manually crafted plugin interface • Supports all endpoint functions • Target language agnostic • Converts C data to target language • Calls target language • Status handling Building bridges wsman.h SWIG C header wsman_wrap.c swig-plugin.c Binding code wsman.i Interface description Compiler wsman.py (Python code) wsman_wrap.so Target language module + openwsman plugin API Plugin endpoint example static int Swig_Enumerate_EP( WsContextH cntx, WsEnumerateInfo* enumInfo, WsmanStatus *status, void *opaqueData ) { Target_Type _context, _enumInfo; Target_Type _status; int rc; _context = SWIG_NewPointerObj((void*) cntx, SWIGTYPE_p__WS_CONTEXT, OWN); _enumInfo = SWIG_NewPointerObj((void*) enumInfo, SWIGTYPE_p___WsEnumerateInfo, OWN); _status = SWIG_NewPointerObj((void*) status, SWIGTYPE_p__WsmanStatus, OWN); rc = TargetCall(cntx->indoc, _TARGET_MODULE, "enumerate", 3, _context, _enumInfo, _status ); return rc; } target_$lang.c • Target language specific layer • Very thin – TargetInitialize(...) – TargetCall(...) – TargetCleanup(...) • Loads/Unloads target interpreter • Loads endpoint implementation • Calls endpoint implementation Code size • swig-plugin.c: 1225 lines • target_python.c: 491 lines • target_ruby.c: 401 lines • Easy to maintain • Easy to extend Implementation example • Enumerate (Ruby) def enumerate context, enum_info, status selectors = context.selectors results = compute( selectors ) # compute enumeration result enum_info.index = 0; enum_info.total_items = results.size enum_info.enum_results = results enum_info.enum_context = self true # success ! end Implementation example (cont.) • Pull (Ruby) def self.pull context, enum_info, status if enum_info.index < enum_info.total_items then # create SOAP response out_doc = context.indoc.create_response_envelope body = out_doc.body # Construct WS-Enumeration pull response response = body.add(XML_NS_ENUMERATION, WSENUM_PULL_RESP) response = response.add(XML_NS_ENUMERATION, WSENUM_ITEMS) # resource representation response.add(enum_info.result[enum_info.index].to_xml) enum_info.pull_result = out_doc return true end end Status • Beta quality – Code available through openwsman svn • Ruby as first choice – Author is a Python illiterate • Need other languages ? – Please give feedback (or code) Outlook • Documentation • Improve openwsman plugin API • Finish Python backend References • Openwsman – http://www.openwsman.org • Swig plugin source – http://www.openwsman.org/trac/browser/openws man/trunk/src/plugins/swig • Swig – http://www.swig.org Thank you ! Questions ?.
Load more

Recommended publications
  • The Machine That Builds Itself: How the Strengths of Lisp Family
    Khomtchouk et al. OPINION NOTE The Machine that Builds Itself: How the Strengths of Lisp Family Languages Facilitate Building Complex and Flexible Bioinformatic Models Bohdan B. Khomtchouk1*, Edmund Weitz2 and Claes Wahlestedt1 *Correspondence: [email protected] Abstract 1Center for Therapeutic Innovation and Department of We address the need for expanding the presence of the Lisp family of Psychiatry and Behavioral programming languages in bioinformatics and computational biology research. Sciences, University of Miami Languages of this family, like Common Lisp, Scheme, or Clojure, facilitate the Miller School of Medicine, 1120 NW 14th ST, Miami, FL, USA creation of powerful and flexible software models that are required for complex 33136 and rapidly evolving domains like biology. We will point out several important key Full list of author information is features that distinguish languages of the Lisp family from other programming available at the end of the article languages and we will explain how these features can aid researchers in becoming more productive and creating better code. We will also show how these features make these languages ideal tools for artificial intelligence and machine learning applications. We will specifically stress the advantages of domain-specific languages (DSL): languages which are specialized to a particular area and thus not only facilitate easier research problem formulation, but also aid in the establishment of standards and best programming practices as applied to the specific research field at hand. DSLs are particularly easy to build in Common Lisp, the most comprehensive Lisp dialect, which is commonly referred to as the “programmable programming language.” We are convinced that Lisp grants programmers unprecedented power to build increasingly sophisticated artificial intelligence systems that may ultimately transform machine learning and AI research in bioinformatics and computational biology.
    [Show full text]
  • Omnipresent and Low-Overhead Application Debugging
    Omnipresent and low-overhead application debugging Robert Strandh [email protected] LaBRI, University of Bordeaux Talence, France ABSTRACT application programmers as opposed to system programmers. The state of the art in application debugging in free Common The difference, in the context of this paper, is that the tech- Lisp implementations leaves much to be desired. In many niques that we suggest are not adapted to debugging the cases, only a backtrace inspector is provided, allowing the system itself, such as the compiler. Instead, throughout this application programmer to examine the control stack when paper, we assume that, as far as the application programmer an unhandled error is signaled. Most such implementations do is concerned, the semantics of the code generated by the not allow the programmer to set breakpoints (unconditional compiler corresponds to that of the source code. or conditional), nor to step the program after it has stopped. In this paper, we are mainly concerned with Common Furthermore, even debugging tools such as tracing or man- Lisp [1] implementations distributed as so-called FLOSS, i.e., ually calling break are typically very limited in that they do \Free, Libre, and Open Source Software". While some such not allow the programmer to trace or break in important sys- implementations are excellent in terms of the quality of the tem functions such as make-instance or shared-initialize, code that the compiler generates, most leave much to be simply because these tools impact all callers, including those desired when it comes to debugging tools available to the of the system itself, such as the compiler.
    [Show full text]
  • Allegro CL User Guide
    Allegro CL User Guide Volume 1 (of 2) version 4.3 March, 1996 Copyright and other notices: This is revision 6 of this manual. This manual has Franz Inc. document number D-U-00-000-01-60320-1-6. Copyright 1985-1996 by Franz Inc. All rights reserved. No part of this pub- lication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means electronic, mechanical, by photocopying or recording, or otherwise, without the prior and explicit written permission of Franz incorpo- rated. Restricted rights legend: Use, duplication, and disclosure by the United States Government are subject to Restricted Rights for Commercial Software devel- oped at private expense as specified in DOD FAR 52.227-7013 (c) (1) (ii). Allegro CL and Allegro Composer are registered trademarks of Franz Inc. Allegro Common Windows, Allegro Presto, Allegro Runtime, and Allegro Matrix are trademarks of Franz inc. Unix is a trademark of AT&T. The Allegro CL software as provided may contain material copyright Xerox Corp. and the Open Systems Foundation. All such material is used and distrib- uted with permission. Other, uncopyrighted material originally developed at MIT and at CMU is also included. Appendix B is a reproduction of chapters 5 and 6 of The Art of the Metaobject Protocol by G. Kiczales, J. des Rivieres, and D. Bobrow. All this material is used with permission and we thank the authors and their publishers for letting us reproduce their material. Contents Volume 1 Preface 1 Introduction 1.1 The language 1-1 1.2 History 1-1 1.3 Format
    [Show full text]
  • S Allegro Common Lisp Foreign Function Interface
    Please do not remove this page Extensions to the Franz, Inc.'s Allegro Common Lisp foreign function interface Keane, John https://scholarship.libraries.rutgers.edu/discovery/delivery/01RUT_INST:ResearchRepository/12643408560004646?l#13643533500004646 Keane, J. (1996). Extensions to the Franz, Inc.’s Allegro Common Lisp foreign function interface. Rutgers University. https://doi.org/10.7282/t3-pqns-7h57 This work is protected by copyright. You are free to use this resource, with proper attribution, for research and educational purposes. Other uses, such as reproduction or publication, may require the permission of the copyright holder. Downloaded On 2021/09/29 22:58:32 -0400 Extensions to the Franz Incs Allegro Common Lisp Foreign Function Interface John Keane Department of Computer Science Rutgers University New Brunswick NJ keanecsrutgersedu January Abstract As provided by Franz Inc the foreign function interface of Allegro Com mon Lisp has a number of limitations This pap er describ es extensions to the interface that facilitate the inclusion of C and Fortran co de into Common Lisp systems In particular these extensions make it easy to utilize libraries of numerical subroutines such as those from Numerical Recip es in C from within ACL including those routines that take functions as arguments A mechanism for creating Lisplike dynamic runtime closures for C routines is also describ ed Acknowledgments The research presented in this do cument is supp orted in part by NASA grants NCC and NAG This research is also part of the Rutgers based
    [Show full text]
  • Threading and GUI Issues for R
    Threading and GUI Issues for R Luke Tierney School of Statistics University of Minnesota March 5, 2001 Contents 1 Introduction 2 2 Concurrency and Parallelism 2 3 Concurrency and Dynamic State 3 3.1 Options Settings . 3 3.2 User Defined Options . 5 3.3 Devices and Par Settings . 5 3.4 Standard Connections . 6 3.5 The Context Stack . 6 3.5.1 Synchronization . 6 4 GUI Events And Blocking IO 6 4.1 UNIX Issues . 7 4.2 Win32 Issues . 7 4.3 Classic MacOS Issues . 8 4.4 Implementations To Consider . 8 4.5 A Note On Java . 8 4.6 A Strategy for GUI/IO Management . 9 4.7 A Sample Implementation . 9 5 Threads and GUI’s 10 6 Threading Design Space 11 6.1 Parallelism Through HL Threads: The MXM Options . 12 6.2 Light-Weight Threads: The XMX Options . 12 6.3 Multiple OS Threads Running One At A Time: MSS . 14 6.4 Variations on OS Threads . 14 6.5 SMS or MXS: Which To Choose? . 14 7 Light-Weight Thread Implementation 14 1 March 5, 2001 2 8 Other Issues 15 8.1 High-Level GUI Interfaces . 16 8.2 High-Level Thread Interfaces . 16 8.3 High-Level Streams Interfaces . 16 8.4 Completely Random Stuff . 16 1 Introduction This document collects some random thoughts on runtime issues relating to concurrency, threads, GUI’s and the like. Some of this is extracted from recent R-core email threads. I’ve tried to provide lots of references that might be of use.
    [Show full text]
  • Il Ne Voyageait Pas, Il Décrivait Une Circonférence. C'était Un
    Il ne voyageait pas, il décrivait une circonférence. C’était un corps grave, parcourant une orbite autour du globe terrestre, suivant les lois de la méchanique rationelle. – Jules Verne The mind is its own place and in itself, can make a Heaven of Hell, a Hell of Heaven. – John Milton University of Alberta Automated Planning and Player Modelling for Interactive Storytelling by Alejandro Ramirez Sanabria A thesis submitted to the Faculty of Graduate Studies and Research in partial fulfillment of the requirements for the degree of Master of Science Department of Computing Science c Alejandro Ramirez Sanabria Fall 2013 Edmonton, Alberta Permission is hereby granted to the University of Alberta Libraries to reproduce single copies of this thesis and to lend or sell such copies for private, scholarly or scientific research purposes only. Where the thesis is converted to, or otherwise made available in digital form, the University of Alberta will advise potential users of the thesis of these terms. The author reserves all other publication and other rights in association with the copyright in the thesis and, except as herein before provided, neither the thesis nor any substantial portion thereof may be printed or otherwise reproduced in any material form whatsoever without the author’s prior written permission. To Fran, my family, and my closest friends: words have not yet been crafted to express the feelings of admiration and gratitude I hold dear in my heart for you. Abstract Interactive Storytelling (IS) acknowledges that people want to be participants in the unfolding of a story plot. Given the complex nature of IS, Artificial Intelligence (AI) methods can be called upon to improve and enhance interactive stories in video games.
    [Show full text]
  • Analysis of a Web User Interface for Mathematics: Experiences with Integral Queries for TILU (Table of Integrals Look Up)
    Analysis of a Web User Interface for Mathematics: Experiences with Integral Queries for TILU (Table of Integrals Look Up) Richard Fateman Timothy James Computer Science Division University of California, Berkeley Abstract became an important priority. Other “web design” is- sues included making the instructions more prominent. What can we learn from the range of over 7000 queries made to TILU, a symbolic integration problem-solving server [1] The need to make the design and implementation more • during the course of more than two years? We have saved robust: The underlying program was written as an all queries during this experiment, and based on our analy- experiment. Putting it into production uncovered a sis, and experimented with improvements in the computer- variety of typographical errors, blunders, and loose human interaction components of our web server. We be- ends. Even after making the program relatively secure lieve our experience will be useful in the design of similar against unsyntactic input, it took more effort to make servers that require human input of mathematics. the program relatively robust against web communi- cation problems. For errors related to browser con- nections, we now record such problems but return the 1 Introduction program to a standard state. Previously we had es- TILU1[2] serviced 7363 queries from the date it started run- tablished the practice of accumulating suspended light- ning through January 26, 19982 6995 of these queries were weight processes for debugging. We would run out of successful, meaning TILU gave back an answer as opposed the processes since we began to leave the system run- to stalling without a response.
    [Show full text]
  • Omnipresent and Low-Overhead Application Debugging
    Omnipresent and low-overhead application debugging Robert Strandh [email protected] LaBRI, University of Bordeaux Talence, France ABSTRACT application programmers as opposed to system programmers. The state of the art in application debugging in free Common The difference, in the context of this paper, is that the tech- Lisp implementations leaves much to be desired. In many niques that we suggest are not adapted to debugging the cases, only a backtrace inspector is provided, allowing the system itself, such as the compiler. Instead, throughout this application programmer to examine the control stack when paper, we assume that, as far as the application programmer an unhandled error is signaled. Most such implementations do is concerned, the semantics of the code generated by the not allow the programmer to set breakpoints (unconditional compiler corresponds to that of the source code. or conditional), or step the program after it has stopped. In this paper, we are mainly concerned with Common Furthermore, even debugging tools such as tracing or man- Lisp [1] implementations distributed as so-called FLOSS, i.e., ually calling break are typically very limited in that they do \Free, Libre, and Open Source Software". While some such not allow the programmer to trace or break in important sys- implementations are excellent in terms of the quality of the tem functions such as make-instance or shared-initialize, code that the compiler generates, most leave much to be simply because these tools impact all callers including those desired when it comes to debugging tools available to the of the system itself such as the compiler.
    [Show full text]
  • Franz Allegro Common Lisp Meets Demand for High Performance Artificial Intelligence in Big Data Applications
    Franz’s Gruff Produces Dynamic Visual Discovery for Graph Analytics Gruff and AllegroGraph Power Visual Graph Search and Visual Query Building for Banking, Healthcare, Pharma Discovery and Security Applications OAKLAND, Calif. — November 2, 2015 — Franz Inc., an early innovator in Artificial Intelligence (AI) and leading supplier of Semantic Graph Database technology, today announced Gruff v6.0, the industry’s leading Graph Visualization software for exploring and discovering connections within data. Gruff provides novice users and graph experts the ability to visually build queries and visualize connections between data without writing code, which speeds discovery and enhances the ability to uncover hidden connections within data. “Gruff allows for easy viewing of graph style data and provides an easy on-ramp for non-technical users to explore connections in their data,” said Dr. Jans Aasman, CEO of Franz Inc. “Users can easily create queries visually, without becoming a query language expert, which further empowers the business user for this technology. Power users also benefit by creating ever more detailed queries in order extract knowledge from their data.” Gruff v6.0 produces dynamic data visualizations that organize connections between data in views that are driven by the user. This visual flexibility can instantly unveil new discoveries and knowledge that turn complex data into actionable business insights. Gruff was developed by Franz to address Graph Search in large data sets and empower users to intelligently explore graphs
    [Show full text]
  • Gsharp, Un Éditeur De Partitions De Musique Interactif Et Personnalisable
    Gsharp, un éditeur de partitions de musique interactif et personnalisable Christophe Rhodes* — Robert Strandh** * Department of Computing Goldsmiths, University of London London SE14 6NW United Kingdom [email protected] ** LaBRI, Université Bordeaux 1 351, Cours de la libération 33405 Talence Cedex France [email protected] RÉSUMÉ. Dans cet article, nous présentons Gsharp, un projet dont le but est la création d’un éditeur de partitions de musique traditionnelles. Le logiciel Gsharp est écrit en Common Lisp et utilise CLIM (Common Lisp Interface Manager) comme bibliothèque pour l’interaction avec l’utilisateur. De nombreux algorithmes et structures de données ont été inventés afin d’assurer un performance acceptable pour de simples interactions comme l’insertion ou la suppression d’une note ou d’un accord. ABSTRACT. In this article, we present Gsharp, a project with the purpose of creating an editor for traditional music scores. Gsharp is written in Common Lisp, and uses the CLIM (Common Lisp Interface Manager) library for interactions with the user. Several new algorithms and data structures were invented in order to ensure acceptable performance for simple interactions such as inserting or deleting a note or a chord. MOTS-CLÉS : édition de partitions, Common Lisp, CLIM, personnalisation, logiciels interactif KEYWORDS: score editing, Common Lisp, CLIM, customization, interactive software 2e soumission à Document Numérique, le 23 janvier 2009 2 2e soumission à Document Numérique 1. Introduction Gsharp est un projet dont le but est la création d’un éditeur de partitions de mu- sique. Il s’agit d’un logiciel interactif dans le sens qu’après chaque action de la part de l’utilisateur, le résultat final de la mise en page est visible.
    [Show full text]
  • Knowwe – a Wiki for Knowledge Base Development
    KnowWE – A Wiki for Knowledge Base Development Joachim Baumeister,1 Jochen Reutelshoefer1, Volker Belli1, Albrecht Striffler1, Reinhard Hatko2 and Markus Friedrich1 Abstract. The development of knowledge systems has been driven the graphical editors of the shell-kit D3, but also added sophisticated by changing approaches, starting with special purpose languages tools for testing and refactoring the developed knowledge bases [5]. in the 1960s that evolved later to dedicated editors and environ- However, all aforementioned systems only support the work of one ments. Nowadays, tools for the collaborative creation and mainte- knowledge engineer at the same time, thus hindering a collaborative nance of knowledge became attractive. Such tools allow for the work and distributed development process with many participants. Further- on knowledge even for distributed panels of experts and for knowl- more, the graphical editors restricted the structuring possibilities of edge at different formalization levels. The paper (tool presentation) the knowledge bases by the system-defined structure and expressive- introduces the semantic wiki KnowWE, a collaborative platform for ness. In consequence, the engineers often needed to fit their knowl- the acquisition and use of different types of knowledge, ranging from edge structure into the possibilities of the tool. More importantly, the semantically annotated text to strong problem-solving knowledge. mix of different formalization levels was not possible, e.g., by relat- We also report on some current use cases of KnowWE. ing ontological knowledge with solutions of a decision tree. As the successor of KnowME the system KnowWE (Knowledge Wiki Environment) [4] offered a web-based wiki front-end for the 1 Introduction knowledge acquisition and supported the collaborative engineer- The utility of decision-support systems proved in numerous exam- ing of knowledge at different formalization levels.
    [Show full text]
  • 9 European Lisp Symposium
    Proceedings of the 9th European Lisp Symposium AGH University of Science and Technology, Kraków, Poland May 9 – 10, 2016 Irène Durand (ed.) ISBN-13: 978-2-9557474-0-7 Contents Preface v Message from the Programme Chair . vii Message from the Organizing Chair . viii Organization ix Programme Chair . xi Local Chair . xi Programme Committee . xi Organizing Committee . xi Sponsors . xii Invited Contributions xiii Program Proving with Coq – Pierre Castéran .........................1 Julia: to Lisp or Not to Lisp? – Stefan Karpinski .......................1 Lexical Closures and Complexity – Francis Sergeraert ...................2 Session I: Language design3 Refactoring Dynamic Languages Rafael Reia and António Menezes Leitão ..........................5 Type-Checking of Heterogeneous Sequences in Common Lisp Jim E. Newton, Akim Demaille and Didier Verna ..................... 13 A CLOS Protocol for Editor Buffers Robert Strandh ....................................... 21 Session II: Domain Specific Languages 29 Using Lisp Macro-Facilities for Transferable Statistical Tests Kay Hamacher ....................................... 31 A High-Performance Image Processing DSL for Heterogeneous Architectures Kai Selgrad, Alexander Lier, Jan Dörntlein, Oliver Reiche and Marc Stamminger .... 39 Session III: Implementation 47 A modern implementation of the LOOP macro Robert Strandh ....................................... 49 Source-to-Source Compilation via Submodules Tero Hasu and Matthew Flatt ............................... 57 Extending Software Transactional
    [Show full text]