home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.parallel
- Path: sparky!uunet!europa.asd.contel.com!darwin.sura.net!gatech!hubcap!fpst
- From: zhan@acsu.buffalo.edu (Feibing Zhan)
- Subject: Summary of Responses on Concurrent Object-Oriented Programming
- Message-ID: <1992Jul21.143746.22380@hubcap.clemson.edu>
- Apparently-To: comp-parallel@cis.ohio-state.edu
- Sender: nntp@acsu.buffalo.edu
- Nntp-Posting-Host: autarch.acsu.buffalo.edu
- Organization: UB
- Date: Fri, 17 Jul 1992 14:40:45 GMT
- Approved: parallel@hubcap.clemson.edu
- Lines: 645
-
-
- The following are the responses I have received so far on my request on
- Concurrent Object-Oriented Programming Tools. I simply list them one by one,
- and post them here. Each mail is seperated by a row of *'s. I'd like to thank
- those who responded my request.
-
- Feibing Zhan
- zhan@geog.buffalo.edu
-
- ****************************************************************************
-
- 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
-
- A N D B E T A T E S T P R O G R A M
-
- PostModern Computing Technologies, Inc.
- 1032 Elwell Court, Suite 240
- Palo Alto, California 94303
- Telephone: (415) 967-6169
- Facsimile: (415) 967-6212
-
- ------------------------------------------------------------------------------
-
- In June, 1992, PostModern Computing is planning to distribute
- an early release of its NetClasses product, a set of C++ class
- libraries for distributed object-oriented communications that
- is currently scheduled for production release in the 3rd
- quarter of 1992.
-
- Some simple example C++ application code written to the
- NetClasses libraries is included in this announcement.
-
- NetClasses is a set of C++ class libraries that is organized
- as a software toolkit. The typical user of the NetClasses
- libraries will be a distributed systems application developer
- who requires an object-oriented framework for distributed,
- message-passing based programming. By linking the appropriate
- NetClasses libraries, application programmers are then able
- to:
-
- 1. Transport objects over a network. Currently, there are
- three object varieties that NetClasses can transport:
- 1) Arbitrary C++ objects---once derived from PostModern's
- TransObject class; 2) arbitrary NIH-derived objects; and
- 3) NetClasses Typed Objects. NetClasses Typed Objects
- provide an object-oriented data transport in which the
- structure and organization of network transportable
- objects is specified externally in configurable files
- using a simple, programming language independent abstract
- syntax notation, the NetClasses Abstract Syntax Notation
- (NASN).
-
- 2. Perform remote method invocations (RMI). Using RMI, an
- application on machine B can invoke a method on machine A.
- RMI insulates distributed applications from the complexity
- inherent in traditional, RPC-based distributed systems
- development tools such as protocol compilers, direct TCP/IP
- code writing, and detailed socket handling. RMI makes fault
- tolerance and connection management transparent to the
- application programmer. The RMI layer is built on top of the
- distributed services package that is described below.
-
- 3. Use the NetClasses application programmer interface in
- order to create, manipulate, and destroy typed objects
- given NetClasses Typed Object data type definitions.
- (NIH-derived and native C++ objects are created, manipulated
- and destroyed from C++ itself).
-
- 4. Read and write all three varieties of NetClasses-transportable
- objects on streams using machine-independent external
- representations. All three varieties of objects can be stored
- to and read from files.
-
- 5. Derive new distributed systems applications and reconfigure
- existing ones by leveraging the multiple inheritance, subtyping
- and data encapsulation capabilities of the NetClasses package.
-
-
-
- ---------------------------------------------------------------------------
- Three varieties of object transport
- ---------------------------------------------------------------------------
-
- PostModern Computing's NetClasses package provides a set of
- flexible C++ tools for object transport.
-
- The NetClasses NIH-based and Typed Object-based transports are
- built on top of the National Institutes Health (NIH) class
- library. However, the NetClasses Typed Object application
- programmer interface is not NIH-dependent. In particular, the
- Typed Object interface does not in any way constrain C++
- developers who prefer not to use the NIH library themselves.
-
- The TransObject transport offers C++ programmers a third
- facility for object transport that is entirely NIH independent
- (NIH is not even included in the associated support
- libraries). The TransObject class library offers end-user
- application programmers a way to migrate existing C++ class
- definitions to a network-transportable framework. The
- TransObject facility is independent of both the NetClassses
- Typed Object transport and the NIH-based object transport
- described above.
-
- Here is the actual code to send an object "obj" on port 4001 to
- a client that has requests a connection on that port. Here, obj
- can be pointer to an object that is either derived from a generic
- C++ TransObject, an NIH-derived object, or a NetClasses TypedObject.
-
-
- TCPstrm stream;
- stream.listen(4001); // Listen for connections
- TCPstrm* clientStream = stream.acceptConnection();
- clientStream->send(*obj);
- cout << "Sent the following Object\n" << *obj << endl;
-
-
- Here is the code for the client:
-
-
- TCPstrm stream;
- stream.connect("serv", 4001); // Connect to serv on port 4001
- obj = stream.receive(); // Receive object
- cout << "Received the following Object\n" << *obj << endl;
-
-
- Note that in addition to being sent over a stream, obj is
- written out to cout. It is also possible to store obj in a
- file for later retrieval.
-
- Although this example shows how NetClasses shields the developer
- from tedious communications code, it is still a fairly low-level
- implementation in that port numbers and host names must be
- specified. The developer can be shielded from these details as
- well by using the distributed services and remote method invocation
- facilities described below.
-
- ^L
- ---------------------------------------------------------------------------
- Distributed Services Paradigm
- ---------------------------------------------------------------------------
-
- PostModern Computing's Distributed Service Paradigm is a
- connection and service management mechanism that is organized
- around the idea that network service providers should not have
- to set up explicit port numbers and RPC connections but rather
- should simply ``advertise'' themselves on the network.
- ``Agents'' are active processes on the network that monitor
- network service advertisements and manage connections between
- information producers and consumers. The Distributed Service
- package is organized as a combination of C++ class libraries
- and configurable "dsagent" executables.
-
- ---------------------------------------------------------------------------
- Remote Method Invocation (RMI)
- ---------------------------------------------------------------------------
-
- The distributed services paradigm enables methods to be
- invoked on objects from remote machines. The RMI facility is
- a higher level communications facility that shields the
- developer from port number and host name considerations.
- The focus of RMI is on ease of use. An RMI invocation
- requires no stub or skeleton files, protocol compilers, or RPC
- mechanisms. To enable object X of class C to have its method
- M invoked from a remote machine, a programmer uses
- RMI::advertise method that takes the following form:
-
- RMI::advertise("X.M", new RMIMethod(C)(X, &C::M));
-
- If an application wants to invoke the M method on object X
- from a remote machine, it does
-
- RMI::invoke("X.M");
-
- Parameter passing in RMI can be based on any of the three
- NetClasses object transports (generic C++, NIH-object, or
- TypedObject). Synchronous and asynchronous RMI versions exist.
-
- Multiple agents can advertise method X.M. The one that is
- actually invoked is transparent to the client. RMI thus
- provides an easy mechanism for developing scalable distributed
- applications.
-
-
- ^L
- ---------------------------------------------------------------------------
- Detailed description of Typed Object transport
- ---------------------------------------------------------------------------
-
- Of the three object transports enabled by the NetClasses
- libraries, the NetClasses Typed Object-based transport will be
- the most unfamiliar to the NetClasses newcomer.
-
- The NetClasses Typed Object library enables application
- programs to communicate via "typed objects", a machine-
- independent data representation format. Each typed object has
- associated with it a particular "type", which is in turn
- specified as a collection of "properties". Both types and
- typed objects are organized in an inheritance hierarchy that
- reflects the object- oriented programming concepts of
- information hiding, and single and multiple inheritance.
-
- A NetClasses type definition is described in terms of the
- machine- and programming-language independent "NetClasses
- Abstract Syntax Notation", or NASN. The main goal of NASN is
- to place a level of indirection between how a particular
- application program (written in a particular programming
- language, and running on a particular machine architecture)
- represents and manipulates a typed object, and how the
- corresponding data fields inside a typed object are brought
- into a format suitable for transport over a computer network.
- In its current implementation, NetClasses offers developers a
- C++ application programmer interface for the creation,
- destruction, manipulation, and transmission of typed objects.
-
- The notion of a "type" is central to Typed Object-based
- application programs. NetClasses types are similar to types
- in the programming language world. The main differences are
- that NetClasses types are programming language independent,
- and they are used not only inside a particular program, but
- more importantly as a high-level data communications format
- between different programs.
-
-
- ^L
-
-
- Figure 1, below illustrates an example NetClasses type
- definition file. The type definitions are written in the
- NetClasses Abstract Syntax Notation, or NASN.
-
- create type Person
- (name StringType,
- address StringType,
- phone CharType 10);
-
- create type Topic
- (code FloatType,
- nameOfTopic StringType);
-
- create type Author subtype of Person
- (expertise Topic);
-
- create type Editor subtype of Person
- (expertise Topic many,
- codeNumber IntegerType);
-
- create type Document
- (title StringType,
- authorOf Author,
- subject Topic,
- editor Editor);
-
- Figure 1. A NetClasses Type definitions file written in
- the NetClasses Abstract Syntax Notation (NASN).
-
- ^L
- ---------------------------------------------------------------------------
- Example: Typed Object transport using NetClasses
- ---------------------------------------------------------------------------
-
- In this section, we show how to use the C++ interface to the
- NetClasses package to write an elementary ``producer and
- consumer'' distributed application which we shall call
- StockQuotation.
-
- The StockQuotation application involves two programs. The
- first program, called SQ-Producer, generates a simple stock
- quotation object. SQ-Consumer is a second program that
- receives the stock quotation object from the first program
- over a TCP stream connection.
-
- The first step in writing the StockQuotation application is to
- decide upon a NetClasses type definition for the stock
- quotation object that is going to be passed from the producer
- to the consumer:
-
-
- create type StockQuotation
- (stocksymbol StringType,
- price FloatType,
- code IntegerType);
-
-
- The file SQ.nasn, defining a Stock Quotation type.
-
-
- Next, we show the SQ-Producer program and the SQ-Consumer
- program. For clarity and simplicity, we have removed all
- run-time error checking from the two programs.
- ^L
- -------------------------Start of file SQ-Producer.C------------------------
-
- // Start the Producer first, then the Consumer.
- // This program expects input from SQ.nasn.
-
- #include <libc.h>
- #include <string.h>
- #include <iostream.h>
- #include "NetClasses.h"
- #include "tcpstrm.h"
-
- main()
- {
- Type::readTypes();
-
- Type* SQType = (Type *) Type::getType("StockQuotation");
- TypedObject* SQObject = SQType->createObject();
-
- SQObject->setPropValue( "IBM", "stocksymbol");
- SQObject->setPropValue(110.25, "price");
- SQObject->setPropValue( 321, "code");
-
- TCPstrm stream;
- stream.blocking(YES);
- stream.listen(4001);
-
- TCPstrm* clientStream = stream.acceptConnection();
-
- cout << "Sending the following Object\n" << *SQObject << endl;
- clientStream->send(*SQObject);
-
- clientStream->close();
- stream.close();
- }
- -------------------------End of file SQ-Producer.C--------------------------
-
- -------------------------Start of file SQ-Consumer.C--------------------------
-
- // Start the Producer first, then the Consumer.
- // This program expects input from SQ.nasn.
-
- #include <iostream.h>
- #include "NetClasses.h"
- #include "tcpstrm.h"
-
- main()
- {
- Type::readTypes();
-
- TCPstrm stream;
- stream.blocking(YES);
- stream.connect("pablo", 4001);
-
- TypedObject* object = stream.receive();
-
- cout << "Received the following Object\n" << *object << endl;
- }
-
- -------------------------End of file SQ-Consumer.C--------------------------
- ^L
-
- After compiling and linking these two programs, we could execute them
- by first typing
-
- pablo> SQ-Producer < SQ.nasn &
-
- on the hypothetical machine called ``pablo,'' and then typing
-
- sundev> SQ-Consumer < SQ.nasn
-
- on some other machine, here ``sundev.'' On the machine
- ``pablo'' should appear output similar to the following:
-
- pablo>
- Created type StockQuotation
- Sending the following Object
- TYPE: StockQuotation
- PROPERTY: stocksymbol, TYPE: StringType, VALUE: 'IBM'
- PROPERTY: price, TYPE: FloatType, VALUE: 110.25
- PROPERTY: code, TYPE: IntegerType, VALUE: 321
- pablo>
-
- The machine ``sundev'' would then output information that
- looks like this:
-
- sundev>
- Created type StockQuotation
- Received the following Object
- TYPE: StockQuotation
- PROPERTY: stocksymbol, TYPE: StringType, VALUE: 'IBM'
- PROPERTY: price, TYPE: FloatType, VALUE: 110.25
- PROPERTY: code, TYPE: IntegerType, VALUE: 321
- sundev>
-
- ^L
- ---------------------------------------------------------------------------
- A Selection of NetClasses `TypedObject' features
- ---------------------------------------------------------------------------
-
- 1) Overloaded == for value-based object equality testing.
-
- For example we can write:
-
- if (object1 == object2) ...
-
- 2) Object aggregation in `composite' properties.
-
- Composite properties, which are specified in NASN by the
- keyword `many,' are used to associate multiple instances
- of similarly-typed TypedObjects with one property of a
- (containing) object. For example the NASN definition
-
- create type Library
- (name StringType,
- address StringType,
- holdings Book many);
-
- defines `holdings' to be a composite property of Library.
- Instantiated Library typed objects could then contain multiple
- `Book' typed objects. Composite properties properties have
- object array semantics.
-
- 3) Path-notation accelerators for nested object manipulation.
-
- For example we can write
-
- employeeObj->setPropValue("Ed Jones","dept.supervisor[3].name");
-
- to set the name of the third supervisor in this employeeObj's
- dept property to "Ed Jones."
-
- 4) Machine-independent external data representation.
-
- 5) Exposed Type, Property and TypedObject methods.
-
- Implementation hooks allow programmers to substitute alternative
- parsers and user-interfaces for the NetClasses abstract syntax
- notation. (This is partially intended as an OMG migration
- path).
- ^L
- MISCELLANEOUS INFORMATION:
-
- ---------------------------------------------------------------------------
- Transport mechanisms
- ---------------------------------------------------------------------------
-
- In the first developer's release, NetClasses includes TCP- and
- UDP-based object transport mechanisms. PostModern's Reliable
- Broadcast Protocol (now under alpha testing) is a UDP-based
- layer for _reliable_ object transport in nonconnection-oriented
- environments. The TCP, UDP, and Reliable Broadcast Protocol
- facilities are all organized as C++ class libraries.
-
- ----------------------------------------------------------------------------
- NetClasses frequently asked questions list
- ----------------------------------------------------------------------------
-
- 1) How is the beta release organized?
-
- The NetClasses beta test release is organized as three
- subdirectories. Each subdirectory enables a different
- variety of object transport, as follows:
-
- netclasses/generic:
-
- Contains class libraries and support documentation
- for writing applications that move generic C++ objects
- over a network on top of TCP/IP. Contains in particular
- the TransObject class, from which users derive existing
- classes in order to enable TCP/IP-based object transport.
- Includes streams, distributed services and Remote Method
- Invocation support libraries.
-
- netclasses/nih:
-
- Contains class libraries and support documentation
- for writing applications that move arbitrary NIH-derived
- objects over a network using TCP/IP. Includes streams,
- distributed services and Remote Method Invocation support
- libraries.
-
- netclasses/types:
-
- Contains class libraries and support documentation
- for writing distributed applications that move
- PostModern Computing's Typed Objects on top of TCP/IP.
- Users will first create NetClasses Typed Object data
- definitions in external files using the NetClasses
- Abstract Syntax Notation (NASN). The Types package C++
- API is then used in order to create, manipulate, transmit,
- and destroy objects that meet these definitions. Includes
- streams, distributed services, and Remote Method Invocation
- support libraries.
-
- By using the appropriate object transport and support
- libraries, users can move objects over TCP/IP stream
- connections. Simple code examples are included in each
- subdirectory, and they are explained in the associated
- support documentation. The RMI library allows application
- programmers a further level of abstraction in that host
- name, port number, and connection management duties are
- taken over by active processes that are called distributed
- service agents (dsagent). An application wishing to send
- objects over the network "advertises" itself to an agent as
- a service provider, while processes wishing to receive
- objects request connections to these services through
- these agents.
-
- 2) Is the beta release _really_ going to include all this software?
-
- Yes. The only things that could possibly slip are the Remote
- Method Invocation libraries. The distributed services package
- that RMI is built on top of will certainly ship in the beta
- release.
-
- 3) What information do I need to provide?
-
- We need your mailing address, the system you are using
- (e.g. SUN OS 4.1.2), and the media you would prefer (our
- default is to ship on 1/4'' cartridge tapes in QIC-150
- format). We are using Sun C++ compilers.
-
- Along with the tape, you will receive a nondisclosure
- agreement that you should sign.
-
- 4) What platforms does NetClasses run on?
-
- We are currently testing on Sun Sparcstations and HP workstations.
-
- 5) When will this software be available?
-
- We plan to ship copies to beta test sites in mid- to late-June.
-
- 6) Has retail pricing been decided upon?
-
- No.
-
- 7) Will my input to the beta testing program matter?
-
- Yes, and probably a lot. We want this product to be
- simple, modular, and useful. Most of the interest we have
- received is coming from research laboratories and
- companies that are facing similar problems to what we are
- trying to solve with these libraries.
-
- 8) What is the structure of the beta test program?
-
- We will send you the libraries, headers, and draft
- documentation. You tell us bugs and things you find
- useful or inconvenient. Sending a message to
- plambeck@xenon.stanford.edu is probably the best way to be
- heard.
-
- 9) Do I have to pay anything?
-
- Nothing except the shipping and media costs. (If we were to pay
- for the shipping we would have to limit the number of beta copies
- we ship, and we don't want to do that).
-
-
- PostModern Computing Technologies, Inc.
- 1032 Elwell Court, Suite 240
- Palo Alto, California 94303
- Telephone: (415) 967-6169
- Facsimile: (415) 967-6212
-
-
- ***************************************************************************
-
- You may like to contact
-
- ----------------------------------------------------------------------------
- Mjolner Informatics Aps Phone: +45 86 20 20 00
- Science Park Aarhus Fax: +45 86 20 12 22
- Gustav Wiedsvej 10 Email:
- mjolner@mjolner.dk
- DK-8000 Aarhus C, Denmark
- ----------------------------------------------------------------------------
-
- as they have:
-
- The Mjolner BETA System
-
-
-
- A software development environment supporting
- object-oriented programming
- in the BETA programming language
-
- I have not had a chance to experience with it, but it sounds interesting.
-
-
- **************************************************************************
- Mentat is a medium-grain dataflow CSP implementation of C++. It may be
- found at the University of Virginia and has been implemented on Suns
- and an NCube (I think.) It's shareware.
-
- Contact asst. prof. Andrew Grimshaw at grimshaw@cs.virginia.edu (or is it
- cs.uva.edu?) It's his baby.
-
-
-
- **************************************************************************
-
- You can get an extension of C++ with parallel features (called uC++)
- via anonymous ftp (number: 129.97.129.9). Sorry, but I don't know the
- exact directory (I think pub/...). There is a file u++-3.2.5.tar.Z.
-
- If you get other answers please can you forward it to me.
-
- Thank you
-
- Dietrich.
-
-
- **************************************************************************
-
- Two Concurrent OOPL's that are available in the public domain are:
-
- - Modula-3 from DEC SRC; ftp from gatekeeper.dec.com
- /pub/DEC/Modula-3/m3-??.tar.Z
-
- - uC++ from University of Waterloo; ftp from watmsg.uwaterloo.ca
- (129.97.141.9) pub/dmake/dmake38.tar.Z
-
- Hope this is to some help.
-
-
- ***************************************************************************
-
- Not public domain, but I thought I'd drop you a line just in case you
- were interested in the information.
-
- There is a whole programming tool environment which is far more
- object-orientated than the likes of Express, and PVM etc. called
- TOPSYS produced at the University of Munich (TUM - Technische
- Universitat Munchen, with a few accents here and there!!!).
-
- A few contact names if you are interested:
- Thomas Bemmerl
- Christian Kasperbauer
- Martin Mairandres
- Bernhard Ries.
-
- At least those are the names on one of the more major reports I have
- on that work!!
-
- I have an up to date Email address for Thomas Bemmerl which I found
- easily, I don't know whether I have information on the others.
- Thomas' address is bemmerl@esdc.intel.com, as he is now with Intel
- ESDC.
-
- Hope this was helpful,
-
-
-