| Key points: |
- The best thing about Messaging is its loose coupling of client and server. The worst thing is that, due to this same loose coupling, your development tools (compilers, debuggers, WebORB's management console, etc.) can't help you as much as they can when developing more tightly-coupled applications. You need to be more aware of the PURPOSE and PROCESS of each method call, configuration setting, and compiler variable.
- When deploying a messaging aplication into WebORB (by copying the application's binaries into [WebORB]\bin, as usual), you MUST ALSO create a directory at [WebORB]\Applications\[YourAppName] (where WebORB is the file system directory into which you installed WebORB). If the app has server-side code, then you MUST also place, in that directory, an app.config file. Otherwise, your app Just Won't Work. You can find a copy of the app.config file for this sample application here (that is, at /Applications/CPU_Usage_RSO/app.config). Notice that it sets application-handler to examples.weborb.CPU_Usage_RSO -- that is, to the fully-qualified name of the server-side messaging application's ApplicationAdapter class.
- A single instance of the server-side class CPU_Usage_RSO is instantiated after (a) WebORB's messaging server starts up, and (b) the first call is made to one of the server-side class CPU_Usage_RSO's methods.
- The server-side CPU_Usage_RSO method WakeMeUp() (CPU_Usage_RSO.cs, line 55) does absolutely nothing. It exists solely to provide clients with a convenient "do-nothing" method which, when called, will ensure that a client-side CPU_Usage_RSO service is instatiated by WebORB. (The method's name is not significant.)
- The client's onCreationComplete() method (main.mxml, lines 29-44) does nothing but prepare for, and then make, a remote procedure call to CPU_Usage_RSO.WakeMeUp(), thereby ensuring that CPU_Usage_RSO is instantiated before CPU_Usage_RSO remote shared object is accessed.
- Notice that server-side CPU_Usage_RSO (an ApplicationAdapter) does not implement a constructor. It is tempting to place RSO-creation code in an ApplicationAdapter's constructor, using this.getScope() to get the service's scope. Don't do it! Place the RSO allocation and initialization code in an override of appStart(), which has an IScope parameter, as shown in this example.
- The RSO is marked as persistent in three places: in the server's CPU_Usage_RSO.cs, lines 24 and 37; and in the client's main.mxml, line 63. All three must agree, or Bad Things Will Happen.The persisted object is serialized to a "persistence" folder that WebORB creates in the [WebORB]\Applications\CPU_Usage_RSO folder.
|