home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 October / usenetsourcesnewsgroupsinfomagicoctober1994disk1.iso / answers / object-faq / part2 < prev    next >
Internet Message Format  |  1994-09-17  |  62KB

  1. Path: bloom-beacon.mit.edu!senator-bedfellow.mit.edu!faqserv
  2. From: Bob Hathaway <rjh@geodesic.com>
  3. Newsgroups: comp.object,comp.answers,news.answers
  4. Subject: Comp.Object FAQ Version 1.0.6 (9-15) Part 2/9
  5. Supersedes: <object-faq/part2_777166834@rtfm.mit.edu>
  6. Followup-To: comp.object
  7. Date: 17 Sep 1994 12:04:19 GMT
  8. Organization: Geodesic Systems
  9. Lines: 1349
  10. Approved: news-answers-request@MIT.Edu
  11. Expires: 31 Oct 1994 12:03:01 GMT
  12. Message-ID: <object-faq/part2_779803381@rtfm.mit.edu>
  13. References: <object-faq/part1_779803381@rtfm.mit.edu>
  14. NNTP-Posting-Host: bloom-picayune.mit.edu
  15. Summary: Frequently Asked Questions (FAQ) List and Available Systems For Object-Oriented Technology
  16. X-Last-Updated: 1994/09/15
  17. Originator: faqserv@bloom-picayune.MIT.EDU
  18. Xref: bloom-beacon.mit.edu comp.object:12651 comp.answers:7310 news.answers:25850
  19.  
  20. Archive-name: object-faq/part2
  21. Last-Modified: 9/15/94
  22. Version: 1.0.6
  23.  
  24. 2.1)  What Is Polymorphism?
  25. ---------------------------
  26.  
  27. Polymorphism is a ubiquitous concept in object-oriented programming and is
  28. defined in many ways, so many definitions are presented from: Websters',
  29. Author, Strachey, Cardelli and Wegner, Booch, Meyer, Stroustrup, and Rumbaugh.
  30. Polymorphism is often considered the most powerful facility of an OOPL.
  31.  
  32. > Webster's New World Dictionary:
  33.  
  34. Polymorphism 1. State or condition of being polymorphous.  2. Cryall.
  35.   crystallization into 2 or more chemically identical but
  36.   crystallographically distinct forms.  3.  Zool., Bot. existence of an
  37.   animal or plant in several forms or color varieties.
  38.  
  39. polymorphous adj. having, assuming, or passing through many or various forms,
  40.   stages, or the like.  Also, polymorphic. [<Gk polymorphous multiform]
  41.  
  42.  
  43. > Author's Definition:
  44.  
  45. Polymorphism is the ability of an object (or reference) to assume (be replaced
  46. by) or become many different forms of object.  Inheritance (or delegation)
  47. specifies slightly different or additional structure or behavior for an object,
  48. and these more specific or additional attributes of an object of a base class
  49. (or type) when assuming or becoming an object of a derived class characterizes
  50. object-oriented polymorphism.  This is a special case of parametric
  51. polymorphism, which allows an object (or reference) to assume or become any
  52. object (possibly satisfying some implicit or explicit type constraints
  53. (parametric type), or a common structure), with this common structure being
  54. provided by base classes or types (subclass and subtype polymorphism,
  55. respectively).
  56.  
  57. "Poly" means "many" and "morph" means "form".  The homograph polymorphism has
  58. many uses in the sciences, all referring to objects that can take on or assume
  59. many different forms.  Computer Science refers to Strachey's original
  60. definitions of polymorphism, as divided into two major forms, parametric and
  61. ad-hoc.  Cardelli and Wegner followup with another classification scheme,
  62. adding inclusion polymorphism for subtyping and inheritance.
  63.  
  64.  
  65. > Strachey's Original Definition [Strachey 67]:
  66.  
  67. "Parametric polymorphism is obtained when a function works uniformly on a range
  68. of types; these types normally exhibit some common structure.  Ad-hoc
  69. polymorphism is obtained when a function works, or appears to work, on several
  70. different types (which may not exhibit a common structure) and may behave in
  71. unrelated ways for each type."  
  72.  
  73. Parametric polymorphism is also referred to as "true" polymorphism, whereas
  74. ad-hoc polymorphism isn't (apparent polymorphism).
  75.  
  76.  
  77. > Cardelli and Wegner's Definition [Cardelli 85]:
  78.  
  79. C+W refine Strachey's definition by adding "inclusion polymorphism" to model
  80. subtypes and subclasses (inheritance).  Strachey's parametric polymorphism is
  81. divided into parametric and inclusion polymorphism, which are closely related,
  82. but separated to draw a clear distinction between the two forms, which are then
  83. joined as specializations of the new "Universal" polymorphism.
  84.  
  85.                                  |-- parametric
  86.                  |-- universal --|
  87.                  |               |-- inclusion
  88.   polymorphism --|
  89.                  |               |-- overloading
  90.                  |-- ad hoc    --|
  91.                                  |-- coercion
  92.  
  93. Polymorphic Languages: some values and variables may have more than one type.
  94.  
  95. Polymorphic Functions: functions whose operands (actual parameters) can
  96.   have more than one type.  [...] If we consider a generic function to be
  97.   a value, it has many functional types and is therefore polymorphic.
  98.  
  99. Polymorphic Types: types whose operations are applicable to operands of more
  100.   than one type.
  101.  
  102. Parametric Polymorphism: a polymorphic function has an implicit or explicit
  103.   type parameter which determines the type of the argument for each
  104.   application of that function.
  105.  
  106. Inclusion Polymorphism: an object can be viewed as belonging to many different
  107.   classes that need not be disjoint; that is, there may be inclusion of
  108.   classes.
  109.  
  110. The two forms of "Universal Polymorphism", parametric and inclusion are closely
  111. related, but are distinct enough in implementation to justify separate
  112. classifications.
  113.  
  114. Parametric polymorphism is referred to as generics.  Generics can be syntactic,
  115. where each instantiation creates a specialized version of the code allowing
  116. fast running execution, but in a "true polymorphic system", only a single
  117. implementation is used.
  118.  
  119. On inheritance is subtype polymorphism:
  120. "Subtyping on record types corresponds to the concept of inheritance
  121. (subclass) in languages, especially if records are allowed to have functional
  122. components."
  123.  
  124. Author's Notes:
  125. Implicit parametric polymorphism can be implemented with type inferencing
  126. schemes [Aho 85].  ML is prototypical in providing this facility.
  127.  
  128. Inclusion polymorphism is common and is found in languages such as Simula,
  129. Ada-9x, C++, CLOS, Eiffel and etc. (subclass polymorphism).  Smalltalk also
  130. uses inclusion polymorphism; its used in declaring classes, and subclass
  131. polymorphism is used in practice but not enforced.  For inheritance, inclusion
  132. polymorphism specifies an instance of a subclass can appear wherever an
  133. instance of a superclass is required.  For subtyping (subtype polymorphism),
  134. the same applies because all operations required by the supertype are present
  135. in the subtype (subtype is subset of supertype).  Cardelli and Wegner view
  136. classes as sets of objects (resulting in subtype objects are a subset of
  137. supertype objects, or an extensional view), as contrasted with a feature based
  138. (intensional) approach (where subtypes are supersets of (contain) supertypes).
  139. MI provides an interesting example here, as it is set intersection with an
  140. extensional view and set union with an intensional view.  Details are left as
  141. an exercise for the reader.
  142.  
  143. Ada generics and C++ templates provide explicit syntactic generics.  While
  144. Ada may infer some actual generic parameters (operations) and C++ doesn't
  145. require explicit instantiation of its template functions, formal generic
  146. parameters must still be declared and many bodies are generated.
  147.  
  148. Inclusion polymorphism can refer to subtyping, or having at least as much or
  149. more than required.  Since derived classes can inherit structure and behavior
  150. from base classes, such inheritance is an example of inclusion polymorphism
  151. with respect to representation (subclassing).  An example of inclusion
  152. polymorphism with respect to assignment (and initialization, or replacement if
  153. viewed in an almost symbolic way) occurs when object types may be specified and
  154. assignment is based on actual object membership in that type (often of the CLOS
  155. is-a-member-of form in OO).  Emerald provides another example of an object-
  156. oriented language using inclusion polymorphism with respect to replacement;
  157. however, inclusion is with respect to subtyping only with abstract types
  158. ("bounded quantification" by C+W.  C+W's parameters are subtype polymorphic
  159. but lose the inherent type).  Any object possessing all required operations is
  160. acceptable and no inheritance relation is required (subtype polymorphism).
  161. They refer to this as "best-fitting" types [Black 86].  The original Trellis/
  162. Owl also had such a facility but with two separate inheritance hierarchies,
  163. although it was abandoned in favor of a single class-based approach for
  164. simplicity.  See also section 2.7.
  165.  
  166. [As inclusion polymorphism covers both subtype and subclass polymorphism,
  167.  perhaps IP could be further divided in C+W's above classification.]
  168.  
  169.  
  170. > Booch's Definition [Booch 91, p. 517]:
  171.  
  172. polymorphism  A concept in type theory, according to which a name (such as a
  173. variable declaration) may denote objects of many different classes that are
  174. related by some common superclass; thus, any object denoted by this name is
  175. able to respond to some common set of operations in different ways.
  176.  
  177. Booch also has several sections devoted to polymorphism.
  178.  
  179. [The author notes Booch's definition above is clearly in the context of
  180.  conventional, classical OO and subclass polymorphism.]
  181.  
  182.  
  183. > Meyer's Definition [Meyer 88, sect. 10.1.5 Polymorphism]:
  184.  
  185. "Polymorphism" means the ability to take several forms.  In object-oriented
  186. programming, this refers to the ability of an entity to refer at run-time to
  187. instances of various classes.  In a typed environment such as Eiffel, this is
  188. constrained by inheritance: ...
  189.  
  190. [The Author notes Meyer has a following section 10.1.7 on Static Type,
  191.  dynamic type, which is relevant, but claims "... there is no way the type
  192.  of an object can ever change.  Only a reference can be polymorphic: ...".
  193.  Meyer is clear between the concept and the Eiffel realization in his
  194.  polymorphism definition above, but here neglects the "becomes" facility
  195.  as found in several dynamically typed OO languages such as Actors, CLOS,
  196.  Self and Smalltalk, which allows an object (and not just a reference) to
  197.  change its class.]
  198.  
  199.  
  200. > Stroustrup's Definition [Stroustrup 90, p. 209]:
  201.  
  202. The use of derived classes and virtual functions is often called "object-
  203. oriented programming".  Furthermore, the ability to call a variety of
  204. functions using exactly the same interface - as is provided by virtual
  205. functions - is sometimes called "polymorphism".
  206.  
  207. [The Author notes this is a functional view of polymorphism (as provided in
  208. C++).  [Stroustrup 91, p. 136] has an example of polymorphism with void *'s,
  209. but a newer template function is incomparably preferable, as implied in
  210. [Stroustrup 90, ch 14]]
  211.  
  212.  
  213. Rumbaugh's Definition [Rumbaugh 91, p. 2]:
  214.  
  215. "Polymorphism" means that the same operation may behave differently on
  216. different classes.
  217.  
  218.  
  219. 2.2)  What Does Polymorphism Boil Down To In OO Programming Languages?
  220. ----------------------------------------------------------------------
  221.  
  222. In C++, virtual functions provide polymorphism.  This is because a polymorphic
  223. object (pointer or reference (or such parameter)) is assignment compatible with
  224. any object of a derived class.  Is this polymorphism in itself?  Objects
  225. can take on objects of different forms (the derived classes), but of what use
  226. is it?  To make any difference, the differing forms must have some effect.  In
  227. dynamically typed languages, polymorphic objects are passed messages and will
  228. respond in whatever way the object has defined (usually starting from its most
  229. derived class and working its way up).  But for static objects, a virtual
  230. function is invoked.  This is the stored method from the derived class that
  231. overrode the virtual method from its base class, providing specialized behavior
  232. for the polymorphic object; and hence, polymorphism.  This common pure
  233. statically typed example is, of course, an example of inclusion polymorphism,
  234. subclass polymorphism to be more specific (see section 2.1).  Pure statically
  235. typed subtype polymorphism, as provided in Emerald, can be implemented
  236. similarly [Black 86].
  237.  
  238.  
  239. 2.3)  What Is Dynamic Binding?
  240. ------------------------------
  241.  
  242. Dynamic binding has two forms, static and dynamic.  Statically-typed dynamic
  243. binding is found in languages such as C++ (virtual functions) and Eiffel
  244. (redefinition).  It is not known which function will be called for a virtual
  245. function at run-time because a derived class may override the function, in
  246. which case the overriding function must be called.  Statically determining all
  247. possibilities of usage is undecidable.  When the complete program is compiled,
  248. all such functions are resolved (statically) for actual objects. Formal object
  249. usage must have a consistent way of accessing these functions, as achieved thru
  250. vtables of function pointers in the actual objects (C++) or equivalent,
  251. providing statically-typed dynamic binding (this is really just defining simple
  252. function pointers with static typechecking in the base class, and filling them
  253. in in the derived class, along with offsets to reset the receiver).
  254.  
  255. The run-time selection of methods is another case of dynamic binding, meaning
  256. lookup is performed (bound) at run-time (dynamically).  This is often desired
  257. and even required in many applications including databases, distributed
  258. programming and user interaction (e.g. GUIs).  Examples can be found in
  259. [Garfinkel 93, p80] and [Cox 91, pp 64-67].  To extend Garfinkels example with
  260. multiple-polymorphism, a cut operation in an Edit submenu may pass the cut
  261. operation (along with parameters) to any object on the desktop, each of which
  262. handles the message in its own way (OO).  If an (application) object can cut
  263. many kinds of objects such as text and graphical objects, multiple-polymorphism
  264. comes into play, as many overloaded cut methods, one per type of object to be
  265. cut, are available in the receiving object, the particular method being
  266. selected based on the actual type of object being cut (which in the GUI case is
  267. not available until run-time).
  268.  
  269. Again, various optimizations exist for dynamic lookup to increase efficiency
  270. (such as found in [Agrawal 91] and [Chambers 92]).
  271.  
  272. Dynamic binding allows new objects and code to be interfaced with or added to
  273. a system without affecting existing code and eliminates switch statements.
  274. This removes the spread of knowledge of specific classes throughout a system,
  275. as each object knows what operation to support.  It also allows a reduction in
  276. program complexity by replacing a nested construct (switch statement) with a
  277. simple call.  It also allows small packages of behavior, improving coherence
  278. and loose coupling.  Another benefit is that code complexity increases not
  279. linearly but exponentially with lines of code, so that packaging code into
  280. methods reduces program complexity considerably, even further that removing
  281. the nested switch statement!  [Martin 92] covers some of these issues.
  282.  
  283.  
  284. 2.4)  Is There A Difference Between Being A Member Or Instance Of A Class?
  285. --------------------------------------------------------------------------
  286.  
  287. Yes (but be careful of context).  To use C++ terminology, an object (not
  288. a reference) is defined to be an instance of exactly one class (in classical
  289. OO), called its most derived class.  An object not directly contained in any
  290. other is called the complete object [Stroustrup 90].  An object is a member
  291. of several classes, including all of the classes its declared (or most derived)
  292. class inherits from.  With static typing and inclusion polymorphism based on
  293. class, if a polymorphic object (or reference) is made to refer to an object,
  294. that object must be a member of the polymorphic object's class.
  295.  
  296. This also provides a good example of differing definitions among object-
  297. oriented languages, since a member is defined as above in CLOS, but a member of
  298. a class is one of its instance variables in C++.
  299.  
  300.  
  301. 2.5)  What Is The Difference Between Static And Dynamic Typing?
  302. ---------------------------------------------------------------
  303.  
  304. Static typing refers to types declared in a program at compile-time, so no type
  305. information is available on objects at run-time.  Dynamic typing uses the
  306. inherent types of polymorphic objects, keeping track of the types of objects at
  307. run-time.  Statically typed dynamic binding is a compromise (usually
  308. implemented with tables of function pointers and offsets), and is how
  309. statically-typed OO languages provide polymorphism.  Some approaches provide
  310. both static and dynamic typing, sometimes with static typing providing type-
  311. safe programs and dynamic typing providing multiple-polymorphism [Agrawal 91]
  312. [Mugridge 91].  See also section 2.3.
  313.  
  314. Static typing is more efficient and reliable, but loses power.  Typical
  315. restrictions include only allowing a common set of base class functions (or
  316. any common functions for the more general subtyping or parametric polymorphic
  317. cases) to be available on formal objects and a lack of multiple-polymorphism
  318. (see section 1.19), both of which are overcome with dynamic typing.
  319.  
  320. Many languages provide dynamic typing: Smalltalk, Self, Objective-C, and etc.
  321. A limited dynamic typing scheme, called RTTI (Run Time Type Identification),
  322. is even being considered for the C++ standard.  A similar facility to safe
  323. downcasting (historically known as type narrowing), the thrust of RTTI, can
  324. also be found in recent versions of Eiffel.
  325.  
  326. See section 3.4 for a categorization of common OO languages by type system.
  327.  
  328.  
  329. 2.6)  What Is This I Hear About ML And Functional Programming Languages?
  330. ------------------------------------------------------------------------
  331.  
  332. ML, Metalanguage, is a functional programming language with a strongly typed
  333. polymorphic type system [Wikstrom 87].  Russell (see Appendix E) is a more
  334. recent functional language and Haskell [Hudak 92] provides a more modern and
  335. "pure" example.  Section 2.5 discusses why static typing has less power/
  336. flexibility than dynamic typing and the same applies to ML (although see the
  337. appendixes for an experimental dynamic extension to ML, Alcool-90 and [Cardelli
  338. 85] for a proper placement of ML's type system).  ML doesn't use inheritance
  339. for polymorphism; unlike OO languages, but provides the prototypical example of
  340. parametric polymorphism, so no inheritance is required.  This is "true" or
  341. "pure" statically (or strongly) checked parametric polymorphism, by Strachey's
  342. (and Cardelli and Wegner's) definitions.
  343.  
  344. Smalltalk is an example of a dynamically-typed language which does not check
  345. types during assignment (and hence for parameters) and therefore provides
  346. parametric polymorphism without static constraints (by Strachey's definition).
  347. However, Smalltalk's style uses inclusion polymorphism in practise and
  348. inheritance for subclassing (representation).
  349.  
  350.  
  351. 2.7)  What Is A Separation Between Type And Class (Representation)?
  352. -------------------------------------------------------------------
  353.  
  354. For a short answer:
  355.   Subtype Polymorphism, as opposed to Subclass Polymorphism, is the best answer
  356.   in OO.  Parametric polymorphism is a related concept where this is also true,
  357.   but is of a different flavor (and usually requires object attributes by use.
  358.   See also section 2.1).
  359.  
  360. A type can be considered a set of values and a set of operations on those
  361. values.  This can insure type-safe programming.  However, the representation of
  362. types (classes in OO) can be separated from the notion of type allowing many
  363. representations per type while still maintaining reasonable type-safety.
  364.  
  365. In many languages, a type has a single representation insuring all operations
  366. performed on that type are well defined (statically bound) and providing for
  367. efficiency by taking advantage of that representation wherever used.  In many
  368. OO languages, subclassing and dynamic binding provides for greater flexibility 
  369. by providing object specialization.  However, in many OO languages classes are
  370. used for assignment compatibility forcing an assigned object to inherit
  371. (transitively) from any polymorphic object's class (inclusion polymorphism
  372. based on class, or subclass polymorphism).  This insures all operations to be
  373. performed on any polymorphic object are satisfied by any replacing objects.
  374. This also insures all types share a common representation, or at least a
  375. common base interface specification.
  376.  
  377. By separating type from class, or representation (or perhaps separating class
  378. from type, by the aforementioned definition of type), a replacing object must
  379. satisfy the operations or type constraints of a polymorphic object (subtype
  380. polymorphism) but are not required to do to do so by an inheritance relation
  381. (subclass polymorphism), as is typical in most OOPLs.  Dropping this
  382. restriction is somewhat less type-safe, because accidental matches of method
  383. signatures can occur, calling for greater care in use.  [Black 86] discusses
  384. this issue in Emerald.  The same issue arises in parametric polymorphism
  385. (generics/templates), as any method matching a required signature is accepted,
  386. calling for careful matching of actual and formal generic parameters.  The
  387. difference between static and dynamic binding in OO and dynamic binding and
  388. subtyping seems similar.  A possible loss of semantic integrity/similarity is
  389. contrasted with greater power.
  390.  
  391. It is possible to specify desired abstract properties of type specifications
  392. with mechanisms similar to Eiffel's pre-, post-, and invariant conditions.
  393. This helps to insure the semantic integrity of replacing objects and their
  394. behavior.  [Liskov 93] provides a recent exposition.
  395.  
  396. Abstract classes ([Stroustrup 91] and [Meyer 88]) in typing provide a facility
  397. similar to subtype polymorphism; however, ACs require type compatible classes
  398. to inherit from them, providing a subclass polymorphism facility, and ACs can
  399. also specify representation.  Subtyping is therefore most useful to avoid
  400. spreading knowledge of classes throughout a system, which is a high priority
  401. for loosely coupled modules and in distributed programming [Black 87].
  402.  
  403. The formal type system found in [Cardelli 85], Emerald/Jade [Black 86] and
  404. [Raj 89], original trellis/Owl, an experimental C++ extension (See Appendix E,
  405. Signatures), Sather (originally Eiffel-based), and an Eiffel superset
  406. [Jones 92] are all examples of OO systems providing subtype polymorphism.
  407. Functional languages such as ML, Russell, and Haskell provide a separation with
  408. pure parametric polymorphism (as is also commonly found in OO languages in
  409. additon to inclusion polymorphism).
  410.  
  411. See also [Cook 90], "Inheritance Is Not Subtyping", for a formal approach.
  412.  
  413.  
  414. 2.8)  What Are Generics And Templates?
  415. --------------------------------------
  416.  
  417. Short Answer: Parametric Polymorphism (although various implementations
  418.               provide various subsets).
  419.  
  420. Generics (or Templates in C++) refer to the ability to parameterize types
  421. and functions with types.  This is useful for parameterized classes and
  422. polymorphic functions as found in languages such as Ada, C++, Eiffel, and
  423. etc., although these are "syntactic" or restricted forms [Cardelli 85].
  424. Generics are orthogonal to inheritance, since types (and classes)
  425. may be generically parameterized.  Generics provide for reusability in
  426. programming languages.  An example is a Stack with a generically
  427. parameterized base type.  This allows a single Stack class to provide
  428. many instantiations such as a Stack of ints, a Stack of any fundamental
  429. or user defined type, or even a Stack of Stacks of ...  Another example is
  430. a polymorphic sort function taking a base type with a comparison operator.
  431. The function can be called with any type (containing a comparison operator).
  432. See [Booch 87b] for several examples in Ada and [Stroustrup xx] and [Murray
  433. 93] for examples in C++.
  434.  
  435. While generics have many advantages, typical limitations include a static
  436. nature, which is an advantage for strong typechecking but a potential
  437. disadvantage when causing dynamic compilation (leading to a time/space
  438. efficiency tradeoff), and sources can cause inlining and create source code
  439. dependencies and expand code size (unlike a single-body or "true"
  440. parametrically polymorphic implementation.  Generics can also be viewed as a
  441. special case of type variables.
  442.  
  443. Functions are typically generic in statically-typed parametrically-polymorphic
  444. languages.  One such popular functional language is ML, in which all functions
  445. are generic.  Russell and Haskel are more modern variants (references are
  446. forthcoming, however see APPENDIX E).
  447.  
  448.  
  449. SECTION 3:  GENERAL
  450. ===================
  451.  
  452.   References:   (many more are to come)
  453.     [Coplien 92]    Covers C++, symbolic, exemplar (single-hierarchy), etc.
  454.     [Kim 89]        Covers many OO systems.
  455.  
  456.  
  457. 3.1)  What Is The "Classical" Object-Oriented Paradigm?
  458. -------------------------------------------------------
  459.  
  460. This refers to the usual class and object model.  Its any 2+ level system
  461. as described in section 1.4.  See also [Coplien 92].
  462.  
  463.  
  464. 3.2)  What Is The "Delegation/Prototyping" Object-Oriented Paradigm?
  465. --------------------------------------------------------------------
  466.  
  467. See [Kim 89, ch 1,3].
  468.  
  469. This is the 1 Level System as Described under Meta-Classes.  Delegation refers
  470. to the delegating of responsibility and can be applied to inheritance.  When a
  471. derived class does not have a desired attribute, it "delegates" responsibility
  472. to one of its base classes.  In delegation systems, each object has a delegate
  473. list instead of a parent list. Thus, delegation's primary emphasis is 
  474. on message passing where an object could delegate responsibility of a message
  475. it couldn't handle to objects that potentially could (its delegates).  Any
  476. object can be added to the delegate list, giving dynamic inheritance (of a
  477. sort).  Typically, delegation and prototyping languages also have "part
  478. inheritance" in which fields and methods can be added and deleted from objects.
  479. This makes for easy "prototyping", which allows for objects to be constructed
  480. piece by piece at run-time, although the term "prototyping" in the context of
  481. delegation languages usually refers to objects serving as prototypes for
  482. object instantiation, or exemplars.
  483.  
  484. Next's NextStep OS provides delegation using Objective-C, providing an example
  485. of delegation in a class-based language [Garfinkel 93].
  486.  
  487.  
  488. 3.3)  Are There Any Other Object-Oriented Paradigms?
  489. ----------------------------------------------------
  490.  
  491. There are many alternatives in OO.  Emerald/Jade ([Black 86] and [Raj 89])
  492. provides one, where inheritance is replaced with a roughly equivalent form
  493. where reuse occurs at a finer degree of granularity - method and instance
  494. variables - with subtype polymorphism making up the difference.
  495.  
  496. CLOS [Kim 89, ch 4] has a looser coupling of methods to classes and doesn't
  497. distinguish a receiver, but packages can help make up the difference.
  498.  
  499. Object Specialization [Sciore 89] is an example of a hybrid approach between
  500. delegation and classical systems, where parent classes have an extra level
  501. of indirection and inheritance hierarchies are specified on a per object/class
  502. basis.
  503.  
  504.  
  505. 3.4)  What Are The Major Object-Oriented Programming Languages Today?
  506. ---------------------------------------------------------------------
  507.  
  508. Statically-Typed:
  509.   Add 1 To Cobol giving Cobol with Objects.
  510.   C++
  511.   Classic-Ada
  512.   Dragoon
  513.   Emerald/Jade
  514.   Object Pascal
  515.   Trellis/Owl
  516.  
  517. Dynamically-Typed:
  518.   Actors Languages
  519.   C+@
  520.   Flavors
  521.   Self
  522.   Smalltalk
  523.  
  524. Both:
  525.   Actor
  526.   Ada-9x
  527.   BETA
  528.   C++ (With RTTI)
  529.   Cecil
  530.   CLOS
  531.   Eiffel
  532.   Modula-3
  533.   Objective-C
  534.   Sather
  535.  
  536.  
  537. 3.5)  What Are Object-Oriented Databases And Persistence?
  538. ---------------------------------------------------------
  539.  
  540. See also Appendices B and E and the comp.database.object newsgroup.
  541. Refs to be included in future FAQs.
  542.  
  543. Object-Oriented Databases are databases that support objects and classes.  They
  544. are different from the more traditional relational databases because they allow
  545. structured subobjects, each object has its own identity, or object-id (as
  546. opposed to a purely value-oriented approach) and because of support for methods
  547. and inheritance.  It is also possible to provide relational operations on an
  548. object-oriented database.  OODBs allow all the benefits of object-orientation,
  549. as well as the ability to have a strong equivalence with object-oriented
  550. programs, an equivalence that would be lost if an alternative were chosen, as
  551. with a purely relational database.
  552.  
  553. Another way of looking at Object-Oriented Databases is as a persistent object
  554. store with a DBMS.
  555.  
  556. Persistence is often defined as objects (and their classes in the case of
  557. OODBs) that outlive the programs that create them.  Object lifetimes can be
  558. viewed as a hierarchy, with locals/automatics having the shortest default
  559. lifetime and objects stored indefinitely in an OODB (which are persistent)
  560. having the longest.  Persistent object stores do not support query or
  561. interactive user interface facilities, as found in a fully supported OODBMS.
  562.  
  563. Appendix B also contains references for relational interfaces to OODBs.
  564.  
  565.  
  566. 3.6)  What Are Object-Oriented Operating Systems?
  567. -------------------------------------------------
  568.  
  569. Refs to be included in future FAQs.  See also Appendix E.
  570.  
  571. Object-Oriented Operating Systems provide resources through objects, sometimes
  572. all the way down to to the machine (OO architectures are found at the bottom).
  573. They are almost always distributed systems (DOS or DPOS), allowing objects to
  574. be passed freely between machines.  They are typically capability-based since
  575. objects, and hence system resources, can only be accessed if a capability to
  576. them is available to programs.
  577.  
  578. Here are some abstracts taken from several postings to the net.  This list is
  579. by no means exhaustive.
  580.  
  581. Apertos (Meta-Object-based Mikro-Kernel.  See Appendix E, Papers, entry 28)
  582. Chorus Micro-kernel (written in C++, COOL, See Appendix E, Papers)
  583. Choices (research OS, UofI, C++, supports SVR4, See Appendix E, Papers)
  584. GEOS    (GeoWorks', written in Object Assembler, OO superset of 8086) 
  585. Mach    (CMU, supports BSD 4.3, really message-based)
  586. NachOS  (written in C++, OS teaching/learning OS)
  587. Ouverture Project (ESPRIT funded OMG IDL defines inter-module interfaces)
  588. Peace    (OO family-based parallel OS, See Appendix E, General)
  589. SOS
  590. Spring      (Sun, written in C++)
  591. PenPoint OS (Go, written in C++)
  592.  
  593. For the Spring Papers (free), Contact:
  594.   Sun Microsystems Laboratories, Inc.
  595.   M/S 29-01
  596.   2550 Garcia Avenue
  597.   Mountain View, CA USA  94043
  598.  
  599.  
  600. From: whitney@oberon.Meakins.McGill.CA ()
  601.  
  602. Insight ETHOS: On Object-Orientation in Operating Systems
  603. ISBN 3 72811948 2
  604.  
  605. This thesis covers the design of an extensible object-oriented 
  606. operating systems. The language used was Oberon-2. It includes
  607. a generalization of the Rider/Carrier principle, Object Directories
  608. as well as basic OS issues such as memory, file, tasking management. 
  609. It covers extensible objected-oriented programming from hardware up.
  610. It reviews other designs such as Clouds and Choices which where written
  611. It reviews other designs such as Clouds and Choices which where written
  612. on C++. [[ The lack of type-tests in C++ was a problem in other designs.]]
  613. ETHOS was implemented as an operating system for the Ceres computers
  614. at the ETH. 
  615.  
  616.  
  617. 3.7)  What Are The Current Object-Oriented Methodologies?
  618. ---------------------------------------------------------
  619.  
  620. Here is a list of OOSE Methodologies:
  621.  
  622.   Berard                        [Berard 93]
  623.   BON                           [Nerson 92]
  624.   Booch                         [Booch 94]
  625.   Coad/Yourdon                  [Coad 91]
  626.   Colbert                       [Colbert 89]
  627.   de Champeaux                  [de Champeaux 93]
  628.   Embley                        [Embley 92]
  629.   EVB                           [Jurik 92]
  630.   FUSION                        [Coleman 94]
  631.   HOOD                          [HOOD 89]
  632.   IBM                           [IBM 90,91]
  633.   Jacobson                      [Jacobson 92]
  634.   Martin/Odell                  [Martin 92]
  635.   Reenskaug (OOram, was OORASS) [Reenskaug 91]
  636.   ROOM                          [Selic 94]
  637.   Rumbaugh et al.               [Rumbaugh 91]
  638.   Shlaer and Mellor             [Shlaer 88 and 92]
  639.   Wasserman                     [Wasserman 90]
  640.   Winter Partners (OSMOSYS)     [Winter Partners]
  641.   Wirfs-Brock et al.            [Wirfs-Brock 90]
  642.  
  643. Further Ideas And Techniques:
  644.   Meyer                         [Meyer 88]
  645.   Stroustrup                    [Stroustrup 91]
  646.  
  647. See APPENDIX D for CASE systems supporting these methodologies (several from
  648. the originators themselves).
  649.  
  650. See also section 1.21 for a discussion on OOA/OOD and etc.
  651.  
  652. Summaries and comparisons will be provided in future FAQs.  Suggestions for
  653. inclusion of other major or new methodologies should be sent to the FAQ author.
  654.  
  655. Here are some comparison studies posted to the net:
  656.  
  657. Arnold, P., Bodoff, S., Coleman, D., Gilchrist, H., Hayes, F., An Evolution of 
  658. Five Object Oriented Development Methods, Research report, HP Laboratories, 
  659. June 1991
  660.  
  661. de Champeaux, Dennis and Faure, Penelope. A comparative study of object-
  662. oriented analysis methods. Journal of Object Oriented Programming (JOOP), pp
  663. 21-32.  Vol.5, No. 1, 3/4-92
  664.  
  665. Fichman R.G. & Kemerer C.F.  OO and Conventional Analysis and Design
  666. Methodologies.  Computer, Oct 1992, Vol 25, No. 10, p 22-40
  667.  
  668. Fichman, Robert and Kemerer, Chris. Object-Oriented and Conventional Analysis
  669. and Design Methods - Comparison and Critique.  IEEE-Comp, Oct, 1992, pp 22-39.
  670. OOA, OOD, conventional analysis, conventional design, DeMarco SA, Yourdon SA,
  671. Bailin OO requirements specification, Coad-Yourdon OOA, Shlaer-Mellor OOA,
  672. Yourdon-Constantine SD, Martin information engineering design, Wasserman OOSD,
  673. Booch OOD, Wirfs-Brock responsibility-driven design.
  674.  
  675. Hong, S., van den Goor, G., and Brinkkemper, S.  A Comparison of Object-
  676. oriented Analysis and Design Methods. Working paper, Computer Information
  677. Systems Department, Georgia State University, Atlanta USA, 1992, 12 pages. To
  678. appear in the Proceedings of the 26th Hawaiian international conference on
  679. System Sciences, IEEE Computer Science Press.
  680.  
  681. Hong, S., van den Goor, G., Brinkkemper, S. A Formal Approach to the Comparison
  682. of Object-Oriented Analysis and Design Methodologies, Hawaii International 
  683. Conference on System Sciences (HICSS) (IEEE Computer Society Press, Hawaii)
  684. 1993, Vol. IV, pp. 689-698.  Summary of [van den Goor et.al., 1992] below.
  685.  
  686.   Order procedure:
  687.   Available from the authors at cisssh@gsusgi2.gsu.edu or sjbr@cs.utwente.nl.
  688.   The authors, regretfully, cannot supply ftp, postscript, TEX, or 
  689.   whatsoever.
  690.  
  691. Monarchi, David and Puhr, Gretchen I. A Research Typology for Object-Oriented
  692. Analysis and Design.  CACM/September 1992/Vol.35, No.9, pp35.
  693.  
  694. [Wilkie 93] summarizes, compares, and provides examples of Booch, Wirfs-Brock,
  695. Hood, Coad and Yourdon, Winter Partners, Shlaer and Mellor, Jacobson,
  696. Wasserman et al, Rumbaugh, Reenskaug et al, and Colbert.
  697.  
  698. Wirfs-Brock, R.J. and Johnson, R.E., "Surveying Current Research in Object-
  699. Oriented Design," The Communications of ACM, (33, 9) Sept. 1990, pp. 104-1124.
  700.  
  701. UNICOM. Approaches to Object-Oriented Analysis and Design.
  702. tel: l 44 895 256 484. Ask the TOC and have a look at it.
  703.  
  704.  
  705. Also commercially available:
  706.  
  707. An Evaluation of Object-Oriented Analysis and Design Methodologies (9)
  708. J. Cribbs, C Roe, S. Moon
  709. SIGS Books
  710. (212) 274-0640
  711. $149.
  712.  
  713. Object-Oriented Methodology Comparison Study (10 methodologies)
  714. Berard, Booch, Coad/Yourdon, Colbert, Embley, IBM, Martin/Odell, Rumbaugh,
  715. Shlaer/Mellor, Wirfs-Brock.  Also contains refs to several previous studies.
  716. Berard Software Engineering
  717. 101 Lakeforest Blvd., Suite 360, Gaithersburg, MD 20877
  718. Contact Person: Jim Youlio
  719. Phone:        301-417-9884
  720. Fax:          301-417-0021
  721. email:        info@bse.com
  722.  
  723. [van den Goor et.al., 1992] G. van den Goor, S. Hong and S. Brinkkemper,
  724. A Comparison of Six Object-oriented Analysis and Design Methods. Report
  725. Center of Telematics and Information Technology, University of Twente,
  726. the Netherlands, and Computer Information Systems Department, Georgia
  727. State University, Atlanta, USA, 1992, 163 pages, US$ 70.
  728.  
  729. This report gives an in-depth analysis of six generally accepted
  730. O-O methods, that are available in textbooks. The background, steps,
  731. concepts, notations, and specification techniques of the methods
  732. are extensively compared.
  733.  
  734. The six methods are:
  735. -  Object Oriented Analysis & Object Oriented Design (OOA/OOD) of Coad &
  736.       Yourdon (1991)
  737. -  Designing Object Oriented Software (DOOS) of Wirfs-Brock et.al. (1990)
  738. -  Object Modelling Technique (OMT) of Rumbaugh et.al. (1991)
  739. -  Object Oriented Systems Analysis (OOSA) of Shlaer & Mellor (1988)
  740. -  Object Oriented Design with Applications (OODA) of Booch (1991)
  741. -  Object Oriented Analysis and Design (OOAD) of Martin & Odell (1992).
  742.  
  743. The comparison is performed by meta-modelling, resulting into detailed
  744. information on the concepts of the methods (in EER notation) and on the
  745. steps of the procedure of the methods (in Task Diagrams). Extensive
  746. comparison tables of steps, concepts, techniques are included. Mappings of
  747. the methodical concepts to the constructs of programming languages (C++,
  748. Objective-C, Smalltalk-80, Object Pascal en CLOS) are given. A small
  749. test case illustrates the application of the methods.
  750.  
  751. Order procedure:
  752. Those who want to order the complete report (163 pp.) can order one by
  753. specifying their postal address in an e-mail (sjbr@cs.utwente.nl) or fax
  754. (+31.53.33.9605) attn. Sjaak Brinkkemper. The report will be send within
  755. two weeks with an invoice for US$ 70. (seventy dollar; including shipping,
  756. excl VAT).
  757.  
  758.  
  759. 3.8)  What Is the OMG/OMA/ORB/CORBA?
  760. ------------------------------------
  761.  
  762. Contents:
  763.   (3.8.1)  Contact Information
  764.   (3.8.2)  OMG Summary
  765.   (3.8.3)  Mail Server Access
  766.   (3.8.4)  OMG Publications
  767.              - First Class (Bi-Monthly Newsletter)
  768.              - Object Management Architecture Guide (OMA)
  769.              - The Common Object Request Broker: Arch. and Spec. (Corba)
  770.              - Pricing
  771.   (3.8.5)  Implementations (Brief)
  772.   (3.8.6)  Implementation Descriptions
  773.   (3.8.7)  Books, Articles, And Literature
  774.  
  775.  
  776. 3.8.1  Contact Information
  777. __________________________
  778.  
  779. Contact Person: Richard Soley (technical director) soley@omg.com
  780.  
  781. FTP Sites: 
  782.   omg.org:pub/*
  783.   omg.org:pub/NEC_DII/93-1-2.tar...            *CORBA (DII) (corba.ps.Z)
  784.   omg.org:pub/OMG_IDL_CFE_1.2/bin*              idl.SunOS4.x, idl.Solaris2.x
  785.   claude.ifi.unizh.ch:under pub/standards/spec  CORBA Spec
  786.  
  787. Headquarters:                            Marketing Office:
  788.   492 Old Connecticut Path                 3823 Birchwood Drive
  789.   Framingham, MA 01701                     Boulder, CO  80304
  790.   Tel: 508-820-4300                        Tel: 303-444-8129
  791.   Fax: 508-820-4303                        Fax: 303-444-8172
  792.  
  793.  
  794. 3.8.2  OMG Summary
  795. __________________
  796.  
  797. From: soley@emerald.omg.ORG (Richard Mark Soley)
  798. Subject: OMG
  799.  
  800. In answer to your general question about the OMG, here's a brief overview.
  801. Feel free to call, fax or email for more information.
  802.  
  803.         -- Richard Soley
  804.            Vice President & Technical Director
  805.            Object Management Group, Inc.
  806.            and coincidentally, MIT '82, SM '85, PhD '89 (EECS)
  807.  
  808. The Object Management Group (OMG) is an international software industry
  809. consortium with two primary aims:
  810.  
  811. (*) promotion of the object-oriented approach to software engineering
  812.     in general, and
  813.  
  814. (*) development of command models and a common interface for the development
  815.     and use of large-scale distributed applications (open distributed
  816.     processing) using object-oriented methodology.
  817.  
  818. In late 1990 the OMG published its Object Management Architecture
  819. (OMA) Guide document. This document outlines a single terminology for
  820. object-oriented languages, systems, databases and application
  821. frameworks; an abstract framework for object-oriented systems; a set
  822. of both technical and architectural goals; and an architecture
  823. (reference model) for distributed applications using object-oriented
  824. techniques.  To fill out this reference model, four areas of
  825. standardization have been identified:
  826.  
  827. 1) the Object Request Broker, or key communications element, for
  828.    handling distribution of messages between application objects in
  829.    a highly interoperable manner;
  830.  
  831. 2) the Object Model, or single design-portability abstract model for
  832.    communicating with OMG-conforming object-oriented systems;
  833.  
  834. 3) the Object Services, which will provide the main functions for
  835.    realising basic object functionality using the Object Request Broker -
  836.    the logical modeling and physical storage of objects; and
  837.  
  838. 4) the Common Facilities will comprise facilities which are useful in
  839. many application domains and which will be made available through OMA
  840. compliant class interfaces.
  841.  
  842. The OMG adoption cycle includes Requests for Information and
  843. Proposals, requesting detailed technical and commercial availability
  844. information from OMG members about existing products to fill
  845. particular parts of the reference model architecture.  After passage
  846. by Technical and Business committees to review these responses, the
  847. OMG Board of Directors makes a final determination for technology adoption.
  848. Adopted specifications are available on a fee-free basis to members and
  849. non-members alike.
  850.  
  851. In late 1991 OMG adopted its first interface technology, for the Object
  852. Request Broker portion of the reference model.  This technology, adopted
  853. from a joint proposal (named "CORBA") of Hewlett-Packard, NCR Corp.,
  854. HyperDesk Corp., Digital Equipment Corp., Sun Microsystems and Object
  855. Design Inc. includes both static and dynamic interfaces to an inter-
  856. application request handling software "bus."
  857.  
  858. Unlike other organizations, the OMG itself does not and will not
  859. develop nor sell software of any kind.  Instead, it selects and promulgates
  860. software interfaces; products which offer these interfaces continue to be
  861. developed and offered by commercial companies.
  862.  
  863. In order to serve OMG membership interested in other object-oriented systems
  864. arenas besides the distributed system problem, the Group supports Special
  865. Interest Groups for discussion of possible standards in other areas.  These
  866. groups at present are:
  867.  
  868.         1) Object Oriented Databases;
  869.         2) OO Languages;
  870.         3) End-User Requirements;
  871.         4) Parallel Processing;
  872.         5) Analysis & Design Methodologies;
  873.         6) Smalltalk; and
  874.         7) Class Libraries.
  875.  
  876. Any company, university/research institution or individual, whether
  877. end-user or vendor, can become a member of this body.  Administrative
  878. details are given at the end of this paper.
  879.  
  880.  
  881. 3.8.3  Mail Server Access
  882. _________________________
  883.  
  884. Information via Mail Server:
  885.   Send the following commands in a letter to the mail server.
  886.  
  887. mail omg_server@omg.org
  888. help                             (how to use file server)
  889. index                            (return a list of all available files)
  890. get <file>                       (get files returned by  index)
  891. log <info>                       (logs info on server)
  892. address <e-mail address)         (use this address instead of sender)
  893. list <directory> [match]         (index a directory, pattern 'match' files)
  894. size <segment size>              (max file size to send)
  895.  
  896. list mail
  897. list docs
  898. get docs/doclist.txt             
  899. get docs/91-12-1.ps               CORBA spec [although it looks a little old]
  900.  
  901.  
  902. Recommended (from the net):
  903.  
  904. mail omg_server@omg.org
  905. Subject: 
  906. help
  907. index
  908. list
  909. list mail
  910. list docs
  911. get docs/doclist.txt
  912.  
  913.  
  914. 3.8.4  OMG Publications
  915. _______________________
  916.  
  917. Below is from omg.org:pub/CORBA
  918.  
  919.  
  920. > First Class (Bi-Monthly Newsletter)
  921.  
  922. First Class is OMG's non-commercial bi-monthly 28-page
  923. newsletter. First Class provides current information on Object
  924. Technology developments, both technically and commercially. First
  925. Class offers an open editorial forum on numerous Object
  926. Technology topics and issues.  This publication features
  927. commentaries from software industry leaders, informative user
  928. case histories, OT training information and the latest object-
  929. oriented product announcements.  All OMG activities and the
  930. ongoing development of the Object Management Architecture are
  931. regularly reported.
  932.  
  933.  
  934. > Object Management Architecture Guide (OMA)
  935.  
  936. The members of the OMG have a shared goal of developing and using
  937. integrated software systems.  These systems should be built using
  938. a methodology that supports modular production of software;
  939. encourages reuse of code; allows useful integration across lines
  940. of developers, operating systems and hardware; and enhance long-
  941. range maintenance of that code.  As an organization, OMG believes
  942. that the object-oriented approach to software construction best
  943. supports their goals.  The OMA publication outlines the
  944. groundwork for technology response to Request for Proposals (RFP)
  945. and the adoption of specifications.
  946.  
  947.  
  948. > The Common Object Request Broker: Arch. and Spec. (Corba)
  949.  
  950. The CORBA, as defined by the OMG's Object Request Broker (ORB),
  951. provides the mechanisms by which objects transparently make
  952. requests and receive responses. The ORB provides interoperability
  953. between applications on different machines in heterogeneous
  954. distributed environments and seamlessly interconnects multiple
  955. object systems. The Common Object Request Broker Architecture and
  956. Specification described in this published document is a self-
  957. contained response to the Request for Proposals (RFP) issued by
  958. the ORB Task Force of the OMG.
  959.  
  960. > Pricing
  961.  
  962. [Here's why you don't see the specifications posted to the net or available via
  963.  ftp!  These are from the list of literature and periodicals listed in
  964.  omg.org:pub/CORBA]
  965.  
  966. o I would like a one year subscription to First Class
  967.     ______ for $40 U.S.,  ______ for $50 outside U.S.
  968.  
  969. o I would like to order  ______ copy(s) of the Object Management
  970.   Architecture (OMA) Guide for $50 each.
  971.  
  972. o I would like to order  ______ copy(s) of the CORBA for $50 each.
  973.  
  974. o [Combinations]
  975.  
  976. Contact documents@omg.org or omg_documents@omg.org for more of the same...
  977.  
  978.  
  979. 3.8.5  Implementations (Brief)
  980. ______________________________
  981.  
  982. > DEC ObjectBroker Version 2.5  (Version 2.1 was ACA)
  983.  
  984. Full implementation of OMG CORBA 1.1
  985.  
  986. Digital's ObjectBroker is a 100 % compliant implentation of CORBA and
  987. is availlable on these  platforms:
  988.     IBM AIX
  989.     IBM MVS      (port in progress)
  990.     HP-UX
  991.     Macintosh
  992.     MS-Windows 3.1
  993.     NT
  994.     OSF/1
  995.     SunOS
  996.     ULTRIX
  997.     Digital  VAX/VMS
  998.     Digital OpenVMS
  999.  
  1000. Contact:
  1001.  
  1002. Andrew Comas
  1003. comas@nyo.dec.com  (212) 856-2507
  1004. Digital Equipment Corporation.
  1005. ObjectBroker
  1006. 110 Spit Brook Road
  1007. Nashua, New Hampshire  03062-2698
  1008.  
  1009.  
  1010. > HP ORB Plus and HP Distributed Smalltalk
  1011.    Full implementation of the OMG CORBA 1.1 Object Request Broker. Also DOMF.
  1012.  
  1013.    Hewlett-Packard
  1014.    Distributed Computing Group
  1015.    19447 Pruneridge Avenue
  1016.    Cupertino, CA 95014-9974 (USA)
  1017.    Ian Fuller ian@cup.hp.com (408) 447-4722
  1018.  
  1019. > HyperDesk (Westborough MA) HD-DOMS, joe_cordo@hyperdesk.com
  1020.    Runs on SPARC, HP/UX, IBM RS-6000, Data General Aviion, MS-Windows (client
  1021.    API only), NetWare (planned, Novell owns part of HyperDesk).
  1022.  
  1023. > IBM SOM (System Object Model)
  1024.    Available on AIX and OS/2.  See Distributed Computing Monitor, March 93 for
  1025.    a detailed review.
  1026.  
  1027. > ILU (free, see APPENDIX E entry 59)
  1028.    Object RPC compatible with OMG CORBA 1.2 spec (will compile OMG IDL and
  1029.    generate OMG compliant code for OMG-specified languages).
  1030.    parcftp.parc.xerox.com:/pub/ilu/ilu.html
  1031.  
  1032. > IONA Technologies, Dublin Orbix, info@iona.ie
  1033.     runs on (Unix (Solaris 1.1) (now), DOS, Windows, NT (planned)
  1034.  
  1035. > NCR 'Cooperative Frameworks' -- a Distributed Object Foundation
  1036.   (1) C++ ORB toolkit consisting of over 300 C++ classes and runtime libraries
  1037.   (2) CORBA 1.1 toolkit
  1038.  
  1039. > ROLSCH CONSULTING (RC-ORB)
  1040.   Implements ORB spec, DOS/Windows 3.1, 12 user license: $99.
  1041.   Ref: Datamation, LOOK AHEAD Section, August 1.  German Company.
  1042.  
  1043. > SuiteSoftware (Anaheim CA) SuiteDOME
  1044.     runs on VAX/VMS, Unix, PC
  1045.  
  1046. > Sun DOE
  1047.  
  1048. > Tivoli
  1049.  
  1050. > CS Dept. University of Zurich, Switzerland.  maffeis@ifi.unizh.ch
  1051.     The ELECTRA Toolkit (not finished)
  1052.  
  1053.  
  1054. 3.8.6  Implementation Descriptions
  1055. ___________________________________
  1056.  
  1057. The OMG also has a (Corporate) Membership list and "known CORBA supporters"
  1058. list with their info package.
  1059.  
  1060.  
  1061. > The ELECTRA Toolkit
  1062.  
  1063. CS Dept. University of Zurich, Switzerland.  maffeis@ifi.unizh.ch
  1064. The ELECTRA Toolkit
  1065.  
  1066. Subject: ORB Implementations
  1067. Date: Tue, 4 May 1993 13:12:36 +0200 (MET DST)
  1068. From: Silvano Maffeis <maffeis@ifi.unizh.ch>
  1069.  
  1070.   something like an Object Broker, but it is *not* CORBA compatible (yet).
  1071.   Electra is a research project and not available yet.
  1072.  
  1073.   Its a toolkit for building failure resilient, distributed applications
  1074.   in C++. It supports object-groups, virtual synchrony, multithreading
  1075.   etc. Electra is based on the HORUS toolkit (which is "the new ISIS
  1076.   implementation" developed at Cornell, Ithaca NY.)
  1077.   An overview paper to electra is available from:
  1078.   ftp.ifi.unizh.ch: pub/techreports/electra.ps.Z
  1079.  
  1080.  
  1081. > HD_DOMS
  1082.  
  1083. HD-DOMS (HyperDesk Distributed Object Management System).  A
  1084. CORBA-compliant DOMS.  Includes a GUI API driver for prototyping and
  1085. exercising objects, a bundled object database for persistent object
  1086. storage, a Kerberos-based authentication service, a location service, a
  1087. set of base classes to speed development, and a test script language.
  1088. Revision 1.0 has been shipping since beginning of '92.  Revision 1.1
  1089. (which includes support for CORBA's static client interface) is available
  1090. now, and a NetWare version is in the works.  Submitted a C++ language
  1091. mapping for IDL to the OMG recently.
  1092.  
  1093. HyperDesk Corporation
  1094. 2000 West Park Drive
  1095. Westboro, MA 01581
  1096. (508)366-5050
  1097.  
  1098.  
  1099. > HP ORB Plus and HP Distributed Smalltalk
  1100.  
  1101.   ============================================================================
  1102.   SUBJECT:  HP INTRODUCES DISTRIBUTED-COMPUTING SOLUTION FOR BUILDING
  1103.             SCALABLE, OBJECT-ORIENTED APPLICATIONS
  1104.   DATE:     September 27, 1993
  1105.   ----------------------------------------------------------------------------
  1106.  
  1107.    PALO ALTO, Calif.--(BUSINESS WIRE) via First! -- Hewlett-Packard Company
  1108.  today introduced a distributed-computing solution for building scalable,
  1109.  object-oriented applications.
  1110.  
  1111.    With HP ORB Plus, programmers can develop scalable, object-based
  1112.  applications that can be distributed throughout the enterprise.  HP also
  1113.  introduced an enhanced version of HP Distributed Smalltalk.
  1114.  
  1115.    HP ORB Plus and HP Distributed Smalltalk are major components of HP's
  1116.  overall distributed-computing strategy, which is designed to give customers
  1117.  integrated, desktop access to enterprise-wide information and resources in
  1118.  distributed heterogeneous systems environments.  Of all computer companies,
  1119.  HP believes it is best positioned to help customers take advantage of
  1120.  distributed computing. HP provides a wide variety of distributed-computing
  1121.  products, understands how to help customers adopt new technology for maximum
  1122.  business benefit, and offers worldwide support and training programs,
  1123.  ranging from analysis and design to deployment.
  1124.  
  1125.    HP ORB PLUS:  CORBA AND DCE COMBINED
  1126.  
  1127.    HP ORB Plus is the only environment that combines the complete CORBA 1.1
  1128.  specification from the Object Management Group with the DCE standard from
  1129.  the Open Software Foundation(tm) as its transport mechanism.  DCE is
  1130.  designed to let developers write one application and then deploy it --
  1131.  without modification -- on any other system that supports DCE.  HP ORB Plus
  1132.  reduces the complexity of developing distributed applications so programmers
  1133.  can concentrate on the application itself without needing to know multiple
  1134.  operating systems, networking protocols or where application objects are
  1135.  stored.
  1136.  
  1137.    The DCE (Distributed Computing Environment) standard provides an
  1138.  integrated set of services that can be used separately or together to
  1139.  provide a distributed computing environment that's easy to administer.  The
  1140.  CORBA (common-object-request-broker architecture) specification provides a
  1141.  standard for how objects (in applications, repositories or class libraries)
  1142.  make requests and receive responses across a distributed network.
  1143.  
  1144.    HP ORB PLUS DETAILS
  1145.  
  1146.    HP ORB Plus consists of several components: the Distributed Object
  1147.  Management Facility (DOMF), object services, developers' and administrative
  1148.  tools, and sample applications.  HP's DOMF provides a location-transparent
  1149.  object-communication mechanism across heterogeneous networks by using the
  1150.  DCE standard.  This object- enabling technology specification was jointly
  1151.  developed with SunSoft. By following a common specification, HP and SunSoft
  1152.  have made it easier for their customers to port applications between their
  1153.  platforms.
  1154.  
  1155.    In addition, HP is working with IBM to integrate HP's DOMF with IBM's
  1156.  System Object Model with extensions for distribution.  This integration will
  1157.  eventually provide users with complete scalability, portability and
  1158.  interoperability of distributed applications across HP and IBM platforms.
  1159.  This is part of the companies' planned approach toward a standards-based,
  1160.  "plug-and-play"  object-oriented environment.  This will give developers,
  1161.  system administrators and end users language-neutral, enterprise-wide,
  1162.  heterogeneous support for building, managing and using distributed object-
  1163.  oriented applications.
  1164.  
  1165.    "We're so convinced of the value of object technology that we're staking
  1166.  our entire company on it,"  said Richard Tanler, president and chief
  1167.  executive officer of Information Advantage, Inc.  "Our object-based
  1168.  applications for retailers provide the means to a competitive business edge.
  1169.  We plan to use HP ORB Plus to develop new object-based products that
  1170.  retailers can distribute to end users throughout headquarters, all chain
  1171.  stores, and warehousing and distribution operations."
  1172.  
  1173.    HP DISTRIBUTED SMALLTALK 2.0
  1174.  
  1175.    In a related announcement, HP introduced Version 2.0 of HP Distributed
  1176.  Smalltalk.  This toolset works with VisualWorks from ParcPlace Systems to
  1177.  provide programmers with a rapid development environment for creating and
  1178.  running distributed applications.  These applications can use object
  1179.  databases (currently OpenODB from HP and Gemstone from Servio) as their
  1180.  storage mechanism to facilitate the reuse of objects.
  1181.  
  1182.    Applications built using HP Distributed Smalltalk currently run without
  1183.  modification on HP, Sun and IBM UNIX(R) system-based workstations.  They
  1184.  also will run on Apple Macintosh computers and on any PC running the Windows
  1185.  3.1 or Windows NT operating systems from Microsoft(R) Corp., once
  1186.  VisualWorks 2.0 is released (expected within two months.)
  1187.  
  1188.    New HP Distributed Smalltalk 2.0 features include the following:
  1189.  
  1190.    --  easier deployment, with the ability to run multiple HP
  1191.        Distributed Smalltalk-based applications on a single system;
  1192.    --  up to 400 percent increased performance, through quicker
  1193.        sending and receiving of remote messages, and reusable
  1194.        object libraries;
  1195.    --  run-time version, for full production deployment; and
  1196.    --  easier development, with remote object browsing so
  1197.        developers can find and use objects more quickly.
  1198.  
  1199.    TECHNICAL DETAILS AND AVAILABILITY
  1200.  
  1201.    HP's DOMF includes the object request broker, interface- definition-
  1202.  language compiler, static and dynamic invocation interface and interface
  1203.  repository.  In addition to these OMG-specific features, most developers
  1204.  writing distributed, object-oriented applications require additional
  1205.  interfaces to use objects effectively.  So developers don't need to create
  1206.  their own, HP has supplied several object-service interfaces for developers
  1207.  to use. That's why HP ORB Plus includes OMG interfaces and implementations
  1208.  for properties, life cycle, associations, event notification and naming.
  1209.  
  1210.    HP's limited release of HP ORB Plus to key developers is designed so that
  1211.  customer input can be incorporated into the product early in its development
  1212.  cycle.  The initial version will work with the C++ programming language.
  1213.  For the generally available Developer's Kit, C++, C and Smalltalk
  1214.  interoperability is planned so objects written in different languages can be
  1215.  combined into one application.  The Developer's Kit is scheduled to be
  1216.  available mid- 1994; prices will be announced then.  HP ORB Plus runs on the
  1217.  HP Apollo 9000 Series 700 workstations and HP 9000 Series 800 business
  1218.  servers.
  1219.  
  1220.    Hewlett-Packard Company is an international manufacturer of measurement
  1221.  and computation products and systems recognized for excellence in quality
  1222.  and support.  The company's products and services are used in industry,
  1223.  business, engineering, science, medicine and education in approximately 110
  1224.  countries.  HP has 94,900 employees and had revenue of $16.4 billion in its
  1225.  1992 fiscal year.
  1226.  
  1227.  EDITORIAL CONTACTS:
  1228.     Hewlett-Packard Company
  1229.     Lynne Hanson, 408/447-1415, Cupertino, Calif.
  1230.     Jill Kramer, 408/447-4275, Cupertino, Calif.
  1231.  
  1232.  ==================
  1233.    For more information about HP ORB Plus, contact Kathy Litch
  1234.    (litch_k@apollo.hp.com).
  1235.  
  1236.    For more information about HP Distributed SmallTalk, contact
  1237.    Jerry Boortz (jerry_boortz@hp4000.desk.hp.com).
  1238.  
  1239.  
  1240. > Iris RDOM
  1241.  
  1242. From: rcbc@cs.cornell.edu (Robert Cooper)
  1243. Subject: Re: DCE vs. CORBA
  1244. Reply-To: rcbc@isis.com
  1245. Product: Isis Reliable Distributed Object Manager(tm) (RDOM)
  1246. Company: Isis Distributed Systems, Inc., Ithaca NY, USA.
  1247.  
  1248. Isis RDOM(tm) is a fault tolerant distributed ORB platform for reliable
  1249. multi-lingual object-oriented applications. RDOM provides an "object group"
  1250. paradigm for constructing complex applications out of collections of
  1251. cooperating objects. RDOM is built on top of the Isis Distributed
  1252. Toolkit(tm). RDOM provides interfaces from Smalltalk (Parcplace),
  1253. Objective-C, and C++, and runs on most Unix workstations. RDOM is currently
  1254. not CORBA compliant, but will be brought to compliance during 3Q93.
  1255.  
  1256. Status: 
  1257.  
  1258. RDOM has been at beta test sites since January. General release of
  1259. the Smalltalk and Objective-C language interfaces is expected in June.
  1260. The C++ interface in August. Customers include AMD, Consilium and Swiss
  1261. Bank Corp).  
  1262.  
  1263.  
  1264. > Orbix
  1265.  
  1266. Orbix
  1267. Iona Technologies Ltd.
  1268. 8-34 Percy Place
  1269. Dublin 4
  1270. Ireland
  1271.  
  1272. The latest release of Orbix, Version 1.2, includes an Object Loader function 
  1273. for the first time, as well as an upgraded Interface Repository, a new
  1274. approach to filtering, and more code examples to guide programmers. 
  1275.  
  1276. Orbix was launched in June 1993 as the first full and complete implementation 
  1277. of the Object Management Group's (OMG's) Common Object Request Broker
  1278. Architecture (CORBA) standard.  With Orbix, programmers can develop
  1279. distributed, object oriented applications following a consistent and
  1280. straightforward, standards-based model. 
  1281.  
  1282. With Orbix Version 1.2 IONA has added the ability to dynamically load objects 
  1283. at runtime through its Object Loader function. This enables developers to more 
  1284. easily integrate Orbix applications with existing data stores be they 
  1285. traditional flat file databases, relational databases or object oriented
  1286. databases. 
  1287.  
  1288. The improved Interface Repository is an integral part of IONA's CORBA 
  1289. implementation. The Interface Repository operates as a dynamic browser which is
  1290. populated with all objects or services available at runtime keeping programmers
  1291. informed of the functions, attributes and characteristics of objects and 
  1292. services. 
  1293.  
  1294. In version 1.2 IONA has also extended the whole approach to filtering of 
  1295. requests, and has made it easier for users to integrate Orbix with their
  1296. security systems providing for improved reliability of distributed systems
  1297. built using Orbix. IONA has also extensively extended the number, and scope, of
  1298. code examples it ships with the product to help developers learning how to use
  1299. the system. 
  1300.  
  1301. IONA released Orbix for SunSoft Solaris and SunOS at the Object World 
  1302. exhibition in San Francisco, Calif., June 1993.  Since then it has rolled
  1303. out versions of Orbix for Microsoft Windows NT,  Silicon Graphics IRIX  and
  1304. HP/UX. IONA demonstrated a version of Orbix for Microsoft Windows 3.1 at
  1305. Object World in London, England last October.  Orbix for Microsoft Windows
  1306. 3.1 is now in beta.  In January 1994, IONA and SunSoft Inc. signed an
  1307. agreement to align their implementations of CORBA. The two companies
  1308. demonstrated interoperability between IONA's Orbix running on Microsoft
  1309. Windows 3.1 and SunSoft's Distributed Objects Everywhere (DOE) on Solaris.
  1310.  
  1311. In addition Orbix-TP, integration with Tuxedo for transaction processing, has 
  1312. just entered beta testing. Work is underway on Orbix-FT, integration with
  1313. the Isis distributed system, will deliver a fault-tolerant ORB.
  1314.  
  1315. Paul Hickey,                                        tel: +353-1-6686522
  1316. Iona Technologies Ltd.,                             fax: +353-1-6686573
  1317. 8-34 Percy Place,                                   email: pth@iona.ie
  1318. Dublin 4
  1319. Ireland
  1320.  
  1321. Availibility
  1322. ------------
  1323. SunOs, Solaris, HP-UX, IRIX, Ultrix(beta), Unixware(beta), NT, Windows3.1(Beta)
  1324.  
  1325.  
  1326. > NCR 'Cooperative Frameworks' -- a Distributed Object Foundation
  1327.  
  1328. From: Randy Volters <randy.volters@columbiasc.ncr.com>
  1329. Subject: re-post: NCR Cooperative Frameworks (new phone no.)
  1330.  
  1331. November 19, 1993
  1332.  
  1333. NCR ANNOUNCES BETA AVAILABILITY
  1334. OF 'Cooperative Frameworks' -- 
  1335. a Distributed Object Foundation
  1336.  
  1337. Product Background -
  1338. NCR Cooperative Frameworks(TM) were first released for sale 
  1339. in 10/1991 as "the frameworks" part of the NCR COOPERATION(TM) 
  1340. product, and are based on NCR's submission to OMG.  
  1341. Cooperative Frameworks release 3.0 makes the product 
  1342. available apart from COOPERATION. 
  1343.  
  1344. Product Description -
  1345. Cooperative Frameworks is a distributed object foundation 
  1346. for building computing applications and services on networks 
  1347. of heterogeneous computers.
  1348.  
  1349. Cooperative Frameworks consists of an integrated suite of 
  1350. C++ class libraries that:
  1351.  
  1352.     -    defines and implements a comprehensive enterprise 
  1353.         architecture and methodology for creating 
  1354.         distributed implementations of C++ classes over 
  1355.         networks
  1356.  
  1357.     -    allows customers to build and use object services 
  1358.         over a network 
  1359.  
  1360.     -    supports TCP/IP, NetBIOS, Lan Manager NetBEUI and 
  1361.         OSI protocols, X.25
  1362.  
  1363. NCR Cooperative Frameworks currently has two portable ORB 
  1364. toolkits (others are planned for future release) -- 
  1365. (1) C++ ORB toolkit consisting of over 300 C++ classes and 
  1366.     runtime libraries
  1367.  
  1368. (2) CORBA 1.1 toolkit  Both are for:
  1369.