‘ W:de—rea
`7 Comfhunicatit
`
`L
`
`T
`[V Unféferer
`gg ,O_bject _
`
`Exhibit 201 2
`
`SeryiceN0w V. HP
`IPR2015—0063 1
`
`

`
`Library of congress
`on file
`
`Cataloging- in-Pub1{cation Data
`
`Vice President and Editorial Director, ECS: Marcia Horton
`Publisher: Alan Apt
`Associate Editor: Toni D. Ilolm
`Vice President and Director of Production and Manufacturing, ESM: David W. Riccardi
`Executive Managing Editor: Vince O'Brien
`Managing Editor: David A. George
`Assistant Managing Editor and Production Coordinator: Camille Trentacoste
`Director of Creative Services: Paul Belfanti
`Creative Director'. Carole Anson
`Art Di-rector: .Eleather Scott
`Assistant to Art Director: John Christiana
`Cover Art and Design: Doz Martinetti
`Cover Illustration Concept: Andrew S. Tanenbaum and Maarten vdn Steen
`Interior Design and Typesetting: Andrew S. Tanenbaum
`Interior Illustrations: Maarten van Steen
`Manufacturing Managet Trudy Pisciotti
`Manufacturing Buy er: Lisa McDow e ll
`Marketing Manager: Jennie Burger
`
`@ 2002by Prentice-Hall, Inc.
`Upper Saddle River, New Jersey 07458
`
`The authors and publisher of this book have used their best efforts in preparing this book. These efforts include the
`development, research, and testing ofthe theories and programs to determine their effectiveness. The authors and put
`lisher make no waranty of any kind, expressed or implied, with regard to these programs or to the documentation
`contained in this book. The authors and publisher shall not be liable in any event for incidental or consequential dar
`ages in connection with, or arising out of, the furnishing, performance, or use ofthese programs.
`
`.
`
`..;
`
`Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks
`and registered trademarks. Where those designations appear in this book, and Prentice Hall and the authors were .
`aware of a trademark claim, the designations have been printed in initial caps or all caps. All product names mentione(
`remain trademarks or registered trademarks oftheir respective owners.
`Al1 rights reserved. No part of this book may be reproduced, in any form or by any means,
`without permission in writing from the publisher.
`Printed in the United States of Americ a
`t0987 654321
`ISBN 0-13-088893-1
`
`':.a
`
`,'t:1.
`
`Prentice-Hall Intemational (UK) Limited, London
`Prentice-Hall of Australia Pty. Limited,, Sydney
`Prentice-Hall Canada Inc., Toronto
`Prentice-Hall Hispanoamerican a, S. A., M exic o
`Prentice-Hall of India Private Limited, New Delhi
`Prentice-Hall of Japan, lnc., Tolcyo
`Pearson Education Asia Pte. Ltd., Singapore
`Editora Prentice-Hall do Brasil, Ltda., Rio de Janeiro
`
`

`
`'1
`
`502
`
`DISTRIBUTED oBJECT-BASED SYSTEMS
`
`CHAPI
`
`once semantics, implying that the invoked method may have been invoked
`or not at all. Note that it is up to an implementation to provide these semantics. .l
`Synchronous invocation is therefore useful when the client expects an unsrn
`If a proper response is returned, coRBA guarantees that the method has beJ
`invoked exactly once. However, in those cases where no response is needed, ,
`would be better for the client to simply invoke the method and continue with il
`own execution as soon as possible. This type of invocation is similar to the asr
`chronous RPCs we discussed inChap.Z.
`.i
`In CORBA, this form of asynchronous invocation is called a one;tr
`request. A method can be specified as being one-way only if it is specifiedi
`return no results. However, unlike the guaranteed delivery of asynchronous
`one-way requests in CORBA offer only a best-effort delivery service. In othe
`words, no guarantees are given to the caller that the invocation request . !
`delivered to the object's server.
`)
`Besides one-way requests, CORBA also supports what is known aS;i
`deferred synchronous request. Such a request is, in fact, a combination of,
`one-way request and letting the server asynchronously send the result back to:th
`client. As soon as the client sends its request to the server, it continues withou
`waiting for any response from the server. In other words, the client can nqvi
`know for sure whether its request is actually delivered to the server
`These three different invocation models are summarized inFig. g-4.
`
`:
`
`Request type
`Synchronous
`
`Failure semantics
`At-most-once
`
`One-way
`
`Best effon delivery
`
`Deferred
`synchronous
`
`At-most-once
`
`Description
`Caller blocks until a response is returned or
`an exception is raised
`Caller continues immediately without waiting
`for any response from the server
`Caller continues immediately and can later
`block until response is delivered
`
`Figure 9-4. Invocation models supported in CORBA.
`
`i
`
`Event and Notification Services
`
`Although the invocation models offered by CORBA should normally
`most of the communication requirements in an object-based distributed system, i
`was felt that having only method invocations was not enough. In particular, therr
`was a need to provide a service that could simply signal the occurrence of ar
`event. Clients amenable to that event could take appropriate action.
`The result is the definition of an event service. The basic model for events.,i
`CORBA is quite simple. Each event is associated with a single data item, gen.
`erally represented by means of an object reference, or otherwise an applicati
`
`j
`
`':jl '
`'r:
`
`:ii::.
`
`:.:'
`
`:tl
`
`

`
`SEC. 9.1
`
`CORBA
`
`503
`specific value. An event is produced by a supplier and received by a consumer.
`Events are delivered through an event channet, which is logically placed between
`suppliers and consumers, as shown in Fig. 9_5.
`
`Push event to consumers
`
`Figure 9-5. The logical organization of suppliers and consumers of events, for-
`Iowing the push-style model.
`Fig. 9-5 shows what is referred to as the push model. In this model, when-
`ever an event occurs, the supplier produces the event and pushes it through the
`event channel, which then passes the event on to its consumers. The push todel
`comes closest to the asynchronous behavior that most'people associate with
`events. In effect, consumers passively wait for event propagatio.r, and expect to be
`intemrpted one way or the other when an event happans.
`An alternative model, also supported by coR^BA, is the pull model shown in
`Fig' 9-6. In this model, contu-eti poll the event channel io check whether an
`event has happened. The event channer, in turn, polls the various suppliers.
`
`Ask suppliers for new event
`
`Figure 9-6. The pull_style model for event delivery in CORBA.
`Although the event service provides a simple and straightfbrward way for
`event propagation, it has a number of serious drawbacks. In order to propagate
`events, it is necessary that suppliers and consumers are connected to ihe^eient
`channel' This also means that when a consumer connects to an event channel after
`the occurrence of an event, that afterward, the event will be lost. In other words,
`CORBA's event service does not support persistence of events.
`More serious is that consumers have hardly any means to filter events; each
`event is, in principle, passed to every consumer. If different event types need to be
`distinguished, it is necessary to set a separate event channel for each type. Filter-
`ing capabilities have been idded to an extension called the notification service
`(.oMG, 2000a). In addition, this service offers facilities to prevent event propaga-
`tion when no consumers are interested in a specific event.
`.. Finally, event propagation is inherently unreliable. The coRBA specifica-
`tions state that no guarantees need to be given concerning the delivery of events.
`
`

`
`504
`
`DISTRIBUTED OBJECT-BASED SYSTEMS
`As we will discuss in_ chap. 12, appriiations exist for which reriable evenr propa_,
`gation is important. Such applications should not use the coRBA .u"n, ,J*iLi
`but should resort to other means of communication.
`Messaging
`
`CHAP.
`
`:::.
`
`1tl::::l]:1rt"", in CORBA as.described so far is transienr. rrris meanJ
`that a message is stored by,the underlying communication system ""r, ",
`r"'"*:d
`both its sender and its receivers are executing. As we discuised in chap. ,, ,h".;;
`are many applications. that require persistent communication so ,rt"
`ti"*"g."iSi
`stored until it can be delivered. with persistent communication, it does n", n?ir.",
`"
`whether the sender or receiver is executing after the message rr". u"", ;;;;;il;;
`-':i
`cases, it will be stored as long u, ne""r.*y
`A wetl-kno'" -:i:ij:i llffi fll';mmunication is the messase-qu*di;
`::*: jlY*^'lln:*:hl' model as^an additional messaging serv-ice: il;?*
`makes messaging in coRBA different from other systems rJitr-inr,.r.;;;j.;
`3::.:*::f:::tl""j:,TT1Tl,jll,rn parricurar, the desiglo, or tne messa'g-ins
`service needed to retain the model that ill communication takes place by ir";il;;
`an object. In the case of messaging, this design constraint resulted in two addir;
`' " *-'.
`tional forms of asynchronous method invocations.
`^f ^^-.- ^r^,^-,- -
`In the callback qoder, a client provides an object that implements an intei:,
`I:*:::::l*: :il:::*I.l1l1,:Inese merhods .un u. .uu.; ;t il;"d..'ry,s
`communication systerir to pass the result of an asynchronous invocation. Ani:
`important design issue is that asynchronous method invocations d;;;;;ff*
`*;,
`original implementation of an object. In other words, it is the .h;.;;;;;;il:,
`^f ^- ^r-:,
`ity to transform the original synchronous invocation into an uryn"tronorrr:"*,;d
`server is presented a normal (synchronous) invocation request.
`constructing an asynchronous invocation is done in two steps. First, the origi_ i
`nal interface as implemented by the object is replaced by two riew interfa.", ,iuri
`are to be implemented by crient-side software only. one int"rru." .onffi;h#
`specification of methods that the client can call. None of these *"rrr"orl.i"L-'rt
`value or has any output parameter. The second interface i, th" ";ll;;;k ;;rf*;;
`For each operation in the original interface, it contains u ro",troJii"l^riii';;
`called by the client's oRB to pass the results of the associared -"in"J^ ""ir.;
`by the client.
`As an example, consider an object implementing a simple interface with just,
`one method:
`
`tin-^1
`
`f^*-
`
`nricinal
`
`imnlo*^-+^+:^'^
`
`, T
`
`,,,,,,)
`
`Assume that this method (which we expressed in coRBA IDL) takes two nonne-.,,
`gative integers i and j^and retums i + j as output parameter k. The operation iiiri
`assumed to return -r if the operation did not rr"".rrfrlly complete T;";;;i";
`the original (synchronous) method invocation into an urynit-n*r-""" ,iifi.'
`
`:ri,:
`
`ai.
`
`i:
`':;
`
`..