home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / parallel / 1760 < prev    next >
Encoding:
Text File  |  1992-07-21  |  26.3 KB  |  659 lines

  1. Newsgroups: comp.parallel
  2. Path: sparky!uunet!europa.asd.contel.com!darwin.sura.net!gatech!hubcap!fpst
  3. From: zhan@acsu.buffalo.edu (Feibing Zhan)
  4. Subject: Summary of Responses on Concurrent Object-Oriented Programming
  5. Message-ID: <1992Jul21.143746.22380@hubcap.clemson.edu>
  6. Apparently-To: comp-parallel@cis.ohio-state.edu
  7. Sender: nntp@acsu.buffalo.edu
  8. Nntp-Posting-Host: autarch.acsu.buffalo.edu
  9. Organization: UB
  10. Date: Fri, 17 Jul 1992 14:40:45 GMT
  11. Approved: parallel@hubcap.clemson.edu
  12. Lines: 645
  13.  
  14.  
  15. The following are the responses I have received so far on my request on
  16. Concurrent Object-Oriented Programming Tools. I simply list them one by one, 
  17. and post them here. Each mail is seperated by a row of *'s. I'd like to thank 
  18. those who responded my request.
  19.  
  20. Feibing Zhan
  21. zhan@geog.buffalo.edu
  22.  
  23. ****************************************************************************
  24.  
  25.      N E T C L A S S E S   E A R L Y   D E V E L O P E R ' S   R E L E A S E
  26.  
  27.                   A N D   B E T A   T E S T   P R O G R A M
  28.  
  29.                   PostModern Computing Technologies, Inc.
  30.                        1032 Elwell Court, Suite 240
  31.                        Palo Alto, California 94303
  32.                         Telephone: (415) 967-6169
  33.                         Facsimile: (415) 967-6212
  34.  
  35. ------------------------------------------------------------------------------
  36.  
  37.         In June, 1992, PostModern Computing is planning to distribute
  38.         an early release of its NetClasses product, a set of C++ class
  39.         libraries for distributed object-oriented communications that
  40.         is currently scheduled for production release in the 3rd
  41.         quarter of 1992.
  42.  
  43.         Some simple example C++ application code written to the
  44.         NetClasses libraries is included in this announcement.
  45.  
  46.         NetClasses is a set of C++ class libraries that is organized
  47.         as a software toolkit.  The typical user of the NetClasses
  48.         libraries will be a distributed systems application developer
  49.         who requires an object-oriented framework for distributed,
  50.         message-passing based programming.  By linking the appropriate
  51.         NetClasses libraries, application programmers are then able
  52.         to:
  53.  
  54.          1.  Transport objects over a network.  Currently, there are
  55.              three object varieties that NetClasses can transport:
  56.              1) Arbitrary C++ objects---once derived from PostModern's
  57.              TransObject class; 2) arbitrary NIH-derived objects; and
  58.              3) NetClasses Typed Objects.  NetClasses Typed Objects
  59.              provide an object-oriented data transport in which the
  60.              structure and organization of network transportable
  61.              objects is specified externally in configurable files
  62.              using a simple, programming language independent abstract
  63.              syntax notation, the NetClasses Abstract Syntax Notation
  64.              (NASN).
  65.  
  66.          2.  Perform remote method invocations (RMI).  Using RMI, an
  67.              application on machine B can invoke a method on machine A.
  68.              RMI insulates distributed applications from the complexity
  69.              inherent in traditional, RPC-based distributed systems
  70.              development tools such as protocol compilers, direct TCP/IP
  71.              code writing, and detailed socket handling.  RMI makes fault
  72.              tolerance and connection management transparent to the
  73.              application programmer.  The RMI layer is built on top of the
  74.              distributed services package that is described below.
  75.  
  76.          3.  Use the NetClasses application programmer interface in
  77.              order to create, manipulate, and destroy typed objects
  78.              given NetClasses Typed Object data type definitions.
  79.              (NIH-derived and native C++ objects are created, manipulated
  80.              and destroyed from C++ itself).
  81.  
  82.          4.  Read and write all three varieties of NetClasses-transportable 
  83.              objects on streams using machine-independent external 
  84.              representations.  All three varieties of objects can be stored 
  85.              to and read from files.
  86.  
  87.          5.  Derive new distributed systems applications and reconfigure
  88.              existing ones by leveraging the multiple inheritance, subtyping
  89.              and data encapsulation capabilities of the NetClasses package.
  90.  
  91.  
  92.  
  93. ---------------------------------------------------------------------------
  94.                    Three varieties of object transport
  95. ---------------------------------------------------------------------------
  96.  
  97.         PostModern Computing's NetClasses package provides a set of
  98.         flexible C++ tools for object transport.
  99.  
  100.         The NetClasses NIH-based and Typed Object-based transports are
  101.         built on top of the National Institutes Health (NIH) class
  102.         library.  However, the NetClasses Typed Object application
  103.         programmer interface is not NIH-dependent.  In particular, the
  104.         Typed Object interface does not in any way constrain C++
  105.         developers who prefer not to use the NIH library themselves.
  106.  
  107.         The TransObject transport offers C++ programmers a third
  108.         facility for object transport that is entirely NIH independent
  109.         (NIH is not even included in the associated support
  110.         libraries).  The TransObject class library offers end-user
  111.         application programmers a way to migrate existing C++ class
  112.         definitions to a network-transportable framework.  The
  113.         TransObject facility is independent of both the NetClassses
  114.         Typed Object transport and the NIH-based object transport
  115.         described above.
  116.  
  117.         Here is the actual code to send an object "obj" on port 4001 to
  118.         a client that has requests a connection on that port.  Here, obj
  119.         can be pointer to an object that is either derived from a generic
  120.         C++ TransObject, an NIH-derived object, or a NetClasses TypedObject.
  121.  
  122.  
  123.         TCPstrm stream;
  124.         stream.listen(4001);                 // Listen for connections
  125.         TCPstrm* clientStream = stream.acceptConnection();
  126.         clientStream->send(*obj);
  127.         cout << "Sent the following Object\n" << *obj << endl;
  128.  
  129.  
  130.         Here is the code for the client:
  131.  
  132.  
  133.         TCPstrm stream;
  134.         stream.connect("serv", 4001);       // Connect to serv on port 4001
  135.         obj = stream.receive();             // Receive object
  136.         cout << "Received the following Object\n" << *obj << endl;
  137.  
  138.  
  139.         Note that in addition to being sent over a stream, obj is
  140.         written out to cout.  It is also possible to store obj in a
  141.         file for later retrieval.
  142.  
  143.         Although this example shows how NetClasses shields the developer
  144.         from tedious communications code, it is still a fairly low-level
  145.         implementation in that port numbers and host names must be
  146.         specified.  The developer can be shielded from these details as
  147.         well by using the distributed services and remote method invocation
  148.         facilities described below.
  149.  
  150. ^L
  151. ---------------------------------------------------------------------------
  152.                      Distributed Services Paradigm
  153. ---------------------------------------------------------------------------
  154.  
  155.         PostModern Computing's Distributed Service Paradigm is a
  156.         connection and service management mechanism that is organized
  157.         around the idea that network service providers should not have
  158.         to set up explicit port numbers and RPC connections but rather
  159.         should simply ``advertise'' themselves on the network.
  160.         ``Agents'' are active processes on the network that monitor
  161.         network service advertisements and manage connections between
  162.         information producers and consumers.  The Distributed Service
  163.         package is organized as a combination of C++ class libraries
  164.         and configurable "dsagent" executables.
  165.  
  166. ---------------------------------------------------------------------------
  167.                     Remote Method Invocation (RMI)
  168. ---------------------------------------------------------------------------
  169.  
  170.         The distributed services paradigm enables methods to be
  171.         invoked on objects from remote machines.  The RMI facility is
  172.         a higher level communications facility that shields the
  173.         developer from port number and host name considerations.
  174.         The focus of RMI is on ease of use.  An RMI invocation
  175.         requires no stub or skeleton files, protocol compilers, or RPC
  176.         mechanisms.  To enable object X of class C to have its method
  177.         M invoked from a remote machine, a programmer uses 
  178.         RMI::advertise method that takes the following form:
  179.  
  180.                  RMI::advertise("X.M", new RMIMethod(C)(X, &C::M));
  181.  
  182.         If an application wants to invoke the M method on object X
  183.         from a remote machine, it does
  184.  
  185.                  RMI::invoke("X.M");
  186.  
  187.         Parameter passing in RMI can be based on any of the three
  188.         NetClasses object transports (generic C++, NIH-object, or
  189.         TypedObject).  Synchronous and asynchronous RMI versions exist.
  190.  
  191.         Multiple agents can advertise method X.M.  The one that is
  192.         actually invoked is transparent to the client.  RMI thus
  193.         provides an easy mechanism for developing scalable distributed
  194.         applications.
  195.  
  196.         
  197. ^L
  198. ---------------------------------------------------------------------------
  199.               Detailed description of Typed Object transport
  200. ---------------------------------------------------------------------------
  201.  
  202.         Of the three object transports enabled by the NetClasses
  203.         libraries, the NetClasses Typed Object-based transport will be
  204.         the most unfamiliar to the NetClasses newcomer.
  205.  
  206.         The NetClasses Typed Object library enables application
  207.         programs to communicate via "typed objects", a machine-
  208.         independent data representation format.  Each typed object has
  209.         associated with it a particular "type", which is in turn
  210.         specified as a collection of "properties".  Both types and
  211.         typed objects are organized in an inheritance hierarchy that
  212.         reflects the object- oriented programming concepts of
  213.         information hiding, and single and multiple inheritance.
  214.  
  215.         A NetClasses type definition is described in terms of the
  216.         machine- and programming-language independent "NetClasses
  217.         Abstract Syntax Notation", or NASN.  The main goal of NASN is
  218.         to place a level of indirection between how a particular
  219.         application program (written in a particular programming
  220.         language, and running on a particular machine architecture)
  221.         represents and manipulates a typed object, and how the
  222.         corresponding data fields inside a typed object are brought
  223.         into a format suitable for transport over a computer network.
  224.         In its current implementation, NetClasses offers developers a
  225.         C++ application programmer interface for the creation,
  226.         destruction, manipulation, and transmission of typed objects.
  227.  
  228.         The notion of a "type" is central to Typed Object-based
  229.         application programs.  NetClasses types are similar to types
  230.         in the programming language world.  The main differences are
  231.         that NetClasses types are programming language independent,
  232.         and they are used not only inside a particular program, but
  233.         more importantly as a high-level data communications format
  234.         between different programs.
  235.  
  236.  
  237. ^L
  238.  
  239.  
  240.         Figure 1, below illustrates an example NetClasses type
  241.         definition file.  The type definitions are written in the
  242.         NetClasses Abstract Syntax Notation, or NASN.
  243.  
  244.                 create type Person
  245.                     (name      StringType,
  246.                      address   StringType,
  247.                      phone     CharType 10);
  248.  
  249.                 create type Topic
  250.                     (code         FloatType,
  251.                      nameOfTopic  StringType);
  252.  
  253.                 create type Author subtype of Person
  254.                     (expertise    Topic);
  255.  
  256.                 create type Editor subtype of Person
  257.                     (expertise  Topic  many,
  258.                      codeNumber IntegerType);
  259.  
  260.                 create type Document
  261.                     (title      StringType,
  262.                      authorOf   Author,
  263.                      subject    Topic,
  264.                      editor     Editor);
  265.  
  266.         Figure 1.  A NetClasses Type definitions file written in
  267.                    the NetClasses Abstract Syntax Notation (NASN).
  268.  
  269. ^L
  270. ---------------------------------------------------------------------------
  271.           Example: Typed Object transport using NetClasses
  272. ---------------------------------------------------------------------------
  273.  
  274.         In this section, we show how to use the C++ interface to the
  275.         NetClasses package to write an elementary ``producer and
  276.         consumer'' distributed application which we shall call
  277.         StockQuotation.
  278.  
  279.         The StockQuotation application involves two programs.  The
  280.         first program, called SQ-Producer, generates a simple stock
  281.         quotation object.  SQ-Consumer is a second program that
  282.         receives the stock quotation object from the first program
  283.         over a TCP stream connection.
  284.  
  285.         The first step in writing the StockQuotation application is to
  286.         decide upon a NetClasses type definition for the stock
  287.         quotation object that is going to be passed from the producer
  288.         to the consumer:
  289.  
  290.  
  291.                  create type StockQuotation
  292.                    (stocksymbol   StringType,
  293.                     price         FloatType,
  294.                     code          IntegerType);
  295.  
  296.  
  297.            The file SQ.nasn, defining a Stock Quotation type.
  298.  
  299.  
  300.         Next, we show the SQ-Producer program and the SQ-Consumer
  301.         program.  For clarity and simplicity, we have removed all
  302.         run-time error checking from the two programs.
  303. ^L
  304.  -------------------------Start of file SQ-Producer.C------------------------
  305.  
  306. // Start the Producer first, then the Consumer.
  307. // This program expects input from SQ.nasn.
  308.  
  309. #include <libc.h>
  310. #include <string.h>
  311. #include <iostream.h>
  312. #include "NetClasses.h"
  313. #include "tcpstrm.h"
  314.  
  315. main()
  316. {
  317.    Type::readTypes();
  318.  
  319.    Type*        SQType   = (Type *) Type::getType("StockQuotation");
  320.    TypedObject* SQObject = SQType->createObject();
  321.  
  322.    SQObject->setPropValue( "IBM", "stocksymbol");
  323.    SQObject->setPropValue(110.25, "price");
  324.    SQObject->setPropValue(   321, "code");
  325.  
  326.    TCPstrm stream;
  327.    stream.blocking(YES);
  328.    stream.listen(4001);
  329.  
  330.    TCPstrm* clientStream = stream.acceptConnection();
  331.  
  332.    cout << "Sending the following Object\n" << *SQObject << endl;
  333.    clientStream->send(*SQObject);
  334.  
  335.    clientStream->close();
  336.    stream.close();
  337. }
  338. -------------------------End of file SQ-Producer.C--------------------------
  339.  
  340. -------------------------Start of file SQ-Consumer.C--------------------------
  341.  
  342. //   Start the Producer first, then the Consumer.
  343. //   This program expects input from SQ.nasn.
  344.  
  345. #include <iostream.h>
  346. #include "NetClasses.h"
  347. #include "tcpstrm.h"
  348.  
  349. main()
  350. {
  351.         Type::readTypes();
  352.  
  353.         TCPstrm stream;
  354.         stream.blocking(YES);
  355.         stream.connect("pablo", 4001);
  356.  
  357.         TypedObject* object = stream.receive();
  358.  
  359.         cout << "Received the following Object\n" << *object << endl;
  360. }
  361.  
  362. -------------------------End of file SQ-Consumer.C--------------------------
  363. ^L
  364.  
  365.         After compiling and linking these two programs, we could execute them
  366.         by first typing
  367.  
  368.             pablo> SQ-Producer < SQ.nasn &
  369.  
  370.         on the hypothetical machine called ``pablo,'' and then typing
  371.  
  372.            sundev> SQ-Consumer < SQ.nasn
  373.  
  374.         on some other machine, here ``sundev.''  On the machine
  375.         ``pablo'' should appear output similar to the following:
  376.  
  377.          pablo>
  378.          Created type StockQuotation
  379.          Sending the following Object
  380.          TYPE: StockQuotation
  381.          PROPERTY: stocksymbol, TYPE: StringType, VALUE: 'IBM'
  382.          PROPERTY: price, TYPE: FloatType, VALUE: 110.25
  383.          PROPERTY: code, TYPE: IntegerType, VALUE: 321
  384.          pablo>
  385.  
  386.         The machine ``sundev'' would then output information that
  387.         looks like this:
  388.  
  389.          sundev>
  390.          Created type StockQuotation
  391.          Received the following Object
  392.          TYPE: StockQuotation
  393.          PROPERTY: stocksymbol, TYPE: StringType, VALUE: 'IBM'
  394.          PROPERTY: price, TYPE: FloatType, VALUE: 110.25
  395.          PROPERTY: code, TYPE: IntegerType, VALUE: 321
  396.          sundev>
  397.  
  398. ^L
  399. ---------------------------------------------------------------------------
  400.              A Selection of NetClasses `TypedObject' features
  401. ---------------------------------------------------------------------------
  402.  
  403.         1)  Overloaded == for value-based object equality testing.
  404.  
  405.             For example we can write:
  406.  
  407.                   if (object1 == object2) ...
  408.  
  409.         2)  Object aggregation in `composite' properties.
  410.  
  411.             Composite properties, which are specified in NASN by the
  412.             keyword `many,' are used to associate multiple instances
  413.             of similarly-typed TypedObjects with one property of a
  414.             (containing) object.  For example the NASN definition
  415.  
  416.                   create type Library
  417.                      (name     StringType,
  418.                       address  StringType,
  419.                       holdings Book many);
  420.  
  421.             defines `holdings' to be a composite property of Library.
  422.             Instantiated Library typed objects could then contain multiple
  423.             `Book' typed objects.  Composite properties properties have
  424.             object array semantics.
  425.  
  426.         3)  Path-notation accelerators for nested object manipulation.
  427.  
  428.             For example we can write
  429.  
  430.             employeeObj->setPropValue("Ed Jones","dept.supervisor[3].name");
  431.  
  432.             to set the name of the third supervisor in this employeeObj's
  433.             dept property to "Ed Jones."
  434.  
  435.         4)  Machine-independent external data representation.
  436.  
  437.         5)  Exposed Type, Property and TypedObject methods.
  438.  
  439.             Implementation hooks allow programmers to substitute alternative
  440.             parsers and user-interfaces for the NetClasses abstract syntax
  441.             notation.  (This is partially intended as an OMG migration
  442.             path).
  443. ^L
  444. MISCELLANEOUS INFORMATION:
  445.  
  446. ---------------------------------------------------------------------------
  447.                          Transport mechanisms
  448. ---------------------------------------------------------------------------
  449.  
  450.         In the first developer's release, NetClasses includes TCP- and
  451.         UDP-based object transport mechanisms.  PostModern's Reliable
  452.         Broadcast Protocol (now under alpha testing) is a UDP-based
  453.         layer for _reliable_ object transport in nonconnection-oriented
  454.         environments.  The TCP, UDP, and Reliable Broadcast Protocol
  455.         facilities are all organized as C++ class libraries.
  456.  
  457. ----------------------------------------------------------------------------
  458.                 NetClasses frequently asked questions list
  459. ----------------------------------------------------------------------------
  460.  
  461.         1)  How is the beta release organized?
  462.  
  463.             The NetClasses beta test release is organized as three
  464.             subdirectories.  Each subdirectory enables a different
  465.             variety of object transport, as follows:
  466.  
  467.             netclasses/generic:
  468.  
  469.               Contains class libraries and support documentation
  470.               for writing applications that move generic C++ objects
  471.               over a network on top of TCP/IP.  Contains in particular
  472.               the TransObject class, from which users derive existing
  473.               classes in order to enable TCP/IP-based object transport.
  474.               Includes streams, distributed services and Remote Method
  475.               Invocation support libraries.
  476.  
  477.             netclasses/nih:
  478.  
  479.               Contains class libraries and support documentation
  480.               for writing applications that move arbitrary NIH-derived
  481.               objects over a network using TCP/IP.   Includes streams,
  482.               distributed services and Remote Method Invocation support
  483.               libraries.
  484.  
  485.             netclasses/types:
  486.  
  487.               Contains class libraries and support documentation
  488.               for writing distributed applications that move
  489.               PostModern Computing's Typed Objects on top of TCP/IP.
  490.               Users will first create NetClasses Typed Object data
  491.               definitions in external files using the NetClasses
  492.               Abstract Syntax Notation (NASN). The Types package C++
  493.               API is then used in order to create, manipulate, transmit,
  494.               and destroy objects that meet these definitions.  Includes
  495.               streams, distributed services, and Remote Method Invocation
  496.               support libraries.
  497.  
  498.             By using the appropriate object transport and support
  499.             libraries, users can move objects over TCP/IP stream
  500.             connections.  Simple code examples are included in each
  501.             subdirectory, and they are explained in the associated
  502.             support documentation.  The RMI library allows application
  503.             programmers a further level of abstraction in that host
  504.             name, port number, and connection management duties are
  505.             taken over by active processes that are called distributed
  506.             service agents (dsagent).  An application wishing to send
  507.             objects over the network "advertises" itself to an agent as
  508.             a service provider, while processes wishing to receive
  509.             objects request connections to these services through
  510.             these agents.
  511.  
  512.         2)  Is the beta release _really_ going to include all this software?
  513.  
  514.             Yes.  The only things that could possibly slip are the Remote
  515.             Method Invocation libraries.  The distributed services package
  516.             that RMI is built on top of will certainly ship in the beta
  517.             release.
  518.  
  519.         3)  What information do I need to provide?
  520.  
  521.             We need your mailing address, the system you are using
  522.             (e.g. SUN OS 4.1.2), and the media you would prefer (our
  523.             default is to ship on 1/4'' cartridge tapes in QIC-150
  524.             format).  We are using Sun C++ compilers.
  525.  
  526.             Along with the tape, you will receive a nondisclosure
  527.             agreement that you should sign.
  528.  
  529.         4)  What platforms does NetClasses run on?
  530.  
  531.             We are currently testing on Sun Sparcstations and HP workstations.
  532.  
  533.         5)  When will this software be available?
  534.  
  535.             We plan to ship copies to beta test sites in mid- to late-June.
  536.  
  537.         6)  Has retail pricing been decided upon?
  538.  
  539.             No.
  540.  
  541.         7)  Will my input to the beta testing program matter?
  542.  
  543.             Yes, and probably a lot.  We want this product to be
  544.             simple, modular, and useful.  Most of the interest we have
  545.             received is coming from research laboratories and
  546.             companies that are facing similar problems to what we are
  547.             trying to solve with these libraries.
  548.  
  549.         8)  What is the structure of the beta test program?
  550.  
  551.             We will send you the libraries, headers, and draft
  552.             documentation.  You tell us bugs and things you find
  553.             useful or inconvenient.  Sending a message to
  554.             plambeck@xenon.stanford.edu is probably the best way to be
  555.             heard.
  556.  
  557.         9)  Do I have to pay anything?
  558.  
  559.             Nothing except the shipping and media costs.  (If we were to pay
  560.             for the shipping we would have to limit the number of beta copies
  561.             we ship, and we don't want to do that).
  562.  
  563.  
  564.                   PostModern Computing Technologies, Inc.
  565.                        1032 Elwell Court, Suite 240
  566.                        Palo Alto, California 94303
  567.                         Telephone: (415) 967-6169
  568.                         Facsimile: (415) 967-6212
  569.  
  570.  
  571. ***************************************************************************
  572.  
  573. You may like to contact
  574.  
  575. ----------------------------------------------------------------------------
  576. Mjolner Informatics Aps                            Phone: +45 86 20 20 00
  577. Science Park Aarhus                                Fax:   +45 86 20 12 22
  578. Gustav Wiedsvej 10                                 Email:
  579. mjolner@mjolner.dk
  580. DK-8000 Aarhus C, Denmark
  581. ----------------------------------------------------------------------------
  582.  
  583. as they have:
  584.  
  585. The Mjolner BETA System
  586.  
  587.  
  588.  
  589.          A software development environment supporting
  590.                   object-oriented programming
  591.                in the BETA programming language
  592.  
  593. I have not had a chance to experience with it, but it sounds interesting. 
  594.  
  595.  
  596. **************************************************************************
  597. Mentat is a medium-grain dataflow CSP implementation of C++.  It may be
  598. found at the University of Virginia and has been implemented on Suns
  599. and an NCube (I think.)  It's shareware.
  600.  
  601. Contact asst. prof. Andrew Grimshaw at grimshaw@cs.virginia.edu (or is it 
  602. cs.uva.edu?)  It's his baby.
  603.  
  604.  
  605.  
  606. **************************************************************************
  607.  
  608. You can get an extension of C++ with parallel features (called uC++)
  609. via anonymous ftp (number: 129.97.129.9). Sorry, but I don't know the
  610. exact directory (I think pub/...). There is a file u++-3.2.5.tar.Z.
  611.  
  612. If you get other answers please can you forward it to me.
  613.  
  614. Thank you
  615.  
  616.    Dietrich.
  617.  
  618.  
  619. **************************************************************************
  620.  
  621. Two Concurrent OOPL's that are available in the public domain are: 
  622.  
  623.  - Modula-3 from DEC SRC; ftp from gatekeeper.dec.com
  624.    /pub/DEC/Modula-3/m3-??.tar.Z 
  625.  
  626.  - uC++ from University of Waterloo; ftp from watmsg.uwaterloo.ca
  627.    (129.97.141.9) pub/dmake/dmake38.tar.Z
  628.  
  629. Hope this is to some help.
  630.  
  631.  
  632. ***************************************************************************
  633.  
  634. Not public domain, but I thought I'd drop you a line just in case you
  635. were interested in the information.
  636.  
  637. There is a whole programming tool environment which is far more
  638. object-orientated than the likes of Express, and PVM etc. called
  639. TOPSYS produced at the University of Munich (TUM - Technische
  640. Universitat Munchen, with a few accents here and there!!!).
  641.  
  642. A few contact names if you are interested:
  643. Thomas Bemmerl
  644. Christian Kasperbauer
  645. Martin Mairandres
  646. Bernhard Ries.
  647.  
  648. At least those are the names on one of the more major reports I have
  649. on that work!!
  650.  
  651. I have an up to date Email address for Thomas Bemmerl which I found
  652. easily, I don't know whether I have information on the others.
  653. Thomas' address is bemmerl@esdc.intel.com, as he is now with Intel
  654. ESDC.
  655.  
  656. Hope this was helpful,
  657.  
  658.  
  659.