Jump to content

User:Pet-ro/Dylan Service Framework

From Wikipedia, the free encyclopedia

General Note: While the preface describes that the article was first motivated by Dylan, this article may later change into a general article about Software Architecture or spread onto already known entries in the wikiedipa. Currently this article is under the concern original research. Therefore the page is a subpage of my user page. I will discuss any concern before releasing it as entry to the wikipedia.

While working on this page I encoutered European Computer Manufacturers Association 's Reference Model for Frameworks of Software Engineering published in 1993. Something similar I tried here on my own.

Preface

Luke Hohmann in his book Beyond Software Architecture states some alternative thoughts on Software Architure:

  • Subsystems are designed to manage dependencies
  • Subsystems are designed according to human motivations and desires
  • Subsystems are designed to create a sense of wholeness or completeness
  • Beauty is in the eye of the beholder!

The following chapters introduce the reader to one definition of a beauty Service Framework related to Software Architecture.

The indented audience

  • Anyone interested in a sence of wholeness or completeness related to Software Architecture

Movitation behind

  • Present how a Services-Ontology related to Software Architecture might look like
  • Demonstrate which services are already implicit in Dylan
  • Provide a guidance which Dylan Stuff needs to be stated more explicit, to bring the beauty of the service ontology to Dylan.
  • Interest people in Dylan
  • Convince them that Dylan is on the way to a great wholeness or completeness
  • Dylan is on the way but of course requires (your) support to reach a better level of wholeness and completeness.

Intro

Currently IT related buzz words are: SOA (Service Oriented Architectur) and Service-Ontology. An older buzz word is Killer application. But in the history of commercial software engineering there also exists several skilled, but killed projects, which started proposed as killer application, but for whatever reason ended up as a killed application. Let me name some of these skilled projects of the níneties:

Skilled projects of the níneties

  • Taligent's CommonPoint initiated by Apple and IBM in 1992, stopped in 1998. Original business idea and vision as stated by its CEO, Joe Guglielmi: Success in the world of computing in the 21st century requires the pragmatic application of object technology to solve real customer problems."
  • Apple's Dylan programming language (started in the late eigthies, first version of the reference manual in 1992, second version in 1995. When Apple closed its Cambridge Research Labs in 1995 the language design team was scattered to the four winds.
  • Harlequin's Dylan Implementation. Harlequin jointed Apple's Dylan programming language project and prepared a windows implementation and continued with the project despite Apple's decision to close the Cambridge Labs.
  • Symbolics

Skilled projects are only possible with skilled peoples. So let us remind some of them.

Profile of Software Architectur innovator of the ninities

Our focus here is triggered by people who worked either on Taligent or on Dylan:

  • Mike Potel was Vice President of Technology Development at Taligent, in 1988 as Director of Software Engineering at Apple, he initiated the original Pink project out of which business concept of Taligent growed.
  • Former Symbolics staffers P.T. Withington, David Moon, Gary M. Palter, Sonya Keene, Scott McKay, Neal Feinberg were also invovled in the Dylan project at the Apple Cambridge Labs and at Harlequin.

David Moon brought into the Dylan Language Specification his hugh experience from the design of Common Lisp.

Scott McKay is an experienced GUI standard designer and developed a GUI standard for Common Lisp (CLIM) and Dylan (DUIM). Scott McKay led the CLIM implementation and the CLIM specification while at Symbolics and developed DUIM while at Harlequin. DUIM related to CLIM does not have the presentation layer, but has updated ideas on core graphics and widgets and Scott McKay on april 6th, 2003 on comp.lang.lisp: CLIM *is* behind the times. Nobody has invested in it seriously since 1994 at the latest. Nobody has done a careful redesign of its architecture to better support modern toolkits. ... When I did DUIM for Dylan, I thought very carefully about many of these issues (with Andy Armstrong as my right-hand man). DUIM has a far more modern architecture. DUIM has "the right" architecture to scale to new features. For example, the Open Dylan DUIM examples include a DUIM sheet class that transparently supports (no pun intended) OpenGL. The amount of code beyond the raw FFI code is negligible. The DUIM sources are open-source..

During preparing and working on this article the work of the following people impressed me:


Other innovative people's work is quoted later. So these are not the only ones.

ToDo

 Thinkpad: History Web last week until research.ibm

 Anchor Dylan in  Common Lisp in Section with other Lisp.
 see http://www.openbsd.org/de/donations.html as an example of a donation concept

 http://www.cs.cmu.edu/afs/cs.cmu.edu/project/gwydion/external-sources/duim-6-6-96/postscript/postscript-port.dylan

http://www.semanticweb-deutschland.de/indexf.htm





The idea is to use the taxonomy to reorganizes Open Dylan Libraries, a Dylan programming language implementation.

The Service Framework ( Work in Process )

We look here in the following chapter on a service ontology related to Software Architure. In its roots this service ontology is inspired by the taxonomy of Taligent 's CommonPoint Framework. Taligent's taxonomy is described in Taligent's Developer Resource.

(Note: high level service are mentioned first.)

Application Services

  • Application Services
    • Communication Services
      • Common Syntax (the structure or assembling of information)
      • Common Mechanism (common mechanism for exchanging information)
      • Common Semantics (the meaníngs of something )
    • Presentation Services
    • Localization Services
    • Resource Exchange Services
      • Intraoperability Concepts
        • clipboard
        • embbedding
      • Technologies
    • Resource Storage Services
      • Access Languages Engines
      • Access Technologies
        • ODBC (Windows)
    • Execution Serivces provides
      • Command Services (logging of commands, replay of logged commands)
      • Extensiblity to CLI (Command language Interface) which allows to parse complex commands
      • Selection
      • Actions
    • Manipulation Serivces
      • Cursor Tools
      • drag-and-drop

User Interface Management Services

A Dylan UI Management DUIM is an updated CLIM (Common Lisp Interface Manager) is a portable, graphical user interface toolkit originally developed by International Lisp Associates, Symbolics, and Xerox PARC, and now under joint development by several Lisp vendors, including Symbolics, Franz, Lucid, Illudium, and Harlequin.. To graps the concepts of DUIM may first look at CLIM articles.

Here are a list of CLIM related links


CLIM's services include

  • low-level facilities like geometry, graphics, event-oriented input and windowing.
  • intermediate level facilities like stream operations, output recording, and advance output formatting.
  • high-level facilities like context sensitive input, an adaptive toolkit, an application building framework.


DUIM Backends

  • Win32-API' was the first implemented backend used by DUIM.
  • Unter 'unix' several proposal have been made:
    • coding a 'GTK2-backend' estimate that it could be done in 2-3 months, if someone is interested and has some spare time (GTK/cario)
    • compling the 'win32-duim' via wine libraries under unix.
    • using Trolltech's [ http://trolltech.com/products/qt Qt]
  • a way to decouple duim from os-related user interface APIs is to use OpenGL

UI Management Services

    • User Interface Management Services
      • Presentation Services
        • Visual presentation
          • A sheet defines the portion of the display devices to which a programm can draw.
          • sheet behavior framework
            • sheet-hierarchies-related
            • input-related
            • output-related (acting as content presenter)
            • layout-related
            • repaintable
            • acting as control (Dialogs)
          • Geometrie Service
      • Visual Content Services
      • Input-Services
        • Keyboards
        • Mices
        • Scanning
      • Output-Services
        • Port
          • Output Utility Services
            • Graphic Device Support
          • Printing
        • Windows
        • Gluing input and output
        • Frames


A list of related publications

Visual Topics

see Visual Languages and Description Logics

see Layoutspezifikationen für komplexe graphische Objekte

see Looking Beyond Computer Applications: Investigating Rich Structures

see A High Level Language for Specifying Graph-Based Languages and their Programming Environments (1995)



see A Tool for Java Object Graph Analysis

see library dependency graph for minimal-console-compiler generated via GraphViz and a (perl) script that read the *.mkf. Generating GraphViz files from within the IDE would be neat.

Business Interoperability Approaches

  • Business Interoperability Approaches
    • User Interface Integration - Consists of presenting a common view of business service descriptions, characteristics and policies, enabling visibility and management of the business service lifecycle.
    • Control integration - Consists of alerting and notification integration; launching events and actions; and integration of business service governance and lifecycle
    • Data integration - Consists of leveraging the Business Service Registry as the primary service description, characteristic, and policy catalog.

For details look at

Interoperability Technologies

    • Web services, which are primarily message based. (SOAP, despite its name, does not really deal with objects)
    • Corba provides a true object-oriented component architecture

For details look at

SPIN Services

SPIN ; Polylingual Support for Persistence, Interoperability and Naming

see Polylingual Systems: An Approach To Seamless Interoperability

  • Polylinguality Approaches
    • via VM (Virtual Machines)
    • via FFI (Foreign Format Interface)
    • The Chasm approach provides an interesting approach to provide bridging code to interface Perl and Phython scripts with C, C++ and Fortan libraries. Chasm eliminates the need for IDLs by using compiler-based tools and static source analysis to generate an XML-based representation of procedure interfaces.

Chasm users must complete a series of steps to make calls between foreign languages:

  • Static analysis step parses a program and emit its abstract syntax tree in the compilers intermediate language (IL) representation. An IL analyzer then parses this language specific representation and produces a uniformprogramdatabase (PDB) format text file common to Fortran and C/C++. The DUCTAPE library provides an API for accessing entities represented in the PDB file. The PDB file is translated to an equivalentXML form in the next phase. The final output of this phase is a human readable XML file describing the interfaces discovered by the compiler.
  • Bridging-code generation. These tools take as input the XML file generated in phase 1 and output stub and skeleton bridging code (described below).
  • Compile and link.

A quote from Bridging the language gap in scientific computing: the Chasm approach about the advantages:

Several advantages are seen to using Chasm over the traditionalmethod of hand-modifying user code and making the interlanguage function calls directly from the caller’s code. First it removes the shear drudgery of hand coding and removes compiler dependencies from user code. However, perhaps more mportantly, it means that bridging code will not become out of sync with changes in user code, because normally a simple make will regenerate the bridging code. Chasm generated code is less susceptible to errors than hand-generated code.
Furthermore, because Chasm is easily extensible, it can be modified on a project-wide basis to meet project needs. This allows projects to impose project-wide language transformation standards so that individual project programmers need not ‘invent’ their own, thus leading to surprises and ultimately to errors. There need not be any long-term dependencies on Chasm, because each project ‘owns’ the generated code and it can be distributed with project libraries. The open source license of Chasm allows source code for the small Chasm run-time library to be distributed with a user’s source distribution.

    • Interoperabiltiy Approaches
      • Low-Level
        • Common file formts
        • (Remote) Procedure call
        • Message-passing via
          • via Point-to-Point, Multicast, Broadcast
          • either synchrously or asynchronously
      • Push Interoperability
        • via shared types (externals)
          • OMG's CORBA
          • MS's OLE
        • via language features (internal)
        • shared databases databases with APIs for different languages
  • Framework based Multilanguage Interoperabiltiy Services
    • foreign-type systems (e.g. CORBA)
    • PolySPIN

Web Technology Services

Web Server

[Koala_Web_Servcer | Koala] is an HTTP server written in [Dylan programming language]. It includes the following features:

  • a {H:title| The template to dynamically generate HTML, XML or other types of documents in response to a Web client request (HTTP-request).| Template engine] call Dylan Server Pages (DSP),

Template Engine in general is software that processes input text (the template) to produce one or more output texts. Some have additional features:

  • scriptlets, and
  • an XML-RPC server/client.
The technology allows Java code and certain pre-defined actions to be embedded into static content.


TODO's

  • add Koala to [Comparison of web servers]
  • add OpenLaszlo

Layering Domain Knowledge

Eric Evan in Domain-Driven Design emphasis an old truth, that operations of a domain are abstracted into knowledge.

Designing Software Appplication to support a specific domain requires a knowlwdge. Often the software designing process triggers the exploaration of new knowledge about the domain. Providing knowledge means handling information in a structured way. On way to classify the handling of information is via these levels:

  • Store & Retrieve information: DBMS, Document Management, Statistical Search, Data Warehousing, Query Tools, Linguistic Search, Information Request Brokers
  • Structure & Navigate Information: Presentation Formats (HTML, XML, etc), Semantic Models
  • Send Information: Internet, E-mail, Workflow, Netcasting
  • Online Sharing of Information: Discussion Databases, Video Conferencing, Application Sharing, Electronic Meeting Support
  • Synthesize Information: Business Intelligence, Data Mining, Agents, Visualization, Content Extraction
  • Solve: Rule-based Systems, Case-based Reasoning, Neural Networks


Domain Services

  • Domain Services
    • Domain Types
      • CAD
      • Workflows and Process
      • Agent
    • Domain Utility Services
      • Constraints
      • Math Services
        • Basic Math Content examples:
          • System for random number generation
          • Common factor: Greatest common divisor and least common multiple
        • Interval Arithmetic support is provided for interval data types, basic arithmetic on intervals, interval extensions of standard intrinsic functions, relational operators, I/O, etc. Intervals create a tight logical connection between computing and scientific, engineering, and mathematical reality. See the Interval Arithmetic Specification and related examples. A introduction is provided via a Sun page portraying Bill Walster, who outlined the specifaction as well by anAmerican Scientist article. The University of Texas El Paso provide a bibliographic list. An C++ related implementation is described at boost.org
          • Geometry
        • Collections use the module provided by the language or an extended version
        • Linear Algebra requires Basic Math and Collection. Content examples:
          • Basic linear algebra for dense, packed and sparse matrices
        • Probability requires Linear Algebra
        • Database requires Collections, and
        • Statistics requires Database and Probability
      • 'Scientific graphics toolkit'
        • Quantitatice Graphics, which require user interface management, Constraints, Collections, and Linear Algebra
      • Finite State Machine Services

List of related publications:

Real-Time Code

List of related publications

Dylan System

  • Compiler System. Most compiler component typically have a portable layer and a machine specific layer. ** GC
    • Mikrokernel
      • x86 Services
    • Processing Style
      • Single Processing
      • Multi Processing via two communication styles shared variables and message passing:
    • Parallel Tools Platform (PTP)
        • Shared-variables. A shared-memory architecture supports the shared-variables style as model for parallel programming is used by The OpenMP Application Program Interface (API) supports multi-platform shared-memory parallel programming in C/C++ and Fortran on all architectures, including Unix platforms and Windows NT platforms. Jointly defined by a group of major computer hardware and software vendors, OpenMP is a portable, scalable model that gives shared-memory parallel programmers a simple and flexible interface for developing parallel applications for platforms ranging from the desktop to the supercomputer. From the operating system point of view, OpenMP functionality is based on the use of threads, while the user's job simply consists in inserting suitable parallelization directives into his/her code. These directives do not influence the sequential functionality of the code since they take the form of Fortran comments and C/C++ preprocessor pragmas, respectively. However, an OpenMP aware compiler will be capable of transforming the code-blocks marked by OpenMP directives into threaded code; at run time the user can then decide (by setting suitable environment variables) what resources can be directed to the parallel parts of his executable, and how they are organized or scheduled. .
        • Message-passing has become accepted as a portable style of parallel programming, but has several significant weaknesses that limit its effectiveness and scalability. Message-passing in general is difficult to program and doesn't support incremental parallelization of an existing sequential program. Message-passing was initially defined for client/server applications running across a network, and so includes costly semantics (including message queuing and selection and the assumption of wholly separate memories) that are often not required by tightly-coded scientific applications running on modern scalable systems with globally addressable and cache coherent distributed memories. for shared and distributed memory.
  • Dylan Run-time Tools multiple tools cooperate in monitoring and controlling of the programming language system.
    • A Source Code Debugger provides
      • complex language features
      • wide compiler and platform support
      • Multithreaded debugging
      • Distributed Debugging
      • Memory Debugging Capabilities
      • Powerful and Easy GUI (Visualization examples: Total View) usable for
        • Status
        • Process Control
        • Data Exploration
      • Extensible via Scripts or Probes are code patches which are insert into a program dynamically. Probes can collect and report program information, program state or modify the program execution. Probes may be placed at specific locations in the program and can be activated: (1) whenever execution reaches that location, (2) by expiration of a timer, or exactly once. .
    • Debugging Database
    • Performance Analyser ( see OpenSource Performance Debugger OpenSpeedShop, the Tuning and Analysis Utilities TAU (related slides, Program Database Toolkit PDT, dPOMP or IBM's DPCL ).
    • Load Balancer
  • Development Environment
    • Perspectives
    • Refactoring
  • Deployment Service
    • CDAN Service


= ToDo

Combining Development Framework and Automatic Performance Tuning

The portable portable layer a performance analyzing tool supports both Preset events arem mappings fro, symbolic names to machine specific definitions for a particular hardware event. Presets may be deriverd from the underlying hardware. and A native event is an event countable by the CPU. A CPU-specific bit is used as event definition. . An example of a performance API is PAPI.

A Performance and Tracing Service Framework consist of the following components

  • An analyser extract the high-level language constructs (sometime from an intermediate language) and outputs item descriptions to a program database . (Sometime also the term debbuging database is used instead). To support different programming languages an analyzer has language specific part. These descriptions characterisze the program's functions and classes, types, namespaces, macros and source files.
  • Another component provides an API to the datbase. In a A Tool Framework for Static and Dynamic Analysis of Object-oriented Software with Templates a programm database format is described.


Tasks of a Collector Framework: Process Control, Perfomance Data Collection Abstraction (Collectors, Parameters, Metrics), Symbol Table Caching, Data Management & Chanching, Extensibility via Collector Plugins.

[UI Semantic Routines] provide

  • Commonm Performance Tool Operations
    • Create Process, Attach to Thread
    • Start/Stop Thread
    • Experiment Management / Selection
    • Get/Set Parameters
    • Start/Stop Data Collection
    • Save/Restore Performance Data

Basic Content Standards

Basic Framework Patterns

  • Basic Framework Service
    • Notification: a naming convention is used to make notification explicit. Here some example take from a user interface manager: note-sheet-region-changed (Further examples are listed in section 8.5 of the CLIM II specification.
    • The Interceptor pattern triggers (external) services automatically when certain events occur in an application. The pattern is a framework with call-backs associated with particular events. A user extends the framework by writing modules that register user-defined call-backs with the framework. When a framework event arises, the registered methods are invoked thereby alerting the user to these events. The term Interceptor was used by Pattern-Oriented Software Architecture, Volume 2, Patterns for Concurrent and Networked Objects

Basic Interoperability Patterns

  • Basic Interoperability Patterns
    • Appproach
      • Command-line based Interoperability
      • GUI-based Interoperability
    • Concept
      • Connector
        • Instrumented Connector are connectors whose message traffic is observed by an intermediary omponent. An intermediary can record message traffic for later play-back (e.g., to simulate actual usage), analysis (e.g., to determine message invocation frequency), or to act as a transducer that modifies message traffic to achieve a particular purpose. As a general rule, instrumented connectors are non-invasive and idempotent. Non-invasive means that their presence in a connector’s implementation is undetectable; idempotent means that any number of intermediaries can be chained because their import and export interfaces are the same and that they are non-invasive. Related technologies are

The idea is to place a wrapper around a CLP to programmatically invoke its commands. The CLP responds by outputting text that represents the result of the command. This text can be returned directly to the client, but it burdens the client to parse the returned text to decipher the output. A better way, as is to have the wrapper parse the generated output and return a semantically useful result (an integer, an object, etc.) that can be more easily consumed by a calling program. Parsing is complicated by the possibility that the CLP can report events prior to reporting the result of a method call. For example, if the CLP is a debugger, the debugger can report that a breakpoint has been reached. The parser must be smart enough to recognize the semantics of the CLP response. A wrapper specification language was used in the wrap-O-Matic Project( http://citeseer.ist.psu.edu/wohlstadter01generating.html ) to simplify the development of parsers for CLP responses., A detour is a code fragment that is executed immediately prior to a function call and is unobtrusively injected like a breakpoint into the process space that contains the target function [12][13]. The detour encapsulates the actions of an intermediary — e.g. call monitoring code. , A common technique in Windows platforms is emulation. Each COM component (or dynamically linked library (DLL)) has a GUID (Globally Unique IDentifier). The Windows registry is a database of DLLs organized by GUIDs. A client loads a DLL by invoking a system call with the DLL’s GUID; the registry is searched for the location of that DLL. Emulation is a registry technique that replaces an existing DLL with an intermediary DLL that implements the same COM interfaces but has a different GUID. When a client requests a particular DLL, the intermediary is loaded instead. In turn, the intermediary loads the shadowed DLL and acts as a “pass-through” for all client requests. Thus the intermediary can monitor call traffic for a COM interface unobtrusively.. ( Quoted from Integrating and Reusing GUI-Driven Applications)

System Services

  • System Services
    • Foundation Services
      • Interoperability Services
        • Remote Object Call Services
        • Messaging Services
      • Persistance Services
      • Testing

Communciaton Services

  • Communciaton Services
    • Data Sharing Service
    • Interprocess Communication Service
    • Network Service
    • Message Service
    • Event Notification Service


OS Services

    • OS Services
      • File Systems
      • Object Runtime Services
      • Threads

Modelling Features

 OOPM Object-oriented Physical Modeling
 see  MOOSE: architecture of an object-oriented multimodeling simulation system (1997)
  http://citeseer.ist.psu.edu/cubert97moose.html
 
 MOOSE: an object-oriented multimodeling and simulation application framework (1997)
   mentions the Life  Game
   http://citeseer.ist.psu.edu/345226.html

 COCOOS - OBJECT ARCHITECTURE FOR AUTOMATIC PROCESS CONTROL APPLICATIONS.
 http://citeseer.ist.psu.edu/cache/papers/cs/25729/ftp:zSzzSzftp.cs.utexas.eduzSzpubzSzpredatorzSzIIDE.pdf/integrating-and-reusing-gui.pdf

Code Maintance Features

  • Dylan related CLOS conventions
    • The term protocol means a set of generic functions that together form a coherent interface. A protocol specification not only includes the syntactic details of the function names and the number of function arguments, but also the functions’ purpose and the semantics of the return values (and/or side effects) must be given in a textual specification.

Language Features

  • Dylan Language *
      • Standard based on the Dylan Reference Manual
      • common-extension additional supported by (most) Dylan implementation.
      • Proposal to be include in the next Dylan Reference Manual

Language Vision

  " Does Dylan cross-call Lisp or vice versa?  If not, they should.  Be a darned pity to have these two markets isolated from one another.  If it did, one could just cross=call from one language to the other." Kent M. Pitmann on Fr 3 Nov. 2000 on comp.lang.lisp.
Retrieved from "https://en.wikipedia.org/w/index.php?title=User:Pet-ro/Dylan_Service_Framework&oldid=55128705"