Wikipedia

User:Pet-ro/Dylan Service Framework

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 ECMA's Reference Model for Frameworks of Software Engineering published in 1993. Something similar I tried here on my own.

Preface edit

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 edit

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

Movitation behind edit

  • 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 edit

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 edit

  • 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 edit

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 a fare more modern architecture.

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 edit 

 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 ) edit

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 edit

  • Application Services
    • Distributed 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 Services
      • Cursor Tools
      • drag-and-drop
    • Context-Aware Services: Services, that support context-aware applications (see Model Based Approach for Context Aware and Adaptive user Interface Generation)

User Interface Management Services edit

A Dylan UI Management DUIM is an updated CLIM, Common Lisp Interface Manager. To graps the concepts of DUIM you 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.


Basic graphical tasks edit

User interface management system support these basic graphical tasks:

specification
free specification through text fields, specification by selection of

one or many elements such as radio buttons, lists, spinners, sliders, check boxes, menus, combo boxes),

activation
via the UI items button, menu, list

and

navigation
via button, link, scroll.


see also:

Note
Dylan Library already contains a UI approach based on OpenGL. What about combining this with an User Interface Markup Language (UIML)?

DUIM Backends edit

  • 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 edit

      • Output-Services
        • Port
          • Output Utility Services
            • Graphic Device Support
          • Printing
        • Windows
        • Gluing input and output
        • Frames


A list of related publications

Visual Topics edit

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 edit

  • 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 edit

    • 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 edit

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 edit

Web Server edit

[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 edit

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


= Event Services


Domain Services edit

List of related publications:

Real-Time Code edit

List of related publications

Dylan System edit

  • 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 OpenMP.
        • Message-passing 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.
    • 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 edit

Combining Development Framework and Automatic Performance Tuning

The portable portable layer a performance analyzing tool supports both preset events and native events . 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 edit

Basic Framework Patterns edit

  • 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 POSA-Vol-2

Basic Interoperability Patterns edit

  • 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 wrapping command line programs, detours, emulation.

( Quoted from Integrating and Reusing GUI-Driven Applications)

System Services edit

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

Communciaton Services edit

  • Communciaton Services
    • Data Sharing Service
    • Interprocess Communication Service
    • Network Service
    • Message Service
    • Event Service introduces dimensions to characterize distributed event definition, detection, production and notification; details in Towards a Semantic Event Service. Composing events from different event sources in loosely coupled distributed systems has to deal with varying transmission delays. Introducing an accuracy intervals with reliable error bounds for timestamping of events can reflect the inherent inaccuracy in time measurements. Think if composite events have a start and endpoint. But the specification and automatic detection of event patterns- so-called composite events - are not always well suited to detect real-world states (see Event-Based Systems for Detecting Real-World States with Sensor Networks: A Critical Analysis. A event service can be the base of a distributed reliable event-based application management

OS Services edit

    • OS Services
      • File Systems
      • Object Runtime Services provide the following runtime capabilities
        • Memory Pool Service provides a multithread-safe way to allocate memory. Such a service is often also term as garbadge collection (GC) (For further links see: [2], [3]). Related open-source service implementations are
          • the Memory Pool System Project: It permits the flexible combination of memory management techniques, supporting manual and automatic memory management, in-line allocation, finalization, weakness, and multiple concurrent co-operating incremental generational garbage collections. It also includes a library of memory pool classes implementing specialized memory management policies. Another Memory Pool Service implementation is
          • the Boehm-Weiser Conservative.
        • Shared Libraries Service provide a mechanism for packaging code and data into loadable shared libraries.
      • Threads

Modelling Features edit 

 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 edit

  • 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 edit

  • 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 edit 

  " 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=1114516999"