Asynchronous transport mechanism in CORBA
(This article is reproduced from Software Engineering Expert Network www.21cmm.com)
Guoliang
This article is mainly discussed in the CORBA asynchronous transmission mechanism Oneway and event services. At the same time, delPHIL uses the online and event service asynchronous transport mechanism implementation.
The CORBA model we usually discussed tends to discuss the C O R B A system from the perspective of the client. Simply a usual client and server model: client and server components run on different machines, the client issues a request and then the client implicitly. The server actively monitors the request from the client. When a request is received, the server processes this request and returns the result to the requesting client. The client is blocked when waiting for the response, only after it receives the answer.
In many cases, this model is exactly what the user is desirable. And this model is also conforming to the traditional C / S model, and there is an answer. But in many cases, this model is not needed. In the stock system, the price update in the eyes of ordinary investors, the display of on-site data in the SCADA power system, etc., it is not required to request a request, the server returns the result. client. Also in many cases, the client has issued a request, and does not want to get the server's answer. It is only a notification to the server, and the front machine is applied to the server in the SCADA power system. You don't have to wait for the answer to the answer on this server. In order to solve the above problems, CORBA proposes an ONEWAY and an event service asynchronous transmission mechanism.
Oneway asynchronous transmission, as the name suggests, oneway is "One-way", that is, the client issues their excitation, then continue to process, and do not need to block after issuing a request until the result returns, when the server completes the process of the request, it You can also return the result by sending a corresponding one-way excitation knot to the client. Quot; return.
It is relatively simple to use the oneway asynchronous transmission, and its general step is the same as the normal CORBA application: 1. First define the IDL file of the interface. 2. Compile IDL file. 3. Write a server-side program. 4. Write a client program.
Here I use delphi6 (in the Delphi6 CORBA specification) to implement Oneway asynchronous transmission:
1. First define the IDL file of the interface: For simple, I only define a one OneWay method here.
Module Pro {Interface IonewDemo; Interface Ionewaya (in long aa);}; interface onewdemofactory {ionewdemo createinstance (in string instancename);};
2. And 3 in Delphi6, the second step and third step are together.
Select File-New-Other-CORBA-CORBA Server Application In the idl2pas create server dialog, press the Add button to join the IDL file just defined, press the OK button, compile it by the IDL2PAS compiler, generate pro_c.pas, PRO-I.PAS, PRO_IMPL.PAS, PRO_S.PAS four files defined in the pro_impl.pas file
Procedure Tionewdemo.onewaya (const aa: integer); begin form1.listbox1.items.clear; form1.listbox1.items.add (INTTOSTR (AA)); END; initialization during program startup
procedure TForm1.FormCreate (Sender: TObject); var Acct: IOnewDemo; begin CorbaInitialize; // Add CORBA server code here like this Acct: = TIOnewDemoSkeleton.Create ( 'ygl', TIOnewDemo.Create); BOA.ObjIsReady (Acct as _Object END;
Compile the generated server server.
4. Write a client program:
Initialization Procedure TFORM1.FORMCREATE (Sender: TOBJECT); begin corbainitialize; // bind to the corba server limited; = = tiNEWDEMOHELPER.BIND;
Call interface definition method Procedure TFORM1.TIMER1TIMER (Sender: TOBJECT); // Utilize The Mothod of Interface Var i: integer; begin randomize; i: = random (20); acct.onewaya (i); end;
Compilation Generate the client-side program.
Event service in CORBA is based on the following reasons:
The relationship between the event sender and the event recipient is loosely: When the event sender sends a message, it doesn't care about anyone who will receive the message. When the event recipient receives the message, it is not careful to send the message. Here event senders are called event suppliers, and event recipients are called event consumers.
In the event implementation of Visibroker, it defines two event models: PUSH model and PULL model: If an event is issued by the supplier, the consumer is accessed, called the PUSH model, if an event is active by the consumer Request, the supplier is delivered, called the PULL model.
The PUSH model can be simply represented as:
A universal interface is defined in the CosEvent unit in Delphi6:
Pushconsumer, Pushsupplier, Pullsupplier, Pullconsumer, Proxypushconsumer Proxypullsupplier, Proxypullconsumer, Proxypushsupplier, ConsumeRadmin, Supplieradmin, Eventchannel ... ..
Here I use the PUSH model to simply talk about the process of communication:
Supplier:
1. The supplier gets a Supplieradmin object. The supplier gets a Supplieradmin object by calling the Event_Channel's for_suppliers.
2. The supplier gets a proxypushconsumer object. The supplier gets a proxypushconsumer object by calling supplieradmin Obtain_Push_Consumer.
3. The supplier connects the remote Proxypushsupplier object using the connePushConsumer object's connect_push_supplier.
Consumer side:
1. Consumers get a ConsumeRadmin object. Consumers get a ConsumeRadmin object by calling Event_Channel's for_cHannel. 2. Consumers get a proxypushsupplier object. Consumers get a proxypushsupplier object by calling consumeRadmin's Obtain_push_supplier.
3. Consumers connect the remote proxypushconsumer object with the connecture_push_consumer of the Proxypushsupplier object. Examples of the PUSH model implementation of the event service in Delphi6 are as follows:
Supplier:
Implement TPushsupplier class TPUSHSUPPLIER = Class (TinterFaceDObject, Pushsupplier) public constructor create; procedure disconnect_push_supplier;
Main program:
procedure TForm1.FormCreate (Sender: TObject); var PushSupplier_Skeleton, PushSupplier_Skeletonaaa: PushSupplier; Event_Channel, Event_Channelaaa: EventChannel; Supplier_Admin, Supplier_Adminaaa: SupplierAdmin; Push_Consumer, Push_Consumeraaa: ProxyPushConsumer; myAny: any; begin CorbaInitialize; // Create the skeleton and register it with the boa PushSupplier_Skeleton: = TPushSupplierSkeleton.Create ( 'ygl', TPushSupplier.Create); BOA.SetScope (RegistrationScope (1)); BOA.ObjIsReady (PushSupplier_Skeleton as _Object);
// bind to the Event Channel and get a supplier admin object Get the event channel interface, the parameter of the BIND is the parameter in the following command line YGL: Event_Channel: = TEVENTCHANNELHELPER.BIND ('ygl'); // Can connect another event channel the parameter is a parameter yglaaa bind another instance: // Event_Channelaaa: = TEventChannelHelper.bind ( 'yglaaa'); SupplierAdmin obtained Interface: Supplier_Admin: = Event_Channel.for_suppliers; // get a push consumer and register the supplier object obtained ProxyPushConsumer Interface: Push_Consumer: = Supplier_Admin.obtain_push_consumer; ProxyPushSupplier connection interfaces Push_Consumer.connect_push_supplier (PushSupplier_Skeleton); push data channel to randomize; myany: = random (1000); try Push_Consumer.Push (myAny); except on EDisconnected do ShowMessage ( 'Client Disconnected '); end; end; consumer side:
Achieve TPushConsumer class TPushConsumer = class (TInterfacedObject, PushConsumer) public constructor Create; procedure push (const data: Any); procedure disconnect_push_consumer; end; What is important here is to: procedure TPushConsumer.push (const data: Any); var num: Integer Begin Num: = data; Form1.ListBox1.Items.Add (INTTOSTR (NUM)); END; it indicates that consumers receive data after data.
Main program:
procedure TForm1.FormCreate (Sender: TObject); var PushConsumer_Skeleton: PushConsumer; Event_Channel: EventChannel; Consumer_Admin: ConsumerAdmin; Push_Supplier: ProxyPushSupplier; begin CorbaInitialize;
// Create the skeleton and register it with the boa PushConsumer_Skeleton: = TPushConsumerSkeleton.Create ( 'ygl', TPushConsumer.Create); BOA.SetScope (RegistrationScope (1)); BOA.ObjIsReady (PushConsumer_Skeleton as _Object);
Get an event channel interface:
// bind to the event channel and get a Supplier Admin object Event_Channel: = TEventChannelHelper.bind ( 'ygl'); ConsumerAdmin obtained Interface: Consumer_Admin: = Event_Channel.for_consumers; // get a push consumer and register the supplier object obtained ProxyPushSupplier; Interface: Push_supplier: = Consumer_Admin. Obtain_push_supplier; Connect the proxypushconsumer interface push_supplier.connect_push_consumer (pushconsumer_skeleton); end;
The program runs:
First run the SmartAgent, then run the Channel YGL in a command line in ... / Visibroker / bin and then run the supplier, the consumer end program.
Pay attention to two aspects here:
1. Since most O r b use T C P as the underlying transmission, T C P is a reliable protocol, so even if the user thinks is a non-blocking call, it is actually a call to the block. User client applications may not wait for the server application to receive and start processing requests, but the client's T c P / I P stack is waiting until the request buffer is successfully received (and confirmed) successfully (and confirmed).
2. There is no control - filtering function of event granularity in Visibroker.
