# Max-Hailperin/Operating-Systems-and-Middleware--Supporting-Controlled-Interaction

### Subversion checkout URL

You can clone with
or
.
 9fc6cbc initial commit corresponding to revised edition 1.1 Max-Hailperin authored Aug 5, 2011 1 %% This file is a portion of the source for Revised Edition 1.1 of 2 %% Operating Systems and Middleware: Supporting Controlled 3 %% Interaction, Copyright 2011 by Max Hailperin. This work is 4 %% licensed under the Creative Commons Attribution-ShareAlike 3.0 5 %% Unported License. To view a copy of this license, visit 6 %% http://creativecommons.org/licenses/by-sa/3.0/ or send a letter to 7 %% Creative Commons, 171 Second Street, Suite 300, San Francisco, 8 %% California, 94105, USA. 9 \chapter{Messaging, RPC, and Web Services} 10 \label{distmid-chapter} 11 12 \section{Introduction} 13 14 Application programmers who create distributed systems of 15 communicating processes fundamentally rely upon the support for 16 networking provided by operating systems; 17 this support was described in Chapter~\ref{networking-chapter}. 18 Sometimes this reliance is direct; 19 for example, the application programs may use sockets to open 20 connections between TCP ports and then send byte streams that encode 21 application messages. Increasingly, however, this reliance is 22 indirect because a middleware layer comes 23 between the application program and the socket API. The application 24 programmer works in terms of the middleware-supported abstractions, 25 such as message queues and remotely accessible objects. The 26 middleware provides those abstractions by making use of the more 27 fundamental operating system--supported facilities. 28 29 In this chapter, I will present two distinct styles of communication 30 middleware. Messaging systems, discussed in 31 Section~\ref{messaging-section}, support the one-way transmission of 32 messages. Application programmers can choose to use those messages in 33 request-response pairs, but the middleware remains oblivious to this 34 pairing and treats each message individually. Sending a request and 35 receiving a response happen in separate transactions, potentially at 36 quite different times. For more tightly coupled interactions, Remote 37 Procedure Call (RPC) systems provide an alternative style of 38 communication, as presented in Section~\ref{RPC-section}. 39 Each time a process invokes an RPC operation, it sends a request and 40 then immediately waits for a response as part of the same 41 transaction. The RPC system makes the request-response pair appear to 42 the application program as a normal procedure call and return. 43 44 After presenting each of these styles of communication, I turn in 45 Section~\ref{web-services-section} to their connection with web 46 services. Web services use standardized communication mechanisms to 47 make programmed functionality available over the Internet. Most web 48 services fit the RPC model, though they can also use one-way messaging 49 or (in theory) more general message exchange patterns. 50 51 Finally, the chapter concludes, as usual, with a look at security 52 issues in Section~\ref{distmid-security-section} and then exercises, 53 projects, and notes. 54 55 \section{Messaging Systems}\label{messaging-section} 56 57 Applications based on one-way transmission of messages use a form of 58 middleware known as \vocabs{messaging system} or 59 \foldvocab{message-oriented}{middleware} (\vocab{MOM}). One popular 60 example of a messaging system is IBM's WebSphere MQ, formerly known as 61 MQSeries. One popular vendor-neutral API for messaging is the Java 62 Message Service (JMS), which is part of J2EE. 63 64 Messaging systems support two different forms of messaging: 65 \vocab{message queuing} and \vocab{publish/subscribe messaging}. I 66 already introduced message queuing in 67 Section~\ref{transactions-message-queuing-systems-section}. Here I 68 will build on that introduction to message queuing and also 69 provide an introduction to publish/subscribe messaging. 70 71 Figure~\ref{scan-10-1} illustrates the difference between the two 72 forms of messaging. 73 \begin{figure} 74 \centerline{\includegraphics{hail_f1001}} 75 %\centerline{\def\epsfsize#1#2{0.6#1}\epsfbox{scan-10-1.eps}} 76 \caption{Message queuing involves three steps: (1) the client sends a 77 message to a queue, (2) the queue retains the message as long as 78 necessary, (3) the server retrieves the message. Publish/subscribe 79 messaging involves a different sequence of three steps: (1) each subscriber 80 subscribes with one of the messaging system's topic'' objects, (2) the 81 publisher sends a message to the topic, (3) the message is 82 distributed to all current subscribers.} 83 \label{scan-10-1} 84 \end{figure} 85 Message queuing strongly decouples the timing of the client and the 86 server, because the queue will retain the messages until they are 87 retrieved. (Optionally, the client can specify an expiration time for 88 unretrieved messages.) The server need not be running at the time a 89 message is sent. On the other hand, the client is only weakly 90 decoupled from the server's identity. Although the client doesn't send 91 the message to a specific server, it does send it to a specific queue, 92 which still creates a \vocab{point-to-point} architectural structure, because each 93 queue normally functions as the in-box for a particular server. A 94 point-to-point structure means that if the 95 message is of interest to multiple servers, the client needs to 96 send it to multiple queues. The publish/subscribe architecture, in 97 contrast, strongly decouples publishers from any knowledge of the 98 subscribers' identities. Each message is sent to a general topic and 99 from there is distributed to any number of subscribers that have 100 indicated their interest in the topic. However, publish/subscribe 101 messaging usually does not strongly decouple timing. Messages are usually only 102 sent to current subscribers, not retained for future subscribers. 103 104 The portion of a messaging system managing topic objects for 105 publish/subscribe messaging is known as a \vocab{broker}. The broker 106 is responsible for maintaining a list of current subscribers for each 107 topic and for distributing each incoming publication to the current 108 subscribers of the publication's topic. 109 110 Section~\ref{transactions-message-queuing-systems-section} explained 111 the relationship between message queuing and transactions. A 112 transaction can retrieve messages from queues, do some processing, such 113 as updating a database, and send messages to queues. When the 114 transaction commits, the input messages are gone from their queues, 115 the database is updated, and the output messages are in their queues. 116 If the transaction aborts, then the input messages remain in their 117 queues, the database remains unchanged, and the output messages have 118 not entered their queues. 119 120 This transactional nature of message queuing has an important 121 consequence for systems in which request messages are paired with 122 response messages and will help me explain the difference between 123 messaging and RPC systems. Consider a client and server coupled 124 through request and response queues, as shown in 125 Figure~\ref{scan-10-2}. 126 \begin{figure} 127 \centerline{\includegraphics{hail_f1002}} 128 %\centerline{\def\epsfsize#1#2{0.6#1}\epsfbox{scan-10-2.eps}} 129 \caption{A client and server can engage in a request-response protocol 130 using two message queues. Typically, the client tags each request 131 message with a unique identifying string, known as a 132 \vocab{correlation ID}. The server copies this ID into the 133 resulting response message so that the client knows to which request 134 the response corresponds.} 135 \label{scan-10-2} 136 \end{figure} 137 The client can generate a request message in one transaction and then 138 in a second transaction wait for a response message. However, it 139 cannot do both in a single transaction, or it will wait forever, 140 having deadlocked itself. Until the transaction commits, the request 141 message doesn't enter the request queue. As a result, the server has 142 nothing to respond to and won't generate a response message. 143 Therefore, the client will continue waiting for the response message 144 and so the transaction won't commit, completing the deadlock. If 145 your goal is to have the client make use of the server as one 146 indivisible step within a transaction, then you need to use RPC rather 147 than messaging. 148 149 Publish/subscribe messaging can participate in transactions as well, 150 but the results are less interesting. Publishing is just like sending 151 to a queue, in that the message isn't actually sent until the 152 transaction commits. However, receipt of messages by subscribers is 153 handled differently. If a subscriber receives a message within a 154 transaction and then aborts the transaction, it cannot count on the 155 message being redelivered when the transaction is retried. 156 157 In either messaging model, a consumer may want to receive only 158 selected messages that are of interest to it. For example, it may 159 want to receive stock ticker messages with updated prices, but only 160 for IBM stock and only if the price is less than 75 or more than 150. 161 The program could receive all stock ticker messages (by reading from a 162 queue to which they are sent or by subscribing to a topic to which 163 they are published) and ignore those that are uninteresting. 164 However, for the sake of efficiency, messaging systems generally 165 provide mechanisms to do the filtering prior to message delivery. 166 167 In the publish/subscribe model, the selection of just IBM stock might 168 be accomplished simply by having a sufficiently specific topic. 169 Messaging systems generally allow topics to be hierarchically 170 structured, much like files in directory trees or Internet domains 171 within the DNS. Thus, a topic for IBM stock prices might be 172 \verb|finance/stockTicker/IBM|. A subscriber interested only in this 173 one stock could subscribe to that specific topic, whereas a subscriber 174 interested in all stock prices could subscribe to 175 \verb|finance/stockTicker/+|, where the wildcard \verb|+| indicates 176 any one subtopic. Another wildcard, \verb|#|, is fancier than needed 177 in this case but can be useful in other circumstances. A 178 subscription to \verb|finance/stockTicker/#| would receive not only 179 messages about each individual stock, such as IBM, but also general 180 messages, directed to \verb|finance/stockTicker| itself, and more 181 specialized messages, directed to descendant subtopics any number of 182 levels below \verb|finance/stockTicker/IBM| and its siblings. 183 184 This hierarchy of topics is limited, however. It fits the 185 publish/subscribe model but not the message queuing model, and 186 it addresses only 187 qualitative selection criteria that naturally lead to distinct 188 topics. In the example I gave earlier, it is unlikely that a system 189 architect would create three subtopics of \verb|IBM| for 190 \verb|under75|, \verb|between75and150|, and \verb|over150|. Among 191 other reasons, there may be other subscribers interested in other price 192 ranges. 193 194 Therefore, messaging systems allow message consumers to specify more general selection 195 criteria. In the JMS API, for example, if \verb|s| is a messaging 196 \verb|Session| and \verb|d| is a messaging \verb|Destination|, that 197 is, either a \verb|Queue| or a \verb|Topic|, then executing 198 \begin{verbatim} 199 s.createConsumer(d, "Symbol = 'IBM' AND " + 200 "(Price < 75 OR Price > 150)") 201 \end{verbatim} 202 will produce a \verb|Consumer| object with the specified selector. 203 Any \verb|receive| operation performed on that \verb|Consumer| (or any 204 \verb|MessageListener| registered with that \verb|Consumer|) will see 205 only those messages satisfying the selection criterion. 206 207 \section{Remote Procedure Call}\label{RPC-section} 208 209 The goal of \vocab{Remote Procedure Call} (\vocab{RPC}) middleware is 210 to make request-response communication as straightforward for 211 application programmers to program as ordinary procedure calls. The 212 client application code calls a procedure in the ordinary way, that is, passing 213 in some arguments and obtaining a return value for its further use. 214 The procedure it calls just happens to reside in a separate server. 215 Behind the scenes, the middleware encodes the procedure arguments into 216 a request message and extracts the return value from the response 217 message. Similarly, the server application code can take the form of 218 an ordinary procedure. By the time it is invoked, the procedure 219 arguments have already been extracted from the request message, 220 freeing it from that responsibility. 221 Section~\ref{RPC-generalities-section} explains further the 222 principles upon which RPC operates. Section~\ref{RMI-example-section} 223 provides a concrete example of using RPC in the particular form of 224 Java RMI (Remote Method Invocation). The subsequent section, 225 \ref{web-services-section}, is devoted to web services but also 226 provides additional information on how RPC plays out in that context. 227 228 \subsection{Principles of Operation for RPC}\label{RPC-generalities-section} 229 230 To understand how RPC middleware functions, it is helpful to 231 think about the fact that different procedures can present the same 232 interface. For example, consider procedures for squaring a number. 233 You could have several different procedures that take a numeric 234 argument, compute the square, and return it. One might work by 235 multiplying the number by itself. Another might use a fancy 236 calculation involving logarithms. And a third might open up a network 237 instant-messaging connection to a bored teenager, ask the teenager 238 what the square of the number is, then return the value it receives, 239 correctly extracted from the textual instant-messaging response. This 240 third procedure is known as a \vocab{proxy} for the teenager. The 241 proxy's method of squaring the number involves neither multiplication 242 nor logarithms, but rather delegation of responsibility. However, the 243 proxy still is presenting the same interface as either of the other 244 two procedures. 245 246 Figure~\ref{scan-10-3} shows how RPC middleware uses a proxy to 247 put the client in the position of making a normal procedure call. The 248 client application code actually does make a normal procedure call; 249 that much is no illusion. However, it only gives the illusion of 250 calling the server procedure that does the real computation. Instead, 251 the called procedure is a proxy standing in for the server procedure; 252 the proxy is often known as a \vocab{stub}. The stub proxy discharges 253 its responsibility not by doing any actual computation itself, but by 254 using request and response messages to communicate with the server. 255 \begin{figure} 256 \centerline{\includegraphics{hail_f1003}} 257 %\centerline{\def\epsfsize#1#2{0.6#1}\epsfbox{scan-10-3.eps}} 258 \caption{In Remote Procedure Call, application code makes a normal 259 procedure call to a stub proxy, which doesn't carry out the 260 requested computation itself, but rather sends a request message to 261 the server and then turns the response message into the procedure 262 return value.} 263 \label{scan-10-3} 264 \end{figure} 265 266 The stub proxy suffices to hide communication issues from the 267 application programmer writing the client code. In some cases, that 268 is all that is needed, and the server is written by a networking 269 expert who can directly write code to handle request and response 270 messages. More typically, however, the server code is written by 271 another application programmer who appreciates middleware support. 272 As shown in Figure~\ref{scan-10-4}, 273 \begin{figure} 274 \centerline{\includegraphics{hail_f1004}} 275 %\centerline{\def\epsfsize#1#2{0.6#1}\epsfbox{scan-10-4.eps}} 276 \caption{In order for the server application code to be free from 277 communication details, it can be a normal procedure invoked by a 278 portion of the RPC runtime sometimes called a skeleton or a tie.} 279 \label{scan-10-4} 280 \end{figure} 281 the server application code can be a 282 normal procedure, called the same way it would be if it were running 283 on the same machine with the client. Once again, the illusion is only 284 partial. The server application code really is being called with an 285 ordinary procedure call. The only illusion concerns what code is 286 doing the calling. From an application standpoint, the caller seems 287 to be the client. However, the caller really is a dedicated portion of the 288 RPC runtime system, known as a \vocab{skeleton} or a \vocab{tie}, 289 the purpose of which is to call the procedure in response to the 290 request message. See Figure~\ref{scan-10-5} for the application 291 programmer's view of the result; the middleware communication 292 disappears from view and the client application code seems to be 293 directly calling the server application procedure, as though they were 294 part of a single system. 295 \begin{figure} 296 \centerline{\includegraphics{hail_f1005}} 297 %\centerline{\def\epsfsize#1#2{0.6#1}\epsfbox{scan-10-5.eps}} 298 \caption{The application programmer's view of an RPC system has the 299 client code apparently making a direct call to the server procedure; 300 the RPC proxy mechanism is invisible.} 301 \label{scan-10-5} 302 \end{figure} 303 304 Early versions of the RPC communication model were based on ordinary 305 procedure calls, whereas more recent versions are based on the 306 object-oriented concept of method invocation. The basic principles 307 are the same, however, and the name RPC is commonly understood to 308 include method invocation as well as procedure calling. 309 310 A key example of a non-object-oriented RPC standard is Open Network 311 Computing (ONC) RPC, which was developed at Sun Microsystems and 312 became an Internet standard. ONC RPC serves as the foundation for 313 NFS, the Network File System discussed in Section~\ref{dfs-section}. 314 Each NFS operation, such as reading from a file, is carried out by 315 calling an RPC stub procedure, which takes responsibility for 316 packaging the procedure arguments into a request message and for 317 extracting the return value from the response message. 318 319 In object-oriented versions of RPC, the stub proxy is an object 320 presenting the same interface as the server object. That is, the same 321 repertoire of methods can be invoked on it. The stub uses a 322 uniform strategy for handling all methods: it translates method 323 invocations into appropriate request messages. 324 325 Two significant object-oriented RPC standards are \vocab{CORBA} and 326 \vocab{RMI}. CORBA (\vocab{Common Object Request Broker Architecture}) is a 327 complicated language-neutral standard that allows code written in one 328 language to call code written in another language and located 329 elsewhere in a distributed system. RMI (\vocab{Remote Method 330 Invocation}) is a considerably simpler 331 mechanism included as part of the Java 332 standard API; part of its simplicity comes from needing to 333 support only a single programming language. Because RMI can optionally use 334 CORBA's communication protocol, the Internet Inter-ORB Protocol 335 (IIOP), the two systems can interoperate. 336 337 One important feature of object-oriented RPC systems such as RMI is 338 that the values communicated as method arguments and return values can 339 include references to other objects. That is, a remotely invoked 340 method can operate not only on basic values, such as integers or 341 strings, but also on user-defined types of objects. One 342 remotely accessible object can be passed a reference that refers to another 343 remotely accessible object. In fact, this is the way most objects find 344 out about other objects to communicate with after getting past an 345 initial startup phase. 346 347 To initially get communication started, client objects typically look 348 up server objects using a \vocab{registry}, which is a specialized 349 server that maintains a correspondence between textual names and 350 references to the remotely accessible objects. (These correspondences 351 are known as \vocab{bindings}.) The registry itself can be located, 352 because it listens for connections on a prearranged port. When an 353 application server object is created that a client might want to 354 locate, the server object is bound to a name in the registry. The 355 client then presents the same textual name to the registry in a lookup 356 operation and thereby receives a reference to the initial server 357 object it should contact. 358 359 After this initial contact is made, the objects can use the arguments 360 and return values of remote method invocations to start passing each 361 other references to additional objects that are not listed in the 362 registry. Pretty soon any number of client and server objects can 363 have references to one another and be invoking methods on each other. 364 365 Section~\ref{RMI-example-section} is occupied by an RMI programming 366 example designed to reinforce the aforementioned point, that remote 367 objects are located not only using the registry, but also by being 368 passed as references. This example illustrates the way in which an 369 application programmer uses RMI and thereby complements the preceding 370 general discussion of how RPC stubs and skeletons work. I do not 371 provide any more detailed information on the inner workings of RMI. 372 However, in Section~\ref{web-services-section}, I show the how RPC 373 messages are formatted in the web services environment. 374 375 \subsection{An Example Using Java RMI}\label{RMI-example-section} 376 377 Using RMI, it is possible to develop an implementation of the 378 publish/subscribe messaging model, in which publishers send messages 379 to topic objects, which forward the messages along to subscribers. 380 The code in this section shows such an implementation in the simplest 381 possible form. In particular, this code has the following limitations; 382 to address each limitation, there is at least one corresponding Programming Project: 383 \begin{itemize} 384 \item 385 The message delivery is fully synchronous. That is, the publisher asks 386 the topic object to deliver a message; control does not return to the 387 publisher until the message has been delivered to all the subscribers. 388 Programming Projects \ref{BoundedBuffer-TopicServer-project} and 389 \ref{Spawning-TopicServer-project} address this. 390 \item 391 The example programs support only a single topic. Programming 392 Projects \ref{registered-topics-project} and 393 \ref{multi-topic-server-project} address this. 394 \item 395 In the example code, there is no way for a subscriber to explicitly 396 unsubscribe from a topic. However, the code does support subscribers 397 that terminate, lose communication, or otherwise fail. Programming 398 Project~\ref{unsubscribe-project} provides explicit unsubscription. 399 \item 400 The example code includes simple command-line interfaces for sending 401 textual strings as messages and for displaying received messages on 402 the terminal. These suffice to demonstrate the communication but do 403 not have the appeal of a chat-room application or multi-player game. 404 Programming Project~\ref{chat-room-game-project} provides the opportunity 405 to address this shortcoming. 406 \end{itemize} 407 408 When using RMI, each object that is remotely accessible must implement 409 a Java interface that extends {\tt java.rmi.Remote}. Each method in 410 that interface must be declared as potentially throwing {\tt 411 java.rmi.RemoteException}. This potential for an exception is 412 necessary because even if the underlying operation cannot possibly 413 fail, the remote invocation of that operation can fail in myriad ways, 414 such as through a network disconnection or a crash of the machine on which 415 the remote object is located. Figure~\ref{MessageRecipient-source} 416 shows the source code for a simple remote interface implemented by 417 subscribers and also by topic objects. The reason why these two 418 categories of participants in the publish/subscribe model 419 implement this same interface is that they have something in common: 420 they both receive messages. 421 \begin{figure} 422 \begin{verbatim} 423 import java.rmi.Remote; 424 import java.rmi.RemoteException; 425 426 public interface MessageRecipient extends Remote { 427 void receive(String message) throws RemoteException; 428 } 429 \end{verbatim} 430 \caption{The {\tt MessageRecipient} interface describes the common 431 feature shared by subscribers and the central topic objects that 432 redistribute published messages to subscribers: any of these objects 433 can receive a message.}\label{MessageRecipient-source} 434 \end{figure} 435 436 Subscribers directly implement the {\tt MessageRecipient} 437 interface, as you will see later. However, topic objects need to 438 implement an extension of the interface, because they can do 439 more than receive messages; they can also add subscribers. 440 Figure~\ref{Topic-source} shows the {\tt Topic} interface, which 441 extends {\tt MessageRecipient} through the addition of a {\tt 442 addSubscriber} method. Notice that the argument passed to {\tt 443 addSubscriber} is itself a {\tt MessageRecipient}. This allows a 444 reference to one remotely accessible object (the subscriber) to be 445 passed to another (the topic) for its later use. 446 \begin{figure} 447 \begin{verbatim} 448 import java.rmi.RemoteException; 449 450 public interface Topic extends MessageRecipient { 451 void addSubscriber(MessageRecipient subscriber) 452 throws RemoteException; 453 } 454 \end{verbatim} 455 \caption{The {\tt Topic} interface provides an operation for 456 subscribers to use to register their interest in receiving messages. 457 By extending the {\tt MessageRecipient} interface, the {\tt Topic} 458 interface is also prepared to receive messages from publishers.}\label{Topic-source} 459 \end{figure} 460 461 Having seen these two interfaces for remotely accessible objects, you 462 are now ready to see an example of code that makes use of such an 463 object. Figure~\ref{Publisher-source} contains a simple program for 464 sending a textual message (given as the first command-line argument) 465 to a remote object implementing the {\tt Topic} interface. The 466 specific remote object is looked up with the aid of a registry, that is, a service 467 within RMI that records name/object bindings. The registry is 468 located on a server computer whose hostname is specified as the second 469 command-line argument or on the local computer if no hostname is given. 470 \begin{figure} 471 \begin{verbatim} 472 import java.rmi.registry.LocateRegistry; 473 import java.rmi.registry.Registry; 474 475 public class Publisher { 476 477 public static void main(String[] args) { 478 if(args.length < 1 || args.length > 2){ 479 System.err.println("Usage: java Publisher message [host]"); 480 System.exit(1); 481 } 482 String message = args[0]; 483 String hostname = args.length > 1 ? args[1] : null; 484 try { 485 Registry registry = LocateRegistry.getRegistry(hostname); 486 Topic topic = (Topic) registry.lookup("topic.1"); 487 topic.receive(message); 488 } catch (Exception e) { 489 System.err.println("caught an exception: " + e); 490 e.printStackTrace(); 491 } 492 } 493 } 494 \end{verbatim} 495 \caption{This program uses the registry to locate the remote object 496 that is named {\tt topic.1} and that 497 implements the {\tt Topic} interface. The program then asks that 498 object to receive a message.}\label{Publisher-source} 499 \end{figure} 500 501 Let's turn next to an example of how a remotely accessible object can 502 be created and listed in the registry. The {\tt Topic Server} class, 503 as shown in Figures \ref{TopicServer-source1} and \ref{TopicServer-source2}, implements the {\tt Topic} 504 interface. Each {\tt TopicServer} keeps track of its current 505 subscribers; additions happen in the {\tt addSubscriber} method, and 506 deletions happen when a message cannot be successfully delivered. 507 Because the RMI infrastructure is allowed to invoke each operation in its own 508 thread, the remote operations 509 are marked as {\tt synchronized} so as to provide mutual exclusion. 510 This prevents any races in the manipulations of the list of subscribers. 511 When the {\tt TopicServer} program is run from the command line, the 512 {\tt main} method creates an instance of the class, exports it for 513 remote access, and places it in the local registry, using the same 514 {\tt topic.1} name as the {\tt Publisher} class looks up. 515 \begin{figure} 516 \begin{verbatim} 517 import java.rmi.registry.Registry; 518 import java.rmi.registry.LocateRegistry; 519 import java.rmi.RemoteException; 520 import java.rmi.server.UnicastRemoteObject; 521 import java.util.List; 522 import java.util.ArrayList; 523 524 public class TopicServer implements Topic { 525 526 private List subscribers; 527 528 public TopicServer(){ 529 subscribers = new ArrayList(); 530 } 531 532 public synchronized void receive(String message) 533 throws RemoteException 534 { 535 List successes = 536 new ArrayList(); 537 for(MessageRecipient subscriber : subscribers) { 538 try { 539 subscriber.receive(message); 540 successes.add(subscriber); 541 } catch(Exception e) { 542 // silently drop any subscriber that fails 543 } 544 } 545 subscribers = successes; 546 } 547 \end{verbatim} 548 \caption{The {\tt TopicServer} class continues in the Figure~\ref{TopicServer-source2}. 549 The {\tt receive} method shown here is remotely invoked 550 by publishers and itself remotely invokes the {\tt receive} method 551 of subscribers.}\label{TopicServer-source1} 552 \end{figure} 553 \begin{figure} 554 \begin{verbatim} 555 public synchronized void addSubscriber(MessageRecipient subscriber) 556 throws RemoteException 557 { 558 subscribers.add(subscriber); 559 } 560 561 public static void main(String args[]) { 562 try { 563 TopicServer obj = new TopicServer(); 564 Topic stub = 565 (Topic) UnicastRemoteObject.exportObject(obj, 0); 566 Registry registry = LocateRegistry.getRegistry(); 567 registry.rebind("topic.1", stub); 568 System.err.println("Server ready"); 569 } catch (Exception e) { 570 System.err.println("Server exception: " + e.toString()); 571 e.printStackTrace(); 572 } 573 } 574 } 575 \end{verbatim} 576 \caption{This continuation of the {\tt TopicServer} class, begun in Figure~\ref{TopicServer-source1}, 577 shows how remote objects are 578 created, exported (that is, made remotely accessible), and bound to a 579 name in the registry.}\label{TopicServer-source2} 580 \end{figure} 581 582 The final component of the example publish/subscribe system is the 583 {\tt Subscriber} class, as shown in Figure~\ref{Subscriber-source}. 584 This class provides a simple test program which displays all the 585 messages it receives. Like the {\tt Publisher} class, it uses the 586 registry on a specified host or on the local host if none is specified. 587 Also like the {\tt Publisher} class, it looks up the name {\tt 588 topic.1} in that registry, thereby obtaining a reference to some 589 remote object implementing the {\tt Topic} interface. 590 The reference will actually be to 591 a proxy that implements the interface. However, the 592 proxy will be communicating with an instance of the {\tt TopicServer} 593 class. Unlike the {\tt Publisher}, the {\tt Subscriber} is itself a 594 remotely accessible object. It is created and exported just like the 595 {\tt TopicServer} is. However, it is not bound in the registry; the 596 {\tt TopicServer} does not locate its subscribers by name. 597 \begin{figure} 598 \begin{verbatim} 599 import java.rmi.registry.LocateRegistry; 600 import java.rmi.registry.Registry; 601 import java.rmi.RemoteException; 602 import java.rmi.server.UnicastRemoteObject; 603 604 public class Subscriber implements MessageRecipient { 605 606 public synchronized void receive(String message) 607 throws RemoteException 608 { 609 System.out.println(message); 610 } 611 612 public static void main(String[] args) { 613 if(args.length > 1){ 614 System.err.println("Usage: java Subscriber [hostname]"); 615 System.exit(1); 616 } 617 String hostname = args.length > 0 ? args[0] : null; 618 try { 619 Registry registry = LocateRegistry.getRegistry(hostname); 620 Topic topic = (Topic) registry.lookup("topic.1"); 621 Subscriber obj = new Subscriber(); 622 MessageRecipient stub = (MessageRecipient) 623 UnicastRemoteObject.exportObject(obj, 0); 624 topic.addSubscriber(stub); 625 } catch (Exception e) { 626 System.err.println("caught an exception: " + e); 627 e.printStackTrace(); 628 } 629 } 630 } 631 \end{verbatim} 632 \caption{Instances of the {\tt Subscriber} class are created and 633 exported the same way as {\tt TopicServer}s are, so that they can be 634 remotely accessed. However, they are not bound in the registry. 635 Instead, the stub referring to the {\tt Subscriber} is passed to the {\tt addSubscriber} 636 method so the {\tt TopicServer} can store the reference away for later.}\label{Subscriber-source} 637 \end{figure} 638 639 Before you can successfully run the {\tt 640 TopicServer} and test it using the {\tt Publisher} and {\tt 641 Subscriber} programs, you will probably need to run the {\tt rmiregistry} program that comes 642 as part of the Java system. The details of how you run this program are 643 system-specific, as is the mechanism for ensuring that all components 644 of the overall RMI system have access to your classes. Therefore, you 645 are likely to need to consult the documentation for your specific Java 646 system in order to successfully test the sample code or complete 647 the programming projects. Once you get over these technical hurdles, 648 however, you will be able to communicate among multiple machines, so 649 long as they are all running Java and so long as no network firewalls 650 impede communication among them. In the following section, you will 651 see how web services provide an alternate RPC mechanism 652 that can allow communication between an even wider assortment of machines. 653 654 \section{Web Services}\label{web-services-section} 655 656 A \vocab{web service} is a communicating component that complies with a 657 collection of Internet standards designed to share as much as possible 658 with the standards used for ordinary web browsing. This allows web 659 services to take advantage of the web's popularity, hopefully making 660 communication between programmed components as ubiquitous as the 661 communication with humans facilitated by the web. 662 663 The web services standards are based on \vocab{XML} (\vocab{Extensible Markup 664 Language}), a form of structured 665 textual document. All XML documents have nested components with 666 explicitly indicated types and attributes. The specific kinds of 667 nested components depend on the XML application. For example, where 668 XML is used for request messages, the component parts indicate what 669 operation is being invoked and what arguments are being supplied to 670 it. By contrast, where XML is used not to invoke an operation but to 671 define an interface, the component parts enumerate what the 672 interface's operations are, what kinds of messages should be exchanged 673 to invoke those operations, and so forth. 674 675 Web service interfaces are described using an XML notation known as 676 \vocab{WSDL} (\vocab{Web Services Description Language}). This notation is rather 677 verbose and is not usually read or written by humans. Instead, 678 the humans normally use user-friendly tools to process the WSDL, which 679 serves as a common interchange format accepted by all the tools. 680 However, you can get a feel for WSDL by looking at the excerpts shown 681 in Figure~\ref{example-WSDL-excerpt}. 682 \begin{figure} 683 \begin{verbatim} 684 685 686 687 688 689 690 691 692 693 694 695 696 697 \end{verbatim} 698 \caption{These excerpts from the WSDL definition of the GoogleSearch API 699 show the two messages used to ask for and receive a spelling 700 suggestion and the operation that combines those two messages.}\label{example-WSDL-excerpt} 701 \end{figure} 702 The GoogleSearch API, from 703 which these are taken, provides operations for searching for web 704 pages. However, it also provides an operation for suggesting spelling 705 corrections, as shown here. The operation involves two message types, 706 one for request messages and one for response messages. Request 707 messages contain two string arguments; one is an access control key 708 that Google demands so as to limit use of their 709 service, and the other is the phrase to correct. The response message 710 contains just the returned value, a string containing the suggested 711 correction. 712 713 Notice that in Figure~\ref{example-WSDL-excerpt}, the \verb|doSpellingSuggestion| 714 operation is explicitly specified as using an input request message 715 and an output response message. Because WSDL provides this detailed 716 specification of how operations exchange messages, it can be used for 717 patterns of communication other than RPC. The most common usage is 718 for RPC, as with the GoogleSearch API. However, an operation can have 719 only an input message, in which case the web service fits the 720 messaging model instead of the RPC model. In theory, an operation 721 could also specify a more extended message exchange pattern, with 722 multiple input and output messages; however, I am unaware of any use of 723 this feature. 724 725 The WSDL standard allows providers of web services to make their 726 interfaces known to potential users without concern for what 727 programming language or implementation technology they use. For 728 example, I cannot tell from the WSDL excerpted in 729 Figure~\ref{example-WSDL-excerpt} whether Google is using 730 J2EE, Microsoft's .NET, or some other technology. I am free to use 731 whichever I choose in writing my client. 732 733 For this goal of interoperability to be realized, the service 734 providers and users need to agree on more than just WSDL as a means of 735 specifying interfaces. They also need to agree upon the specific 736 format for transmitting the request and response messages. For this 737 purpose, web services use a second XML format, known as \vocab{SOAP}. 738 (SOAP once stood for Simple Object Access Protocol but no longer does.) 739 Each SOAP document is a 740 message and should match one of the message descriptions from the 741 WSDL interface description. For example, you saw WSDL message 742 descriptions for the two message types \verb|doSpellingSuggestion| and 743 \verb|doSpellingSuggestionResponse|. Figures 744 \ref{example-SOAP-request} and \ref{example-SOAP-response} show 745 specific SOAP messages that fit these two descriptions. The first one 746 is a message asking for suggestions as to how middlewear'' should 747 really be spelled, and the second is a message responding with the 748 suggestion of middleware.'' 749 \begin{figure} 750 \begin{alltt} 751 752 759 760 761 \textrm{\textit{GoogleAccessControlKeyHere}} 762 middlewear 763 764 765 766 \end{alltt} 767 \caption{This example SOAP message asks Google for spelling suggestions 768 on the string {\tt middlewear}. This message has been broken into indented lines 769 for legibility and has a place-holder where a real message would contain an 770 access-control key issued by Google, which I am not allowed to divulge.}\label{example-SOAP-request} 771 \end{figure} 772 \begin{figure} 773 \begin{verbatim} 774 775 779 780 784 middleware 785 786 787 788 \end{verbatim} 789 \caption{This example SOAP message returns {\tt middleware} as a spelling suggestion 790 in response to {\tt middlewear}. (Line breaks and indentation changed 791 for legibility.)}\label{example-SOAP-response} 792 \end{figure} 793 794 Some transport mechanism needs to underlie SOAP. That mechanism delivers the 795 string of bytes shown in Figure~\ref{example-SOAP-request} to the 796 server and then deliver the bytes shown in 797 Figure~\ref{example-SOAP-response} back to the client. The most 798 common transport mechanism for SOAP is HTTP, the application-layer 799 protocol normally used to access web pages. Notice that in web 800 services terminology, HTTP is referred to as a transport, because it 801 conveys the SOAP messages, whereas in traditional networking 802 terminology, the transport layer is one layer lower, where TCP 803 operates. In effect, web services are building a 804 super-application-layer on top of the application layer, thereby 805 treating the HTTP application layer as though it were only a transport 806 layer. As mentioned in Chapter~\ref{networking-chapter}, one 807 advantage of this arrangement is that it circumvents obstacles such as 808 firewalls that stand in the way of deploying new application-layer 809 protocols. Almost any Internet connection is open to HTTP traffic. 810 811 When HTTP is used for a request-response message pair, as in the 812 spelling suggestion example, the client opens a connection to the 813 server exactly as it would to an ordinary web server, providing a URL 814 that represents the particular web service, known as an 815 \vocab{endpoint address}. The client then sends the 816 SOAP request message as the body of a POST method, the kind of HTTP 817 transaction more traditionally used for filled-in forms. The server 818 sends the SOAP response message in the body of its HTTP response. 819 820 Although SOAP is most commonly used with HTTP, the web services 821 architecture is intentionally neutral with regard to transport. SOAP 822 messages can equally well be sent as the bodies of email messages, 823 using SMTP, or as messages in a reliable message-queuing system, such 824 as WebSphere MQ. 825 826 If you remember that the goal of communication middleware is to ease 827 application programmers' burdens, it should be obvious that SOAP and 828 WSDL are not intended to be used without the aid of automated tools. 829 You could, in principle, read the GoogleSearch API's WSDL specification 830 yourself and based on it write code that sent the SOAP message 831 shown in \ref{example-SOAP-request} over HTTP. You could do this by using nothing more than 832 the ability to open up a TCP socket and send bytes through it. Then 833 you could read in from the socket the bytes constituting 834 Figure~\ref{example-SOAP-response}'s response and arduously extract 835 from it the spelling suggestion being returned. However, this would 836 be making a distributed system harder to construct, not easier. 837 838 Luckily, there are a variety of language-specific and vendor-specific 839 tools that make web services much easier to construct. In particular, 840 both .NET and J2EE have support for web services. As an example, let's 841 look at \vocab{JAX-RPC} (\vocab{Java API for XML-Based RPC}), a component of 842 J2EE. 843 844 In Programming Project~\ref{jax-rpc-project}, you can use a JAX-RPC 845 tool to automatically translate the 846 GoogleSearch WSDL file into a Java interface that contains 847 ordinary Java-callable methods for each of the web service's 848 operations. For example, it contains 849 \begin{verbatim} 850 public String doSpellingSuggestion(String key, String phrase); 851 \end{verbatim} 852 Using this, you can set a variable to the suggested spelling with 853 just this code: 854 \begin{alltt} 855 suggestion = aGoogleSearch.doSpellingSuggestion( 856 "\textrm{\textit{GoogleAccessControlKeyHere}}", 857 "middlewear"); 858 \end{alltt} 859 The Java object named \verb|aGoogleSearch| is a stub proxy 860 implementing the interface created from the WSDL file; a few prior 861 lines of code would set it up. This proxy 862 takes care of generating the big, messy SOAP request message, 863 sending it, reading in the response, and picking the suggestion out 864 from amid all its SOAP wrappings. You, the application programmer, 865 don't need to do any of that. 866 867 The WSDL and SOAP facilities described thus far provide the core 868 facilities for web services, but there are many other standards, and 869 proposed standards, for less central aspects. The entire area is in 870 considerable flux with many competing draft standards. 871 However, one other standard is approximately as solid as 872 WSDL and SOAP are. That standard, \vocab{UDDI} (\vocab{Universal Description, Discovery, 873 and Integration}), provides a way for web service 874 providers to list their services in a registry and for potential 875 users to discover them by looking in the registry for services 876 matching a description. UDDI registries are themselves web services, 877 accessed via SOAP messages in accordance with a WSDL specification. 878 879 \section{Security and Communication 880 Middleware}\label{distmid-security-section} 881 882 Messaging systems and RPC servers often use ACLs to control access, 883 much like file systems do. For example, a broker with a hierarchy of 884 publish/subscribe topics can associate 885 an ACL with each topic in the hierarchy; the ACL specifies the users or groups that may publish and 886 those that may subscribe. ACLs on subtopics take 887 precedence over those on more general topics. Thus, protection can be 888 specified as precisely as necessary for those subtopics where it 889 matters while allowing most subtopics the convenience of inheriting 890 an ancestor topic's ACL. 891 892 An ACL lists the users or groups that should be granted access, but 893 this still leaves open one of the most difficult aspects of security 894 in a distributed system. Namely, how should a server know which 895 user's access rights apply for each incoming connection? Any robust 896 solution to this problem relies on the cryptographic mechanisms 897 described in Section~\ref{network-security-section}. I can illustrate 898 this using an example from web services. 899 900 Recall that the exchange of SOAP messages between a client and web 901 service normally takes place using the same HTTP protocol as is used 902 for browsing the web. As such, the same cryptographic security 903 mechanisms are used by interposing the Secure Sockets Layer, SSL, 904 between HTTP and the underlying TCP connection. 905 906 Just as with a secure web site, a secure web service identifies itself 907 by using a \vocab{certificate}, which is a document attesting to the 908 server's identity and to the public half of the server's asymmetric 909 key pair. This public key can be used by the client to check the 910 server's digitally signed 911 messages and also to send the server a secret key for 912 confidential communication. The certificate itself is digitally 913 signed by some trusted \vocab{Certification Authority} (\vocab{CA}), 914 an organization that has made its public key well known and that can be 915 counted on to check out the legitimacy of another organization's or 916 individual's identity claim before issuing a certificate. 917 918 The server's certificate allows the client to trust that it is 919 communicating with the real server and not an impostor. However, the 920 server still has no idea which user identity to associate with the 921 client. Two options exist for solving that problem, one that 922 continues to follow the lead of ordinary web sites used by humans and 923 another that may be better suited to widespread deployment of web 924 services. I will present the solution first that you are probably 925 familiar with from your own use of the web and then the more robust 926 alternative. 927 928 When you connect to a secure web site, your browser checks the 929 server's certificate and if all is well signals this fact by showing 930 you a locked padlock. The server then typically asks you to enter a 931 username and password for the site. The strings that you enter are 932 sent over the SSL-encrypted communication channel and so are not 933 subject to eavesdropping or tampering in transit. Moreover, because 934 your browser checked the server's certificate, you can be sure you 935 aren't sending your password to a con artist. The server gets the 936 strings in decrypted form and checks them against its user database. 937 This style of authentication relies on you and the site having a 938 shared secret, the password. In general, each client/server pair 939 requires a shared secret established in advance. 940 941 This first style of client authentication, which is provided by HTTP 942 under the name \vocab{basic authentication}, can be a workable method for web 943 services that are not widely deployed, especially for those that are 944 deployed only internally to an enterprise. In that context, the 945 various web services will ordinarily be controlled by the same 946 administrators and as such can all share a common authentication 947 server that keeps track of users 948 with their passwords. Thus, a secret password needs to be established 949 for each user, but not for each user/service pair. Even across 950 enterprise boundaries, basic authentication may suffice for web 951 services that have only a small number of users, such as a web service 952 used to facilitate one particular relationship between a pair of 953 enterprises. 954 955 Before I move on to the more sophisticated alternative, it is worth 956 contrasting the first alternative, basic authentication using SSL, 957 with weaker password-based authentication. Consider, for example, the 958 GoogleSearch API's spelling suggestion operation, which was shown in 959 Section~\ref{web-services-section}. This operation takes a secret 960 access-control key as an argument in the request message itself. The 961 access-control key is issued by Google and essentially acts as a 962 combination of username and password in a single string. However, the 963 GoogleSearch web service does not use SSL; it uses ordinary unencrypted 964 HTTP directly over TCP. One consequence is that the access control 965 keys are subject to eavesdropping and so could be captured and then 966 reused. However, there is a second way in which a malefactor could 967 capture a key. 968 969 Recall that with SSL, the client program receives a certificate of the 970 server's identity, protecting it against impostors. Because 971 GoogleSearch is not using SSL, you could be sending your misspellings 972 to an impostor, perhaps someone who wants to embarrass you. Moreover, 973 because you send your key along, you could also be sending your key to 974 an impostor. This helps explain the significance of SSL's server 975 authentication. It not only protects the client from rogue servers, 976 but also protects the server from misuse through password capture. 977 Even if you don't care whether your misspellings become public 978 knowledge, Google presumably cares that their service isn't used 979 indiscriminately. Otherwise they would not have established 980 access-control keys. 981 982 What can you conclude, then, about Google's security design? 983 Presumably they decided that their service was valuable enough to make 984 some attempt to discourage casual misuse, but not so valuable that 985 they were willing to pay the price of SSL cryptography to keep 986 determined adversaries away. Also, their main concern is not with the 987 actual identity of the user, but with limiting the number of searches 988 made by any one user. If someone captures your GoogleSearch key, they 989 will simply share your daily limit on searches, not imposing any extra 990 burden on Google. Thus, Google's design stems from a well thought-out 991 cost-benefit analysis, paradigmatic of how security decisions ought to 992 be made. They did not make a mistake in using passwords without SSL. 993 However, you would be making a mistake to blindly emulate their 994 security mechanism on a web service of greater value. 995 996 Let us return, then, to security mechanisms suitable for high-value 997 targets that are likely to attract serious attackers. Recall that the problem 998 with using HTTP's basic authentication over SSL is that it requires a 999 shared secret password for each pair of client and server. If web 1000 services are to form a ubiquitous Internet-wide economy, as some 1001 prognosticators suggest, this will not be workable. Any client must be able 1002 to securely access any web service without prearrangement. 1003 1004 To solve this problem, web services can use the 1005 \foldvocab{mutual}{authentication} feature of SSL, which is almost 1006 never used for ordinary human-oriented web sites. In mutual 1007 authentication, both the client and the server have digitally-signed 1008 certificates obtained from trusted Certification Authorities. They 1009 exchange these certificates in the initial setup handshake that starts 1010 an SSL connection. Thus, without needing any usernames or passwords, 1011 each knows the identity of its communication partner for the entire 1012 duration of the connection. Mutual authentication is impractical for 1013 ordinary consumer-oriented web browsing, because merchants don't want 1014 to require all their customers to go to the trouble and expense of 1015 getting certificates. However, for the business-to-business 1016 communications where web services are expected to play their major 1017 role, mutual authentication seems well suited. It does, however, 1018 still have limitations, as I explain next. 1019 1020 The use of SSL, sometimes with mutual authentication, is widely 1021 deployed in practical web service applications. It also is 1022 incorporated in the most mature standards for web services; the Web 1023 Services Interoperability Organization's Basic Profile specifies that 1024 web service instances may require the use of HTTP over SSL and, in 1025 particular, may require mutual authentication. However, this approach to 1026 web service security has a fundamental limitation, with the result 1027 that more sophisticated, less mature standards take a different approach. 1028 The fundamental limitation is that SSL secures communication channels, 1029 rather than securing the SOAP messages sent across those channels. 1030 1031 To understand the difference between securing a channel and securing a 1032 message, consider the fact that several SOAP messages, originated by 1033 different users running different applications, may be sent across a 1034 single network connection. Consider also the fact that a single SOAP 1035 message may be relayed through a whole succession of network 1036 connections on its way from its originator to its ultimate 1037 destination. In both cases, SSL allows each computer to be sure of 1038 the authenticity of the neighboring computer, but it doesn't provide 1039 any direct support for associating the SOAP message with its author. 1040 1041 Therefore, the Web Services Security standard provides a mechanism 1042 whereby the XML format of a SOAP message can directly contain a 1043 digital signature for the message. Standards also govern the 1044 transmission of XML in encrypted form and the use of XML to send 1045 certificates. Using these mechanisms, the Web Services 1046 Interoperability Organization's Basic Security Profile, currently only 1047 a working draft, provides requirements for SOAP messages to be 1048 encrypted and digitally signed. Because the signature is on the 1049 message itself, it can be forwarded along with the message through 1050 relay channels and has sufficient specificity to allow messages of 1051 varying origins to share a network connection. 1052 1053 One final advantage of the Web Services Security approach compared 1054 with SSL is that SOAP messages that have been digitally signed support 1055 non-repudiation, as described in 1056 Section~\ref{network-security-section}. That is, because the 1057 recipient is in no better position to forge a message than anyone else 1058 would be, the recipient can present the message to a third party with 1059 a convincing argument that it came from the apparent sender. Today, 1060 web services are largely used within organizations and between close 1061 business partners with a high degree of mutual trust. However, as web 00625d5 fixes #7 punctuation error Max-Hailperin authored Aug 8, 2011 1062 services spread into more arm's-length dealings between parties that 9fc6cbc initial commit corresponding to revised edition 1.1 Max-Hailperin authored Aug 5, 2011 1063 have no established relationship, non-repudiation will become more 1064 important. Moreover, even if the communicating enterprises have a 1065 trust relationship, individual employees may be corrupt; digital 1066 signatures limit the scope of investigation that is needed if 1067 tampering is suspected. 1068 1069 \section*{Exercises} 1070 \begin{chapterEnumerate} 1071 \item 1072 How does messaging differ from sending bytes over a TCP connection? 1073 \item 1074 How does messaging differ from sending an email message? 1075 \item 1076 How does messaging differ from RPC? 1077 \item 1078 Does using response messages turn a message-queuing system into the 1079 equivalent of an RPC system? Why or why not? 1080 \item 1081 Are web services an alternative to messaging and RPC systems, that is, 1082 a third kind of communication middleware? Why or why not? 1083 \item 1084 For each of the following communication methods, give one example 1085 application scenario where you think it would be appropriate: message 1086 queuing, publish/subscribe messaging, RPC. In each case, justify your 1087 choice of communication method. 1088 \item 1089 Recall that in publish/subscribe topic hierarchies, the wildcard 1090 \verb|+| represents one component topic, whereas \verb|#| represents a 1091 sequence of zero or more components separated by slashes. 1092 Suppose a publish/subscribe system has topics \verb|a|, \verb|b|, 1093 \verb|a/c|, \verb|a/d|, \verb|b/c|, \verb|b/e|, 1094 \verb|a/c/e|, and \verb|a/d/e|. For each of the 1095 following subscriptions, specify which of those topics would be 1096 included: \verb|a|, \verb|a/+|, \verb|a/#|, \verb|a/c/+|, \verb|a/+/e|, \verb|#/e|. 1097 \item 1098 Suppose \verb|s| is a JMS messaging session and \verb|d| is a JMS 1099 messaging destination. Show how to create a \verb|Consumer| that 1100 would receive all 1101 messages sent to \verb|d| containing a \verb|Symbol| of \verb|IBM| and that 1102 would also receive all those containing a \verb|Price| of 0, 1103 independent of their \verb|Symbol|. 1104 \item 1105 In the RMI programming example, suppose several {\tt Subscriber} 1106 objects are all subscribed to a single {\tt TopicServer} and that 1107 several {\tt Publisher} objects send messages to that {\tt 1108 TopicServer}. Will all the {\tt Subscriber}s necessarily print the 1109 messages in the same order? Explain why or why not. 1110 \item\label{BoundedBuffer-TopicServer-exercise} 1111 In the {\tt TopicServer} implementation shown in 1112 Figures \ref{TopicServer-source1} and \ref{TopicServer-source2} on pages \pageref{TopicServer-source1} and \pageref{TopicServer-source2}, 1113 the {\tt receive} method invokes each subscriber's {\tt 1114 receive} method. This means the {\tt TopicServer}'s {\tt receive} 1115 method will not return to its caller until after all of the 1116 subscribers have received the message. Consider an alternative 1117 version of the {\tt TopicServer}, in which the {\tt receive} method 1118 simply places the message into a temporary holding area and hence 1119 can quickly return to its caller. Meanwhile, a separate thread 1120 running in the {\tt TopicServer} repeatedly loops, retrieving messages from the holding 1121 area and sending each in turn to the subscribers. What 1122 Java class from Chapter~\ref{synchronization-chapter} would be appropriate to use 1123 for the holding area? Describe the pattern of synchronization provided by 1124 that class in terms that are specific to this particular application. 1125 \item 1126 The text shown in Figure~\ref{bogus-SOAP-request} has the right form 1127 to be a legal SOAP message, but it would not be legitimate to send 1128 this message to the GoogleSearch web service. Why not? 1129 \begin{figure} 1130 \begin{verbatim} 1131 1132 1139 1140 1141 314159 1142 middlewear 1143 1144 1145 1146 \end{verbatim} 1147 \caption{This is a legal SOAP message but is not legitimate for sending 1148 to the GoogleSearch web service.}\label{bogus-SOAP-request} 1149 \end{figure} 1150 \item 1151 Section~\ref{distmid-security-section} mentions one reason why mutual 1152 authentication using certificates is not common in the human-oriented 1153 web: merchants don't want to turn customers off by requiring them to 1154 get certificates. One item of context here is that most consumers 1155 do business with only a small number of merchants. This is starting 1156 to change, as more businesses develop online presences and as 1157 consumers start branching out and shopping online for more than just 1158 books, music, videos, and airline tickets. Can you see any reason why 1159 this change might affect consumers' willingness to acquire certificates 1160 rather than use passwords? 1161 \end{chapterEnumerate} 1162 1163 \section*{Programming Projects} 1164 \begin{chapterEnumerate} 1165 \item 1166 Create an RMI analog of the 1167 message-storage server of Figure~\ref{Server-code} on 1168 page~\pageref{Server-code} and its companion client of 1169 Figure~\ref{Client-code} on page~\pageref{Client-code}. 1170 \item\label{BoundedBuffer-TopicServer-project} 1171 Modify the {\tt TopicServer} class shown in 1172 Figures \ref{TopicServer-source1} and \ref{TopicServer-source2} on pages \pageref{TopicServer-source1} and \pageref{TopicServer-source2} 1173 as described in Exercise~\ref{BoundedBuffer-TopicServer-exercise}. Be 1174 sure to correctly synchronize access to the list of subscribers. 1175 \item\label{Spawning-TopicServer-project} 1176 Exercise~\ref{BoundedBuffer-TopicServer-exercise} describes one way to 1177 modify the {\tt TopicServer} class so that the {\tt receive} method 1178 does not need wait for each subscriber's {\tt receive} method, at least 1179 under normal circumstances. An alternative design to achieve that 1180 same goal would be for the {\tt TopicServer}'s {\tt receive} method to 1181 create a new thread for each incoming message. The thread would deliver 1182 that one message to the subscribers. Modify the {\tt TopicServer} class shown in 1183 Figures \ref{TopicServer-source1} and \ref{TopicServer-source2} on pages \pageref{TopicServer-source1} and \pageref{TopicServer-source2} 1184 in this alternate way. Be 1185 sure to correctly synchronize access to the list of subscribers. 1186 \item\label{registered-topics-project} 1187 In the RMI example code given in Section~\ref{RMI-example-section}, only a single topic 1188 is used, bound in the registry to the name {\tt topic.1}. Show how 1189 the {\tt Publisher}, {\tt TopicServer}, and {\tt Subscriber} programs 1190 can be generalized to take a topic name as an additional command line 1191 argument, with each topic separately bound in the registry. 1192 Demonstrate the concurrent execution of two different topic objects on 1193 the same host, 1194 each with its own subscribers. 1195 \item\label{multi-topic-server-project} 1196 In Programming Project~\ref{registered-topics-project}, you 1197 accommodated multiple publish/\linebreak[0]subscribe topics by having a separate 1198 {\tt TopicServer} for each and by registering each in the registry. 1199 An alternative design would be to have a single {\tt TopicServer} 1200 object, but with the {\tt receive} and {\tt addSubscriber} methods taking an extra argument 1201 that is the topic name. Develop and demonstrate the code for this 1202 approach. You may want to include extra methods for such purposes as 1203 adding topics and obtaining a list of the current topics. 1204 \item\label{unsubscribe-project} 1205 The publish/subscribe system provided as an RMI example in 1206 Section~\ref{RMI-example-section} does not 1207 include a method for removing a subscriber from a topic. Arguably, such a 1208 method would be 1209 redundant, because the 1210 {\tt TopicServer} class is prepared for subscribers that 1211 fail. A subscriber that wishes to unsubscribe could simply arrange to 1212 intentionally fail. However, that option doesn't handle the case 1213 of a subscriber that is subscribed to more than one topic and wishes to 1214 unsubscribe from one of them. 1215 The design would be cleaner and more 1216 flexible if the {\tt Topic} interface and {\tt TopicServer} class 1217 supported a {\tt removeSubscriber} method. Add one and demonstrate its use. 1218 \item\label{chat-room-game-project} 1219 Section~\ref{RMI-example-section} shows how RMI can be used to convey 1220 textual messages from publishers to subscribers by way of intermediate 1221 topic objects. If you have the requisite skill in building user 1222 interfaces in Java, you could use this RMI mechanism as the foundation 1223 for a chat-room application or a multi-player game. Write such a 1224 program. Depending on your design, you may want to incorporate some of 1225 the features from earlier programming projects; for example, multiple topics 1226 could support multiple chat rooms. You are also welcome to change the 1227 message type; an application-specific class of game 1228 moves might be more appropriate than textual strings. 1229 \item\label{publish-to-MessageRecipient-project} 1230 The {\tt Publisher} class in Figure~\ref{Publisher-source} on 1231 page~\pageref{Publisher-source} makes use of the {\tt Topic} interface 1232 even though the {\tt MessageRecipient} interface would suffice. 1233 Change the class to use the more general interface and demonstrate 1234 that, with appropriate changes elsewhere, the {\tt Publisher} can wind 1235 up communicating either directly with a {\tt Subscriber} or with an 1236 intermediary {\tt TopicServer} as before. 1237 \item\label{topic-as-subscriber-project} 1238 The {\tt Topic} interface in Figure~\ref{Topic-source} on 1239 page~\pageref{Topic-source} extends the base interface {\tt MessageRecipient} 1240 and also uses that same interface as the argument type for the {\tt 1241 addSubscriber} method. Demonstrate how this allows one {\tt 1242 TopicServer} to function as a subscriber to another {\tt 1243 TopicServer}. Assuming that you have done Programming Project \ref{registered-topics-project}, there is no need for the \texttt{TopicServer} that is functioning as a subscriber to add itself to the other one using \texttt{addSubscriber}. Instead, you can leave the code for \texttt{TopicServer} unchanged and add a new program that looks up the two \texttt{TopicServer} objects in the registry and adds one as a subscriber to the other. 1244 \item\label{jax-rpc-project} 1245 Acquire an access control key for GoogleSearch from Google and 1246 download the software associated with the \textit{J2EE 1.4 Tutorial}. After 1247 working through the JAX-RPC portion of the tutorial, modify one of the 1248 example clients so that it gets a spelling suggestion 1249 from GoogleSearch instead of accessing the example Hello web service. c513400 fixes #3 fixes #4 using hyperref etc Max-Hailperin authored Aug 8, 2011 1250 You can use \textit{\nolinkurl{http://api.google.com/search/beta2}} as the endpoint 1251 address and \textit{\nolinkurl{http://api.google.com/GoogleSearch.wsdl}} as the WSDL 9fc6cbc initial commit corresponding to revised edition 1.1 Max-Hailperin authored Aug 5, 2011 1252 location. Optionally, you can use a packet capture program such as 1253 {\tt wireshark} to verify that the web service is being accessed through 1254 ordinary HTTP, without the use of SSL, and that the SOAP messages are 1255 essentially as shown in Figures \ref{example-SOAP-request} and 1256 \ref{example-SOAP-response}. 1257 \end{chapterEnumerate} 1258 1259 \section*{Exploration Projects} 1260 \begin{chapterEnumerate} 1261 \item 1262 Read about message-driven beans in the \textit{J2EE 1.4 Tutorial} and write a 1263 concise explanation of what they are and why they are more convenient 1264 than directly using JMS. 1265 \item 1266 Work through the examples in Chapters 28 and 33 of the 1267 \textit{J2EE 1.4 Tutorial}, A Message-Driven Bean Example'' and 1268 The Java Message Service API.'' 1269 \end{chapterEnumerate} 1270 1271 1272 \section*{Notes} 1273 The topics in this chapter are subject to particularly rapid technical 1274 developments. As such, your best source of information is likely to c513400 fixes #3 fixes #4 using hyperref etc Max-Hailperin authored Aug 8, 2011 1275 be the web sites. The Java web site, \textit{\url{http://java.sun.com}}, has 9fc6cbc initial commit corresponding to revised edition 1.1 Max-Hailperin authored Aug 5, 2011 1276 information both on RMI and on J2EE, which includes JMS and JAX-RPC. c513400 fixes #3 fixes #4 using hyperref etc Max-Hailperin authored Aug 8, 2011 1277 The Web Services Activity web site, \textit{\url{http://w3c.org/2002/ws/}}, has 9fc6cbc initial commit corresponding to revised edition 1.1 Max-Hailperin authored Aug 5, 2011 1278 information on WSDL, SOAP, and web services in general. Other 1279 important sites for web services standards are the Web Services c513400 fixes #3 fixes #4 using hyperref etc Max-Hailperin authored Aug 8, 2011 1280 Interoperability Organization, \textit{\url{http://www.ws-i.org/}}, and OASIS, 1281 \textit{\url{http://www.oasis-open.org/}}, which tends to have more specialized, 9fc6cbc initial commit corresponding to revised edition 1.1 Max-Hailperin authored Aug 5, 2011 1282 advanced standards. The information on these sites---and in many 1283 published books for that matter---tends to emphasize the technical 1284 details over the big picture of how to use the technology. One book 1285 that does provide a lot of big-picture advice on the use of messaging 1286 is by \index{Hohpe, Gregor}Hohpe and \index{Woolf, Bobby}Woolf~\cite{max1157}. 1287