BLUE COAT SYSTEMS - Exhibit 1034 Page 1
`
`BLUE COAT SYSTEMS - Exhibit 1034 Page 1
`
`

`
`PwGHshed bv NlicrosfJft P~~'~
`/•, Division of fvt:!;::::ros<it Corporiltion
`Dn~ M!t;.ri:)S;Gl't \'Vay
`.
`RedmOrid·,.vvash!ngl:on· 980.52-6399
`
`f.1art of lh!! nv1ten~ of thls byok rnay be
`or
`Df by a:~y moans v:!thout th~ V.'titte-n penni%iOtt of th~ ;:;c.bii>h,er,
`
`o:s::r_iSuted t·o.t.he bnok trade in. Can~da by M('::fTnflia:i of Canada, a dlv1sk:m of Can aria
`P'ubl~shing Corporation,
`
`r-.'taclrit.oo'h·_ls::.~::n.so&gwre9: ~adeit1-tnk 0t A.ppl->:: Cl::JrDr~tC"fx He·, ISM i~ 11 mgistetOO twdernark ()f
`,l_r1t~fnath~~xak B~:;_~ness \A<:t:hlne$' c{\E'f:R~nltiorL 1-2~3 end l-otvs i'Hitl rmgi~;J;;r$:J tfad€~!'k§. of Lotu:;;
`Dey~i5Jfn!~~Ci::ltp:ftmtl.on-. Mkro~oft! Mkrnsoft J'r~~-' ~rfinint Vh;u~l 6i'Mc, Vi:tim~ C++,
`. \VimlQ\\:s;)h1d}¥i[l(}:o:W? NT __ Me registered tm00rMJJks and At;tiveX 4fl(J Visi.ial h--+ ;tre tr<1dr:!ma:b
`_ofJ<~iCtk?~oft-,>;?~tln:ti_~ -~dsc.ape h a H~Ji:fn:.o<k of'Nct-;c::tp~ C.f«n:nun~c~t!nns Cotpnr<!tkm.
`· N~'fNiirt'._AA<'BJ f,;p:;ri?U ;m:: rq;t~t~n:!d !ri!dern<irk$·of Nc-1!\)l\,. ktC, Pt'W1i.'ttlullder- 1:> a tr;acl£:r:hlfk oi
`P<;:r,\~tf':r~Qft,C)'rp(}~<lt!oll •. fWl1 .. unci S.un Micwsy!i;~ms aro reg;ist&t!;';d t·;;dermlrk> .a0d Java \sa
`tfa:;:hrm.>!k t{S~JQ:Mj.C:m:ystetl'H, !r.c.
`
`:iil
`
`BLUE COAT SYSTEMS - Exhibit 1034 Page 2
`
`

`
`wart to use Actlvc:X and OLE technologl·es !n the sofbivare
`deveiop, but it encompasses a broader audience a.s wen .. As you
`can quickly determine by tHpping through the pages, this ts not a
`programming book-it contains almosl no code, Although : do
`as.sume that the reader Ls a software professional of sorne kjnc.'L i
`
`c>o.'-'-~ r~1"\1'1..'1 "-'"·" :"""""'~''""'·~~~t ·~nA !_.,_,,..~,_HtMo- u•h::>f'
`_;• __ 1:.'-"~---V' r-..~ t:'
`ttttllt$, i'"\'LUVCA 1 "-JL!xt ct;l;) '1.,-.-V'"'~ CHC: 3113r.'Vt~c;.to•~~ <~'''-' '"''VY''"'b u'FH
`they are and how they work matters to a. broader group than ih:o~A:
`who program for Microsoft V\lit~dows. Some famlilanty W!th using
`\Vindows. is taken for granted!
`this. seemed safe fiJ me:
`as it's h~nJ "i:f) f!nrlnnyo;;e in this fle!d who hasn't used VJindows
`
`A Timestamp
`The ActiveX and OLE technolog!es are a mcr .. "ing target This book
`describes the fundamental COM-based technologies as of mid-
`1996, jn particular, Chapter 10 on Dlstributt:~d COf.i\ ;rd Chapter
`
`sonh::
`m __ :t-u~ny shippe-ci.
`before tho~e
`details described in these chapters might not exactiy match what
`is fl0ally deHvcred,
`
`Where to find More Detail
`For sume people, the
`of coveragt: c;ffered in t?1is book win
`be enough. {For
`1t wd! s.u•·t;-'y t>e h.!(J much,J uevelopttrs
`who need a more intimate understanding of the topic wifl
`want to get a copy of the OLE ~·bible" for progr<!mmers, Kra!g
`BroCkschmidt's inside OLE, 2d eeL (P.A~cros-nft Pre"s, 19YS), A11-
`
`'
`
`•
`
`'
`
`,
`
`'
`
`-"""' ,,.,
`
`'
`
`~~.' .-. '""
`
`' -
`
`'
`
`'
`
`-
`
`- -' _J-
`
`, • .,_
`
`,_ L
`
`"
`
`' '
`
`'
`
`'
`
`runy aaaresseo m msme uu:::, ~~ tjLt: Lotnrw!i ms:ut:: \Jw, oy
`Adam Denning {Mkro5oft PreSS1 1995)o {Watch for a new edition
`of this book, too, one ;hat descr!b"'s the recent changes in what
`are now known as ActiveX controls.) For the truly hard~t::OrE~
`
`BLUE COAT SYSTEMS - Exhibit 1034 Page 3
`
`

`
`to rnake my
`re:_1.dable, co::e-ct, 2.r:d c!e2.r. ThanYs :;dsc to
`David Clark, tv-Hcros(>ft Press acqulsitions editol~ for accepHng my
`:ather mforrnal p:oposo! for this book
`
`Hna!!Yt my v~.hfe, Karen, has been
`and
`supportive through thb and many other projects, somethlng! too
`often forget to mention. \;\/hhout her, it wou!d be hard to do any
`rli thP thino:-::. l dn
`-· v·~ v-···o~. ~·~-
`
`ju.fy 1996
`
`BLUE COAT SYSTEMS - Exhibit 1034 Page 4
`
`

`
`C h -a p t e r 0 n e
`
`•
`
`•
`
`I
`
`•
`
`I ntrOOliCing
`anci
`ACtiVe A
`
`&
`
`...
`
`,_,
`
`OLE
`
`Writing good software is hard, Writing software that's !arge and
`complex, as most code is today, is even harder. As computers
`continue to infiltrate our lives, as we depend on them for every_(cid:173)
`thing frorn running our.cars to writing letters to making toasc the
`effectiveness and reliability of software become more and more
`important. Good code is becoming the bedrock of our civilization.
`
`In some ways, the history of software is the history of efforts to
`\.'Vrite better code. App! ications and system softvvare both. have
`sufiered from endless delays, mind-boggling complexity, and
`more bugs than anyone cares to admit. But creating software is
`tough-there's no way around ii. Doing it weii requires the ability
`to take a big-picture view coupled with a willingness (an eager(cid:173)
`ness, even) to deal vvith a rnyriad of sn1all details. The intellectual
`effort required is substantial, and the tools are never perfect.
`
`l~.v1icrosoft's ActiveX and OLE are a step toward the creation of
`better software. "Better" here means software that's more reliable,
`certainly, and more effective as vve!!. But it also means softvvare
`that can do things that were impossible before, software that
`enables so!utiOflS to ne\.v problems. Although ActiveX and OLE
`are buiit on a quite sirnpie idea, this 1dea turns out to have pro(cid:173)
`found implications for improving hovv vve create softvvare.
`
`Writing good
`software is just
`plain hard
`
`ActiveX and OLE
`are about writing
`better software
`
`1
`
`BLUE COAT SYSTEMS - Exhibit 1034 Page 5
`
`

`
`OLE 1 provided a
`way to create
`compound
`documents
`
`Fron1 OLE to ActiveX
`The fiist incaination of OLE, Obj€ct Linking and Embedding 11
`was a mechanism for creating and working with compound
`documents. To its user, a compound document appears to be a
`singie set of information, but in fact it contains elements created
`by tvvo or more different appl !cations. \A/ith OLE 1, for example, a
`user couid combine a spreadsheet created using Microsoft Excei
`with a text document created using Microsoft Word, as shown in
`Figure 1-1. The idea was to give users a "document-centric" view
`of computing, to let them think more about their information and
`less about the appli~ations they were using to work with that
`information. As the name suggested, compound documents could
`be created either by linklng tvvo separate documents together or
`by completely embedding one document in another.
`
`figure 1-1
`
`A. user~o;; 1det.1/ of a compound document.
`
`Fourth q\.Wler salu more than exceeded our projections, and early reports indicate thatse~onally adjusted
`sales this quarter :are nu:u-:Ung well ahead ofthe sa.me period last yeat. The embedded spreadsheet dearly
`shows 1h.e ttendi
`
`OLE 2 introduced
`the Component
`Object Modei
`
`Like most version 1 sofp.vare releases, OLE 1 \vasn't perfect. The
`architects of the next release set out to improve on the original
`design. They soon realized that the compound-document problem
`was actuaiiy a special case of a more general problem: how
`
`2
`
`Chapter One
`
`BLUE COAT SYSTEMS - Exhibit 1034 Page 6
`
`

`
`should various software components provide services to one
`another? To address this larger problem, OLE's architects created
`a set of technologies that were applicable to much more than
`compound documents. Foremost among these technologies vvas
`the Component Object Modei (COM), which provided the foun(cid:173)
`dation for OLE 2_ This new version of OLE supported compound
`docurnents even better than the first release 1 b.ut clearly a lot more
`was going on here than simply combining documents created by
`different applications. OLE 2 offered the potential for a nevv way
`of thinking about how software of all kinds should interact.
`
`This potentia! \vas largely the result of COt·A. COt\.-\ establishes a
`common paradigm for interaction among all sorts of software-(cid:173)
`libraries, applications, system soft\·vare, and more. Accordlng!y,
`virtually any kind of software technology can be implemented
`using the approach COM defines, and doing so offers some very
`tangible benefits.
`
`Because of those benefits, COM soon became a part of technolo(cid:173)
`gies that had nothing to do with cornpound docurnents. ,-.vJdcro(cid:173)
`soft, however, still wanted to have a common name to refer to all
`C0t'v1-based technologies as a group. The company decided to
`reduce the name Obiect Linking and Embedding to just OLE-this
`three~!etter combination \Vas no !anger treated as an acronym-and
`to drop the version number.
`
`Under this ne\A! regime, the term OLE was applied to anything
`buiit using the paradigm COM provides (aithough COM was aiso
`used in products that didn't have OLE in their name). OLE no
`longer meant only compound documents but was now a iabel
`assigned to any COM-based technology. In some ways, grouping
`under a single nan-.e all softWare written using COtv~. rnakes no
`more sense than, say, grouping together all software written in
`C++. Both C0t'v1 and a programming language such as C++ are
`general tools that can be used to create all kinds of software. Still,
`both for historical reasons and to mark the advent of this ne'v ... w1 and
`far-reaching technology, the term OLE was used to identify many
`(but not quite a I!) COl\~-based technologies.
`
`CO~v1 is a foun-
`dation for inter(cid:173)
`action among all
`kinds of software
`
`The name Object
`Linking and
`Embedding
`became simply
`OLE
`
`The OLE !abe!
`was applied to
`any technology
`that used COM
`
`Introducing ActiveX and OLE
`
`3
`
`BLUE COAT SYSTEMS - Exhibit 1034 Page 7
`
`

`
`Today, most
`CO!'v1-based
`technoiogies
`are assigned
`the label
`
`-~
`
`Traditionaiiy,
`different kinds of
`software provided
`services in
`different ways
`
`In early 1996, Microsoft dropped another term into the fray:
`AciiveX. in its first appearances, this new term was associated
`with technologies related to the Internet and applications that
`grew out of the Internet, such as the VJorld V\/ide \Veb. Because
`most of Microsoft's efforts in this area were based on COM,
`,a,ctiveX >vvas directly connected to OLE. Soon, though, this nevv'
`term began to usurp more and more of OLE's traditional territory,
`and today things have come fu!! circle. No\A/ the term OLE once
`again refers only to the technology used to create compound
`documents through Object Linking and Embedding. The diverse
`set of technologies built using COM, once all grouped under the
`OLE label, are now grouped under the Active X banner. In several
`cases, technologies that had OLE in their narne have been
`rechristened as ActiveX technologies. New COM--based tech nolo-
`gies that once might have been given the OLE label are novv
`frequently tagged with ActiveX instead.
`
`!s this the end of the naming saga for COI'-A-based technologies?
`Given the history so far, the answer is probably no. What Micro(cid:173)
`soft's marketing mavens will think up next is anybody's guess. But
`despite these adventures in nomenclature, what's realiy important
`hasn't changed. What's really important is COM.
`
`Understandim! LUM
`.......
`Aii OLE technologies and aii the ActiveX technologies described
`in this book are built on the foundation provided by COM. So just
`what is C0tv1?To answer this question, think first about another·:
`how should one chunk of software access the services provided
`by another chunk of software? Today, as shown i·n rigure 1-2 1 the
`answer depends on what those chunks of software are. An appli-
`cation might, for example, link to a library and then access the
`library's services by calling the functions in the library. Or one
`application might use the services provided by another, \Vhich
`runs in an entirely separate process. In this case, the two iocal
`processes typically communicate by using an interprocess com(cid:173)
`munication mechanism, which usuaiiy requires defining a proto(cid:173)
`col between the two applications (a set of messages allowing one
`
`4
`
`Chapter One
`
`BLUE COAT SYSTEMS - Exhibit 1034 Page 8
`
`

`
`application to specify its requests and the other to respond appro-
`priately). A third example is an application that might use services
`provided by an operating syste-m. Here the application commonly
`makes system caiis, each of which is handled by the operating
`system. Or; fina!!y, an application might need the services of
`software that is running on a compieteiy different machine, acces(cid:173)
`sible via a network. Many different approaches can be used to
`access ihese services, such as exchanging messages wiih ihe
`remote application or issuing remote procedure calls.
`
`VVithout COM, different mec,hanisms are used to iiC'CC.'IiiS the services
`provided by iibraries, iocai processes, the operating system, and remote
`processes.
`
`Figure 1 .. 2
`
`Network
`
`The fundamental need in aii these relationships is the same: one
`chunk of software must access services provided by another.
`But the rnechanisrn for getting at those services differs in each
`case-local function calls, messages passed via interprocess
`communication, system calls (which in fact look pietty much
`like function calls to the programmer), or some kind of network
`cornmunication. \AJhy is this? \A/ou!dn't it be sirr:p!er to define one
`common way to access all kinds of software services, regardless
`of ho\A/ they are provided?
`
`Accessing services
`in different ways
`is needlessly
`complex
`
`This is exactly what COM does. it defines a standard approach by
`vvhich one chunk of softvvare supplies its services to another, an
`approach that works in aii the cases just described. By applying
`
`COM defines a
`common way to
`access Software
`seivices
`
`Introducing ActiveX and OLE
`
`5
`
`BLUE COAT SYSTEMS - Exhibit 1034 Page 9
`
`

`
`COM objects
`provide· services
`v1a methods that
`are grouped
`into interfaces
`
`this common service architecture across libraiies, applications,
`system software, and networks, COM is transforming the way
`soft-vvare is constructed.
`
`How COM Works
`\Nith COM, any chunk of soft\"Jare implements its services as one
`or more COM objects} Every COM object supports one or more
`interfaces, each of which includes a number of methods. A
`method is typically a function or a procedure that performs a
`specific action and can be called by the software using the COM
`object (the client of that object). The methods that make up each
`interface are usually related to one another in some way. Clients
`can access the services provided by a CO~v't object only by invok-
`ing the methods in the object's interfaces--they can't directly
`access any of the object's data.
`
`For example, imagine a speii checker implemented as a COM
`object. This object might support an interface that includes meth(cid:173)
`ods such as LookUp\tVord, AddToDiciionary, and RemoveFrom(cid:173)
`Dictionary. If the object's developer later wanted to add support
`for a thesaurus to this saine COtv1 object, the object would need
`to support another interface (perhaps with a single method such
`as ReturnSynonym}. The methods in each interface collectively
`provide related services, either spell checking or access to a
`thesaurus.
`
`The methods in
`each interface
`usua!!y focus
`on supplying a
`particuiar service
`
`Or imagine a COM object representing your bank account. it might
`support an interface that you access directly, one with methods
`such as Deposit, Withdrawal, and CheckBaiance. This same object
`might support a second interface containing methods such as
`ChangeAccountNurnber and CloseAccount, which can be in(cid:173)
`voked only by bank employees. Again, each interface contains
`methods that are related to one another.
`
`Don't confuse COM objects with the ob.iects in programming languages such
`as C++, Although they're similar in some ways; they're not the same~ Later; this
`chapter describes how COM objects relate to other kinds of objects.
`
`6
`
`Chapter One
`
`BLUE COAT SYSTEMS - Exhibit 1034 Page 10
`
`

`
`Figure 1-3 illustrates a C0r'"v1 object. l"-v1ost C0l"v1 objects support
`more than one interface, and the object in Figure 1-3 is no excep-
`ticn: it supports three interfaces, each represented by a sma!!
`circie attached to the object. The object itself is always imple(cid:173)
`mented inside a server, shovvn as the rectangle around the object.
`Tnis server can be either a dynamic-iink iibrary (OLL), which is
`loaded as needed when an application is running, or a separate
`process of iis own.
`
`A C(Jtv1 object is
`implemented
`inside a server
`and usua!!y
`supports rnultiple
`interfaces
`
`A COM object's services are accessed via its interface.•.
`
`Figure 1·3
`
`Server
`
`Figuie 1-4 shows a close~up of a single interface suppoited by this
`COM object. This interface allows access to a spell checking
`ser .. tice and contains the three methods previously listed. If another
`of the object's interfaces allowed access to the thesaurus service
`described earlier, a c!ose-up of it \vou!d contain on!y the Return-
`Synonym method. (In fact, this diagram is a bit simplified-ali
`interfaces actua!!y include a few more standard methods, which
`aren't shown here.)
`
`Each interface provides one or more methods.
`
`Figure 1-4
`
`.. ~
`
`··.'!;
`
`,· .. ;· ·,
`
`·)
`.)
`
`Introducing ActiveX and OLE
`
`7
`
`BLUE COAT SYSTEMS - Exhibit 1034 Page 11
`
`

`
`Adient uses an
`interface pointer
`to invoke an
`interface's
`methods
`
`figure i-5
`
`To invoke the methods in a C0l'v1 object's interface, a client must
`acquire a pointer to that interface. A COM object typically pro-
`vides its services through several interfaces, and the client must
`have a separate pointer to each interface whose methods it plans
`to invoke. For example, a client of our sample C0!\-1 object \o\Jou!d
`need one interface pointer to invoke the methods in the object's
`spe!! checker interface and another pointer to invoke the method
`in the object's thesaurus interface. Figure 1-5 shows a client with
`pointers to two interfaces on a single COM object.
`' _,..... - ' . . ··- . . " -
`. . . . . .
`. ....
`. ,.
`I\ <:uenl wun polnlers tu LWQ or a LVJYI ODJel.TS 1nu~rr~n:es.
`
`('
`
`Each COM object
`is an instance of
`a class
`
`Pointer to spell
`checker interface
`
`Pointer to thesaurus
`interface
`
`Every COM object is an instance of a specific class. One class, for
`example, might contain objects that provide spell checking and
`thesaurus services, while another might contain objects represent-
`ing bank accounts. Typically, you must knovv an object's class to
`begin running an actual instance of that object, which you can do
`using the COM library. This library is present on every system that
`supports COM, and it has access to a directory of aii avaiiabie
`classes of COM objects on that system. A client can, for example,
`call a funclion in the CCJtvi library specifying the class of COtvi
`object it wants and the first supported interface to which it wants
`a pointer. (The C0t'v1library provides its services as ordinary
`function calls, not through methods in COM interfaces.) The COM
`library then causes a server that implements an object of that class
`to start running. The iibrary aiso passes back to the initiating client
`a pointer t~ the requested interface on the nevvly instantiated
`COM object. The ciient can then ask the object directiy for point(cid:173)
`ers to any other interfaces the object supports.
`
`Once a ciient has a pointer to the desired interface on a running
`object it can start using the object's services simply by invoking
`
`8
`
`Chapter One
`
`_ _I
`
`BLUE COAT SYSTEMS - Exhibit 1034 Page 12
`
`

`
`the methods in the interface. To a programmer, invoking a rnethod
`looks like invoking a local procedure or function. In fact, how-
`ever, the code that gets executed might be running in a library or
`in a separate process or as part of the operating system or even on
`another system entirely. VVith COf\A, clients don't need to be
`aware of these distinctions-everything is accessed in the same
`\>Vay. As shovvn in Figure 1-6, one common mode! is used to
`access services provided by aii kinds of software.
`
`With COM,. an application acce.~~Jse.liJ an object~" services (no matter
`lvhere that object resides) by invoking a method in an interface ..
`
`Figure 1-6
`
`CO!vl and Object Orientation
`Objects are a central idea in COM. But how COM defines and
`uses objects son1etiiT1es differs frotTI the way objects are used in
`other popular object technologies. To understand how COM
`relates to other object-oriented technologies, it's useful to describe
`what's commonly meant by the term object-oriented and then see
`hovJ" CO!'v1 fits in.
`
`Defining an object The term object has been blurred by mar-
`keteers trying to !atch on to the latest fad, but in the minds of
`most, object-oriented technologies have a few key characteristics.
`Chief among these is a common notion of what constitutes an
`object. There is widespread agreement that an object consists of
`two elements: a defined set of data (also called state or attributes)
`
`An object is a
`combination of
`data and methods
`
`Introducing ActiveX and OLE
`
`9
`
`BLUE COAT SYSTEMS - Exhibit 1034 Page 13
`
`

`
`and a group of methods. These methods, commonly implemented
`riS procedures or functions, rill ow'" client of the object to ask the
`object to perform various tasks. Figure 1-7 shows a simple picture
`of an object
`
`,I
`
`I
`
`Figure 1-7
`
`An object has both n;eiJ;ods and data.
`
`Uniike COM, most
`popular object
`technologies
`al\o·w only a
`singie interface
`per object
`
`So far, so good-objects in COM are exactly like this. But in most
`object technologies~ each object supports a.sing!e interface vvith a
`singie set of methods. in contrast, COM objects can-and neariy
`always do-support more than one interface . .An object in C++,
`for exarnple1 has only a single inierface that includes all the
`object's methods. A COM object, with its multiple interfaces,
`might well be in1plemented using several C++ objects, one for
`each COM interface the object supports (although C++ isn't the
`only language that can be used to build CO~v1 objects). 2
`
`Another familiar idea in object technology is the notion of class.
`A!! objects representing bank accounts, for example, might be of
`the same ciass. Any particuiar bank account object, such as the
`one representing your account; is an instance of this class.
`
`in COM, a ciass
`identifies a par(cid:173)
`ticular imple-
`mentation of a
`set of interfaces
`
`COM objects, too, have classes, as already described. in COM, a
`class identifies a specific implementation of a set of interfaces.
`Several different irnplernentations of the sarne set of interfaces can
`exist, each of which is a different class. From the client's point of
`view, what n1atters are the interfaces. How those inteifaces are
`implemented, which is what the class really indicates, isn't the
`
`I
`
`I
`
`I
`I
`
`10
`
`2
`
`It's worth noting that, like COM objects, objects in the Java programming
`language can have muitipie interiaces. in fact, as described in chapter 11,
`java is a good fit for deveioping COM objects in scvcrai other ways, too.
`
`Chapter One
`
`J
`
`BLUE COAT SYSTEMS - Exhibit 1034 Page 14
`
`

`
`c! ~nt's concern, This abi! ity to work identical !y with different kinds
`of objects, each supporting the same interfaces but implementing
`them differently, is called polymorphism. It's described a bit more
`in the next section.
`
`Encapsulation, polymorphism, and inheritance If a tech no logy
`models things as groups of methods and data and then Oiganizes
`those groups into classes, is that sufficient to qualify it as object-
`oriented? /\!though there's plenty of debate, the ans\.ver frof1! most
`quarters is no. In general, being object-oriented requires support
`for three more characteristics: encapsulation, polymorphism, and
`inheritance.
`
`Encapsulation means that an object's data is not directly avai!ab!e
`to the object's clients. instead, that data is encapsulated, hidden
`away from direct access. The only way to access the object's data
`is by using that object's nlethods-. These n1ethods collectively
`present a well-defined interface to the outside world, and it's only
`through this interface that a user of the object can read or modify
`its data. Encapsulation protects the object's data from inappropriate
`access and !ets the object itself control ho\v the data is accessed.
`By preventing inadvertent, incorrect changes from being made
`directly to an object's data, encapsulation can he!p enormously in
`the creation of better software.
`
`C++ provides direct support for encapsulation (although it also
`offers ways around it). if a programmer inappropriateiy attempts
`to directly modify an object's data, the compiler can flag the
`attempt as an eiiOi. Although C0tv1 isn't a piogiainining language,
`the same idea holds. A client can access a COM object's data only
`through the methods in that object's interfaces./\ co,~v1 object's
`data is encapsulated.
`
`Encapsulation
`prevents a client
`from directiy
`accessing an
`object's dat.J_
`
`COM objects
`support
`encapsulation
`
`The second defining characteristic of object-oriented technologies
`is poiymorphism. Simpiy put, poiymorphism means that a client
`can treat different objects as if they \A/ere the same, and yet each
`object wiii behave appropriateiy. For exampie, think of an object
`representing your checking account. This object probably has a
`
`Polymorphism
`lets a client treat
`different objects
`as if they were
`the same
`
`Introducing ActiveX and OLE
`
`11
`
`BLUE COAT SYSTEMS - Exhibit 1034 Page 15
`
`

`
`Different objects
`can irnpiE'mt:>nt
`the same method
`in different ways
`
`Withdrawal method, which you implicitly call each time you
`write a check. You rnight also have an object representing your
`savings account, an object that also has a Withdrawal method.
`To a client, these two methods look just the same; and when
`either method is invoked, the same thing happens: the object's
`balance shrinks.
`
`In fact, however, the implementation of these two methods might
`be quite different. The implementation in the savings account
`object might simply check the requested debit amount against the
`account balance. !f the debit amount is smaller than the balance,
`the request succeeds; if not, it fails. The Withdrawal method in the
`checking account object, on the other hand, might be a hit more
`cornplex. Checking accounts cornrnonly offer an autornatic loan
`up to a certain amount if a check would otherwise bounce. In
`implementing the \Vithdra"vval method, the checking account
`object could check the requested debit amount against both the
`current account balance and the maximum loan currently avail-
`able. In this case, the request succeeds and the check clears if the
`requested debit amount is less than the sum of the current balance
`and the available loan amount.
`
`To a client, these two Withdrawal methods look alike; the differ(cid:173)
`ences in their implementation, important as they are, are hidden.
`This ability to treat different things as if they were the same, with
`each nevertheless behaving appropriately, is the essence of poly(cid:173)
`morphism. This example also demonstrates the great benefit of
`polymorphism: clients can remain blissfully unavvarc of differ=
`cnccs that don't concern them, which simplifies the development
`of client soft\·vare.
`
`COM objects
`provide
`po!ymorphism
`
`COM objects fully support this idea. It's entirely possible for two
`objects of different classes to present the same interfaces or perhaps
`oniy a single common inethod definition to their ciients, even
`though each ohject implements the relevant methods differently.
`
`The final defining characteristic of traditional object-oriented
`technologies is inheritance. The idea is simple: given an ohject,
`
`12
`
`Chapter One
`
`BLUE COAT SYSTEMS - Exhibit 1034 Page 16
`
`

`
`you can create a ~e'vV object that automatically includes some or
`all of the features of the existing object. just as a man might, with
`no effort on his part, inherit male-pattern baldness from his
`parents, an object cim automatically inherit characteristics of
`another object.
`
`There are various kinds of inheritance. One distinction that's
`worth making here is between implementation inheritance and
`interface inheritance. vVith implementation inheritance, an object
`inherits code from its parent. When a client of the child object
`calls one of the chi I d's inherited methods, the code of the paient's
`method is actually executed. With interface inheritance, however,
`the child inherits on!y the definitions of the parent's methods.
`When a client of the child object calls one of these methods, the
`chi!d itself must provide the code for handling the requests.
`
`implementation inheritance is a mechanism for code reuse, one
`that's widely used in languages such as C++ and Smallta!k.' Inter(cid:173)
`face inheritance, in contrast, is really about reusing a specifica(cid:173)
`tion-the definition of the methods that an object supports. An
`irnportant reason for using interface inheritance is that it rnakes it
`easier to provide polymorphism. Defining a new interface by
`inheriting from an existing interface guarantees that an object
`supporting the new interface can be treated like an object that
`supports the o!d one.
`
`Programming languages such as C++ support both implementa(cid:173)
`tion inheritance and interface inheritance. COM objects, how(cid:173)
`ever, support only interface inheritance. COM's creators beiieved
`that, given COM's very general applicability, supporting imple(cid:173)
`mentation inheritance was an inappropriate (and even potentially
`dangerous) way for one COM object to reuse another. For example,
`because irraplementation inheiitance often exposes the inheriting
`object to details of its parent's implementation, it can break the
`encapsulation of the parent. Supporting only interface inheritance,
`as COM does, allows reuse of a key part of another object-its
`interface--\vhi!e avoiding this problem.
`
`lnheiitance allovvs
`a new object to
`build on an
`existing object
`
`I mpiementation
`inheritance and
`interface inheri(cid:173)
`tance are diffeient
`
`Interface inheri(cid:173)
`tance reuses a
`specification
`rather than
`actual code
`
`COM objects
`support only
`interface
`inheriia.nce
`
`Introducing ActiveX and OLE
`
`13
`
`BLUE COAT SYSTEMS - Exhibit 1034 Page 17
`
`

`
`COM objects.
`can reuse
`code through
`containment or
`aggregation
`
`COM is object-
`oriented, but
`il differs frorr~
`other popular
`object-oriented
`techno!ogies
`
`But without implementation inheritance, ho\AJ can one COM object
`reuse another's code? in COM, this is done with mechanisms
`called containment and aggregation. With containment, one
`object simply calls another object as needed to help carry out its
`functions. With aggregation, an object presents one or more of
`anothei object's interfaces as its own; vvhat a client sees as a
`single object providing a group of interfaces is in fact two or more
`objects aggregated together. /\s you might imagine, aggregation
`takes a bit more work to implement than containment does, but
`both provide an effective \·vay to build on existing COt\A objects.
`
`Is COM reaiiy object-oriented! COM has a great deai in common
`with other object-oriented technologies. !ts basic notion of an
`object as a coiiection of data and methods resembles that idea in
`languages such as C++, although COM allows a single object to
`have nlultiple intelfaces. co, .. v1 also provides encapsulation, poly(cid:173)
`morphism, and interface inheritance, but it reuses code through
`containment and aggregation rathei than thiough implementation
`inheritance. Objects are fundamental to COM, but the way those
`objects are defined and exactly ho\·V they behave differ some\Alhat
`from other widely used object-oriented technologies.
`
`So is COM rea!!y object-oriented? The ans\·ver depends on \Nhat
`this question means. if it's asking "Are COM objects exactiy iik:e
`objects in languages such as C++?", the answer is obviously no,
`This shouldn't be too surprising, since COt'v1 solves a problem that
`is quite different from the one addressed by an object-oriented
`progiamming language. But if the real question is instead "Does
`COM provide the key features and benefits of objects?", the
`ansvv'cr is just as obviously yes, and it's this second question that
`really matters. The goal isn't to get lost in debates about whose
`definitions to use. The goa! is to \A/rite better softv·;are.
`
`Hardware has
`progressed faster
`than software
`
`COM and Componeni Software
`In the past 35 years, hardware designers have gone from building
`room-size compuiers io creating iighiweighi iaptops based on
`tiny, powerful microprocessors. In the same 35 years, software
`
`14
`
`Chapter One
`
`BLUE COAT SYSTEMS - Exhibit 1034 Page 18
`
`

`
`developers. have gone fr