📄 ch09.htm
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"><HTML><HEAD><SCRIPT LANGUAGE="JavaScript"><!--function popUp(pPage) { var fullURL = document.location; var textURL = fullURL.toString(); var URLlen = textURL.length; var lenMinusPage = textURL.lastIndexOf("/"); lenMinusPage += 1; var fullPath = textURL.substring(0,lenMinusPage); popUpWin = window.open('','popWin','resizable=yes,scrollbars=no,width=525,height=394'); figDoc= popUpWin.document; zhtm= '<HTML><HEAD><TITLE>' + pPage + '</TITLE>'; zhtm += '</HEAD>'; zhtm += '<BODY bgcolor="#FFFFFF">'; zhtm += '<IMG SRC="' + fullPath + pPage + '">'; zhtm += '<P><B>' + pPage + '</B>'; zhtm += '</BODY></HTML>'; window.popUpWin.document.write(zhtm); window.popUpWin.document.close(); // Johnny Jackson 4/28/98 }//--> </SCRIPT> <META NAME="Author" Content="Bryan Flores"> <META HTTP-EQUIV="Content-Type" CONTENT="text/html;CHARSET=iso-8859-1"> <TITLE>Teach Yourself CORBA In 14 Days -- Ch 9 -- Using Callbacks to Add Push Capability</TITLE></HEAD><BODY TEXT="#000000" BGCOLOR="#FFFFFF"><CENTER><H1><IMG SRC="../button/sams.gif" WIDTH="171" HEIGHT="66" ALIGN="BOTTOM" BORDER="0"><BR><FONT COLOR="#000077">Teach Yourself CORBA In 14 Days</FONT></H1></CENTER><CENTER><P><A HREF="../ch08/ch08.htm"><IMG SRC="../button/previous.gif" WIDTH="128" HEIGHT="28"ALIGN="BOTTOM" ALT="Previous chapter" BORDER="0"></A><A HREF="../ch10/ch10.htm"><IMGSRC="../button/next.gif" WIDTH="128" HEIGHT="28" ALIGN="BOTTOM" ALT="Next chapter"BORDER="0"></A><A HREF="../index.htm"><IMG SRC="../button/contents.gif" WIDTH="128"HEIGHT="28" ALIGN="BOTTOM" ALT="Contents" BORDER="0"></A> <HR></CENTER><CENTER><H1><FONT COLOR="#000077">Day 9<BR>Using Callbacks to Add Push Capability</FONT><A HREF="#Heading1"></A></H1></CENTER><UL> <LI><A HREF="#Heading1">Defining Additional Requirements</A> <LI><A HREF="#Heading2">Modifying the Class Diagram</A> <UL> <LI><A HREF="#Heading3">Modifying Existing Classes</A> </UL> <LI><A HREF="#Heading4">Modifying the IDL Specification</A> <LI><A HREF="#Heading5">Implementing the New Functionality</A> <UL> <LI><A HREF="#Heading6">Enhancing the BankImpl</A> <LI><A HREF="#Heading7">Enhancing the CustomerImpl</A> <LI><A HREF="#Heading8">Enhancing the ATMClient</A> </UL> <LI><A HREF="#Heading9">Running the Application</A> <LI><A HREF="#Heading10">Ideas for Future Enhancements</A> <LI><A HREF="#Heading11">Summary</A> <LI><A HREF="#Heading12">Q&A</A> <LI><A HREF="#Heading13">Workshop</A> <UL> <LI><A HREF="#Heading14">Quiz</A> <LI><A HREF="#Heading15">Exercises</A> </UL></UL><P><HR SIZE="4"><CENTER><H1><FONT COLOR="#000077"></FONT></H1></CENTER><P>On Day 8, "Adding Automated Teller Machine (ATM) Capability," you continueddevelopment of the sample <TT>Bank</TT> application by adding Automated Teller Machine(ATM) capabilities. Now, you'll make the final enhancements, this time adding pushcapability.<BLOCKQUOTE> <P><HR><B>Note:</B>Although <I>push</I> appears to be one of the latest buzzwords in the industry (particularly where the Internet is concerned), the concept has been around for quite some time. (The Internet is simply one of the more visible applications for it.) Client/server applications typically follow the pull model, in which the client <I>pulls</I> information from the server when it so desires (in other words, the client initiates the transaction). In the push model, the server <I>pushes</I> information to the client--that is, the server initiates the transaction. For example, when a stock price changes, a server can push the updated information to its clients. Push can be much more efficient than pull when information is updated infrequently, especially when there are a number of clients in a system. <HR></BLOCKQUOTE><P>Push capability can be utilized in many ways, but in the <TT>Bank</TT> applicationyou'll use it to implement an account update system. Through this system, customersreceive account balance updates every minute. (Of course, this would probably beuseless in an actual bank application, but it serves to demonstrate the concept.)The process you'll follow is the same as in the previous chapter:<UL> <LI><I>Define additional requirements</I>. Modify the system requirements to specify a requirement for the account update capability.<BR> <BR> <LI><I>Modify the system design. </I>Translate the additional requirements into changes in system design, again reinforcing the notion of software design as an iterative process.<BR> <BR> <LI><I>Modify the IDL definitions.</I> Create or update the interface definitions for new classes or classes that have changed since the previous iteration.<BR> <BR> <LI><I>Implement the new functionality.</I> After the design is finished and then realized in IDL, implement the new functionality and see how the new application works.</UL><H2><A NAME="Heading1"></A><FONT COLOR="#000077">Defining Additional Requirements</FONT></H2><P>Recall the system requirements for the <TT>Bank</TT> application from Day 8. Asyou did when you added ATM capability to the application, you'll define a set ofrequirements that describes the desired functionality. For the account update capability,assume the following requirements:<UL> <LI>Supports the capability for a server to send account balance updates periodically and automatically to customers<BR> <BR> <LI>Supports the capability for customers to request the account update feature</UL><P>The requirements are straightforward; they formalize the functionality alreadydescribed. Note that there is only a requirement to request the account update feature;there is no requirement to cancel the feature. Adding such a capability is not difficult,but to keep the sample application simple, this feature is omitted. (Perhaps it wouldmake a good exercise...)<H2><A NAME="Heading2"></A><FONT COLOR="#000077">Modifying the Class Diagram</FONT></H2><P>Again, you're ready to translate a modified set of requirements into an updatedsystem design. This time, you won't need to create any additional classes, and you'llneed to modify some existing classes only slightly.<H3><A NAME="Heading3"></A><FONT COLOR="#000077">Modifying Existing Classes</FONT></H3><P>The modifications required to add account updating to the application are clear-cut.First, a <TT>Customer</TT> must subscribe to the service, so the <TT>Bank</TT> mustbe modified to enable this. The only information required to subscribe to the serviceis the <TT>Account</TT>, so the method should take this as a parameter. No otherparameters are strictly necessary; the <TT>Bank</TT> can obtain the <TT>Customer</TT>(s)from the <TT>Account</TT> when necessary. Also, no return value is required. Thesignature for the new method is this:</P><PRE><FONT COLOR="#0066FF"><TT>requestUpdateService(account : Account) : void</TT></FONT></PRE><P>The other requirement is to add a method to the <TT>Customer</TT> class that enablesthe <TT>Bank</TT> to send updates when necessary. So that the <TT>Customer</TT> knowswhich <TT>Account</TT> the update is for (<TT>Customer</TT>s can have multiple <TT>Account</TT>s,after all), the <TT>Account</TT> should be a parameter. With just the <TT>Account</TT>information, the <TT>Customer</TT> can determine the current balance, but for thesake of convenience, the method will take the balance as a parameter as well. Again,no return value is necessary--and just for fun, make the method <TT>oneway</TT> aswell, so the <TT>Bank</TT> will be able to send updates without having to wait forresponses from the <TT>Customer</TT>s. Here is the signature for the method:</P><PRE><FONT COLOR="#0066FF"><TT>updateAccountBalance(account : Account, balance : float) : void</TT></FONT></PRE><BLOCKQUOTE> <P><HR><B>Note:</B>For the <TT>updateAccountBalance()</TT> operation, using the <TT>oneway</TT> calling mechanism is a reasonable choice. Recall that the <TT>oneway</TT> mechanism is unreliable--that is, delivery of <TT>oneway</TT> messages is not guaranteed. This is acceptable for <TT>updateAccountBalance()</TT> because the account update messages are not considered critical. In other words, if an occasional update message is not delivered, the impact on the operation of the application is minimal. <HR></BLOCKQUOTE><P>Appearing in Figure 9.1 is the modified class diagram for the <TT>Bank</TT> application,reflecting these additions. <BR><BR><A HREF="javascript:popUp('01.jpg')"><B>Figure 9.1.</B></A> <I>The modified </I><TT>Bank</TT><I>application class diagram.</I><H2><A NAME="Heading4"></A><FONT COLOR="#000077">Modifying the IDL Specification</FONT></H2><P>As on Day 8, the modifications to the IDL interface specifications are obvious.Start with the modified <TT>Bank</TT> interface, appearing in Listing 9.1, with changeshighlighted in<B> bold.</B><H4><FONT COLOR="#000077">Listing 9.1. Modified Bank.idl.</FONT></H4><PRE><FONT COLOR="#0066FF"><TT> 1: // Bank.idl</TT><TT> 2: </TT><TT> 3: // Forward declaration of Bank interface.</TT><TT> 4: interface Bank;</TT><TT> 5: </TT><TT> 6: #ifndef Bank_idl</TT><TT> 7: #define Bank_idl</TT><TT> 8: </TT><TT> 9: // sequence of Banks</TT><TT>10: typedef sequence<Bank> BankList;</TT><TT>11: </TT><TT>12: #include "Customer.idl"</TT><TT>13: #include "Account.idl"</TT><TT>14: #include "ATMCard.idl"</TT><TT>15: #include "Exceptions.idl"</TT><TT>16: </TT><TT>17: // A Bank provides access to Accounts. It can create an Account</TT><TT>18: // on behalf of a Customer, delete an Account, or list the current</TT><TT>19: // Accounts with the Bank.</TT><TT>20: interface Bank {</TT><TT>21: </TT><TT>22: // This Bank's name.</TT><TT>23: attribute string name;</TT><TT>24: </TT><TT>25: // This Bank's address.</TT><TT>26: attribute string address;</TT><TT>27: </TT><TT>28: // Create an Account on behalf of the given Customer, with the</TT><TT>29: // given account type ("savings" or "checking", where case is</TT><TT>30: // significant), and the given opening balance.</TT><TT>31: Account createAccount(in Customer customer, in string</TT><TT>32: accountType, in float openingBalance);</TT><TT>33: </TT><TT>34: // Delete the given Account. If the Account is not with this</TT><TT>35: // Bank, this operation does nothing.</TT><TT>36: void deleteAccount(in Account account)</TT><TT>37: raises (InvalidAccountException);</TT><TT>38: </TT><TT>39: // List all Accounts with this Bank.</TT><TT>40: AccountList getAccounts();</TT><TT>41: </TT><TT>42: // Issue an ATMCard with the initial PIN and initially</TT><TT>43: // authorized on the given Account. If the Account is not with</TT><TT>44: // this Bank, this operation does nothing.</TT><TT>45: ATMCard issueATMCard(in short pin, in Account account)</TT><TT>46: raises (InvalidAccountException);</TT><TT>47: </TT><B><TT>48: // Request the automatic update service on the given Account.</TT></B><B><TT>49: // Account balances will be sent periodically to the Customers</TT></B><B><TT>50: // owning the Account.</TT></B><B><TT>51: void requestUpdateService(in Account account)</TT></B><B><TT>52: raises (InvalidAccountException);</TT></B><TT>53: };</TT><TT>54: 55: #endif</TT> </FONT></PRE><P>Note that the changes to <TT>Bank.idl</TT> are minimal, consisting only of the⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -