Skip to content


Subversion checkout URL

You can clone with
Download ZIP
100644 1288 lines (1197 sloc) 67.113 kB
9fc6cbc @Max-Hailperin initial commit corresponding to revised edition 1.1
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 %% 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}
12 \section{Introduction}
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.
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.
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.
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.
55 \section{Messaging Systems}\label{messaging-section}
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
207 \section{Remote Procedure Call}\label{RPC-section}
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.
228 \subsection{Principles of Operation for RPC}\label{RPC-generalities-section}
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.
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}
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}
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.
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.
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.
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.
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.
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.
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.
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.
375 \subsection{An Example Using Java RMI}\label{RMI-example-section}
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}
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;
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}
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;
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}
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;
475 public class Publisher {
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}
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;
524 public class TopicServer implements Topic {
526 private List<MessageRecipient> subscribers;
528 public TopicServer(){
529 subscribers = new ArrayList<MessageRecipient>();
530 }
532 public synchronized void receive(String message)
533 throws RemoteException
534 {
535 List<MessageRecipient> successes =
536 new ArrayList<MessageRecipient>();
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 }
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}
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;
604 public class Subscriber implements MessageRecipient {
606 public synchronized void receive(String message)
607 throws RemoteException
608 {
609 System.out.println(message);
610 }
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}
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.
654 \section{Web Services}\label{web-services-section}
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.
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.
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 <message name="doSpellingSuggestion">
685 <part name="key" type="xsd:string"/>
686 <part name="phrase" type="xsd:string"/>
687 </message>
689 <message name="doSpellingSuggestionResponse">
690 <part name="return" type="xsd:string"/>
691 </message>
693 <operation name="doSpellingSuggestion">
694 <input message="typens:doSpellingSuggestion"/>
695 <output message="typens:doSpellingSuggestionResponse"/>
696 </operation>
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.
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.
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.
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 <?xml version="1.0" encoding="UTF-8"?>
752 <env:Envelope
753 xmlns:env=""
754 xmlns:xsd=""
755 xmlns:xsi=""
756 xmlns:enc=""
757 xmlns:ns0="urn:GoogleSearch"
758 env:encodingStyle="">
759 <env:Body>
760 <ns0:doSpellingSuggestion>
761 <key xsi:type="xsd:string">\textrm{\textit{GoogleAccessControlKeyHere}}</key>
762 <phrase xsi:type="xsd:string">middlewear</phrase>
763 </ns0:doSpellingSuggestion>
764 </env:Body>
765 </env:Envelope>
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 <?xml version='1.0' encoding='UTF-8'?>
775 <SOAP-ENV:Envelope
776 xmlns:SOAP-ENV=""
777 xmlns:xsi=""
778 xmlns:xsd="">
779 <SOAP-ENV:Body>
780 <ns1:doSpellingSuggestionResponse
781 xmlns:ns1="urn:GoogleSearch"
782 SOAP-ENV:encodingStyle=
783 "">
784 <return xsi:type="xsd:string">middleware</return>
785 </ns1:doSpellingSuggestionResponse>
786 </SOAP-ENV:Body>
787 </SOAP-ENV:Envelope>
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}
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.
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.
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.
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.
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.
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.
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.
879 \section{Security and Communication
880 Middleware}\label{distmid-security-section}
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 @Max-Hailperin fixes #7 punctuation error
1062 services spread into more arm's-length dealings between parties that
9fc6cbc @Max-Hailperin initial commit corresponding to revised edition 1.1
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.
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 <?xml version="1.0" encoding="UTF-8"?>
1132 <env:Envelope
1133 xmlns:env=""
1134 xmlns:xsd=""
1135 xmlns:xsi=""
1136 xmlns:enc=""
1137 xmlns:ns0="urn:GoogleSearch"
1138 env:encodingStyle="">
1139 <env:Body>
1140 <ns0:doSpellingSuggestion>
1141 <key xsi:type="xsd:int">314159</key>
1142 <phrase xsi:type="xsd:string">middlewear</phrase>
1143 </ns0:doSpellingSuggestion>
1144 </env:Body>
1145 </env:Envelope>
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}
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 @Max-Hailperin fixes #3 fixes #4 using hyperref etc
1250 You can use \textit{\nolinkurl{}} as the endpoint
1251 address and \textit{\nolinkurl{}} as the WSDL
9fc6cbc @Max-Hailperin initial commit corresponding to revised edition 1.1
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}
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}
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 @Max-Hailperin fixes #3 fixes #4 using hyperref etc
1275 be the web sites. The Java web site, \textit{\url{}}, has
9fc6cbc @Max-Hailperin initial commit corresponding to revised edition 1.1
1276 information both on RMI and on J2EE, which includes JMS and JAX-RPC.
c513400 @Max-Hailperin fixes #3 fixes #4 using hyperref etc
1277 The Web Services Activity web site, \textit{\url{}}, has
9fc6cbc @Max-Hailperin initial commit corresponding to revised edition 1.1
1278 information on WSDL, SOAP, and web services in general. Other
1279 important sites for web services standards are the Web Services
c513400 @Max-Hailperin fixes #3 fixes #4 using hyperref etc
1280 Interoperability Organization, \textit{\url{}}, and OASIS,
1281 \textit{\url{}}, which tends to have more specialized,
9fc6cbc @Max-Hailperin initial commit corresponding to revised edition 1.1
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}.
Something went wrong with that request. Please try again.