Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Connecting a Smartphone 2003 Application to a Remoting Infrastructure : Page 3

Despite the fact that remoting is not currently supported in .NET Compact Framework applications running on the Smartphone 2003 platform, by using a third-party object request broker (ORB) you can interact with remote objects.

The Glue: IDL
An IDL (Interface Definition Language) file provides the glue between the host and the subscriber code. The IDL file contains a generic description of the calling interfaces with abstract data types that must be mapped to the actual data types of the target platform.

In the chat example, the subscriber and the host each act as both server and client—the term "subscriber" better describes the part of the application that runs on the mobile device than the term 'client' because of the potential confusion with using the term "client" at the communication level, which can be either side.

The subscriber initializes the session by sending a registration packet to the host, which the host acknowledges by returning a list of current subscribers. Once registered, the client can then send messages to the host as needed. The host calls other subscribers to distribute the message to all participating devices. To unregister, a subscriber must call the host again (see Figure 2).

Figure 2. Sequence Diagram: The sequence diagram visualizes the interactions between subscriber and host at the object level.
How do these requirements translate to an IDL file? The Host interface shown below exposes three methods that subscribers will call: signOn, sendMessage, and signOff.

interface Host { SubscriberInfoList signOn( in::Chat::SubscriberAccount subscriberAccount) raises(SignOnException); void signOff(in wstring name); void sendMessage(in wstring name, in wstring message); };

Table 2 shows how .NET maps data types between IDL and C#. You can find additional information about the IDL syntax and the IDL-to-C# compiler in the MiddSol documentation.

Table 2. The table shows how .NET maps data types between IDL and C#.
IDL Type C# Type
boolean Bool
char Char
wchar Char
string String
wstring String
octet Byte
short Short
unsigned short Ushort
long Int
unsigned long Uint
long long Long
unsigned long long Ulong
float Float
double Double
long double Double

The signOn() method accepts one parameter (subscriberAccount) and returns a SubscriberInfoList, which is a list of all registered subscribers. The subscriber uses the returned list to display all the participating subscribers. The signOff() and sendMessage() methods require the subscriber to pass in a subscriber name; sendMessage() also requires the message that is to be sent. Because the application uses subscriber names as keys, they must be unique. The host enforces this at registration by iterating through the list of current subscribers and rejecting a sign-on attempt for a user name that already exists.

The subscriber, on the other hand, must allow the host to update the display by exposing its interface to the host for a method call, displayMessage(). The displayMessage() method requires two parameters—the name of the sender and the message itself. Here's the IDL for the Subscriber interface.

interface Subscriber { void displayMessage(in wstring from, in wstring message); };

The Host interface above uses the class SubscriberAccount as a parameter—and that's not a primitive type. Because both host and subscriber use that type, it must be defined in the IDL as well. You use the IDL construct valuetype to represent such a class (do not confuse the IDL valuetype with the .NET valuetype—the latter is the .NET base type for primitives and structs).

CORBA valuetypes are serializable classes that can be transmitted "by value" between two communicating partners. In this case, the class is SubscriberAccount and extends the valuetype SubscriberInfo. The class contains information about a subscriber. The subscriber sends an instance of that class to the host during registration. Here's the relevant section of the IDL file

valuetype SubscriberInfo { private wstring strHobby; private wstring strName; wstring queryName(); wstring queryHobby(); }; valuetype SubscriberAccount : SubscriberInfo { private ::Chat::Subscriber subscriber; ::Chat::Subscriber queryInterface(); };

Note that, in addition to the trivial get methods, the class contains a method called queryInterface() that returns the subscriber's interface. The host needs to know this to call the method displayMessage() on the subscriber.

SubscriberInfo was introduced as the base value for SubscriberAccount because publishing a subscriber's interface to all the other subscribers in the chat room would create a security risk. It would not be a good idea for the signOn() method to return a list of SubscriberAccount objects.

typedef sequence <SubscriberInfo> SubscriberInfoList;

Now that the IDL is complete (see Listing 5 for the code) you can run the MiddCor IDL compiler (MCidl2cs.exe) to generate C# stub code. You must add the resulting stub file (Chat.cs) to both the host and the subscriber projects in Visual Studio.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date