Distributed programming based on CORBA (six)

Chapter IV Corba Service Type

4.1 Explain the implementation of CORBA event services

CORBA Event Services provides basic message delivery features by encapsulation of events (generated and transmitted to other objects), after the event is generated, the CORBA event service is to transmit events from event provider objects to event consumer objects. A mechanism. Moreover, event services allow objects to dynamically register or log out of specific events they are interested in, and event services have established a loosely coupled communication channel between objects that do not know each other. The degree of event coupling is called to be loose than the remote process, but it is tight than the intermediate part (MOM) of the message.

4.1.1 Two Event Data Transfer Models:

• Push the Pushpush model:

In the push model, the provider of the event will take the lead in the lead, initiate the transmission of the event;

• 拉 pull model:

In the pull model, the consumer of the event will take the lead in requesting event data to the provider.

Event Channel is an insertion object that is both an event provider and an event consumer, which allows multiple event providers and multiple event consumers to communicate asynchronously without having to know each other. The event channel is a standard CORBA object that resides on the object request intermediary, disconnects the provider and consumer communication.

The event channel utilizes the provider and consumer of the time of the agent. Providers and consumers are not directly interacting, but from the event channel to get a proxy object, let the agent object represent yourself in the future event exchange. The provider gets a consumer agent, while consumers get a provider agent. The event channel exchanges the exchange of these proxy object proxy events.

4.1.2 Event Channel

• For push models:

The event provider issued a call to invoke the PUSH method on the event channel object, and the event channel then pushed the data to the consumer object. Consumers can stop accepting events by calling methods disconnect_push_consumer on the event channel, or call the Connect_Push_ConSumer method on the event channel to register the event type of interest.

• For the pull mode:

Event consumers issued a call, calling the PULL method on the event channel object, and the event channel then pulls the data from the provider. With the try_pull method, the consumer can poll the events periodically. By calling the Disconnect_Pull_ Supplier method on the event channel, the provider can stop accepting requests that provide events, and the provider can also call the add_pull_supplier method on the event channel, register its object tag, and provide its service.

We can understand the CORBA event service architecture by understanding the context of the CORBA event sequence.

4.1.3 Pushing Model

The PUSH event script shown in the figure shows a brief process of pushing the event to a consumer through an event channel.

1. For a push provider of a model, the basic event sequence is as follows:

(1) Bind to the ORB and the event channel:

Org.omg.corba.orb orb = org.omg.corba.orb.init (AGRS, NULL);

Eventchannel Eventchannel = EventChannel Helper.bin (ORB);

(2) Get a push consumption agent from the event channel:

Supplieradmin admin = eventchannel.for_suppliers (); // The first step in the PUSH event script

Proxypushconsumer PushConsumer = admin. Obtain_push_consumer (); // Create a push provider in the second step of the Push event script in the figure:

MySupplier Pushsupplier = new mysupplier ();

(4) Connect the provider to the event channel:

Pushconsumer.connect_push_supplier (Pushsupplier); / / The third step in the Push event script in the picture

(5) Create a CORBA message:

HelloImplementation msg = new helloimplementation ()

(6) Create an ANY event object using the CORBA message:

Org.omg.Corba.Any PushMessage = orb.create_any ();

PushMessage.Insert_Object (MSG);

(7) Push the message to the consumer:

Pushconsumer.push (pushmessage);

// The seventh step of the PUSH event script in the figure

2. For a push-to-cost, the basic event sequence is as follows:

(1) Bind to the ORB and the event channel:

Org.omg.corba.orb orb = org.omg.corba.orb.init (AGRS, NULL);

Eventchannel Eventchannel = EventChannel Helper.bin (ORB);

(2) Get a push provider agent from the event channel:

Consumeradmin admin = eventchannel.for_consumers (); // The fourth step in the Push event script in the picture

Proxypushsupplier Pushsupplier = admin. Obtain_push_supplier ();

/ / The fifth step of the PUSH event script in the picture

(3) Create a push consumer:

Myconsumer pushconsumer = new myconsumer ();

(4) Connect the consumer to the event channel:

Pushsupplier.connect_push_consumer (PushConsumer); // The sixth step of the Push event script in the picture

(5) Received in a PUSH () implementation:

Public void push (any pushmsg)

{

// The seventh step of the PUSH event script in the figure

Org.omg.corba.object object = pushmsg.extract_Object ();

Hello msg = helloheper.narrow (Object);

}

4.1.4 Pull Model

1. For a pulling provider of a pull model, the basic event sequence is as follows:

(1) Bind to the ORB and the event channel:

Org.omg.corba.orb orb = org.omg.corba.orb.init (AGRS, NULL);

Eventchannel Eventchannel = EventChannel Helper.bin (ORB);

(2) Get a pull consumption agent in the event channel:

Supplieradmin admin = Eventchannel.for_suppliers ();

ProxypullConsumer pullconsumer = admin. Obtain_pull_consumer (); (3) Creating a pull provider:

MySupplier Pullsupplier = New MySupplier ();

(4) Connect the provider to the event channel:

PullConsumer.connect_pull_supplier (PULLSUPPLIER);

(5) Provide a PULL () interface for the consumer to pull the message:

Public org.omg.corba.Any Pull ()

{

Org.omg.ocrba.Any Pullmsg = Org.create_any ();

HelloImplementation msg = new helloimplementation ();

PULLMSG.INSERT_Object (MSG);

Ruturn PULLMSG;

}

(6) Design a try_pull () interface for the consumer, implement it only when a message is available:

Public org.omg.corba.any try_pull (org.omg.corba.BooleanHolder isavail)

{}

2. For a scaffolding consumption, the basic event sequence is as follows:

(1) Bind to the ORB and the event channel:

Org.omg.corba.orb orb = org.omg.corba.orb.init (AGRS, NULL);

Eventchannel Eventchannel = EventChannel Helper.bin (ORB);

(2) Get a pull provider agent from the event channel:

Consumeradmin admin = Eventchannel.for_consumers ();

Proxypullsupplier Pullsupplier = admin .Obtain_pull_supplier ();

(3) Create a pull consumption:

Myconsumer pullconsumer = new myconsumer ();

(4) Connect the consumer to the event channel:

PULLSUPPLIER.CONNECT_PULL_CONSUMER (PULLCONSUMER);

(5) Try the TRY_PULL () interface or pull () interface to the pull provider agent and convert it to a message type:

Org.omg.Corba.BooleanHolder Hoder = new org.omg.corba.BooleanHolder ();

Org.omg.corba.Any Pullmsg = Pullsupplier.Tyr_Pull (HOLER);

Org.omg.corba.object obj = punmsg.extract_Object ();

Hello Hello = HelloHelper.narrow (OBJ);

// Convert to message type

Figure 4-1 Push event script

In general, the CORBA event service is only introduced in CORBA, which is the lowest because it does not support message priorities such as MOM, filter, transaction protection, and acceptable confirmation, etc. Management mechanism. Despite this, CORBA Event Services provides a framework for objects that are dynamically registered or logged out of their interested events, using this framework, providers can push events to (PUSH) consumers, consumers can pull from the provider ( PULL) Event data, and multiple providers and consumers can communicate asynchronously on an event channel. Part data, and multiple providers and consumers can communicate asynchronously on an event channel. 4.2 Naming Services of CORBA Interoperability

The CORBA object naming service provides a name for the object instance so that the user can obtain an instance of the object through these names. Object Naming Services is the basic mechanism of objects on ORB to find other objects. The name is used to identify an objectible identifiable value of an object, and the naming service maps these names to object tags, name-object association called names. Name language environment is a name space, the name of the object is unique here. Each object has a unique reference identifier. You can selectively associate one or more names with an object tag. Always define a name relative to its named locale. Using naming services can create a naming hierarchy, customers can search for different named locale and find the object you want. The name locale from different domains can be used together to create a joint naming service for the object. The CORBA naming hierarchy does not require a "unified" root directory. In general, the user can specify the naming principle of the object, representing a series of information such as the host, function of the object, which includes the following three aspects.

(1) The handle of the CORBA object defines the form of the URL (Uniform Resource Location) to allow ORB (Object Request Broker to call CORBA-based service or object instances on remote ORBs.

(2) Any vendor's ORB can initialize the context object for root name service by configuring the client's ORB.

(3) Composite naming for CORBA objects. Define a standard syntax rule. This allows the server and the client to read and write messages through the same format.

Some features of CORBA naming services will be discussed separately.

I. Unified resource positioning of CORBA objects (URL): CORBALOC

On the Internet, you can enter your address directly in your browser, you can go to your designated website, which is also used in CORBA.

The usual approach is to put a CORBA server on a machine with a specified domain name address and port. Corba's server is to serve many of the CORBA objects. Generally we need to add a specific object americ or object name after the URL address of the object instance, which indicates the specific services we need. As follows:

CORBALOC: YOURDOMain.com/nameservice

Where Corbaloc is the keyword of the CORBA URL, the conversion of the object instance and the object handle YourDomain.com is the domain name address or IP address of the machine, / behind NAMESERVICE is an object value.

1. Object of the object

The auditory value of the object is part of the interface object warehouse, mainly used to represent a specific object instance of the client call. The object health is generated by the ORB in the process of generating the object handle, and is used by the ORB generating the object value of the object, so CORBA does not do any standardization for its form and content.

The object is not necessarily a word, which can also be a string sequence. Be followed by the primary domain name or IP address, keeping up / top is an object value. Such as: CORBALOC: YOURDOMAIN.COM/dev/sand/box/corba/nameservice

Significant value of it is dev / sand / box / corba / nameservice

2. Corbaloc's Complete Format and IIOP (Internet Inter-Orb Protocal)

(1) Complete format of CORBALOC URL

The complete format of the CORBALOC URL is as follows:

CORBALOC: IIOP: 1.2@yourdomain.com: 2809 / Pub / Nameservice

That is, CORBALOC is the type of protocol (IIOP is the default protocol type, which can be omitted), and another protocol is RIR (Resolove Initial References). 1.2 is the version number of the protocol. Since each protocol defines a specific message format, the target object is queried, so the specific address information includes a specific protocol type, the protocol's version number, the domain name address, and port number. The default port number of Iona (Internet Association Naming Authority) is 2809, the address in the above example is:

IIOP: 1.2@yourdomain.com: 2809, then the objective value.

(2) COBARLOC and RIR protocol

In addition to the IIOP protocol, there is a RIR protocol. By the RIR, you can use the URL to access the ORL service to pass the string corbaloc: Rir@yourDomain.org/nameservice to string_to_object, return to the corresponding object handle, in CORBALOC: The object values ​​called in RIR can be any of the average values ​​defined in resolve_initial_references.

3. Coding and Corbaloc

Each ORB has a standard interface that converts a string similar to the URL to the object handle via String_to_Object. Also return to a session handle to the client, this session handle, and the NAMESERVICE, TRADSERVICE, or any object values ​​you need.

The server side can use two methods to implement responses to the client.

(1) Typically a CORBA naming or transaction's object instance accepts the client's request, and then returns the result of the result to the customer, and the server-side procedure is only run on the gateway machine of a specific port, accepts the user's request.

(2) Or to mitigate the burden on the gateway, you can install a small agent software on your gateway, not all requests from the client to redirect to a relatively stable server through Locate_Forward, return the result of the processing Give customers, the gateway has played a proxy role.

Second, the name of the object URL (CORBANAME)

Corbaname is running over Corbaloc to parse the remote naming service. As follows:

Corbaname :: YourDomain.org/pub/catalog#year2000/enswear /outdoors.obj

Before #, in addition to the corbaname identifier, the other is the URL of CORBALOC, and after the object is a string named.

Pass the string of the URL to the string_to_object function, orb parsing the CORBALOC section to an instance of the name context of the host naming service (NamingContext). For example, the client's ORB is parsed on the MensWear / OutDoors.obj string on the name context Pub / Catalog instance, which resides on the CORBA server named YourDomain.org. Third, configure the initial service and the handle of the object

Do some configurations on the root named context when the client's program starts. For example, all users' ORB points to the same root; all the namespaces on the organization and allocation of the server, all users can exchange objects of objects, and different users can organize and assign their own root names and Name space. The client program can query the already initialized service through list_initial_services. INS (Interoperable Name Service) provides three ways to the initialization object handle in the naming server.

1. Management settings

Configure a service on the ORB to configure a handle that returns a remote object

2. OrbinitRef

When you start ORB, pass to the following parameters to set the service handle, as shown below:

-Orbinitref =