One angle you missed on it is quite interesting, though. About a year
ago, you wrote an article about HTML competing with MS Word DOC objects
as a standard format for representing, displaying, and storing
information. I thought that was a little misguided at the time, in the
sense that HTML really isn't a serious competitor yet, and doesn't seem
like it will be anytime soon.
However, Rohit Khare, a friend of mine, has been doing some interesting
analysis about how a new way of modeling information content , XML (it's
cross-compatible with HTML), may take off as a competitor to CORBA and
even more general database functions. Rohit just left the W3C and has a
great perspective on this stuff.
Rohit, would you please e-mail Bill your Church of Objectology diatribe
and a link to your XML paper?
- dan
-- Daniel Kohn <dan@teledesic.com> Teledesic Corporation PGP KeyID: 0x6129DD6D +1-425-602-6222 (voice) 602-0002 (fax) http://www.teledesic.com>-----Original Message----- >From: Bill Gurley [SMTP:bgurley@abovethecrowd.com] >Sent: Tuesday, July 01, 1997 8:44 AM >To: atc@abovethecrowd.com >Subject: Above the Crowd: 97-13 > >Above the Crowd: 97-13 >Deutsche Morgan Grenfell Technology Group >J. William Gurley >bill_gurley@dmgtech.com >415-614-1159 > >DCOM AND CORBA: MAKING SENSE OF THE OBJECT WARS >"It's action - reaction; Random interaction. So who's afraid; >Of [a] little abstraction?" - Rush, Roll the Bones > >We often wonder how a generalist portfolio manager interprets the >highly technical and highly popularized object battle between >Microsoft# (MSFT, $128) and the "Gang of Four" [IBM (IBM, $91), >Oracle# (ORCL, $50), Sun (SUN, $32), and Netsacpe@# (NSCP, $34)]. It >must certainly be easy to assume that DCOM and CORBA are of marginal >importance and that all of these analysts and techies are arguing over >something that is of little relevance to the investor. However, >investors may be drawn to a position of indifference solely as a >result of the complexity of the issue and the lack of time which would >be necessary to understand it. With this as a backdrop, we will now >embark on the noble task of simplifying the strategic importance of >the object war in just under three written pages. We have one central >theme - control the tools of the programming community and control the >direction of the entire industry. We also have one conclusion - the >big war is a long way off, but a victory in a subtle near-term battle >could stack the cards for one of the camps. > >Our journey begins with the original IBM PC, a 16-year-old technology >native to Boca Raton, Florida. Early application developers had to be >fairly knowledgeable of the hardware design of this early PC in order >to effectively interface with input/output (I/O) devices such as the >hard drive, the video screen, or the keyboard. While some programmers >chose to interface directly with these devices, others simply >leveraged the very first abstraction layer for PC programmers - the >"BIOS" (Basic Input Output System). The BIOS was encoded on a ROM on >the system's motherboard, and made it easier for programmers to >interact with the machine. Interestingly, but not surprisingly, >Microsoft introduced another abstraction layer in its DOS operating >system. However, due to the poor performance of these early systems, >programmers often ignored the built in "DOS Calls" and continued to >write directly to the hardware and the BIOS. > >Over time, and as the performance improved, Microsoft was able to >encourage more and more programmers to write code based around DOS >calls as opposed to BIOS calls. However, this fight would not occur >without a struggle. First, as an increasing number of programmers >became infatuated with graphical user interfaces as opposed to text, >the need for performance pushed some programmers increasingly closer >to the hardware. Second, Borland began to emerge as the leader in >easy-to-use PC programming languages with products such as Turbo >Pascal and Turbo C. This potentially gave control of the programmer >to Borland which could have encouraged programmers to use proprietary >sub-routines and function calls, removing the direct interaction with >DOS, BIOS, or the hardware. Of course, we all know that this did not >happen. > >Ignoring the fiasco with OS/2, it was the evolution of the Windows >operating system that eventually gave Microsoft complete control over >PC developers. To start with, Microsoft released a new abstraction >layer, known as the Windows API, which sought to further simplify the >complexity of the underlying machine. Over time, this would be >replaced with the Win32 API (a 32-bit version) and finally Microsoft >Foundation Classes (MFC), a set of predefined class libraries that >made it much easier for developers to build standard Windows >applications. MFC also made it easier for the programmer to adopt >Microsoft's compound document technology which was then known as OLE. >OLE would allow programs to share data through features such as copy >and paste, and would also allow one application to edit data that was >placed specifically inside another application. > >Once programmers begin to use MFC for most of their PC programming >needs, they were no longer interfacing directly with the hardware or >I/O devices. Rather, they wrote programs based on standard device >calls controlled by Microsoft. This eventually allowed Microsoft to >port its operating system to multiple hardware systems by implementing >support for MFC on multiple platforms. It was assumed that all >developers would need to do was to recompile for the new platform, >although the reality has not proved to be so simplistic. Microsoft >does still support Windows NT on Digital's Alpha platform, but several >other cross-platform initiatives have been shelved. > >As more programmers became comfortable with Windows, Microsoft evolved >OLE from an compound document technology into a broader component >model. OLE 2.0 would allow programmers to integrate standard >applications and system services at run-time as opposed to compile >time. This way, when the OS is upgraded, the applications can "keep >up with the times." The run-time insertion of code is one of the many >features of an object-oriented programming environment, and explains >why certain Win 3.1 applications can naturally adopt the user >interface of Windows 95. Microsoft would go on to rename its entire >object strategy "COM" (Component Object Model) and also add support >for cross-network communication (DCOM). > >The rise of the Internet would prove unsettling to Microsoft's >continued control of the desktop programmer. By late 1995, the >hippest applications in the land were no longer being written for MFC >or COM, but rather for a quirky text-based format language known as >HTML. Microsoft must have been surprised at how quickly a rudimentary >protocol like HTML was able to sever the programmer and the underlying >software platform. What's more, programs that used HTML as a user >interface would now run on several platforms, not just platforms >designed by Microsoft. Almost simultaneously, Sun was implementing a >programming language, known as Java, which would also run on every >platform (with the help of a hardware-specific interpretation engine). >Developers reveled in these new network-centric tools, and Microsoft >pondered a recovery scheme. > >Microsoft has done two things to limit the potential threat of HTML. >First and foremost, Microsoft has taken a leading roll in defining its >evolution. The company is heavily involved in influencing the >direction at the two leading Internet standards bodies (the W3C and >the IETF). Second, Microsoft introduced ActiveX controls, which are >basically lightweight OLE components that can be executed from within >HTML. You can consider Microsoft adding ActiveX to HTML as an attempt >to string together the browser with the rich abstraction layer that >exists underneath the browser on Windows machines. While HTML is >certainly a poor third cousin with respect to the complexity and >feature-set of MFC, it nonetheless represents a programming >abstraction layer above that which was previously controlled by >Microsoft. > >Java is frustrating to Microsoft simply because the company truly sees >Java as a programming language and not a platform. In Microsoft's >world, programming languages are used to build standardized components >and to link together predefined OS services and applications. In >either case, the choice of the programming language has little to do >with the resulting application. Therefore, one could argue that >Microsoft is more actively evolved in a competition with Java's class >libraries than it is in a direct competition with Java, the >programming language. So while Sun and Netscape race to add a richer >abstraction layer on top of the Java language (they were originally >implementing competing class libraries but have recently merged their >efforts), Microsoft recently introduced "J/Direct," which gives >programmers using Microsoft's Java development environment complete >access to the Win32 operating system services. The J/Direct >initiative, much like the ActiveX initiative, reconnects the browser >(and virtual machine) to the underlying operating system. > >So what are distributed objects? And what are DCOM, CORBA, and IIOP? >As mentioned before, Microsoft's COM model gives programmers (and >users) an easy way to piece together software components on the >desktop while hiding the complexities of the underlying OS and system. >DCOM extends the component model to the network, allowing programmers >to piece together software components across a LAN or the Internet, >while hiding the complexity that is inherently existent in such an >implementation. CORBA is the alternative object model that is >supported by the "Gang of Four." It, too, was designed to help >programmers build applications that span multiple clients and servers. >IIOP is the specific piece of CORBA that defines how objects on >different computers communicate with each other. You may want to >think of IIOP as an abstraction layer above HTTP, the file transfer >protocol that currently dominates Internet communications. The DCOM >equivalent to IIOP was once called Network OLE; however, it is now >typically just thought of as part of DCOM. > >It is important to realize that Microsoft's strength comes from the >desktop whereas CORBA's strength comes from the server. This is >because DCOM is really an extension of a compound document >architecture whereas CORBA was designed from the ground up as a robust >server-side programming model for distributed applications. This >implies that Microsoft will have a huge advantage in integrating DCOM >into the browser. It also implies that CORBA is much more mature than >DCOM in terms of its readiness as server-based distributed application >infrastructure. The heterogeneity of the back office is also a big >plus for CORBA, as IBM, SUN, and Oracle are much more active on the >server than on the desktop. Over time, Microsoft plans to offer high- >end DCOM services, such as directory and security, although these will >not be commercially available until Windows NT 5.0 ships around mid- >1998. Until then, DCOM is more of a competitor to IIOP than it is to >CORBA. > >We believe that the battle between IIOP and DCOM as a network >transport protocol is much more important then the battle between >CORBA and DCOM as a distributed object architecture. Programmers can >take advantage of IIOP without fully supporting CORBA. They would >just be using IIOP as an abstract network communication tool (as an >improvement to HTTP) as opposed to a complete infrastructure for >object-oriented, multitiered, networked applications. They will >eventually write these large distributed applications, but we don't >expect them to become commonplace over the next few years. In the >meantime, we should pay special attention to the competition for the >network abstraction layer. Whoever wins this seemingly insignificant >battle for the cross-network communication protocol could be in an >strong position to control the crucial layer above it. This is >because the distributed object models are currently built on top of >specific network communication protocols. > >Going forward, we expect the DCOM-IIOP battle to heat up >significantly. On the IIOP front, all four of the "Gang of Four" are >quickly adding support to their products. On the DCOM side, Microsoft >is likely to leverage its powerful position as an industry leader to >encourage client/server application vendors such as SAP# (SAPHY, $70) >and PeopleSoft# (PSFT, $56) to implement DCOM extensions to their >underlying application functions. Interestingly, support for DCOM >will likely be limited to the communication between the client and the >application layer. The connection layer behind the application is >much more likely to be based on proprietary technology or even IIOP. >Some will suggest that DCOM/IIOP translators will exist and that all >this worrying will be for naught. However, the Microsoft >interpretation of where this translation should take place exposes the >importance of controlling the network communication abstraction layer. >The March 17, 1997, issue of WebWeek noted, "...Microsoft feels that >it is more appropriate for the translation to take place on the CORBA >server." In other words, keep CORBA as far back in the network as >possible and let DCOM become the abstraction layer that actually >exists on the network. > >Controlling the highest-level abstraction layer for programmers is >strategically important because it allows a company to dictate the way >all programs interact with the underlying operating systems, hardware, >and increasingly the network equipment as well. Also, by controlling >the complex abstraction layer, a company is in a good position to >deliver superior applications built upon the abstraction layer. >Certainly, Microsoft's understanding of Windows and OLE were central >to the company's Microsoft Office success. It should follow that the >potential power that would be awarded to a company that single- >handedly controlled the program interfaces for all distributed >applications would be immense. A vendor in this position would have a >huge advantage in both client and server software sales, would wield >significant control over hardware and network equipment makers, and >would eventually represent a significant threat to the client-server >application vendors, which until now, have controlled their own >distributed application platforms. > >Interestingly enough, DMG's enterprise application analyst, George >Gilbert, believes that an even higher level abstraction layer will >emerge above either DCOM or CORBA. Just as MFC knows about windows, >and menus, and toolbars and hides such things as Win32, DOS, and the >BIOS, this abstraction layer would be cognizant of such things as the >organizational structure and the chart of accounts, and would help >hide DCOM and CORBA. For more on this subject read his own >newsletter, Beyond the Enterprise, which is attached to this one. To >be added to his list, follow the instructions at the end of his >newsletter. > >#Deutsche Morgan Grenfell Inc. makes a market in this security. >@Deutsche Morgan Grenfell Inc. or one of its affiliates managed or co- >managed a public offering of securities for this company within the >last three years. Stocks priced 6/27/97. > >Above the Crowd is a bi-weekly publication focusing on the evolution >and economics of the Internet. It is distributed through First Call, >fax and e-mail. To be placed on the distribution list contact your >Deutsche Morgan Grenfell salesperson or send email to atc- >request@abovethecrowd.com with the word "subscribe" in the body. As >always, feedback is both welcomed and encouraged. ABOVE THE CROWD is a >service mark of J. William Gurley. > >Deutsche Morgan Grenfell 31 W. 52nd Street >New York, NY 10019-6118 Tel. (212) 468-5000/Fax (212) 468-8013 > >Copyright (c) Deutsche Morgan Grenfell Inc. 1997. All rights >reserved. The information contained herein has been obtained from >sources believed to be reliable, but is not necessarily complete and >its accuracy cannot be guaranteed. Any opinions expressed are subject >to change without notice. Deutsche Morgan Grenfell Inc. and its >affiliated companies and/or individuals may, from time to time, own, >have positions in, or options on the securities discussed herein and >may also perform financial advisory services, and/or have lending or >other credit relationships with those companies. This material has >been approved for distribution in the United Kingdom, to professional >investors who fall within the exemptions contained within the UK >Financial Services Act 1986 Investment Advertisement Exemptions Order >1988, by Deutsche Bank AG London, 6 Bishopsgate, London EC2P 2AT. >Member of the LSE and SFA, Tel: (171) 9717900, Fax: (171) 971-7988. >Orders placed by UK persons directly with Deutsche Morgan Grenfell >Inc. will not be governed by all Investor Protection provisions of UK >Financial Services Act 1986. Additional information available on >request. >____________________________________________________________________________ > >Beyond the Enterprise: 97-01 >Deutsche Morgan Grenfell Technology Group >George Gilbert >george_gilbert@dmgtech.com >415-614-1169 > >The Battle for the Enterprise Backbone > >Another battle for control of enterprise computing is emerging: the >new "business operating system" . This is a new software layer that >hides all the SQL databases, transaction monitors, object request >brokers, and traditional server operating systems. The unlikely >sources of these new operating systems are the leading Enterprise >Resource Planning application vendors: SAP, PeopleSoft, BAAN, Oracle, >and J.D. Edwards. > >Alternatively known as enterprise application backbones, these systems >have the potential to orchestrate the entire chain of value-adding >activities across the enterprise. But no one vendor can do it alone. >Controlling the foundation layer upon which customers can assemble >multivendor, tailor-made, enterprise information systems is the focus >of this battle. The best investments are in the backbone vendors; the >specialized application vendors such as i2 Technologies that plug into >the backbone; and suppliers of unique parts of the backbone >infrastructure, such as Documentum. > >The Stakes: > >The enterprise application market, at roughly $17bn already dwarfs >the database market, at roughly $3.5bn, the focus of mainstream >investors' involvement with enterprise software. As the leading >application backbone vendors continue their inexorable rise, they have >the opportunity to push the database and operating system layers >further into the background. > >The tectonic shifts driving applications goes far beyond fixing the >year 2000 problem. The relentless force is the increasing absorption >of in-house development into ever more elastic enterprise application >packages. The expanding scope and rapidly declining cost of assembling >applications based on backbones and prefabricated parts is >commoditizing an ever-growing share of in-house development. > >How these packages can broaden to gradually subsume the $50bn to >$150bn spent on in-house development has less to do with the bricks >and mortar of application components and more to do with the design >integrity of cathedrals and skyscrapers. > >From Interchangeable Parts to Prefabricated Cathedrals and Skyscrapers: > >Software's Holy Grail has always been the creation of reusable, >interchangeable parts. These are the bricks and mortar of software >construction. Conventional wisdom says that a standard for these >parts or components, such as ActiveX or CORBA, will unleash software's >industrial revolution. The Grail remains just beyond our grasp. >Several more obstacles remain. > >The war over component standards does not solve the problem of >creating prefabricated applications. It only solves the problem of >how the components connect. To continue our construction analogy, >with a component standard, we've made it easy for masons to fit each >building block together with its neighbors. We've also reused our >engineers' stone-cutting expertise by allowing building blocks to be >mixed and matched. > >But we still haven't delivered the scarcest and most valuable skill >for reuse. We haven't given the architect's blueprints that specify >how to assemble the building blocks into cathedrals and skyscrapers to >the masons. They are left to come up with their own. > >The True Value of the Backbone: > >Distilled to its technical essence, this blueprint, which we also call >the enterprise backbone, is an application repository. It is more >than a simple container for connecting the application components. It >contains the design rules that bind the components into an application >cathedral. These rules allow each of the components to participate in >the overall design: how a company is organized, including its chart of >accounts; how business processes interact, such as order entry >updating the production plan; and how all components share a >consistent set of data such as a parts list. > >When components share this design, the backbone can rapidly adapt to >changing business conditions. Adding a factory with three product >lines belonging to separate business units simply requires a change in >the organizational model to update the application. > >Designing an adaptable foundation empowers orders-of-magnitude more >third-party and corporate developers to build industry and company- >specific solutions. They need only add their unique requirements. >The backbone already has all the basic administrative functionality >such as financial accounting and control, HR, and order management. >Backbone vendors are now racing against each other to add >functionality to address core operational activities as well. But >they are taking care to make these additions part of the reusable >design. For example, if Baan adds maintenance, repair, and overhaul >functionality for the aerospace & defense market, that same >functionality should serve the shipbuilding and food processing >markets. > >This is the true value of packaging and reusing the work of others. >Individual components are bricks and mortar. But the application's >entire fabric, or backbone, provides a much richer foundation that >reflects the rare design expertise of systems architects rather than >that of a single component engineer. Backbones from SAP, Baan, >PeopleSoft, Oracle, and J.D. Edwards don't overlap completely, as each >continues to compile additional functionality in selected industries. >The availability of competing but complementary backbones will >accelerate the substitution of packaged software for the $50bn-$150bn >spent on custom development each year. Increasingly mature backbones >will drive software's industrial revolution more than any single >bricks-and-mortar standard such as ActiveX or Corba. > >Where Is Microsoft?: > >Readers may wonder, if the backbone battle settles into an oligopoly, >what's to prevent Microsoft from coming in to take control from below >if ActiveX wins? Several factors are likely to delay Microsoft's >entry long enough so that today's leaders become far more entrenched. >First, to compete for the application backbone, Microsoft will have >to use its incomplete ActiveX component model. In other words, it >would have to add temporary patches that may represent migration >obstacles until ActiveX catches up to Corba in two or three years. >All current backbone vendors have made the same compromises but none >is trying to establish a component standard at the same time. More >important, Microsoft appears to believe that responsibility for the >architectural foundation belongs to individual Information Systems >departments within customer organizations. Microsoft has talked >about this component vision without an underlying application backbone >for years. Perhaps most important, Microsoft does not have the >internal resources to go after this market right now. It is having >difficulty staffing many of its currently committed products. We have >heard stories of dozens, if not hundreds, of openings in NT >development alone. > >The Backbone's Place in the Enterprise Computing Universe: > >At any given moment in enterprise computing, there is always a center >of gravity for business solutions that defines which company has >market power. At one point, it was IBM with the mainframe. Later it >was the minicomputer vendors as applications spread beyond the data >center. SQL databases followed when applications became wedded to >them, not the underlying operating system. Now the enterprise >resource planning applications have themselves morphed into backbones, >assuring their continued dominance of enterprise computing as we move >to the next level, industry solutions. Investors and vendors alike >can choose to surf this wave as it gathers strength or watch as it >washes over the entire industry. > >Deutsche Morgan Grenfell 31 W. 52nd Street >New York, NY 10019-6118 Tel. (212) 468-5000/Fax (212) 468-8013 > >Copyright (c) Deutsche Morgan Grenfell Inc. 1997. All rights >reserved. The information contained herein has been obtained from >sources believed to be reliable, but is not necessarily complete and >its accuracy cannot be guaranteed. Any opinions expressed are subject >to change without notice. Deutsche Morgan Grenfell Inc. and its >affiliated companies and/or individuals may, from time to time, own, >have positions in, or options on the securities discussed herein and >may also perform financial advisory services, and/or have lending or >other credit relationships with those companies. This material has >been approved for distribution in the United Kingdom, to professional >investors who fall within the exemptions contained within the UK >Financial Services Act 1986 Investment Advertisement Exemptions Order >1988, by Deutsche Bank AG London, 6 Bishopsgate, London EC2P 2AT. >Member of the LSE and SFA, Tel: (171) 9717900, Fax: (171) 971-7988. >Orders placed by UK persons directly with Deutsche Morgan Grenfell >Inc. will not be governed by all Investor Protection provisions of UK >Financial Services Act 1986. Additional information available on >request. > >