The Impact of Research on the Development of Middleware ... · has had on the development of middleware technology. We undertake an existence proof rather than attempt a comprehensive

The Impact of Research on the Development ofMiddleware TechnologyWolfgang EmmerichDept. of Computer Science, UCL, Gower Street, London, WC1E 6BT, UKandMikio AoyamaNanzan University, 27 Seirei, Seto 489-0863, JapanandJoe SventekDept. of Computing Sciences, University of Glasgow, Glasgow GG12 8QQ, UK

The middleware market represents a sizable segment of the overall Information and Communication Technologymarket. In 2005, the annual middleware license revenue was reported by Gartner to be in the region of 8.5 billionUS Dollars. In this article we address the question whether research had any involvement in the creation of thetechnology that is being sold in this market? We attempt a scholarly discourse. We present the research methodthat we have applied to answer this question. We then present a brief introduction into the key middleware con-cepts that provide the foundation for this market. It would not be feasible to investigate any possible impactthat research might have had. Instead we select a few very successful technologies that are representative forthe middleware market as a whole and show the existence of impact of research results in the creation of thesetechnologies. We investigate the origins of web services middleware, distributed transaction processing middle-ware, message oriented middleware, distributed object middleware and remote procedure call systems. For eachof these technologies we are able to show ample influence of research and conclude that without the researchconducted by PhD students and researchers in university computer science labs at Brown, CMU, Cambridge,Newcastle, MIT, Vrije, and University of Washington as well as research in industrial labs at APM, AT&T BellLabs, DEC Systems Research, HP Labs, IBM Research and Xerox PARC we would not have middleware tech-nology in its current form. We summarise the article by distilling lessons that can be learnt from this evidencedimpact for future technology transfer undertakings.

Categories and Subject Descriptors: D.2.7 [Software Engineering]: Software Architectures; D.4.4 [Operat-ing Systems]: Communications Management; H.2.4 [Database Management]: Systems; D3.3 [ProgrammingLanguages]: Language Constructs and Features; K.1 [The Computer Industry]: ; K.2 [History of Comput-ing]:

This report was written as part of the ACM SIGSOFT sponsored Impact project, which was funded jointly byThe Institution of Electrical Engineers and the National Science Foundation.Permission to make digital/hard copy of all or part of this material without fee for personal or classroom useprovided that the copies are not made or distributed for profit or commercial advantage, the ACM copyright/servernotice, the title of the publication, and its date appear, and notice is given that copying is by permission of theACM, Inc. To copy otherwise, to republish, to post on servers, or to redistribute to lists requires prior specificpermission and/or a fee.c© 20YY ACM 0000-0000/20YY/0000-0002 $5.00

Permission to make digital/hard copy of all or part of this material without fee for personal or classroom useprovided that the copies are not made or distributed for profit or commercial advantage, the ACM copyright/servernotice, the title of the publication, and its date appear, and notice is given that copying is by permission of theACM, Inc. To copy otherwise, to republish, to post on servers, or to redistribute to lists requires prior specificpermission and/or a fee.c© 20YY ACM 0000-0000/20YY/0000-0002 $5.00

ACM Journal Name, Vol. V, No. N, Month 20YY, Pages 2–0??.

2 · Emmerich, Ayoama and Sventek

1. INTRODUCTION

Various commercial trends have led to an increasing demand for integrated systems.Firstly, the number of mergers and acquisitions of companies is rising. The different di-visions of a newly merged or acquired company have to deliver unified services to theircustomers and this usually demands an integration of their IT systems. The time availablefor delivery of such an integration is often so short that building a new system is not anoption and therefore existing system components have to be integrated into a system thatappears as an integrating computing facility. Secondly, time to market requirements arebecoming more stringent. Increasingly the only approach to meeting delivery schedules isthe procurement of components off-the-shelf and their subsequent integration into a dis-tributed system. Components to be integrated may have incompatible requirements fortheir hardware and operating system platforms; they might have to be deployed on differ-ent hosts, forcing the resulting system to be distributed. Finally, the Internet provides newopportunities to offer products and services to a vast number of potential customers. Inthis setting, it is difficult to estimate the scalability requirements. An e-commerce site thatwas designed to cope with a given number of transactions per day may suddenly find itselfexposed to demand that is by orders of magnitude larger. The required scalability cannotusually be achieved by centralized or client-server architectures but demands a distributedsystem architecture.

Distributed systems can integrate legacy components, thus preserving investment, theycan decrease the time to market, they can be scalable and tolerant against failures. Thecaveat, however, is that the construction of a distributed systems is considerably more dif-ficult than building a centralized system. This is because there are multiple points of failurein a distributed system, system components need to communicate with each other through anetwork, which complicates communication and opens the door for security attacks. Mid-dleware has been devised in order to conceal these difficulties from application engineersas much as possible; Middleware is commonly defined as a software layer between ap-plications and operating systems that provides application programmers with higher levelof abstractions, such as remote procedure invocation, reliable message exchange or trans-actions. These abstractions considerably simplify distributed system construction and asa result middleware products are rapidly being adopted in industry [Charles 1999] andmiddleware is generally perceived as a success technology.

Though there is anecdotal evidence for middleware successes, it is very hard to quantifyhow successful middleware technology really is. An indicator might be how widely usedmiddleware products are. Again those data are hard to obtain as the fact that someone hasdownloaded or installed an open source middleware or bought a license for a middlewareproduct does not necessarily mean they are actively using it. However it is not necessarilyrequired to have precise data here to get an impression and license revenue may serveas a useful approximation. A recent Gartner study by [Correira and Biscotti 2006] hasdetermined that the world-wide market for middleware and application integration productshas grown in 2005 to 8.5 billion US Dollars in annual license revenue. Figure 1 shows anoverview of the market share that various middleware vendors had in 2005.

When interpreting these numbers, it is worthwhile to bear in mind that the overall eco-nomic activity that critically depends on middleware is considerably larger for a numberof reasons. Firstly, there are a significant number of deployments of open source middle-ware, such as JBoss [Fleury and Reverbel 2003]. According to the Gartner study JBossACM Journal Name, Vol. V, No. N, Month 20YY.

Impact of Research on the Development of Middleware · 3

3,159.40

1,232.50

739.4

397.1314.4

2,657.30

0.00

500.00

1,000.00

1,500.00

2,000.00

2,500.00

3,000.00

3,500.00

IBM BEA Oracle Microsoft Tibco Others

Vendor

Mil

lio

n U

S $

Fig. 1. Middleware License Revenue in 2005

had 10 million installations in 2005 but JBoss is available free of charge and it thereforeis not reflected in Figure 1. Secondly, in addition to license revenues, middleware ven-dors have often significant revenues in professional services, which are not included here.Thirdly, the total significance of the application server market is larger yet as IBM, BEA,Oracle, Microsoft and Tibco rely on third-party integration service providers to deliver thebulk of their professional services and finally, the full economic significance of middle-ware can only be understood when we also take into account the wealth that distributedapplications whose construction has been enabled with middleware create in domains suchas e-commerce, finance, entertainment and education.

The principle contribution of this article is a scholarly account of the impact that researchhas had on the development of middleware technology. We undertake an existence proofrather than attempt a comprehensive account of any influence that research results mighthave had. Our key findings, which will be refined further in this paper, are shown inFigure 2. The figure uses a notation that we will define more formally in Figure 3.

We document that distributed transactions, which are crucially important for any Javaapplication server product, are standardized in the Java 2 Transaction API, which in turnbuilds on the CORBA Object Transaction Service. The CORBA OTS was defined by ateam that involved Graeme Dixon, who completed a PhD thesis on object transactions inthe Arjuna project at the University of Newcastle. The OTS also defines the concept ofNested Transactions, which were defined in the PhD thesis of Elliot Moss at MIT.

A second constituent specification for any J2EE application server is the Java Messag-ing Service (JMS) that enables asynchronous and reliable exchange of messages betweendistributed Java objects. JMS standardized interfaces to message queuing products and weare able to trace these products back to research undertaken by Skeen at Teknekron and towork done on the Broadcast Message Service that Steven Reiss devised for tool integrationin the Field software development environment.

ACM Journal Name, Vol. V, No. N, Month 20YY.


BEA Tuxedo, IBM Encina

[OMG 94] OTS

[Dixon et al 89]Arjuna

[Dixon 88]Recoverability

[Moss 80]Nested

Transactions

[Sun 01] EJB & JTA

BEA WLS, IBM WebSphere,

JBoss AS

[Sun 01] JMS

[Skeen 92]InformationBus

[Reiss 87]Field

TIBCO TIBDEC MQ

BEA MQ

DEC Fuse

RPC Systems

[IETF 88] ONC

[Birrel&Nelson 84]Cedar RPC

[Nelson 81]RPC

[Lauer 79]Mesa

[DeRemer&Kron 76]Module Interconnection Languages

[APM 88]ANSA

[OMG 91] CORBA

[Birrel & Nelson 93]Network Objects

[Waldo 98] RMI

[Sun 01] RMI IONA Orbix

DEC Object BrokerHP Distr. Smalltalk

Apache AxisMicrosoft .NET

Eclipse WTP

[W3C 03] SOAP & WSDL

[W3C 98] XML

[W3C 86] SGML

[Goldfarb 81]GML

[Reid 81]Scribe

[Bal 89] Orca

[Hutchinson 87]Emerald

Fig. 2. Overview of impact of research on Middleware

The Java RMI specification is again crucially important for any application server toenable synchronous communication between Java objects that reside in different Java Vir-tual Machines. RMI was defined at Sun by a team led by Jim Waldo. In an early paperdescribing RMI, Waldo identified the key influences that Modula-3 Network Objects hadon RMI. Network objects were defined by Andrew Birrell and Greg Nelson Digital SystemResearch. Birrell and Nelson state in their paper that they have merely consolidated andsimplified earlier research results and refer to a number of systems, including Emerald,whose type system was defined in Hutchinson’s PhD thesis and by Orca, whose objectmodel was defined in Bal’s PhD thesis.

A similar impact trace that features Andrew Birrell’s earlier work exists for Remote Pro-cedure Call systems, that were standardized by the IETF. The ONC Request for Commentrefers to the work by Birrell and Nelson at Xerox as the origin of the concept. Bruce Nel-son had previously completed his PhD on RPC systems at CMU and it was rendered usablewhen Xerox built the Cedar programming environment. For the purpose of defining RPCinterfaces, the Cedar RPC system used a language called Mesa, which had abstractions formodule interconnection purposes.

Finally, the latest form of middleware, such as Enterprise Service Buses, uses web ser-vice technology, which implements the World-Wide-Web Consortium’s SOAP and WSDLspecifications. Don Box, the first author of the first W3C note on SOAP, gave a historic ac-ACM Journal Name, Vol. V, No. N, Month 20YY.


count on the origins of SOAP and he acknowledges that the team have used concepts fromRPC systems and CORBA. A similar statement exists for WSDL in a paper co-authored byFrancisco Curbera, who is a co-author of the WSDL specification. Both SOAP and WSDLare XML languages and XML traces back to the ISO SGML standard, which was definedby a team involving Goldfarb. Goldfarb had earlier defined IBM’s Markup Language GMLand in a retrospective paper on GML identified Scribe as giving the key ideas. Scribe wasdefined as part of Brian Reid’s PhD thesis at CMU. The first CORBA specification waswritten by Joe Sventek and Jim Waldo while they were at HP Labs (and before Waldowent on to work at Sun). Sventek had earlier worked on the ANSA middleware, whichwas very influential on the ISO/Open Distributed Processing Reference Model. ANSA ex-tends an RPC model with object-oriented concepts and acknowledges Birrell and Nelson’swork on RPCs.

This paper is further structured as follows: We will discuss the research method that usein this report in Section 2, which includes identifying the different classes of evidence thatwe admit for proving impact. We introduce the notion of impact traces and the graphicalrepresentation used in Figure 2, which relate these pieces of evidence to show the historyof how a particular concept got introduced into a product or standard. In Section 3, wewill present the main middleware concepts that are necessary to follow the discussion. InSections 4-8, we will present the impact traces that show the relationship between researchresults and successful middleware products. In Section 9, we discuss lessons about indus-trial adoption of research that can be learnt for future technology transfer and Section 10concludes the paper.

2. RESEARCH METHOD

We note that the nature of this research is considerably different from those normally pub-lished in ACM Journals. This project reflects on the influence that research results of thepast have had on middleware technology. The project is therefore more akin to the disci-pline of history of science than software engineering research and in many ways it increasesthe level of reflection in that research itself is now the subject of our investigation.

Since the research method we apply may be novel to readers, we think it appropriate todescribe the method first. It was influenced by sibling working groups in the Impact projectwith whom we have exchanged our experience and informed by the project’s History ofScience expert, but there are several aspects that are special to the relationship betweenmiddleware technology and academic and industrial research, our subject of interest.

In this section, we first address the different forms of evidence that we are prepared toadmit to document that a method, technique, specification or idea has influenced some-thing else. We then introduce the notion of an impact trace that captures the trail from asuccessful standard, product or method back to its origins in research. We finally discussthe different methods that we have used for finding evidence of influence or impact.

2.1 Evidence of Impact

Gartner’s recent report confirms that the middleware market is significant. At the sametime it is quite fragmented and the different technologies we consider here are in differentfragments of the middleware market. It is therefore insufficient to just state how large theoverall market is but we have to determine the market relevance of the particular technologyunder consideration. To perform that assessment, we use evidence extracted from marketstudies conducted by professional market research firms, such as Forrester, Gartner, Ovum



and IDC. The aim of these firms is to systematically advise investors and decision makersin the IT industry on current market trends, including the quantitative value of particularmarket segments. Although they have to be interpreted carefully, they are useful to give anindication on how intensively middleware is being used in practice. Once evidence for anexistence of a middleware market has been established, the next set of questions that needsanswering is from where companies obtained the ideas, languages, methods, techniquesand principles that they use in middleware products and services.

When inventing a new technique, idea or method companies often take steps to protecttheir intellectual property. They do so using national or international patents. The patentoffices typically force companies to disclose prior art in the area and explain the relation-ship between the new invention and the prior art. Fortunately, these patent documents arepublicly accessible and form important pieces of evidence.

Vendors of middleware products and services do not encourage scholarly discipline foracknowledging the origin of ideas in the same way as academics do in scientific publica-tions. On the contrary it is often advantageous for career development if engineers do notdisclose the origin of ideas in writing. In order to trace the source of ideas we will also haveto admit oral testimonials of engineers, who made key decisions on building products. Wetherefore record and archive each interview with these engineers to provide this evidence.

An important vehicle for the exchange of ideas between research institutions and ven-dors of middleware products and services is the movement of people who know aboutthese ideas. Together with testimonials, we are therefore also prepared to admit evidenceof impact if someone, who completed a piece of research in a university or industrial re-search lab, moves on to a middleware product or service vendor and provides a recordedtestimony of what ideas they have taken along and used in their new job.

Fortunately, we do not just need to rely on such oral accounts. Companies form de-factostandardization bodies and contribute intellectual property to the standardization effort. Infact, the middleware industry is heavily driven by both de-jure and de-facto standards, suchas the Common Object Request Broker Architecture of the Object Management Group,ISO’s Open Distributed Processing standard and the Java Community Process that adoptedvarious middleware standards. There are certification authorities, such as the OpenGroupthat formally certify that particular products comply to a standard and we take such certi-fication as evidence that the product complies with and therefore uses the main ideas andprinciples that have been incorporated in the standard. Even if no formal certification isavailable but if companies claim that they comply to the standard we are prepared to usethat as evidence that they have used the ideas embodied in the standard when developingtheir products.

Standards may have reference implementations. These reference implementations aresometimes provided by research institutions. We regard the exchange of such referenceimplementations as important evidence for impact. More generally, the use and inspectionof prototypes built in research institutions by industrial middleware vendors is significant.Such exchange is generally achieved by downloads from ftp or web servers and we will belooking for the download logs to provide evidence for such use of prototypes and referenceimplementations.

The documents that define the standard themselves lay out the principles, ideas andtechniques used in the standard and sometimes they explicitly reference the source of thoseideas. We consider these as very significant pieces of evidence for the sake of this study.ACM Journal Name, Vol. V, No. N, Month 20YY.


However, absence of any citations in a standard documents does not necessarily mean thatthere was no impact.

Standardization bodies provide another source of evidence that we use. In particular, thestandardization process of the OMG and the Java Community Process are open processesand they are minuted to record the decisions that have been made together with their ratio-nale. We are therefore also prepared to admit the minutes of these meetings as evidencefor this study.

Moreover, the communication in international standardization bodies is typically widelydistributed and therefore heavily driven by electronic communication. In many cases, thiscommunication is also archived for future reference. We are prepared to admit email ex-change and notes posted to bulletin boards of standardization bodies if they can be at-tributed to individuals and explicitly reference the origin of an idea, principle, method ortechnique, possibly in an academic paper.

Citations of academic papers are among the strongest form of evidence that we can findfor the purpose of this study. We will look for those citations in textbooks that are used toteach students, professional books, standards, case study reports and white papers and inscientific papers themselves. The academic papers that we are prepared to admit are ref-ereed publications, either in national or international conferences, symposia or workshopsor in scientific journals published by either professional societies, such as the ACM, IEEEor IEE or by professional publishers, such as Wiley or Kluwer.

2.2 Impact Traces

The Impact project aims to show how research influenced products and industrial bestpractices. [Redwine and Riddle 1985] showed that it takes a significant period of time forsoftware engineering research results to be incorporated into products and industrial bestpractices. In most cases, impact of research that was published in an academic journal orpresented at an international conference will not be directly picked up by some productdevelopment teams but its influence will be more indirect.

The aim of this study is therefore to relate individual pieces of evidence into an impacttrace, which uses the different forms of evidence discussed above to show the researchorigins of successful middleware products and best practices for their application. In mostcases, these impact traces will not necessarily be linear lists, but rather a directed acyclicgraph. It is important to align impact traces in time to form a time line, which gives thedirection of edges in the graph. In this report we show these traces graphically in graphswith time progressing from bottom to top. We differentiate between the different forms ofimpact by using different lines as shown in Figure 3.

The impact traces also follow certain patterns. In particular, near the root there areindications of evidence on how successful a particular product or method is. Evidencerelated to standards or applied research papers will be found in the middle of these traces,while leaves will have to be scientific publications in journals and conferences or PhDtheses.

We note that it is difficult to relate middleware to a particular computer science researchdiscipline. Middleware does not occur in the ACM classification of computer science and istherefore not (yet) a discipline in its own right, even though conferences that focus on mid-dleware have been created in the last ten years. We expect impact traces for middleware tocross boundaries to computer science disciplines and in particular between programminglanguages, databases, distributed systems and software engineering research. Given the



[Standards Body 2001]Standard

[Author 1998]Prototype

[Author 2000]A Paper

[Another Author 1996]A PhD Thesis

[A Vendor 2003]A Product

CitationStandard Implementation

Use of Concept

People Movement

Inclusion of Source Code

Fig. 3. Legend for Impact Traces

sponsorship of this paper by ACM SIGSOFT and its publication in a software engineeringjournal, we are particularly interested in impact of software engineering research. Indi-cations for whether an article or paper describes “software engineering research” may bedrawn from co-sponsorship of the conference where the paper was presented. If the confer-ence is sponsored or co-sponsored by the IEEE Technical Council of Software Engineeringor the ACM Special Interest Group on Software Engineering or if the editorial board of ajournal is largely composed of members of either of these groups then this can be taken asstrong evidence that the paper describes software engineering research. On the other handpapers might be published by general journals, such as CACM or IEEE Computer.

2.3 Finding Impact Traces

Now that we have discussed the different kinds of evidence that we are prepared to admitas evidence for impact and introduced the notion of impact traces, we can focus on howwe obtain impact traces in a systematic manner.

A main source of impact will be references in research papers published in journals andconference proceedings. While the authors and contributors to this report have a reason-able grasp on the middleware literature, purely relying on this knowledge would deliveronly partial results. In order to construct paths in impact traces related to citations in aca-demic papers, we are therefore going to rely on citation databases, such as Google Scholar,Citeseer or the ACM Portal to Computing Literature. The advantage of this approachis that it directly reveals impact traces. The disadvantage is that the knowledge base ofGoogle Scholar, Citeseer or the ACM Portal to Computing Literature, while continuouslyimproving, is still not complete.

A more complete knowledge base digital libraries and portals, such as those providedby IET Inspec, SpringerLink, ACM and the IEEE. Information retrieval in these databasesare now accessible via the Web and candidate papers can then be downloaded in elec-tronically. The ability to search in Portable Document Formats, the most commonly usedrepresentation in digital libraries greatly improves our search for impact traces.

Information retrieval techniques can also be used to obtain impact traces in the mailinglist archives and meeting minutes of standards bodies, such as the OMG. In particular,the OMG minutes are accessible by search engines, such as Google and Google can beACM Journal Name, Vol. V, No. N, Month 20YY.


constrained to only search, for example the OMG web site.The above techniques will not support finding impact traces that involve evidence that is

not generally accessible, either because it is not available on a public web site or becauseit may not even be accessible in an electronic form. We will therefore also revert to discus-sions with the original engineers, who were involved in building the successful projects.Any such discussion will be recorded in order to make the evidence mentioned verballytractable.

3. MIDDLEWARE CONCEPTS

This section introduces all important middleware concepts that the reader who is not nec-essarily familiar with distributed systems will require to understand the remainder of thisarticle.

The first mention of the term ’middleware’ with the meaning that it has today was madeby Alex d’Agapeyeff at the 1968 NATO Software Engineering Conference in GarmischPartenkirchen. On Page 23 of [Randell and Naur 1969], d’Agapeyeff is reported to havestated that middleware is layered between applications and “service routines and controlprograms”, which we would today refer to as operating systems. At the time of the NATOconference and for a long time thereafter, d’Agapeyeff was the managing director of Com-puter Analysts & Programmers in London. Anthony Hardcastle, one of d’Agapeyeff’semployees gave a talk at a 1972 meeting on “Developments in Computer Auditing” of theLondon and District Society of Chartered Accountants. The subject of Hardcastle’s talkwas “file design and organization, programming and testing” and during the talk Hardcastleexplained the term “middleware”. A brief summary of the talk was published in the journalAccountant [Jenkins 1972]. The article states: “A comparatively new term ’middleware’was introduced because, as some systems had become ’uniquely complex,’ [sic] standardoperating systems required enhancement or modification; the programs that effected thiswere called ’middleware’ because they came between the operating system and the ap-plication programs”. The Accountant article [Jenkins 1972] is referenced by the OxfordEnglish Dictionary as the etymological origin of the term “middleware”1

The term middleware was made popular in the computer science literature in a CACMarticle by [Bernstein 1996]. In-line with d’Agapeyeff’s and Hardcastle’s definition, theterm ’middleware’ today is regarded as a layer between network operating systems and ap-plications that aims to resolve heterogeneity and distribution [Bernstein 1996; Emmerich2000]. A distributed system has one or more component on more than one host. For thesystem to appear as an integrated computing facility these components need to commu-nicate with each other [Colouris et al. 1994]. In theory, components could communicateby directly using the primitives that network operating systems provide. In practice, thisis too complex as application programmers would have to synchronize the communica-tion between distributed component that execute in parallel, transform application leveldata structures into byte streams or datagrams that can be transmitted by network transportprotocols and resolve the heterogeneity of data representation on different hardware archi-tectures. The main aim of middleware is to simplify these tasks and provide appropriateabstractions that application programmers use when building interacting distributed system

1We have written to the editors of the Oxford English Dictionary to suggest that Alex dAgapeyeff’s talk at theNATO Software Engineering Conference be cited as the etymological origin of the term middleware rather thanChartered Accountant meeting summary by [Jenkins 1972].



components. We now define the most successful abstractions that are widely supported bymiddleware products.

Fig. 4. Middleware in a Distributed System

The first key middleware abstraction that was defined in the distributed systems litera-ture are remote procedure calls (RPCs). The principle idea of a remote procedure call isto enable application programmers to invoke a procedure that is deployed, and executes,on a remote host in a similar way as they would invoke a local procedure. In order toachieve this, remote procedure call systems have to accomplish a number of tasks. Firstly,the RPC would need to map complex application level data types that are passed as pa-rameters and results into a transport representation that can be transmitted using the bytestream or datagram transport protocol primitives that network operating systems typicallyprovide. This mapping process is referred to as marshalling in the literature. Secondly,the RPC system might have to transform data representations as the hardware, operatingsystem and programming language on the client and server host cannot be assumed to bethe same. For example, alphanumeric data may use different encoding schemes, such asASCII or ECBDIC, mainframes and personal computers use different number represen-tation schemes, different programming languages represent character strings differently,and so on. Resolution of data heterogeneity is typically achieved by RPC systems throughmapping to and from a standardized serialization format, sometimes also referred to as astandardized data representation. Thirdly, the client that invokes the RPC and the serverthat performs the RPC are generally executing in parallel. In order to mimic the behaviourof local procedure calls that block the caller until the called procedure terminates, RPCsynchronization blocks the RPC client until the remote procedure call either completed orfailed. Finally, due to the existence of multiple points of control, failures in distributedsystems are more likely to occur. RPC systems therefore need to define a richer failuresemantics.

Figure 5 shows the common aspects of the architecture of most RPC systems. The cen-tral architectural element are stubs, which perform synchronization, marshalling, mappinginto a standardized data representation and the network communication. These stubs aresometimes also referred to as proxies as they represent proxies of the server objects forclients and proxies of the client objects for servers. One of the key insights of early RPCsystems was that it is actually hard to build stubs manually and it became common to gen-erate them automatically. RPC systems typically define some form of interface definitionlanguage (IDL) that is used to determine the signatures of remote procedure calls. RPCACM Journal Name, Vol. V, No. N, Month 20YY.


RPC Runtime

Client Server

ClientStub Registry Server

StubActivationInterfaces

Fig. 5. Architecture of RPC systems

systems come with an IDL compiler that is then used to generate stubs automatically. Insome approaches the interface definition language may be separate of a programming lan-guage, in which case a programming language binding needs to be defined that determineshow IDL language primitives are represented in the programming language.

Since RPCs were first introduced the, key principles, most notably the synchronous in-vocation of an operation on a remote host have been reused in different circumstances.Distributed object systems were defined as an object-oriented extensions of RPC systemsand their interface definition languages include primitives to express inheritance, exceptionhandling, late binding and polymorphism. The invocation of a remote invocation in a dis-tributed object system is often referred to as an object request. Modern programming lan-guages, such as Java, now natively support remote method invocations that are essentiallyRPCs of methods that are hosted in another Java Virtual Machine. Finally, web servicesevolved from RPCs by using XML for defining a service interface definition language andalso as a standardized data representation.

Once remote procedure call systems were gaining popularity, application designers hadto build systems that were reliable, fault-tolerant and concurrently usable. A key ab-straction that aided in this respect is the notion of a distributed transaction. DistributedTransactions are sequences that typically contain more than one remote procedure call.Transactions are atomic, consistent, isolated and durable. Transactions had been definedand used earlier [Gray 1978] in database management systems, but the distributed transac-tions required middleware support as server component might work on different databases.These abstractions are commonly provided by transaction processing middleware that issometimes also referred to as transaction processing monitors (TPMs) [Bernstein 1990].These TPMs implement a two-phase commit protocol that allows transactional resourcemanagers, such as databases and message queues to first decide whether they are able tocommit a transaction and once all participating resource managers agree to commit theTPM then asks them to perform the commit.

Remote procedure calls and transactions are useful abstractions when interaction be-tween distributed system components is fundamentally synchronous. There are also sit-uations when an asynchronous interaction style is more appropriate. For example, whendistributed systems operate in different time zones and are not guaranteed to be availableit might be preferential to buffer communication. Likewise, architectures that have high



throughput requirements often demand buffering of requests in order to ensure constant uti-lization of processors. Such asynchronous interaction is today mostly implemented usingmessage passing abstractions that are provided by message oriented middleware (MOM).Message-oriented middleware provides message queues through which messages can besent asynchronously and reliably between distributed system components. Message queuescan persistently store messages so that they survive failures of the messaging middlewareor the receiver. Message queues typically support point-to-point communication. Mes-sage queues also support distributed transactions so that messages can be en-queued andde-queued under transaction control. Message-oriented middleware products often alsoimplement publish/subscribe based communication that permits one message to be sent tomultiple recipients.

Message queues, remote procedure calls and transaction middleware have been inte-grated in application server products. Application servers provide a distributed componentmodel that supports the remote invocation of operations. The life cycle and activation ofdistributed components is often controlled by a container. When the first remote call to acomponent is made the container activates the component, i.e retrieve the component statefrom persistent storage and transfers it into a state so that it can serve the call. In modernapplication servers these requests can be made synchronously using a remote procedurecall or they can be triggered asynchronously when a message arrives on a message queue.Application servers also support the notion of transactions and the container might startand terminate distributed transactions on behalf of every component operation that is ex-ecuted so that application programmers do not have to implement transaction protocolsthemselves. Application servers are to date frequently employed in the implementation ofservice-oriented architectures. We now discuss the origins of this technology.

4. MIDDLEWARE FOR SERVICE-ORIENTED COMPUTING

Since its debut in 2000, Web service technologies have been evolving at an astonishingspeed. A number of specifications related to Web services and Service Oriented Architec-tures (SOA) have already been standardized and an even larger number are currently underdevelopment. Since Web services are platform technology, the impact of Web servicesto software development practice is tremendous. A good introduction into web servicestechnology is provided by [Weerawarana et al. 2005].

The core technologies supported by any web services offering are the SOAP2 [Boxet al. 2000; Gudgin et al. 2003], the Web Services Description Language (WSDL) [Chris-tensen et al. 2001; Chinnici et al. 2004] and the Business Process Execution Language(BPEL) [Andrews et al. 2003]. It is these technologies that the majority of service ori-ented architectures in enterprises build upon. We now trace the origin of these middlewaretechnologies but first again sketch their relevance.

SOAP and WSDL received instant enthusiasm when they were first introduced in 2000.However, due to their very nature as platform technologies, it required a few years todevelop supplemental technologies such as the sizable Web Service Security specifica-tions [Nadalin et al. 2004], as well as to gain enough technical maturity and expertise todevelop distributed applications using Web services. To date Web services provide a uni-versal and common infrastructure for building distributed systems. Such infrastructure is

2SOAP used to be an acronym for Simple Object Access Protocol. However, in the latest W3C specificationSOAP is used as a noun in its own right.



indispensable to federate applications across organizational boundaries.Web services are now implemented by all application server products, including Mi-

crosoft BizTalk server, BEA’s Web Logic Server, IBM’s Websphere, Oracle ApplicationServer, JBoss and various other open source offerings. The resulting impact of Web ser-vices is tremendous. According to a Forrester Research survey, some 50% of large en-terprises are using Service Oriented Architectures (SOA) now or will use it by the end of2006 [Heffner et al. 2006]. It should be noted that Web service technologies are not a merecomputing platform. They have started to change software business modeling, from sellingsoftware to selling services over the Web, and the way of developing a business. Thus, theimpact of Web services and SOA are beyond computing [Hagel and Brown 2002; Bieber-stein et al. 2005]. We now discuss the origins of the main constituent specifications thatform the basis of web services technology.

4.1 Simple Object Access Protocol

SOAP is a standard messaging format based on the eXtensible Markup Language (XML).SOAP provides a mechanism to represent an object invocation and its response in XMLmessages that that are then transmitted using an underlying network transport protocol.SOAP can be used with bindings for both synchronous and asynchronous protocols, suchas HTTP or SMTP. Thus, SOAP is independent of transport protocols. SOAP supportstwo messaging styles, RPC (Remote Procedure Call) and document-literal. We show theimpact traces that led to the definition of SOAP in Figure 6.

SOAP is often implemented in a web server or a web container, which includes ApacheAxis and Microsoft IIS (Internet Information Services). Application servers that providedirect support for SOAP, which include BEA Web Logic Server, Fujitsu Interstage Appli-cation Server, IBM WebSphere Application Server, IONA Artix, and Microsoft BizTalkServer. Implementations of tool kits for processing SOAP messages include the ApacheAxis toolkit available in Java and C++, the IBM Web Services Toolkit, and the MicrosoftSOAP Toolkit. There are also several open source SOAP processors implemented in Perl,PHP and Ruby.

The currently valid and widely used definition of SOAP in Version 1.2 was adopted asa World-Wide-Web Consortium Recommendation in June 2003. The SOAP developmentstarted in 1998 and SOAP went through a number of revisions. The evolution of the SOAPspecification is documented by the first author of the initial Note published by the WorldWide Web consortium on SOAP in [Box 2001]. In this report, Box states essentially thatSOAP emerged directly from earlier RPC protocols by pointing out that “we looked at theexisting serialization formats (ASN.1 BER, NDR, XDR, CDR, JRMP) and RPC protocols(GIOP/IIOP, DCE/DCOM, RMI, ONC) and tried to hit the sweet spot that would satisfythe 80% case elegantly but could be bent to adapt to the remaining 20% case.” Thus Boxstates that SOAP has been influenced by, and been built upon, remote procedure call anddistributed object technologies. We will discuss the origins of these distributed object andRPC technologies in Sections 7 and 8.

4.2 eXtensible Markup Language

SOAP uses the eXtensible Markup Language (XML) [Bray et al. 1998] as the encodingfor requests and reply data that is transmitted between the client and the server involvedin a web service invocation. A language for defining XML type systems was not wellelaborated when the SOAP effort started. In particular, XML did not yet have a schema



[IBM, 2004]WebSphere

[Microsoft, 2004]BizTalkServer

[Box et al, 2000]SOAP 1.1

[Apache, 2004]Axis

[BEA, 2004]WebLogicServer

[Box, 2001]SOAP History

[Open Group, 1997]NDR & DCE

[OMG, 1995]CDR, IIOP & GIOP

[Sun, 1988]XDR & ONC

[Bray et al, 1998]XML

[Gudgin et al, 2003]SOAP 1.2

[ISO, 1986]SGML

[Goldfarb, 1981]Document Markup

[Reid, 81]Scribe[Jones, 1980]

Rigorous SE

[Winer, 1999]XML RPC

[Reid, 81]Scribe

Fig. 6. Impact on the definition of SOAP

definition language and XML schema, which the final version of SOAP uses for definitionof data types. XML schema was only finally defined in 2004 [Birron et al. 2004]. Theabsence of a schema language for XML stalled the SOAP standardization somewhat andan interim approach known as XML/RPC was defined by [Winer 1999] and obtained rapidadoption. When SOAP was finally released it supported both RPC-style invocations asproposed by [Winer 1999] and document-literal invocations that involve passing typedXML messages that encode request and reply data.

The XML family of specifications that include XML [Bray et al. 1998], XMLSchema [Birron et al. 2004] and XPath [Clark and DeRose 1999] were adopted by theWorld-Wide-Web Consortium. XML forms the basis for SOAP, WSDL and BPEL. XMLevolved from the ISO Standardized General Markup Language [ISO 8879 1986]. SGMLACM Journal Name, Vol. V, No. N, Month 20YY.


emerged from, and was defined by the same team that designed IBM’s General MarkupLanguage [Goldfarb 1981], whose development started at the IBM Cambridge ScientificCentre that was embedded within MIT. [Goldfarb 1981] acknowledges that [Reid 1981b]had developed the notion of procedural markup in the Scribe document processing system.Scribe is fully described in [Reid 1981a]. The central idea of GML that survived in SGMLand XML is the strict separation of concern between content and presentation. Separationof concern is not particularly novel for software engineers and it is therefore not surpris-ing that Goldfarb uses the production of Cliff Jones’ software engineering textbook [Jones1980] in GML as a case study in [Goldfarb 1981].

4.3 Web Services Description Language

WSDL provides the language abstractions to define interfaces of web services. It supportsthe identification of port-types, which correspond to modules or types in other IDLs, theidentification of operations and operation signatures. There is an intricate relationshipbetween SOAP and WSDL in that parameter types used in WSDL interfaces determine theXML documents that can be used within SOAP messages. We now discuss the origins ofWSDL. The impact traces that led to WSDL are visualized in Figure 7.

[IBM 2004]WebSphere

[Microsoft 2004]BizTalkServer

[Eclipse 2006]BPEL Designer

[Eclipse 2006]WTP

[Christensen et al, 2001]WSDL 1.1

[Apache 2004]Axis

[BEA 2004]WebLogicServer

[Microsoft,1998]DCOM

[OMG, 1995]IDL


[Chinnici et al, 2004]WSDL 2.0

[Microsoft,1999]SDL

[Curbera,2000]NASSL

[Microsoft,1995]MS RPC

Fig. 7. Impact on the definition of WSDL

Many application servers and software development environments support WSDL.Apache Axis provides bidirectional proxy generators between both Java and C++ andWSDL. Most application servers come with Web services development tools. IBM Ra-tional Application Developer for WebSphere generates a WSDL document from existingapplications and Java proxies from a WSDL document. Microsoft Visual Studio generates



proxy for .NET Framework from WSDL document. Other tools include BEA Workshopfor WebLogic Platform, Fujitsu Interstage Apworks, and IONA Artix.

Ariba, Microsoft and IBM jointly issued a W3C Note in March 2001 defining a WebServices Description Language [Christensen et al. 2001]. The Note states “this draft rep-resents the current thinking with regard to descriptions of services within Ariba, IBM andMicrosoft. It consolidates concepts found in NASSL, SCL, and SDL (earlier proposals inthis space)”.

The Network Accessible Service Specification Language (NASSL) was definedby [Curbera et al. 2000] at the Component Systems Group of IBM Research. The NASSLtechnical report states that “Languages such as MS IDL and OMG IDL are popular indus-try standards used to describe RPC interfaces. Instead of inventing yet another language,NASSL borrows key concepts from some of these languages and adapts them to cover non-RPC types of services”. Examples of concepts taken into NASSL and WSDL from theOMG’s and Microsoft’s Interface definition languages include oneway operations, the fail-ure semantics and strong typing. We will further determine the origins of Microsoft IDLand OMG IDL in Sections 7 and 8. The most significant original contribution of theNASSL technical report itself is the proposed use of different type systems, such as XMLschemas, for the definition of parameter and return types of web services, which eventuallywas adopted for WSDL.

The SOAP Contract Language (SCL) and the Service Description Language (SDL)3

were defined by Microsoft in 1999 and 2000 to support a web service based remotingmodel for Microsoft’s Component Object Model. SDL was relatively widely used and thedefinition of SDL was distributed as part of the Microsoft SOAP toolkit. The definitionof SCL was relatively short-lived and SCL was superseded by WSDL relatively quickly.The main influence of Microsoft’s SDL on WSDL and modern web services was the abil-ity to use different bindings to underlying transport protocols. The SDL document givesexamples of HTTP, HTTPS and Microsoft’s RPCs as used in DCOM.

WSDL, NASSL, SDL and SCL are all XML languages. The first proposal to use XMLto express an interface definition language for web services was made by [Merrick andAllen 1997] in a Note published by the World-Wide-Web Consortium proposing a WebInterface Definition Language (WIDL). Although we are unable to present direct evidencethat WSDL, NASSL, SDL and SCL did indeed borrow this idea from WIDL this seemshighly likely for a number of reasons. Firstly, WSDL, NASSL, SDL and SCL were definedwhile Microsoft and IBM were very much involved in the Protocol Working Group of theWorld-Wide-Web Consortium. Secondly, WIDL was submitted as a Note in 1997 to theWorld-Wide-Web Consortium. Finally and most importantly, the XML Protocol WorkingGroup that eventually adopted WSDL published a matrix that compared the different ap-proaches to defining web services in 2000 [Prudhommeaux 2000]. The matrix comparesamongst others WIDL, WSDL, NASSL and SCL, which means that the language designersof WSDL were aware of the WIDL approach.

3Note that even though the same acronym is used for all of them, Microsoft’s Service Description Languageis fundamentally different from the ISO/IEC Specification and Description Language and should also not beconfused with Microsoft’s own Security Development Lifecycle.



4.4 Business Process Execution Language

[Peltz 2003] identifies two models of composing Web services: orchestration and chore-ography. The primary difference lies in the scope of composition. While orchestratedweb services consider control flow from one party’s view, choreography emphasizes col-laboration of each party and encompass the scope of all parties and their interactions onthe global view of a system. BPEL is intended to orchestrate Web services along witha business process. A diagram showing the impact traces that led to BPEL is shown inFigure 8.

[IBM 2004]WebSphere

[Microsoft 2004]BizTalkServer

[Eclipse 2006]BPEL Designer

[Christensen et al, 2001]WSDL

[Thatte, 2001]XLANG

[Oracle 2004]BPEL Process Manager

[Andrews et al, 2003]BPEL

[Leymann, 1997]WSFL

[Leymann and Altenhuber 1994]FlowMark


[ActiveEndpoints 2004]ActiveBPEL

[Hollingsworth, 1995]WfMC Reference Model

[Barghouti, 1992]PSDE

[Alonso et al, 1995]Advanced Transactions

Fig. 8. Impact on the definition of BPEL

There are a significant number of BPEL implementations. IBM developed BPWS4J(Business Process Execution Language for Web Services Java Run Time). MicrosoftBizTalk Server 2004 translates WS-BPEL into XLANG/s then .NET assemblies for betterperformance while keeping backward compatibility to previous BizTalk servers [Fancey2005]. Oracle bought Collaxa and developed Collaxa’s BPEL suite into Oracle’s BPELProcess Manager which can run both standalone and an option to Oracle ApplicationServer Enterprise Edition. There are a number of open-source BPEL engines availablefrom Active Endpoints, RedHat/JBoss and Apache. Graphical modelling support for BPELis available under an open source license through the Eclipse BPEL Designer project jointlysupported by IBM, Oracle and UCL.



The first specification of BPEL named BPEL4WS (Business Process Execution Lan-guage for Web Services), was published by IBM and Microsoft in August 2002. BPEL4WSstates that it consolidates two earlier languages developed by IBM and Microsoft respec-tively. These are IBM’s Web Services Flow Language (WSFL) [Leymann 2001] and Mi-crosoft’s XLANG [Thatte 2001] used in Microsoft’s Biz Talk Server product family.

WSFL emerged from IBM’s earlier work on FlowMark [Leymann and Roller 1994;Leymann and Altenhuber 1994]. [Alonso et al. 1995] of IBM Almaden claim complianceof FlowMark to the WfMC standard when they state “FlowMark follows very closely thereference model provided by the WfMC”. Further evidence that the FlowMark team werefully aware of the Workflow Management Coalition (WfMC) is the fact that Altenhuberwas a technical committee member of the WfMC.

One of the key artifacts of the WfMC is its Reference Model [Hollingsworth 1995].The model does not include any references but states that, amongst others, the referencemodel evolved from “Project Support Software”. It goes on to state: “Software to han-dle complex IT application project development (eg IPSEs - ”Integrated Project SupportEnvironments”) has often provided a form of workflow functionality within the projectenvironment, for ”transferring” development tasks between individuals and routing infor-mation between individuals to support these tasks”. Were the reference model written as ascholarly publication it would have referenced the extensive literature on process-centredsoftware development environments, such as [Barghouti 1992].

[Meredith and Bjorg 2003] propose the formal definition of behavioral aspects in BPELusing the Polyadic π-Calculus [Milner 1999]. According to [Leymann et al. 2002] thisapproach was used already in XLANG: “Our use of directed graphs to model flows is sim-ilar to the work within the Workflow Management Coalition (WfMC) or the Web ServicesConversation Language. The theoretical underpinning of this approach is rooted in PetriNets and the π-calculus. Languages closer to the latter are XLANG and BPML.”

4.5 Summary

The three key web service technologies that enable the construction of service oriented ar-chitectures are SOAP, WSDL and BPEL. We have shown that they are widely implementedin service oriented middleware systems. These web services technologies use XML tech-nologies to define message content of service invocations, interfaces to web services andto determine web service compositions. We have traced the origins of XML technologiesto the GML effort at the IBM Cambridge lab based at MIT. We have shown that the keyconcepts used in web services are not new but are rather taken from remote procedure call,distributed object and workflow systems.

Service-oriented architectures are often layered onto distributed component systems,such as the Java 2 Enterprise Edition. These component systems provide containers forcomponents that are typically only distributed on a local area network. These containersprovide the mechanisms for persistence of component state, replication, concurrency con-trol, component activation and deactivation, security and transaction management. In thenext section we discuss the origins of distributed transaction processing in such distributedcomponent systems.ACM Journal Name, Vol. V, No. N, Month 20YY.


5. DISTRIBUTED TRANSACTION

5.1 Distributed Transactions in J2EE

Java application servers commonly implement the Java 2 Enterprise Edition (J2EE) definedby Sun Microsystems. It consists of a number of constituent specifications. These includeJava Server Pages (JSP) and Servlets, Java Messaging System (JMS) and Enterprise JavaBeans (EJB). The EJB specification [DeMichiel and Keith 2005] is at the very core of J2EEas it provides a server-side component model, which is capable of providing persistence,replication, transactions, security and concurrency control services in a way that their usecan be kept transparent to application programmers.

In this section, we investigate a particular aspect of the origins of this EJB technology. Itwould be impossible to provide a full account, but we rather endeavour to highlight someof the key ideas that shaped the EJB specification. We deliberately ignore the impact thatresearch has had on the definition of the Java programming language as this aspect is cov-ered in a companion impact report by [Ryder et al. 2005]. We now investigate distributedtransaction processing in the J2EE standard. This is of particular significance as J2EEapplication servers, would not be very useful if it was not possible for multiple users tointeract with applications at the same time, or if failures that are bound to occur could pos-sibly corrupt data held in various distributed data stores. Before investigating the originsof distributed transactions in J2EE we characterise the economic significance of the J2EEapplication server market.

The J2EE application server market had a size of USD 2.19 billion license revenue in2001 according to [Gilpin 2002] of Forrester Research. Figure 9 shows the distribution ofthis market across product vendors. The two main products in the market at the time werethe IBM Websphere J2EE application server and WebLogicServer of BEA Systems, whicheach had a share of 34% of the market. Further products include Sun’s iPlanet, Oracle 9i,as well as the Sybase and HP Arjuna application servers. We note that JBoss [Fleury andReverbel 2003] is widely used and freely available J2EE application whose impact is notreflected here.

BEA WebLogicServer34%

IBM WebSphere34%

Oracle 9i7%

Sun IPlanet6%

Sybase AS4%

HP Arjuna3% Others

12%

Fig. 9. J2EE application server market in 2001

Figure 10 shows an overview of the time-line and key impact traces concerned with dis-tributed transaction management in J2EE. Vendors of J2EE application servers implicitly



acknowledge the fact that they use the J2EE specifications by virtue of claiming compli-ance. For the purpose of transaction management, there are two significant J2EE specifi-cations that a J2EE application server needs to comply with, the Java Transaction Service(JTS) specification [Cheung 1999] and the Java Transaction API specification [Cheung andMatena 1999]. The EJB specification determines two models for transaction management.The first model are container managed transactions where the container that manages thelife cycle of EJB components determines when to start and when to complete transactions.The second approach allows the application programmer to determine the boundary oftransactions and to do so they use the interfaces defined in the JTA specification. Both thecontainer and the implementation of the JTA that an application programmer uses, in turn,rely on a JTS implementation to correctly implement transactions.

The introduction of the JTS specification states that “JTS uses the CORBA Object Trans-action Service (OTS) interfaces for interoperability and portability [...]. These interfacesdefine a standard mechanism for any implementation that utilizes IIOP (Internet InterORBProtocol) to generate and propagate transaction context between JTS Transaction Man-agers. Note, this also permits the use of other API over the IIOP transport mechanismto be used; for example, RMI over IIOP is allowed.” [Cheung 1999]. The JTS specifi-cation therefore merely defines a Java programming language binding to a subset of theCORBA Object Transaction Service and thus it is the origins of the CORBA OTS that areof particular interest for the remainder of this section.

5.2 CORBA Object Transactions

The main aim of the OTS was to encapsulate the protocols required for distributed transac-tion processing in object-oriented interfaces while preserving the interoperability betweendifferent transaction monitors and databases achieved by earlier standards.

We cannot consider the OTS in isolation but also have to take the CORBA ConcurrencyControl Service (CCS) into account, as the OTS uses the CCS to achieve isolation of trans-actions. Both these services were defined as part of the second call for CORBA Servicesproposals by the OMG membership in 1993-94. A collection of all CORBAservices thatincludes the OTS and CCS is published in [OMG 1998a].

Five consortia responded with a proposal for the OTS. A quite influential consortiumconsisted of IBM, Transarc and Tandem and was supported by Hewlett Packard, Objec-tivity and NCR. Their proposal [Object Management Group 1993b] was co-authored byEdward Cobb of IBM, Ken McCoy of Tandem and Graeme Dixon of Transarc. A secondinfluential proposal [Object Management Group 1993a] was co-authored by Herve Lejeuneof Bull, Chris Horn of Iona and Juan Andrade of Novell. By virtue of having leading trans-action monitor products (CICS, Pathway, Tuxedo and Encina respectively), IBM, Tandem,Novell and Transarc had a vested interest in the Object Transaction Service. The finalspecification was submitted by merging key contributions from all competing proposalsand was created by a consortium that included IBM, Transarc, Tandem, Novell, Iona, ICL,Bull and Sun. A good overview of the final object transaction service is provided by [Cobb1997].

The IBM/Tandem/Transarc proposal includes the key abstractions of transactional client,server and manager that were eventually incorporated into the standard. It also defined thenotion of implicit transactions (those that are not explicitly identified through a transactionID), which is a key component of the OTS standard. A key contribution of the Novellproposal was the notion of resource managers and the interoperability with the XA proto-ACM Journal Name, Vol. V, No. N, Month 20YY.


[Gray 1978]Database Operating Systems

[Bernstein and Goodman 1981]Concurrency Control in Distributed Databases

[Lampson & Sturgis 1976]Crash Recovery in Distributed Systems

[Bernstein et al 1987]Concurrency Control & Recovery in Databases

[Shrivastava et al 1991]Arjuna

[Shrivastava & Panzieri 1988]Orphan Detection

[Dixon et al 1989]Persistent Objects in Arjuna

[OMG 1993]IBM/Tandem/Transarc OTS Proposal

[OMG 1994]OTS Specification

[Cobb et al. 1997]IBM OT Monitor Patent

[Bernstein 1990]Transaction Monitors

[Sun1999]JTS Specification

[IBM 2001]WebSphere

[BEA 2001]WebLogic Server

[HP 2001]Arjuna Application Server

[Bluestone 2000]JTS Arjuna

[Arjuna Labs 1998]OTS Arjuna

[Bell Labs 1982]System/T

[Andrade et al 1992]OLTP with Tuxedo

[Novell]Tuxedo

[BEA 1996]Tuxedo

[Sun 2001]Sun iPlanet

[Acker & Seaman 1982]CICS

[DEC 1989]DEC Intact

[X/Open 1991]DTP Specification

[Fleury&Reverbel 2003]JBoss

[Birrel & Nelson 1984]Implementing RPC

Fig. 10. Impact traces for distributed transactions

col [X/Open Group 1991] that is part of the X/Open DTP standard as was required in theRFP and the interoperability model was again finally adopted in the standard.

Edward Cobb was also the lead author of US patent 6,070,197 entitled “Object orientedtransaction monitor for distributed transaction processing environments” that was filed byIBM in 1997. This patent acknowledges the prior art established in the OTS proposal byIBM, Tandem and Transarc. The patent was granted in 2000 and serves to protect IBM’sintellectual property rights on object transaction services. It is also interesting to notethat at the time of writing this report, Edward Cobb is Vice President for architecture andstandards at BEA Systems and we can assume that in that role he has had some influence



on the transaction processing architecture of BEA’s WebLogicServer.The object transaction service relies on a concurrency control service for achieving the

isolation property. Two concurrency control service proposals were submitted. The firstwas also written by Graeme Dixon of Transarc and the second proposal was submitted byEmeraude and supported by members of the PCTE consortium (ICL, Bull, Siemens). Attheir meeting in Dublin in August 1994 the OMG Technical Committee voted unanimouslyin favour of adoption of Dixon’s proposal as it was integrated with the object transactionservice and provided a truly object-oriented view on concurrency control, while the PCTEsubmission merely proposed adoption of the PCTE concurrency mechanisms.

[Gray 1978] Database Operating Systems

[Bernstein et al 1987]Concurrency Control & Recovery in Databases

[Dixon et al 1989]Persistent Objects in Arjuna

[OMG 1993]IBM/Tandem/Transarc

OTS Proposal

[OMG 1994]OTS Specification

[X/Open 1991]DTP Specifications

[OMG 1993]Transarc CCS Proposal

[OMG 1994]CCS Specification

[Moss 1981]Nested Transactions

[OMG 1993]Bull/Iona/Novell

OTS Proposal

[Gray 1993]Transaction Processing

[ISO 1988]ISO 9804/05

[OMG 1991]CORBA

[Dixon 1988]Object Mgmnt for

Recoverability

[ISO 1992]ISO 10026

[Young et al. 1991]Encina

[Spector et al 1985]Distributed Transactions

[Spector et al 1986]Camelot

Fig. 11. Impact traces for CORBA Transaction Service

So where did Dixon, Cobb and Andrade get the ideas embedded in the concurrencycontrol and object transaction service specifications? Figure 11 shows a refinement ofFigure 10 in order to highlight in more detail the origins of the CORBA OTS proposal.

At the time of specifying the OTS, Andrade worked at Novell in the department thatdeveloped the Tuxedo transaction monitor. Tuxedo was later acquired by BEA from Novelland the transaction processing experience gained by Tuxedo forms a cornerstone uponwhich BEA’s Web Logic Server product is built. Andrade also worked on the OSF ODTPstandard and determined the XA protocol. Novell had earlier obtained Tuxedo from AT&TBell Labs where Andrade et all had built an experimental transaction monitor known asSystem/T.ACM Journal Name, Vol. V, No. N, Month 20YY.


Both the CCS and OTS specifications used CORBA IDL as established in [Sventek andAndreas 1991] in order to define the interfaces to their respective services. The concur-rency control service specification explicitly cites [Bernstein et al. 1987] when describingtwo-phase locking. It also refers to [Gray 1978] for the notion of a transaction. Gray citesin this seminal paper [Lampson and Sturgis 1976] as the first mention of the two-phasecommit protocol. Note that contrary what Gray states, the paper was never published inCACM, but was circulated amongst systems researchers in different versions and even-tually appeared as a XEROX technical report in [Lampson and Sturgis 1979]. Encina,Transarc’s TP Monitor also supported the execution of nested transactions and Dixon re-ferred to [Moss 1981; 1985] in the concurrency control service specification in order toensure support for nested transactions was included in the specification.

The Novell OTS proposal includes an extensive list of citations. It defines a CORBAOTS transaction to have the meaning of Gray’s ACID transactions although it cites [Gray1993] rather than his original LNCS paper. The Novell proposal also refers to the X/OpenDTP specifications and states that resource managers can communicate via the XA pro-tocol [X/Open Group 1991] with data stores. The X/Open DTP XA specification is ulti-mately just an API specifications. The underlying protocols and services were specifiedin the ISO 10026 standard, which is explicitly referenced, as well as the underlying two-phase commit and two-phase locking protocols as defined in the ISO 9804 and ISO 9805standards. Like the CCS proposal, the Novell OTS proposal supported the notion of nestedtransactions and again, they acknowledge [Moss 1981] as the origin.

At the time of writing the OTS proposal, Dixon worked with Michael W. Young as chiefarchitect for the Encina product of Transarc. Transarc was spun out of Carnegie MellonUniversity by Alfred Spector to develop distributed transaction processing products. A pa-per that describes the architecture of Encina was published by [Young et al. 1991]. DanielThompson, one of the co-authors of that paper had previously worked with Spector onthe Camelot project at CMU [Spector et al. 1986] and Camelot was extending ideas fordistributed transaction processing that were first built in the TABS system [Spector et al.1985]. Encina used many concepts that were built into Camelot and TABS, includingnested transactions.

Transarc was acquired by IBM in 1994 and the Encina transaction engine became anintegral part of the IBM WebSphere Application Server from Version 3.0. Transarc alsolicensed the Encina Transaction engine to Iona, who marketed it as the Iona Object Trans-action Monitor and to Netscape and Sybase.

While basic distributed transaction handling and nesting of transactions were contributedby members of the Camelot team, it was Dixon who contributed object-oriented abstrac-tions to distributed transaction processing. Dixon obtained his PhD in the distributedsystems group at Newcastle University, where he was a key contributor to the Arjunaproject [Shrivastava et al. 1991]. His research was on concurrency control and transac-tions in persistent distributed object systems [Dixon et al. 1989]. In his PhD thesis [Dixon1988], he investigated how distributed transaction processing could be facilitated using anobject-oriented approach and the key concepts that underpin the CORBA Object Transac-tion and Concurrency Control Services were first defined during his PhD work in New-castle. These include the notion of server objects that could take part in atomic actions aswell as the need for integration of object transaction services with concurrency control andpersistence. Thus, contrary to the claim in the IBM Patent it was the Arjuna project that



had the first object-oriented implementation of a distributed transaction capability between1985 and 1990.

Arjuna used Rajdoot [Panzieri and Shrivastava 1988], an RPC mechanism supportingorphan detection techniques to detect transactional clients and servers that had failed. Thispaper cites [Birrell and Nelson 1984] in order to acknowledge that Birrell had the firstideas for RPCs. It is interesting to note that, once adopted, the OTS and JTS specificationshad reciprocal influence on the Arjuna project. The details of this influence have beendocumented by [Little and Shrivastava 2002] in more detail than we are able to give inthis report. In essence, the Arjuna project tracked the standards development in their workand released versions of the Arjuna middleware that were compliant to the OTS and JTSspecifications respectively.

They then transferred the IPR of the middleware into a spin-off company, Arjuna Labs.Arjuna Labs were then bought by BlueStone, who were, in turn, acquired by HewlettPackard and the Arjuna JTS implementation now provides the transaction engine of HP’sapplication server product. Recently, the Arjuna transaction service technology was soldto JBoss, who were in turn acquired by RedHat and the Arjuna JTS is now being integratedinto RedHat’s Linux offering.

5.3 Summary

We have shown the importance that research has played in the definition of distributedtransaction processing capabilities that form one of the most important foundations of J2EEand CORBA specifications and products. We have shown that basic research results pub-lished in the software engineering and database literature and PhD theses have had a keyimpact in this important area.

Distributed Transactions also play a key role in another cornerstone of the J2EE spec-ification, the Java Messaging Service. It is the distributed transaction protocols we havediscussed above that enable components to en-queue or receive a distributed message aspart of a transaction and most JMS message queue implementations are transactional re-source managers and implement the XA protocol we have discussed above. We investigatethe origins of JMS and more generally message-oriented middleware in the next section.

6. MESSAGE-ORIENTED MIDDLEWARE

Message-oriented middleware supports the asynchronous communication between dis-tributed system components. This is a very important primitive used in most modern ap-plication servers and enterprise services buses. The Java 2 Enterprise Edition includes aspecification called the Java Messaging Service (JMS) [Hapner et al. 2001]. JMS is wellintegrated with other J2EE specifications. In particular, the Enterprise Java Bean spec-ifications from Version 1.2 onwards define the notion of message beans, which can beconfigured to be invoked when a message is received via the Java Messaging Service.

According to [Correira and Biscotti 2006], the size of the market for MOM licenses wasabout 1 billion US $ in 2005, with the biggest vendors of message-oriented middlewarebeing IBM with a market share of about 500 million US Dollars and TIBCO with a marketshare of about 314 million US Dollars. It thus reflects a non-negligible proportion ofthe overall middleware market. At the time of writing this article, the most significantproducts are IBM’s Websphere MQ, the BEA MessageQ, Tibco’s TIB/Rendevous, Sonic’sSonicMQ, Microsoft’s MSMQ, as well as a number of open source products, such as theJBoss Message Queue. These products are not just sold in isolation but are also bundledACM Journal Name, Vol. V, No. N, Month 20YY.


into application servers and enterprise service buses.An important focal point for the adoption of message-oriented middleware market was

the publication of the JMS specification as the result of a Java Community Process. Theaim of this specification is to provide a uniform application programming interface forall leading message-oriented middleware providers. JMS supports both point-to-point andpublish/subscribe communication. It supports the definition of different qualities of ser-vice, such as guaranteed delivery through persistent storage of messages if receivers areunavailable. These concepts were not invented by the committee that defined JMS buthave been used by message-oriented middleware products for a number of years before.A survey of different message-oriented middleware approaches, including those that havenot yet had any significant commercial success is provided by [Eugster et al. 2003]. Inthe remainder of this section, we investigate the origins of key concepts of commerciallysuccessful message-oriented middleware systems. An overview of the key impact traces inthe area of message-oriented middleware is shown in Figure 12.

[Sun 2001]Java Messaging Service

[IBM 1995]MQSeries 1.0

[BEA 1999?]BEA MessageQ 1.0

[DEC1996]DEC Message Queue

[Reiss 1987]Field

[Reiss 1990]Message Passing in Field

[Cagan 1990]HP Softbench

[Hart&Lupton 1995]DEC FUSE

[IBM1992]IBM Networking Blueprint

[SSI 1993]EzBridge

[IBM 2005]WebsphereMQ

[BEA 2005]WebLogicServer

[Sonic 2005]SonicMQ

[JBoss 2005]JBossMQ

[OSF 1991]ODTP XA Spec

[OMG 1994]CORBA EventService

[OMG 1999]CORBA Notification Service

[Bea 2000]WebLogicEnterprise

[ Tibco 1999]TIB

[ Teknekron 1995]InformationBus

[Oki et al 1993]InformationBus[Skeen 1992]

InformationBus

[Cheriton& Deering 1985]NetworkMulticast

[Birman&Thomas 89]Replication

[Rothermel & Mohan 1989]ARIES

Fig. 12. Impact on JMS implementations

The message-oriented middleware product with the largest market share is IBM’s Web-sphere MQ, which was previously referred to as MQSeries [IBM 1995]. MQSeries wassuccessful for a number of reasons. Firstly, it integrated messaging primitives with transac-tion processing by making the messaging middleware compliant to the OpenGroup’s XAprotocol that is part of the Open Distributed Transaction Processing standard. The treat-ment of a message queue as an XA compliant resource manager allowed programmers toinsert or remove a message into or from a queue as part of a distributed transaction thatwould also perform other database operations to process sending or receiving the message.Secondly, MQSeries was made available for more than 30 operating systems and hardware



platforms and allowed the reliable exchange of messages using the same primitives acrossthese platforms.

The creation of MQSeries as a point-to-point message queuing system was facilitatedby State Street Bank in Boston, which demanded the integration of the EzBridge productof System Strategies International (SSI) with the MQI abstractions that were defined aspart of IBM’s Networking Blueprint [Hess et al. 1995]. To meet this request, IBM UKLaboratories in Hursley where the CICS product originated licensed the ezBridge Soft-ware for Tandem and VMS, provided it with MQI interfaces, made it XA compliant andintegrated it with its own MQI implementation that was available for the CICS platform.We interviewed Dick Dievendorff, the technical lead of MQSeries on MVS. Dievendorffstated that the MQSeries team used the ideas of forward recovery to overcome the un-certainty in the two-phase commit protocol. He mentioned that his team used the for-ward recovery techniques published in the 1989 VLDB paper by [Rothermel and Mohan1989]. In fact, this paper won the VLDB most influential paper award in 1999 and [Mo-han 1999] summarizes the history of ARIES retrospectively. On the relationship betweenARIES and MQSeries this paper states: “Asynchronous program to program communi-cation in the form of transaction-based persistent messaging has become quite popular.IBM’s MQSeries, for example, is a very successful product in this arena. MQSeries in-cludes its own non-DBMS-based persistent storage mechanism, using an extended versionof ARIES, for managing the messages” [Mohan and Dievendorff 1994].

In later correspondence about an earlier draft of this article, Dievendorff also confirmedthat the design of the concurrency control mechanism in MQSeries used the seminal workof Jim Gray on transaction management concepts and in particular the locking mechanismsGray proposed. The team also used the source code of the System R lock manager [Astra-han et al. 1976].

In an email correspondence Rob Drew, who was an architect for MQSeries at the time,confirmed that the initiative for developing MQSeries might have been influenced by theavailability of an earlier competing product, the DEC Message Q. As it turns out, the DECMessage Q turned out to be quite influential, too.

In a June 2005 interview with Paul Krill of InfoWorld, Paul Patrick of BEA confirmedthat BEA acquired the ObjectBroker (a CORBA ORB) and the MessageQueue productsfrom DEC and re-engineered the ObjectBroker into their Web Logic Enterprise (WLE)CORBA implementation. WLE implemented the transaction service based on Tuxedodiscussed in the previous section. WLE implemented the CORBA Notification [OMG1998b] by wrapping the BEA MessageQ. An example of an application that was builtusing WLE’s transaction and notification services is described in [Emmerich et al. 2001].Before incorporating MessageQ into WLE, BEA marketed the MessageQ separately andalso bundled it into their Tuxedo transaction monitor.

So where did the messaging primitives DEC built into their message queue originate?DEC had earlier developed a product called DEC Fuse. The aim of DEC Fuse was touse asynchronous and anonymous communication techniques to support the integration ofsoftware engineering tools. Fuse was based on code that DEC licensed from Steven Reiss,who had developed a message-passing based integration mechanism for the Field softwaredevelopment environment [Reiss 1990]. [Hart and Lupton 1995] state in their DEC Journalpaper that describes Fuse that “code that determines Fuse was based on Field Code”. Infact also Sun’s ToolTalk and Hewlett Packard’s Broadcast Message Server tool integrationACM Journal Name, Vol. V, No. N, Month 20YY.


products were based on Field’s concepts. In his HP Journal paper on SoftBench, [Cagan1990] states that “Most influential in the HP Softbench design were the FIELD system doneat Brown University, the FSD system done at USC-ISI and the HP NewWave environment”.When referencing Field, Cagan refers to a 1987 Brown technical report written by [Reiss1987] and for the FSD system he cites [Balzer 1987]. When interviewing Steven Reiss, heconfirmed that HP were made aware of Field during a visit at Brown and that he licensedthe code of Field for inclusion in Fuse. Moreover he confirmed that Fuse was a predecessorof the DEC Message Queue.

It is interesting to note that the CORBA Event Service [OMG 1998a], an importantpredecessor of the Notification service was defined by a consortium that was led by Sun,DEC and HP. It is unclear though which influence, if any, Sun’s, DEC’s and HP’s previouswork on the Tooltalk, Fuse and Broadcast Message Server tool integration mechanismshas had on these developments. Also Dale Skeen of Teknekron took part in the task forcethat defined the CORBA Event service. Skeen had worked previously at Teknekron on aproduct called The Information Broker [Skeen 1992]. In fact, the paper published by [Okiet al. 1993] in the 1993 ACM SIGOPS Principles of Operating Systems Conference de-scribes a publish/subscribe mechanism that is very similar to that used by the CORBAEvent service. In the discussion of related work Oki et al. state that they apply the ideasof publish/subscribe to objects that were proposed by [Cheriton and Deering 1988] formulticast networking and by [Birman and Thomas 1989] for building the ISIS replicationmanager. Following the acquisition of Teknekron by Reuters, the company was renamedinto Tibco and The Information Bus is now merely known by its acronym TIB, which hasthe second largest share of the message-oriented middleware market.

While message queuing middleware is frequently used to provide primitives for asyn-chronous communication between distributed system components, they are less suitablefor synchronous communication. These are typically provided using remote method in-vocation and remote procedure call primitives. We discuss the origins of middleware thatprovide such primitives in the next two sections.

7. DISTRIBUTED OBJECTS

For the discussion in this section we consider the techniques that support the invocationsof operations amongst objects between machine boundaries. The scope therefore includesobject requests as supported by the Common Object Request Broker Architecture, theRemote Method Invocation primitives of Java and the Remoting architecture of .NET.

For developing modern distributed applications, software engineers use remote invoca-tion primitives that are now tightly integrated into programming languages. We have al-ready discussed the size of the J2EE application server market above. The Enterprise JavaBean specification [DeMichiel and Keith 2005] that is an integral specification to which aJ2EE application server needs to comply prescribes the use of Java’s Remote Method In-vocation (RMI) [Sun Microsystems 1998]. The specification determines that ’The remoteand remote home interfaces are Java RMI interfaces’ so that EJBs can be accessed acrossmachine boundaries. .NET uses a primitive called Remoting [Srinnivasan 2001] for thatpurpose. Java RMI and .NET Remoting therefore provide the basis for invoking opera-tions between different distributed tiers of a software architecture without which scalableand reliable web applications could not be built.

[Alur et al. 2003] and [Microsoft 2003] define the best practices for distributed softwareACM Journal Name, Vol. V, No. N, Month 20YY.


design with the Java 2 Enterprise Edition and .NET, respectively. Given they originate atSun and Microsoft respectively, these best practices are widely followed in the softwareindustry and a substantial number of e-commerce, online banking and other web sites aredeveloped using these practices. [Alur et al. 2003] propose a strict separation between apresentation layer and business object layer. The presentation layer is in charge of comput-ing the web content that gives the user interface to an application. The business object layeris concerned with handling the application logic and interfacing to the underlying informa-tion systems and legacy applications. It is best practice to host these on different machinesso as to support load balancing and fault tolerance. As a consequence objects in the pre-sentation layer need to invoke operations from objects in the business object layer acrossmachine boundaries. This is achieved in practice using Java Remote Method Invocation or.NET Remoting.

We can therefore establish that remote operation invocation primitives are of crucialimportance for the construction of distributed software applications and we can now startinvestigating where these remote invocation primitives originated.

7.1 Java Remote Method Invocation

The Remote Method Invocation definition at Sun Microsystems [Sun Microsystems 1998]was led by Jim Waldo and its technical concepts were first published in [Wollrath et al.1996]. RMI enables a Java client object to invoke a method from a server object thatresides in a different JVM, possibly on a different host.

Figure 13 shows the impact traces that led to RMI. [Waldo 1998] describes the main de-sign rationales and origins of RMI. Waldo acknowledges that RMI builds on the heritageof remote procedure call systems and identifies [Birrell and Nelson 1984] as the first RPCsystem. He also cites the OMG’s Common Object Request Broker Architecture [ObjectManagement Group 1991] and Microsoft’s Distributed Component Object Model [Grimes1997] as precursors of RMI. Waldo then outlines the design rationales for RMI and statesimportant differences to earlier work on RPCs, CORBA and DCOM. In particular, RMIgives up the notion of programming language heterogeneity that is resolved by an indepen-dent interface definition language and different programming language bindings that un-derpinned all earlier work on remote procedure call systems. Instead [Wollrath et al. 1996]state that RMI continues the tradition of Modula-3 Network Objects [Birrell et al. 1993]that incorporate remote invocation primitives into the programming language. [Wollrathet al. 1996] also states that RMI builds on the garbage collection mechanism first adoptedin Modula-3 Network Objects.

RMI also differs from previous work on remote procedure calls in that the stubs re-quired for synchronisation, marshalling and unmarshalling are loaded on-demand ratherthan during startup of the distributed program. This mechanism considerably simplifiesthe deployment of distributed programs. To achieve loading of stubs on demand, RMI de-pends on Java’s dynamic class loading mechanism described by [Liang and Bracha 1998].For use in distributed computing, the security of class loading is critical and [Liang andBracha 1998] describe how class loading is made both type safe and secure following theformal proof of flaws of earlier Java class loading mechanisms by [Jensen et al. 1998].

[Birrell et al. 1993] begin their Network Objects paper by stating that “in pure object-oriented programming, clients cannot access the concrete state of an object directly, butonly via the object’s methods. This methodology applies beautifully to distributed comput-ing, since the method calls are a convenient place to insert the communication required by



[Waldo 1998]RPC and RMI


[Birrel et al, 1993]Modula-3

Network Objects

[Microsoft, 1995]DCOM

[Wollrath et al, 1996]RMI

[Liang & Bracha, 1998]JVM Dynamic Class Loading

[Lindholm et al,1995]JVM Specification

[Jensen et al, 1998]Security and Java Class Loading

[Liskov 1988]Argus

[Shapiro et al 1985]SOS

[Bal et al 1988]Orca

[Almes et al 1985]Eden

[Black et al et al 1987 ]Emerald

[Hutchinson 1987]Emerald

[Bal 89]Shared Objects

[Jul et al 1988]Emerald

[Dixon et al 1989]Arjuna

[OMG 1991]CORBA 1.0

[OMG 1995]CORBA 2.0

[Sun 2003]J2SE 1.3 RMI

Fig. 13. Impact trace leading to Java RMI

the distributed system.” Thus, Network Objects continue in Wirth’s and Parnas’ traditionof encapsulation, modularity and information hiding and build on the plethora of work onobject-oriented programming languages. We refer the interested reader to [Ryder et al.2005] for an in-depth discussion of the origins of this work.

[Birrell et al. 1993] state explicitly that Modula-3 Network Objects are built on ideas ofothers and reference Emerald [Jul et al. 1988], Argus [Liskov 1988], Eden [Almes et al.1985], Arjuna [Dixon et al. 1989], Orca [Bal et al. 1992] and SOS [Shapiro et al. 1989]as systems that they built upon. Many of these papers are the journal publications oftechnical reports or theses describing systems in more detail. The object model of Emeraldis defined in [Hutchinson 1987] and its type system was described in [Black et al. 1987],the Arjuna persistent object approach was built by [Dixon 1988] and the Orca object modelwas defined in [Bal 1989].

Birrell et al. claim three main contributions in their paper. The first one is that Net-ACM Journal Name, Vol. V, No. N, Month 20YY.


work Objects are considerably simpler and more lightweight than other approaches; theyachieve this by selecting only those concepts from earlier systems they deem essential fordistributed programming. Their second contribution is the integration into a coherent lan-guage framework and their third contribution is an implementation of that language thatthey have then subjected to rigorous quantitative and qualitative evaluation in order to showthe feasibility of relatively fine grained distribution. The research into Modula-3 NetworkObjects in DEC’s industrial research lab can thus be considered as a necessary and, giventhe impact it had on RMI, very influential consolidation step of earlier, largely academicwork.

Without doubt, Network Objects were also influenced by Andrew Birrell’s earlier workon remote procedure calls [Birrell and Nelson 1984], but before discussing this we wouldlike to trace the impact of research on another direct predecessor of RMI, which is CORBAas acknowledged in [Waldo 1998]. As a matter of fact, Jim Waldo was a member of theteam that defined the first CORBA specification when he was working at HP/Apollo. RMImore or less directly reused a number of key concepts from CORBA, including the useof exceptions to handle communication failures, location transparency of objects throughremote object references, interface inheritance with a well defined root object type, theuse of stubs for marshalling and unmarshalling, the default synchronisation behaviour, theability to perform on-demand activation, and the Internet Inter ORB Protocol (IIOP) as atransport representation.

7.2 The Common Object Request Broker Architecture

The CORBA standard went through a significant number of revisions between 1991 and2003. With the notable exception of the IIOP protocol, which was added in CORBA2.0 [Object Management Group 1995] all the above concepts that made their way intoRMI were already included in the very first CORBA version and we therefore have toinvestigate the origins of that specification.

The impact trace for CORBA is shown in Figure 14. The Common Object RequestBroker Architecture was specified in an open process by the Object Management Group.The first CORBA specification is the result of two task forces, the first of which definedthe Object Model and the second determined the Object Request Broker Architecture.

One can identify two main areas of influence from different research disciplines on thefirst CORBA specification. Research on software engineering and programming languageshas influenced the CORBA object model and research on distributed systems has influ-enced the ORB architecture. We discuss both of these areas below.

It is evident that the team that defined the object model was fully aware of, and buildingon, previous research and development efforts in object oriented programming languages,object-oriented design and object databases. The OMG Technical Committee meetingsduring that period had regular presentations from leading researchers on a topic of rel-evance to CORBA. These presentations included talks from Bjarne Stroustrop on C++and the need for co-existence and integration of C++ with other languages (he mentionedSmalltalk in particular) at the TC Meeting in February 1990, Klaus Dittrich on DatabaseObject Models at the TC Meeting in April 1990, Ivar Jacobson on Objectory at the TCMeeting in June 1990 and Andrew Watson on ANSAware at the TC Meeting in Octo-ber 1990. Moreover, the document that eventually defined the object model [Soley 1992]has an extensive list of references, which includes the object database manifesto [Atkin-son et al. 1990], references to object-oriented programming texts, such as [Meyer 1988],ACM Journal Name, Vol. V, No. N, Month 20YY.


[Atkinson et al, 1990]ODB Manifesto

[Meyer, 1988]OO SW Construction

[Booch, 1991]OO Design

[Liskov & Snyder, 1979]CLU Exceptions

[Liskov et al, 1977]CLU

[Snyder, 1986]Encapsulation&

Inheritance

[ANSA1989]ANSA Reference Manual

[Soley 1992]Object Management Architecture

[OMG 1991]CORBA 1.0

[Sventek&Andreas 1991]Joint Submission

[Sventek&Waldo 1991]HP/Sun Submission

[Sventek 1991]HP Submission

[Snyder 1990a]Glossary

[Snyder 1990b]Draft OMG Object Model

Fig. 14. Impact traces leading to OMG/CORBA

[Keene 1989] and [Cox 1986] and extensive list of references to object-oriented designbooks, including [Booch 1991] and [Wirfs-Brook et al. 1990].The object model was determined in a collaborative manner by one of the very first OMGtask forces as part of an effort to write a ’standards manual’. This manual was edited byRichard Soley, adopted in its first version in September 1990 and eventually published asa book by John Wiley [Soley 1992]. The core object model and the glossary were con-tributed by [Snyder 1990b; 1990a], who was at Hewlett Packard Labs at the time. Both areclearly influenced by Snyder’s earlier research work. The notion of encapsulation and thetreatment of multiple inheritance in the core object model bear considerable resemblanceto the concepts outlined in [Snyder 1986]. The object model enforces data abstractionin that the core object model does not allow any direct access to data, but attributes arerather treated as (pairs of) accessor operations, which is very much in the tradition of dataabstraction in CLU [Liskov et al. 1977]. The exception handling that the CORBA objectmodel profile adds to the core object model is strongly influenced by Snyder’s earlier workon exception management in CLU [Liskov and Snyder 1979].

Following adoption of the object model, a call for proposals [Weber 1990] was pub-lished for the architecture specification of a common object request broker. In response tothis call, OMG received eleven competing proposals from APM [Herbert 1991], Constel-lation [Sheffler 1991], DESET [Shia 1990], Hewlett Packard [Mathews 1991], Bull [Bal-ter 1991], HyperDesk [Andreas 1991], Digital Equipment Corporation [Freburger 1991],Teknekron [Skeen 1991], NCR [Hazeltine 1991], Software AG [Enright 1991] and Sun Mi-



crosystems in January 1991. In February 1991, Software AG, Teknekron and Constellationwithdrew their submission. Sun dropped its proposal and joined the HP submission [So-ley 1991]. The ANSA submission was edited by John Bull, Andrew Herbert and AndrewWatson, with contributions from other ANSA team members. The Advanced NetworkSystems Architecture Reference Manual [ANSA 1989] was produced between 1984 and1989 by a team led by Andrew Herbert and including, Joe Sventek, Dave Otway, OwenRees and others. Sventek left to join HP in 1990, where he co-authored the HP ORB pro-posal. ANSA continued to influence OMG work through the mid-90s, not least becauseAndrew Watson of ANSA chaired the OMG ORB Task Force. The HP/Sun resubmissionwas written by and presented to the OMG TC in March 1991 by Joe Sventek, who led theANSA implementation before joining HP, and Jim Waldo of Hewlett Packard and RichardProbst and Dwight Hare of Sun. At the OMG TC Meeting in May 1991, APM withdrewtheir submission, stating that ’APM would be unable to handle the burden should theirsubmission be successful, that APM is a research consortium that would prefer to work on”future” ORBs and ODP and that the ORB process is well supported by Hewlett Packardand Digital Equipment Corporation’. Following an independent review of the remainingsubmissions by [Shapiro 1991] of INRIA it was also decided at that May meeting to rejectall submissions and invite the remaining submitters to prepare a joint submission. Thisjoint revision was edited by Joe Sventek and Bill Andreas of Hyperdesk and submittedin August 1991 on behalf of HP, DEC, HyperDesk, NCR and Sun [Sventek and Andreas1991]. Sventek and Andreas presented the proposal to the OMG Technical CommitteeMeeting in September 1991 and it was subsequently adopted as a standard. Andrew Wat-son chaired the ORB Task Force form 1992 while working for APM; in 1995 he left to joinOMG as Architecture Director, and later Technical Director.

Thus we have presented evidence that the research on ANSAware at APM to whichHerbert, Watson and Sventek were key contributors and which was funded in part by theEU ESPRIT programme, had a very significant influence on the CORBA architecture. Inthe next section we show the relationship between ANSAWare and RPC systems.

8. REMOTE PROCEDURE CALLS

To characterise the importance of remote procedure calls we cannot use market size as anindicator as these primitives have been commoditised and no longer have a distinct market.Instead remote procedure call primitives are embedded into all major operating systems.Every installation of Windows NT, Windows 2000, Windows XP, every Unix installation,including Linux and all Apple Macintosh computers running Mac OS X routinely useremote procedure calls for communication with other computers. Remote procedure callprimitives are used by modern operating system itself to perform very basic functions.Examples that use RPCs are the management of the Domain Name Service [Mockapetrisand Dunlap 1988] and the management of the DHCP service that assigns IP addressesdynamically, which implements logical Internet domain names. We can therefore postulatethat we would not have the Internet in its current form without remote procedure calls.

There have been a large number of remote procedure call mechanisms proposed. Theseincluded Xerox Courier [Xerox OPD 1981], Xerox Cedar [Birrell and Nelson 1984],Apollo NCA [Dineen et al. 1987], Sun ONC/RPC [Sun Microsystems 1987; 1988], Cam-bridge Mayflower RPC [Bacon and Hamilton 1988], MIT Athena RPCs [Souza and Miller1986], Stanford Modula/V RPCs [Cheriton 1984; Almes 1986], ANSAware [ANSA 1989]ACM Journal Name, Vol. V, No. N, Month 20YY.


and Rajdoot RPCs [Panzieri and Shrivastava 1988]. A comprehensive survey that presentsand compares these approaches is provided by [Tay and Ananda 1990]. With hindsight, weare now able to say that there are three strands of remote procedure calls that had significantimpact. An overview of the relevant impact traces is shown in Figure 15 below.


[Nelson, 1980]Remote Procedure Calls

[Lauer&Satterthwaite 1979]Mesa

[DeRemer & Kron 1976]Module Interconnection Languages

[Liskov et al 1977]CLU

[Liskov 1980]Distributed Systems Primitives

[Parnas 1972]Software Module Specification

[Shirley&Rosenberry 1995]Microsoft RPC

[Dineen et al 1987]NCA

[Leach et al 1982]UIDs

[Goldberg 1980]Smalltalk

[Stroustrup 1977]C++

[Kong 1995]OSF/DCE

[Rosenberry et al, 1992]Understanding DCE

[OSF, 1996]Glossary[IETF RFC 1050, 1988]

Sun ONC RPCs

[Sun, 2001]Solaris 5.9 RPC man

[Redhat 2005]RHEL 3.0 RPC man

[Apple 2006]MacOS X Tiger, RPC man

[APM, 1989]ANSA Reference Manual

[Microsoft TechNet, 2003]What is RPC?

[Microsoft]MS RPC

[Microsoft]DCOM

Fig. 15. Impact traces for remote procedure call systems

The first strand is ANSAWare, which influenced the ODP standard and CORBA as de-scribed above. The ANSA Reference Manual [ANSA 1989] states that “the protocol forremote operation invocation is very similar to remote procedure calls” and explicitly citesthe Cedar RPC mechanism of Xerox [Birrell and Nelson 1984]. ANSAware includes aninterface definition language (IDL), a compiler for that interface definition language thatgenerates stubs, which resolve data heterogeneity and implements presentation and mar-shalling in very much the same way as proposed by [Birrell and Nelson 1984].



The second strand are RPCs as defined by Sun’s Open Network Computing [Sun Mi-crosystems 1987; 1988]. ONC has been highly influential as it defines the RPC mechanismthat is built into any Linux, Mac OS X, Solaris and other BSD Unix variants. Evidence forthis influence is the fact that the RPC manual pages on these Unix variants explicit refer-ence the relevant IETF RFCs that define ONC RPCs. Amongst these, IETF RFC 1050 [SunMicrosystems 1988] refers to Andrew Birrell’s and Bruce Nelson’s work by stating: “Thisdocument specifies a message protocol used in implementing Sun’s Remote Procedure Call(RPC) package. [...] It does not attempt to justify RPC or its uses. The paper by Birrelland Nelson [1] is recommended as an excellent background to and justification of RPC.”.Thus, the IETF RFC explicitly references the XEROX technical report that was eventuallypublished as [Birrell and Nelson 1984] as providing the background and rationale for usingRPCs.

The third strand is the NCA RPC strand that heavily influenced OSF/DCE RPCs andMicrosoft’s RPC. The “What is RPC?” page of Microsoft’s TechNet [TechNet 2003] listsMicrosoft products and technologies that depend on Microsoft’s RPC implementation,which includes DCOM, COM+, the management interfaces to DHCP and DNS services,the Distributed Transaction Coordinator and many others. The relationship between Mi-crosoft RPCs and DCOM was confirmed by Paul Leach in an interview when he said that“DCOM is just a slight extension of MS RPC”. Leach also confirmed that Microsoft werefully aware of Birrell and Nelson’s paper when they defined MS RPCs. Microsoft’s RPCimplementation, however, evolved from the Distributed Computing Environment (DCE)of the Open Software Foundation (OSF). A comprehensive account on the relationship ofMicrosoft’s RPCs and DCE/RPCs is given in Chapter 7 of [Shirley and Rosenberry 1995];We can assume this reference to be authoritative as Rosenberry was also an editor of theOSF/DCE specifications.

OSF/DCE specifies a number of technologies and its remote procedure calls are definedin [Open Group 1997]. DCE was defined by the Open Software Foundation, a precursorto the OpenGroup in a public standardization process. DCE comprises a number of ba-sic technologies that are required to build secure distributed systems. These technologiesinclude a remote procedure call facility, distributed file system, a distributed time service,directory services and a standardized threading library. Unfortunately, the DCE standardsdocuments themselves do not include any references to the origins of the technology thatwas adopted. However, several sources state that the RPC mechanism of DCE emergedfrom Apollo’s Network Computing Architecture (NCA) that was incorporated into HP-UX following Apollo’s merger with Hewlett Packard:

—[Kong 1995] states in his HP Journal article on DCE that the “NCA specifications definethe protocols that govern the interaction of clients and servers, the packet format inwhich RPC data is transmitted over the network, and the Interface Definition Language(IDL) that is used to specify RPC interfaces. DCE RPC is based on Version 2 of NCA.”.

—The DCE glossary [Open Group 1996] states that “ Network Computing Architecture(NCA): An architecture for distributing software applications across heterogeneous col-lections of networks, computers and programming environments. NCA specifies the DCERemote Procedure Call architecture.”

NCA/RPCs were first described by [Dineen et al. 1987]. In their paper describing NCA,[Dineen et al. 1987] explicitly reference Cedar [Birrell and Nelson 1984] to acknowledgethe origin of the concept of a remote procedure call. When we interviewed Paul Leach,ACM Journal Name, Vol. V, No. N, Month 20YY.


one of the original architects of NCA he confirmed that “like ANSAware, NCA includesan interface definition language (IDL), a compiler for that interface definition languagethat generates stubs which resolves data heterogeneity and implements presentation andmarshalling in very much the same way as proposed by Birrell and Nelson in 1984”. TheNCA paper also states that NCA/RPCs borrow object-oriented concepts and explicitly ref-erences [Goldberg 1983] and that it carefully distinguishes between interfaces and imple-mentations. Moreover, the paper states that the object references that are passed as the firstparameter to any remote procedure call are akin to the self concept in Smalltalk and the thisconcept in C++ and the paper refers to [Stroustrup 1986]. NCA/RPCs then define an inter-face definition language, which has many of the concepts that are still used in the IDL ofOSF/RPCs and in Microsoft’s IDL. For example NCA/RPCs are the origin of UUIDs withwhich DCE/RPC or Microsoft IDL interfaces are uniquely identified. The use of uniqueidentifiers in distributed computing was first proposed in [Leach et al. 1982].

Because all three RPC impact traces lead to [Birrell and Nelson 1984], we can indeedsafely conclude that this is the seminal paper that is widely acknowledged as the firstdefinitive description of remote procedure calls. It was written while Andrew Birrell andBruce Nelson were members of the Xerox Palo Alto Research Centre (PARC). The paperdescribes the Cedar remote procedure call system. Cedar was a programming developmentenvironment that was developed at Xerox and RPCs were used for distributed communica-tion between tools within this environment. It is interesting to note that Birrell and Nelsonstate that the particular aim of producing a program development environment forced themto define aspects of an RPC system that were only poorly understood earlier. The maincontribution of Birrell and Nelson’s paper is that it for the first time determined the keyarchitectural abstractions required for an RPC mechanism, such as stubs that marshall andunmarshall parameters, that these stubs can be derived automatically from an interfacedefinition of some form, the different reliability semantics for remote procedure calls, andthe handling of address parameters in remote procedure calls and it reported about theexperimental evaluation and performance results obtained for the Cedar RPC system.

Birrell and Nelson acknowledge that ideas for RPCs had been around much earlier. Priorto his employment at PARC, Bruce Nelson completed his PhD on remote procedure calls inthe Department of Computer Science at Carnegie Mellon University [Nelson 1981]. [Bir-rell and Nelson 1984] state that the Xerox Cedar RPC mechanism was influenced by the“work done at MIT” and reference [Liskov 1980] on principles of distributed computing.In this paper, Liskov highlights the importance of modularity of distributed systems. Toachieve that, Liskov proposes a number of distributed systems extensions to CLU [Liskovet al. 1977]. As far as we can see now, there was little influence of the guardians thatLiskov proposed as a CLU extension in this paper, but her case in favour of modularityand separation of interfaces and implementation of distributed system components wereextremely influential and led to the inclusion of an interface definition language in all RPCmechanisms.

Andrew Birrell and Bruce Nelson describe the importance of an interface in [Birrell andNelson 1984]. It is from such an interface definition that they were the first to derive clientand server stubs that they use in their architecture. This practice is now commonplace inall RPC implementations, it is used in COM and CORBA

For defining interfaces, the Cedar RPC mechanism uses an interface definition languagecalled Mesa. An early description of Mesa is provided by [Geschke et al. 1977]. In their



ICSE 79 paper, [Lauer and Satterthwaite 1979] describe the language in more detail anddescribe that “Mesa has many of the attributes of a module interconnection language, asdefined by [DeRemer and Kron 1975; 1976]” and that it therefore builds on the principlesof information hiding established by [Parnas 1972].

9. SUMMARY

While conducting the study we observed a number of commonalities about the way tech-nology is transferred from research into successful products. We summarize this paper bydistilling these commonalities in an attempt to guide future technology transfer activities.

9.1 Technology transfer takes time

The discussion of the impact that research has had in a number of key middleware marketsegments fully confirms the findings of [Redwine and Riddle 1985], who concluded theirpaper by stating “The case studies show that it takes on the order of 15 to 20 years tomature a technology to the point that it can be popularized and disseminated to the tech-nical community at large”. The transfer of research into widespread use in middlewaretechnologies required an equal amount of time.

Remote Procedure Calls - 16 years:. The key ideas of information hiding and moduleinterconnection languages were published between between 1972 and 1979, the relevantpublications describing research into remote procedure call approaches appeared between1980 (Bruce Nelson’s PhD thesis) and 1987 (Apollo’s Network Computing Architecture).RPCs were included in the first operating systems (Domain and SunOS) from 1987 andstandardized between 1988 (IETF ONC RFCs) and 1991 (OSF/DCE).

Distributed Transactions - 20 years:. Starting from Moss’ PhD thesis in 1980, a largenumber of non-standard transaction mechanisms were published. The notion of transac-tions was first incorporated into distributed objects in Dixon’s PhD thesis in 1988. Between1994 and 1996 distributed transaction mechanisms were standardized by the Open Group(the ODTP XA and RM specifications) and the OMG Object Transaction Service and fol-lowing inclusion of the Java Transaction API and the Java Transaction Service in the J2EEspecification application server products brought distributed transactions to widespread usearound the turn of the millennium.

Distributed Objects - 15 years:. A significant amount of research into distributed ob-jects occurred between 1985 (Eden) and 1988 (Emerald and Argus). The work was con-solidated by Andrew Birrell’s and Greg Nelson’s network objects in 1990, picked up in1996 by Waldo at Sun, standardized through JCP in the late 1990s and has started to beused broadly with the rise of application servers from 2000.

9.2 Interdisciplinarity

We note that the impact traces we have documented above very frequently cut across thedifferent disciplines identified in the ACM computing classification. The RPC trace in-volves citations from the operating systems, networks, programming languages and soft-ware engineering literature. Likewise the distributed transaction trace involves citationsfrom the operating system, database and software engineering literature.

We also observe that the largest impact is sometimes in an industry related to a CS disci-pline other than the one in which an idea was first published. Gray’s notion of transactionswere first published in a book on “Notes on Operating Systems”. They were then nurturedACM Journal Name, Vol. V, No. N, Month 20YY.


by the database community and eventually were integrated with object-oriented conceptsand their largest use of distributed transactions to date is in application server middleware.Likewise the first ideas of message passing were published by Steve Reiss to support inte-gration of software development tools and subsequently they were adopted by tool vendorsand transferred to the middleware departments.

9.3 Importance of PhD research

Another interesting observation is the significant number of PhD theses that featured in theimpact traces. We can only give some examples. For the RPC trace these include Nelson’sPhD thesis at CMU and Panzieri’s thesis at Newcastle. For the distributed transaction traceit includes Moss’ thesis on nested transactions that provided the basic concepts used fornested transactions in the CORBA Transaction service and Dixon’s thesis at Newcastleon the integration of distributed objects and distributed transaction management. For dis-tributed objects Andrew Birrell’s and Greg Nelson’s network object paper refers to Orcafor which Bal’s thesis defined the programming model at Vrije Universiteit in Amsterdam.Likewise the distributed object model of the Emerald system that influenced Network Ob-jects was defined by Hutchinson in his PhD thesis at the University of Washington.

We believe it is therefore fair to state that these PhD theses provided the foundationsfor many concepts and their experimental validation in prototype systems that are used inmiddleware today. And we go on to postulate that without the work of these PhD studentswe would not have distributed object models, RPC semantics and architecture, distributedtransactions and application servers in their current form.

9.4 People movement

Providing conceptual foundations and experimental validation, however, is only one side ofcreating impact. These concepts and the knowledge about how to apply them in carefullyengineered systems need to be transferred into industrial practice. We observed that a verysuccessful mechanism for that transfer that may currently not receive sufficient attention isthe mobility of researchers who devised these concepts from research into industry. Againwe can only give a few examples.

Following completion of his PhD in the Cambridge Computing Lab and a period ofpost-doctoral research on distributed systems with Roger Needham, Andrew Herbert washired as Technical Director for the Alvey-funded ANSA project in 1984. The ANSA Teamproduced the ANSA reference model, middleware and a series of design papers over thenext ten years; in its latter years the project was funded by Esprit ¡and directly by indus-trial partners through Architecture Projects Management Ltd (APM). Following graduationwith a PhD from CMU, Bruce Nelson joined Xerox PARC where he wrote the definitivepaper on RPCs with Andrew Birrell. Birrell had similarly obtained his PhD also fromthe Computing Lab in Cambridge. Andrew Birrell then went on to move to DEC SystemResearch where he wrote the Network Object paper that provided the basis for Java RMIwith Greg Nelson. Andrew Watson who had worked in various European ESPRIT researchprojects at APM on ANSA moved to the OMG, where he played a pivotal role in the defi-nition of the CORBA standard. Joe Sventek moved from APM where he had worked withAndrew Herbert and Andrew Watson to Hewlett Packard where he wrote the CORBA 1.0specification jointly with Jim Waldo Sun. Jim Waldo then moved from Hewlett Packardto Sun where he wrote the RMI specification. Graeme Dixon moved from Newcastle toTransarc where he wrote the OMG Object Transaction and Concurrency Control Service



specifications.

9.5 Standardization

We note that all middleware market segments we have discussed in this article have un-dergone significant standardization efforts. The web services technologies have been stan-dardized by the World Wide Web Consortium, the J2EE specification was defined throughthe Java Community Process. CORBA was defined by the Object Management Groupand the two main flavours of RPCs were defined by the Open Group and the IETF. TheOpen Group also standardized the interfaces for distributed transaction processing and theInternational Standardization Organization played important roles both in distributed trans-action processing and in standardizing SGML. We would even go a step further and saythat we have not seen any significant impact of research results without the results havingbeen consumed by a standardization process.

Apart from facilitating the agreement between the main industrial stakeholders that isrequired for a technology to gain widespread adoption, standardization plays a number offurther important roles that may be less obvious. Firstly, standardization is a necessary, butnot sufficient, pre-requisite for achieving interoperability between different technologies.This is important in order to preserve investments, to achieve migration paths between tech-nology adoptions and to facilitate large-scale integration. Secondly, standardization bodiesare a technology transfer hothouse. When standards are created competing proposals areprepared, written, assessed and merged. As is evident from the significant number of min-utes taken during these discussions intense debates occur on the merits and shortcomingsof proposed techniques and these debates achieve engagement of the participants in thesubject matter. As a result technology transfer occurs very successfully during standard-ization. Thirdly, standardization focuses the attention of market analysts. Once significantinvestment is committed into a standardization process, which often demands availabil-ity of products that implement the standardized technology, analysts gain confidence tocomment on the development of that technology and have done so in the past. As a re-sult the standards and their assessments by market analysts become focal points for futureinvestments.

10. CONCLUSIONS

In this article, we have shown the ample influence that research in different Computer Sci-ence disciplines had on the development of middleware standards and products implement-ing these standards. Without researchers laying the foundations in Computer Science de-partments at Brown, CMU, Cambridge, Newcastle, MIT, Vrije, University of Washingtonwithout industrial researchers at Xerox PARC, IBM Research, HP Labs, DEC Research,AT&T Research, APM consolidating basic research results, contributing them to standardsand informing product development departments we would not have the 8.5 billion dollarmiddleware market in the same form as we have it today.

Acknowledgements

We are very grateful to Mike Mahoney of Princeton University, whose experience andguidance on history of science has helped us to steer clear of the many pitfalls in conductingresearch outside our immediate area of expertise.

This article could not have been researched without the considerable help from a largenumber of people. Amongst others, we are grateful to Andrew Watson, Dino Mandrioli,ACM Journal Name, Vol. V, No. N, Month 20YY.


Frank Leymann, Andrew Herbert, Santosh Shrivastava, Fabio Panzieri, Andrew Birrell, JoeConron, Ward Rosenberry, Paul Kettley, Adrian Colyer, Stefan Tai, Dick Dievendorff, PaulLeach, C. Mohan, Rob Drew, Steven Reiss, Graeme Dixon, C Mohan and Brian Randell.The authors are also indebted to the members of the Impact project and in particular to thesteering committee members, Lee Osterweil, Jeff Kramer, Alexander L. Wolf and CarloGhezzi for the guidance and encouragement they have provided during the last five years.

The authors thank ACM SIGSOFT, the Institution of Electrical Engineers and the Na-tional Science Foundation for significant financial support that made this study possible.

REFERENCES

ALMES, G. 1986. The Impact of Language and System on Remote Procedure Call Design. In Proc. of the 6th

Int. Conference on Distributed Computing Systems. IEEE CS Press, 414–421.ALMES, G. T., BLACK, A. P., LAZOWSKA, E. D., AND NOE, J. D. 1985. The Eden system: A Technical

Overview. IEEE Transactions on Software Engineering 11, 1 (Jan.), 43–58.ALONSO, G., AGRAWAL, D., ABBADI, A. E., KAMATH, M., GUNTHOR, R., AND MOHAN, C. 1995. Ad-

vanced Transaction Models in Workflow Contexts. Research report, IBM Research, IBM Almaden. July.ALUR, D., MALKS, D., AND CRUPI, J. 2003. Core J2EE Patterns: Best Practices and Design Strategies. Sun

Microsystems Press. Prentice Hall.ANDREAS, W. 1991. HyperDesk’s response to the ORB RFP. OMG TC Document 91.1.6, Object Management

Group, 492 Old Connecticut Path, Framingham, MA, USA. Jan.ANDREWS, T., CURBERA, F., DHOLAKIA, H., GOLAND, Y., KLEIN, J., LEYMANN, F., LIU, K., ROLLER,

D., SMITH, D., THATTE, S., TRICKOVIC, I., AND WEERAWARANA, S. 2003. Business process executionlanguage for web services version 1.1. Tech. rep., OASIS, ifr.sap.com/bpel4ws. May.

ANSA. 1989. The Advanced Network Systems Architecture (ANSA). Reference manual, Architecture ProjectManagement, Castle Hill, Cambridge, UK.

ASTRAHAN, M. M., BLASGEN, M. W., CHAMBERLIN, D. D., ESWARAN, K. P., GRAY, J. N., GRIFFITHS,P. P., KING, W. F., LORIE, R. A., MCJONES, P. R., MEHL, J. W., PUTZOLU, G. R., TRAIGER, I. L.,WADE, B. W., AND WATSON, V. 1976. System R: Relational Approach to Database Management. ACMTransactions on Database Systems 1, 2, 97–137.

ATKINSON, M. P., BANCILHON, F., DEWITT, D., DITTRICH, K., MAIER, D., AND ZDONIK, S. 1990. TheObject-Oriented Database System Manifesto. In Proc. of the 1st International Conference on Deductiveand Object-Oriented Databases, Kyoto, Japan, W. Kim, J.-M. Nicholas, and S. Nishio, Eds. North-Holland,223–240.

BACON, J. M. AND HAMILTON, K. G. 1988. Distributed Computing with the RPC: the Cambridge Approach.In Distributed Processing. IFIP, North-Holland, 355–369.

BAL, H. E. 1989. The Shared Data Object Model as a Paradigm for Programming Distributed Systems. Ph.D.thesis, Dept. of Computer Science, Vrije Universiteit Amsterdam, The Netherlands.

BAL, H. E., KAASHOEK, M. F., AND TANNENBAUM, A. S. 1992. Orca: A language for parallel programmingof distributed systems. IEEE Transactions on Software Engineering 18, 3 (Mar.), 190–205.

BALTER, R. 1991. Bull’s response to the ORB RFP. OMG TC Document 91.1.5, Object Management Group,492 Old Connecticut Path, Framingham, MA, USA. Jan.

BALZER, R. 1987. Living in the Next Generation Operating System. IEEE Software, 77–85.BARGHOUTI, N. S. 1992. Supporting cooperation in the Marvel process-centered SDE. In SDE 5: Proceedings

of the fifth ACM SIGSOFT symposium on Software development environments. ACM Press, New York, NY,USA, 21–31.

BERNSTEIN, P. A. 1990. Transaction processing monitors. Communications of the ACM 33, 11, 75–86.BERNSTEIN, P. A. 1996. Middleware: A Model for Distributed System Services. Communications of the

ACM 39, 2, 86–98.BERNSTEIN, P. A., HADZILACOS, V., AND GOODMAN, N. 1987. Concurrency Control and Recovery in

Database Systems. Addison Wesley.BIEBERSTEIN, N., BOSE, S., WALKER, L., AND LYNCH, A. 2005. Impact of Service-Oriented Architecture

on Enterprise Systems, Organizational Structures and Individuals. IBM Systems Journal 44, 4, 691–708.



BIRMAN, K. AND THOMAS, J. 1989. Exploiting replication in distributed systems. In Distributed Systems,S. Mullender, Ed. Addison-Wesley, 319–365.

BIRRELL, A., NELSON, G., OWICKI, S., AND WOBBER, E. 1993. Network objects. ACM SIGOPS OperatingSystems Review 27, 5, 217–230.

BIRRELL, A. D. AND NELSON, B. J. 1984. Implementing Remote Procedure Calls. ACM Transactions onComputer Systems 2, 1 (Feb.), 39–59.

BIRRON, P. V., PERMANENTE, K., AND MALHOTRA, A. 2004. XML Schema Part 2: Datatypes. Tech. rep.,World Wide Web Consortium. Oct.

BLACK, A., HUTCHINSON, N., JUL, E., LEVY, H., AND CARTER, L. 1987. Distribution and abstract types inEmerald. IEEE Transactions on Software Engineering 13, 1, 65–76.

BOOCH, G. 1991. Object-Oriented Design with Applications. Benjamin Cummings.BOX, D. 2001. A Brief History of SOAP. webservices.xml.com/pub/a/ws/2001/04/04/soap.html.BOX, D., EHNEBUSKE, D., KAKIVAYA, G., LAYMAN, A., MENDELSON, N., NIELSEN, H. F., THATTE, S.,

AND WINER, D. 2000. Simple object access protocol (soap) 1.1. Note, World Wide Web Consortium,www.w3.org/TR/2000/NOTE-SOAP-20000508/. May.

BRAY, T., PAOLI, J., AND SPERBERG-MCQUEEN, C. M. 1998. Extensible Markup Language. Recommenda-tion www.w3.org/TR/1998/REC-xml-19980210, World Wide Web Consortium. Mar.

CAGAN, M. R. 1990. The HP SoftBench Environment: An Architecture for a New Generation of SoftwareTools. Hewlett-Packard Journal, 36–47.

CHARLES, J. 1999. Middleware Moves to the Forefront. IEEE Computer 32, 5 (May), 17–19.CHERITON, D. R. 1984. The V Kernel: A Software Base for Distributed Systems. IEEE Software 1, 2, 19–42.CHERITON, D. R. AND DEERING, S. E. 1988. Host Groups: A Multicast Extension for Datagram Networks.

ACM SIGCOMM Computer Communications Review 15, 4, 172–179.CHEUNG, S. 1999. Java Transaction Service (JTS). Sun Microsystems, 901 San Antonio Road, Palo Alto, CA

94303.CHEUNG, S. AND MATENA, V. 1999. Java Transaction API (JTA). Sun Microsystems, 901 San Antonio Road,

Palo Alto, CA 94303.CHINNICI, R., GUDGIN, M., MOREAU, J.-J., SCHLIMMER, J., AND WEERAWARANA, S. 2004. Web services

description language (wsdl) 2.0. Working draft, World Wide Web Consortium, www.w3.org/TR/wsdl20. Aug.CHRISTENSEN, E., CURBERA, F., MEREDITH, G., AND WEERAWARANA, S. 2001. Web Services Description

Language (WSDL) 1.1. W3c note, W3C. March.CLARK, J. AND DEROSE, S. 1999. XML Path Language (XPath) Version 1.0. Recommendation

www.w3.org/TR/1999/REC-xpath-19991116, World Wide Web Consortium. Nov.COBB, E. E. 1997. The impact of object technology on commercial transaction processing. The VLDB Jour-

nal 6, 3, 173–190.COLOURIS, G., DOLLIMORE, J., AND KINDBERG, T. 1994. Distributed Systems: Concepts and Design, 2nd

ed. Addison Wesley.CORREIRA, J. M. AND BISCOTTI, F. 2006. Market Share: AIM and Portal Software, Worldwide, 2005. Gartner

market research report, Gartner. June.COX, B. J. 1986. Object oriented programming: an evolutionary approach. Addison-Wesley Longman.CURBERA, F., WEERAWARANA, S., AND DUFTLER, M. J. 2000. Network accessible service specifica-

tion language: An xml language for describing network accessible services. Tech. rep., IBM Research,apps.alphaworks.ibm.com/technologies/soap4j/nassl.pdf. May.

DEMICHIEL, L. AND KEITH, M. 2005. Enterprise Java Beans Version 3.0: EJB Core Contracts and Require-ments. JSR 220, Sun Microsystems, 4140 Network Circle, Santa Clara, CA 95054. Dec.

DEREMER, F. AND KRON, H. 1975. Programming-in-the-large versus programming-in-the-small. In Proceed-ings of the international conference on Reliable software. 114–121.

DEREMER, F. AND KRON, H. 1976. Programming-in-the-large versus programming-in-the-small. IEEE Trans-actions on Software Engineering SE-2, 2, 80–86.

DINEEN, T. H., LEACH, P. J., MISHKIN, N. W., PATO, J. N., AND WYANT, G. L. 1987. The NetworkComputing Architecture and System: An Environment for Developing Distributed Applications. In Proc. ofthe 1987 Summer USENIX Conference, Phoenix, Arizona, USA. USENIX Association, Berkeley, CAL, 385–398.



DIXON, G. 1988. Object management for persistence and recoverability. Ph.D. thesis, University of Newcastle,School of Computer Science.

DIXON, G. N., PARRINGTON, D. D., SHRIVASTAVA, S. K., AND WHEATER, S. M. 1989. The treatment ofpersistent objects in Arjuna. Computer Journal 32, 4, 323–332.

EMMERICH, W. 2000. Engineering Distributed Objects. John Wiley & Sons, Chichester, UK.EMMERICH, W., ELLMER, E., AND FIEGLEIN, H. 2001. TIGRA – An Architectural Style for Enterprise

Application Integration. In Proc. of the 23rd Int. Conference on Software Engineering, Toronto, Canada.IEEE Computer Society Press, 567–576.

ENRIGHT, C. 1991. Software AG’s response to the ORB RFP. OMG TC Document 91.1.10, Object ManagementGroup, 492 Old Connecticut Path, Framingham, MA, USA. Jan.

EUGSTER, P. T., FELBER, P. A., GUERRAOUI, R., AND KERMARREC, A.-M. 2003. The many faces of pub-lish/subscribe. ACM Computing Surveys 35, 2, 114–131.

FANCEY, J. 2005. Build Better Business Processes with Web Services in BizTalk Server 2004. MSDN Maga-zine 20, 3 (Mar.).

FLEURY, M. AND REVERBEL, F. 2003. The JBoss Extensible Server. In Proc. of the ACM/IFIP/USENIXInternational Middleware Conference 2003, Rio de Janeiro, Brazil, M. Endler and D. C. Schmidt, Eds. LectureNotes in Computer Science, vol. 2672. Springer, 344 – 373.

FREBURGER, L. 1991. DEC response to the ORB RFP. OMG TC Document 91.1.7, Object Management Group,492 Old Connecticut Path, Framingham, MA, USA. Jan.

GESCHKE, C. M., MORRIS, J. H., AND SATTERTHWAITE, E. H. 1977. Early Experience with Mesa. Commu-nications of the ACM 20, 8 (Aug.), 540–553.

GILPIN, M. 2002. Market overview update: Application server market. Tech. rep., Forrester Research. May.GOLDBERG, A. 1983. Smalltalk-80: The Language and its Implementation. Addison Wesley.GOLDFARB, C. F. 1981. A generalized approach to document markup. ACM SIGPLAN Notices 16, 6, 68–73.GRAY, J. 1993. Transaction Processing – Concepts and Techniques. Morgan Kaufman, San Mateo, CA.GRAY, J. N. 1978. Notes on Database Operating Systems. In Operating systems: An advanced course, R. Bayer,

R. Graham, and G. Seegmuller, Eds. Lecture Notes in Computer Science, vol. 60. Springer, Chapter 3.F.,393–481.

GRIMES, R. 1997. DCOM Programming. Wrox.GUDGIN, M., HADLEY, M., MENDELSOHN, N., MOREAU, J.-J., AND NIELSEN, H. F. 2003. Simple object

access protocol (soap). Recommendation, World Wide Web Consortium, www.w3.org/TR/soap12-part1. June.HAGEL, J. AND BROWN, J. S. 2002. Out of the Box: Strategies for Achieving Profits Today and Growth Tomor-

row through Web Services. Harvard Business School Press.HAPNER, M., BURRIDGE, R., SHARMA, R., AND FIALLI, J. 2001. Java Message Service. Sun Microsystems,

2550 Garcia Avenue, Mountain View, CA 94043, USA.HART, R. O. AND LUPTON, G. 1995. DEC FUSE: Building a Graphical Software Development Environment

from UNIX Tools. Digital Technical Journal 7, 2, 5–19.HAZELTINE, N. 1991. NCR’s response to the ORB RFP. OMG TC Document 91.1.9, Object Management

Group, 492 Old Connecticut Path, Framingham, MA, USA. Jan.HEFFNER, R., FULTON, L., CULLEN, A., GILPIN, M., AND PEYRET, H. 2006. Service Oriented Architectures.

Tech. rep., Forrester Research, www.forrester.com/Research/Document/Excerpt/ 0,7211,38503,00.html.HERBERT, A. 1991. APM’s response to the ORB RFP. OMG TC Document 91.1.2, Object Management Group,

492 Old Connecticut Path, Framingham, MA, USA. Jan.HESS, M. L., LORRAIN, J. A., AND MCGEE, G. R. 1995. Multiprotocol networking – A blueprint. IBM

Systems Journal 34, 3, 330–346.HOLLINGSWORTH, D. 1995. The Workflow Reference Model Version 1.1. Tech. Rep. TC00-1003, Workflow

Management Coalition, 2 Crown Walk, Winchester SO22 5XE, UK. Jan.HUTCHINSON, N. 1987. Emerald: An Object-Based Language for Distributed Programming. Ph.D. thesis, Dept.

of Computer Science, University of Washington.IBM. 1995. MQSeries - An Introduction into Messaging and Queuing. Tech. Rep. GC33-0805-01, IBM UK

Laboratories, Hursley Park, Winchester, Hampshire, England, SO21 2JN. June.ISO 8879. 1986. Information processing – Text and Office Systems – Standard Generalized Markup Language

SGML. Tech. rep., International Standards Organisation.



JENKINS, B. 1972. Developments in Computer Auditing. Accountant, 537.JENSEN, T., METAYER, D. L., AND THORN, T. 1998. Security and Dynamic Class Loading in Java: A Formal-

ization. In Proc. of the 1998 Int. Conf. on Computer Languages. IEEE Computer Society Press, 4.JONES, C. B. 1980. Software Development - A Rigorous Approach. Prentice Hall.JUL, E., LEVY, H., HUTCHINSON, N., AND BLACK, A. 1988. Fine-grained mobility in the Emerald system.

ACM Transactions on Computer Systems 6, 1 (Feb.), 109–133.KEENE, S. 1989. Object-Oriented Programming in Common Lisp. Addison-Wesley.KONG, M. M. 1995. DCE: An Environment for Secure Client/Server Computing. Hewlett-Packard Journal 46, 6

(Dec.), 6–15.LAMPSON, B. W. AND STURGIS, H. E. 1976. Crash recovery in a distributed data storage system. unpublished

manuscript.LAMPSON, B. W. AND STURGIS, H. E. 1979. Crash recovery in a distributed data storage system. Technical

report, Xerox PARC.LAUER, H. C. AND SATTERTHWAITE, E. H. 1979. The Impact of Mesa on System Design. In Proc. of the 4th

Int. Conference on Software Engineering, Munich, Germany. IEEE Computer Society Press, 174–182.LEACH, P. J., STUMPF, B. L., HAMILTON, J. A., AND LEVINE, P. H. 1982. UIDs as Internal Names in a

Distributed File System. In Proc. of the Symposium on Principles of Distributed Computing. ACM Press,34–41.

LEYMANN, F. 2001. Web Service Flow Language (WSFL). Tech. rep., IBM, www-4.ibm.com/ soft-ware/solutions/webservices/pdf/WSFL.pdf. May.

LEYMANN, F. AND ALTENHUBER, W. 1994. Managing business processes as an information resource. IBMSystems Journal 33, 2, 326–384.

LEYMANN, F. AND ROLLER, D. 1994. Business Process Management with FlowMark. In Digest of Papers ofCompCon Spring ’94. IEEE Computer Society Press, 230–234.

LEYMANN, F., ROLLER, D., AND SCHMIDT, M. T. 2002. Web Services and Business Process Management.IBM Systems Journal 41, 2, 198–211.

LIANG, S. AND BRACHA, G. 1998. Dynamic class loading in the Java virtual machine. In OOPSLA ’98:Proceedings of the 13th ACM SIGPLAN conference on Object-oriented programming, systems, languages,and applications. ACM Press, 36–44.

LISKOV, B. 1980. Primtives for Distributed Computing. ACM Operating Systems Review 13, 5 (Dec.), 33–42.LISKOV, B. 1988. Distributed Programming in Argus. Communications of the ACM 31, 3 (Mar.), 300–312.LISKOV, B. AND SNYDER, A. 1979. Exception Handling in CLU. IEEE Transactions on Software Engineer-

ing SE-5, 6 (Nov.), 546–558.LISKOV, B., SNYDER, A., ATKINSON, R., AND SCHAFFERT, C. 1977. Abstraction mechanisms in CLU. Com-

munications of the ACM 20, 8 (Aug.), 564–576.LITTLE, S. M. AND SHRIVASTAVA, S. K. 2002. An Examination of the Transition of the Arjuna Distributed

Transaction Processing Software from Research to Products. In Proc. of the 2nd Int. Workshop on IndustrialExperience with Systems Software, Boston, MA (co-located with OSDI ’02). Usenix Association.

MATHEWS, M. 1991. HP’s response to the ORB RFP. OMG TC Document 91.1.4, Object Management Group,492 Old Connecticut Path, Framingham, MA, USA. Jan.

MEREDITH, L. G. AND BJORG, S. 2003. Contracts and Types. Communications of the ACM 46, 10, 41–47.MERRICK, P. AND ALLEN, C. 1997. Web Interface Definition Language. Note, World Wide Web Consortium,

www.w3.org/TR/NOTE-widl. Sept.MEYER, B. 1988. Object-oriented Software Construction. Prentice Hall.MICROSOFT. 2003. Enterprice Solution Patterns Using Microsoft .NET. Microsoft Press.MILNER, R. 1999. Communicating and Mobile Systems: the π-calculus. Cambridge University Press.MOCKAPETRIS, P. AND DUNLAP, K. J. 1988. Development of the domain name system. SIGCOMM Comput.

Commun. Rev. 18, 4, 123–133.MOHAN, C. 1999. Repeating History Beyond ARIES. In Proc. of the 25th International Conference on Very

Large Data Bases, Edinburgh, UK, M. Atkinson, M. E. Orlowska, P. Valduriez, S. B. Zdonik, and M. L.Brodie, Eds. Morgan Kaufman, 1–17.

MOHAN, C. AND DIEVENDORFF, D. 1994. Recent Work on Distributed Commit Protocolls, and RecoverableMessaging and Queuing. IEEE Data Engineering Bulletin 17, 1, 22–28.



MOSS, E. B. 1981. Nested transactions: An approach to reliable distributed computing. Tech. Rep. TR-260,Massachusetts Institute of Technology, Cambridge, MA.

MOSS, J. B. 1985. Nested Transactions: An Approach to Reliable Distributed Computing. MIT Press.NADALIN, A., KALER, C., HALLAM-BAKER, P., AND MONZILLO, R. 2004. Ws security. Tech. rep., OASIS.

Mar.NELSON, B. J. 1981. Remote Procedure Call. Ph.D. thesis, Carnegie Mellon University.Object Management Group 1991. The Common Object Request Broker: Architecture and Specification Version

1.0. Object Management Group, 492 Old Connecticut Path, Framingham, MA 01701, USA.Object Management Group 1993a. Object Transaction Service – Reponse to the OMG’s second RfP. Object

Management Group, www.omg.org/docs/1993/93-11-16.pdf.Object Management Group 1993b. Transaction Service Proposal. Object Management Group,

www.omg.org/docs/1993/93-11-01.pdf.Object Management Group 1995. The Common Object Request Broker: Architecture and Specification Revision

2.0. Object Management Group, 492 Old Connecticut Path, Framingham, MA 01701, USA.OKI, B., PFLUEGL, M., SIEGEL, A., AND SKEEN, D. 1993. The Information Bus: an architecture for extensible

distributed systems. In SOSP ’93: Proceedings of the fourteenth ACM symposium on Operating systemsprinciples. ACM Press, 58–68.

OMG. 1998a. CORBAservices: Common Object Services Specification, Revised Edition. Object ManagementGroup, 492 Old Connecticut Path, Framingham, MA 01701, USA. www.omg.org/docs/formal/98-12/09.pdf.

OMG. 1998b. Notification Service. Object Management Group, 492 Old Connecticut Path, Framingham, MA01701, USA.

Open Group 1996. DCE Glossary. Open Group, Reading, UK. www.opengroup.org/dce/info/papers/dce-glossary.htm.

OPEN GROUP, Ed. 1997. DCE 1.1: Remote Procedure Calls. The Open Group.PANZIERI, F. AND SHRIVASTAVA, S. K. 1988. Rajdoot: A remote procedure call mechanism supporting orphan

detection and killing. IEEE Transactions on Software Engineering 14, 1, 30–37.PARNAS, D. C. 1972. A Technique for the Software Module Specification with Examples. Communications of

the ACM 15, 5, 330–336.PELTZ, C. 2003. Web services orchestration and choreography. IEEE Computer 36, 10, 46–52.PRUDHOMMEAUX, E. 2000. XML Protocol Comparison. Tech. rep., World Wide Web Consortium,

www.w3.org/2000/03/29-XML-protocol-matrix.RANDELL, B. AND NAUR, P., Eds. 1969. Software Engineering. Report on a conference sponsored by the NATO

Science Committee. NATO Scientific Affairs Division. Brussels.REDWINE, S. T. AND RIDDLE, W. E. 1985. Software Technology Maturation. In Proc. of the 8th Int. Confer-

ence on Software Engineering, London, UK. IEEE Computer Society Press, 189–200.REID, B. K. 1981a. Scribe: a document specification language and its compiler. Ph.D. thesis, Carnegie Mellon

University.REID, B. K. 1981b. The Scribe Document Specification Language and its Compiler. In Proc. of the Int.

Conference on Research and Trends in Document Preparation Systems. 59–62.REISS, S. 1987. Overview of the FIELD Environment. Tech. rep., Dept. of Computer Science, Brown University.REISS, S. 1990. Connecting tools using message passing in the field environment. IEEE Software, 57–66.ROTHERMEL, K. AND MOHAN, C. 1989. ARIES/NT: A Recovery Method Based on Write-Ahead Logging for

Nested Transactions. In Proceedings of the Fifteenth International Conference on Very Large Data Bases, Au-gust 22-25, 1989, Amsterdam, The Netherlands, P. M. G. Apers and G. Wiederhold, Eds. Morgan Kaufmann,337–346.

RYDER, B. G., SOFFA, M. L., AND BURNETT, M. 2005. The Impact of Software Engineering Research onModern Programming Languages. ACM Transactions on Software Engineering and Methodology 14, 4, 431–477.

SHAPIRO, M. 1991. General and per-submission evaluations to responses to the ORB RFP. OMG TC Document91.5.7, Object Management Group, 492 Old Connecticut Path, Framingham, MA, USA. Aug.

SHAPIRO, M., GOURHANT, Y., HABERT, S., MOSSERI, L., RUFFIN, M., AND VALOT, C. 1989. SOS: Anobject-oriented operating system: assessment and perspectives. Computer Journal 2, 4, 287–337.



SHEFFLER, L. 1991. Constellation’s response to the ORB RFP. OMG TC Document 91.1.3, Object ManagementGroup, 492 Old Connecticut Path, Framingham, MA, USA. Jan.

SHIA, D. 1990. DSET’s response to the ORB RFP. OMG TC Document 91.1.1, Object Management Group,492 Old Connecticut Path, Framingham, MA, USA. Jan.

SHIRLEY, J. AND ROSENBERRY, W. 1995. Microsoft RPC Programming Guide. O’Reilly.SHRIVASTAVA, S. K., DIXON, G. N., AND PARRINGTON, G. D. 1991. An Overview of the Arjuna Distributed

Programming System. IEEE Software 8, 1, 66–73.SKEEN, D. 1991. Teknekron’s response to the ORB RFP. OMG TC Document 91.1.8, Object Management

Group, 492 Old Connecticut Path, Framingham, MA, USA. Jan.SKEEN, D. 1992. An Information Bus Architecture for Large-Scale Decision-Support Environments. In Proc.

of the Winter Usenix Conference. 183–195.SNYDER, A. 1986. Encapsulation and Inheritance in Object-Oriented Programming Languages. ACM SIGPLAN

Notices 21, 11, 38–45. Proc. of the Object-Oriented Programming Systems, Languages and Applications(OOPSLA) Conference, Portland, OR.

SNYDER, A. 1990a. A Glossary of Common Object-Oriented Terminology. OMG TC Document 90.1.8, ObjectManagement Group, 492 Old Connecticut Path, Framingham, MA, USA. Jan.

SNYDER, A. 1990b. Draft OMG Object Model. OMG TC Document 90.1.2, Object Management Group, 492Old Connecticut Path, Framingham, MA, USA. Jan.

SOLEY, R. 1991. ORB RFP Responses: Final submissions. Memorandum to OMG TC ORB Task Force.www.omg.org/docs/1991/91-02-02.txt.

SOLEY, R. M. 1992. Object Management Architecture Guide. Wiley, 492 Old Connecticut Path, Framingham,MA 01701, USA.

SOUZA, R. J. AND MILLER, S. P. 1986. Unix and Remote Procedure Calls: A Peaceful Coexistence? In Proc.of the 6th Int. Conference on Distributed Computing Systems. IEEE CS Press, 268–277.

SPECTOR, A. Z., BLOCH, J. J., DANIELS, D. S., DRAVES, R., DUCHAMP, D., EPPINGER, J. L., MEENES,S. G., AND THOMPSON, D. S. 1986. The Camelot Project. IEEE Database Engineering Bulletin 9, 3, 23–34.

SPECTOR, A. Z., BUTCHER, J., DANIELS, D. S., DUCHAMP, D. J., EPPINGER, J. L., FINEMAN, C. E.,HEDDAYA, A., AND SCHWARZ, P. M. 1985. Support for Distributed Transactions in the TABS Prototype.IEEE Transactions on Software Engineering 11, 6, 520–530.

SRINNIVASAN, P. 2001. An Introduction to Microsoft .NET Remoting Framework. Tech. rep., Microsoft,Redmont, Washington, USA. July.

STROUSTRUP, B. 1986. The C++ Programming Language. Addison Wesley.SUN MICROSYSTEMS. 1987. XDR: External Data Representation Standard (RFC 1014). IETF.SUN MICROSYSTEMS. 1988. RPC: Remote Procedure Call Protocol Specification, Ver. 2.0 (RFC 1050). IETF.Sun Microsystems 1998. Java Remote Method Invocation Specification, Revision 1.50, JDK 1.2 ed. Sun Mi-

crosystems.SVENTEK, J. AND ANDREAS, W. 1991. The Common Object Request Broker: Architecture and Specification.

OMG TC Document 91.8.1, Object Management Group, 492 Old Connecticut Path, Framingham, MA, USA.Aug.

TAY, B. H. AND ANANDA, A. L. 1990. A survey of remote procedure calls. ACM SIGOPS Operating SystemsReview 24, 3, 68–79.

TECHNET. 2003. What is RPC? Microsoft. technet.microsoft.com.THATTE, S. 2001. Xlang: Web services for business process design. Tech. rep., Microsoft.WALDO, J. 1998. Remote Procedure Calls and Java Remote Method Invocation. IEEE Concurrency 6, 3 (July-

September), 5–7.WEBER, B. 1990. Object Request Broker Request for Proposals. OMG TC Document 90.10.5, Object Manage-

ment Group, 492 Old Connecticut Path, Framingham, MA, USA. Oct. www.omg.org/docs/1990/90-10-05.txt.WEERAWARANA, S., CURBERA, A., LEYMANN, F., STOREY, T., AND FURGUSON, D. F. 2005. Web Services

Platform Architecture. Prentice Hall.WINER, D. 1999. XML RPC. Tech. rep., UserLand Software. June. www.xmlrpc.com/spec.WIRFS-BROOK, R., WILKERSON, B., AND WIENER, L. 1990. Designing Object-Oriented Software. Prentice

Hall.



WOLLRATH, A., RIGGS, R., AND WALDO, J. 1996. A Distributed Object Model for the Java System. UsenixComputing Systems 9, 4, 265–290.

Xerox OPD 1981. Courier: The Remote Procedure Call Protocol, Xerox System Integration Standard 038112ed. Xerox OPD.

X/OPEN GROUP. 1991. Distributed Transaction Processing: The XA Specification. X/Open Company, ISBN 1872630 24 3, Reading, UK.

YOUNG, M. W., THOMPSON, D. S., AND JAFFE, E. 1991. A Modular Architecture for Distributed TransactionProcessing. In Proc. of the Winter 1991 USENIX Conference. Usenix Association, 357–363.


Documents

The Impact of Research on the Development of Middleware ... · has had on the development of middleware technology. We undertake an existence proof rather than attempt a comprehensive