CORBA service
(This article is reproduced from Software Engineering Expert Network www.21cmm.com)
Su Yang
Basic content of CORBA services
Various types of services are defined in the CORBA system specification, such as Naming, LifeCyle, Event, Transaction, Persistent Objects, Query , Characteristics, time (TIME) and other service functions. The relationship between the CORBA service and the object request agent is shown below.
In the CORBA specifications, there is no clear explanation of all service functions to the middleware products of different vendors, and allow the manufacturer to develop its own service type. Therefore, different manufacturers' ORB products are different from the support capabilities of CORBA services, so that we have more choices when making our intermediate product selection in the function of the system to develop system.
The CORBA service content that is closely related to the design and development of distributed applications:
1. Object Naming Service (Naming Service)
In the naming service, the implementation of the service object is determined by imparting the service object to a unique identifier in the current network space. On the client, by specifying the name of the service object, the search and positioning of the service object implementation can be invoked to the service object implementation by using the binding (bind) mode.
2. Object Security (SECURITY)
In a distributed system, the security of the service object and the security of the client application have always been a relatively sensitive problem, and security requires every aspect of distributed application calculations. For distributed applications distributed in the Internet, CORBA provides strict security policies to prevent malicious users or unauthorized methods, CORBA provides strict security policies, and has developed corresponding object security services. Security services can be implemented as follows:
● Recognition and certification of service request objects;
● Authorization and access control;
● Safety listening;
● Communication security guarantee;
● Management of safety information;
● Behavior confirmation.
The CORBA system is responsible for the functionality of the security management of the object request, and the system components only need to be responsible for the security management of the system itself, making the responsibility based on distributed applications in security control.
3. Concurrency Control Service
The purpose of defining concurrent control services in the CORBA specification is to implement concurrency control and management of shared resources in multi-customer access.
The concurrent control service consists of a plurality of interfaces that support transaction models and non-transaction models of access methods. Due to the introduction of two models, when the non-transactional customer is accessing the shared resource, if the resource is locked (Lock), the customer is transferred to the blocked state until the transaction method is completed, and the resource will be shared Customers with lock open, non-transaction models can access the shared resource.
The concurrent control service allows multiple objects to access shared resources using resource locks (LOCK). Before accessing the shared resource, the customer object must be locked from the concurrent control service. When confirming that the resource is currently being idle, obtain the right to use resources. Each lock is a resource - customer pair, indicating which customer is accessing what type of resource.
4. Object Life Service (Lifecycle)
Life service in CORBA defines and describes how to create, delete, copy, and move objects. Through life service, client applications can be controlled to remote objects.
Use Naming service
Distributed application
A naming service is used when using Javaidl developed distributed applications in the last article. Object Naming Services is a simple way for ORB find service objects. 1. Functional requirements analysis and definition interface file
The main function of this example is to simulate telephone subscriber registration and telephone number query services, develop a distributed application based on naming service, and the middleware products use Visibroker 4.5.1 for Java.
According to the definition of system functions, both services belong to the business scope of telecommunications services, so define the module name Telecom. The telephone number is registered as a telecom service management function range. You need to define the function interface Registry, which contains the user registration method register (); phone number query is the user service function range, you need to define the interface user, the interface contains the query personal phone number Method GetNumber (). After the above analysis, the IDL interface definition file Telecom.idl is as follows:
Module Telecom
{Interface user // interface user declaration
{/ / Definition of getNumber method in the interface
Int getnumber ();
}
Interface registry // interface registry declaration
{// Interface Register method definition, where String type variable is used as an input parameter 'method Returns a User object
User register (in string name);
}
}
After the interface definition file is compiled by IDL2JAVA, generate the Telecom subdirectory in the current interface file directory, including Userpoa.java, Registrypoa.java, etc. in this directory. These files are the framework of the client and the service object implementation function and related support files. Interested readers can actually create IDL files, analyze the format generated by Idl to the Java language.
2. Implement service function
(1) UserImpl implementing the USER interface
Depending on the functionality determined by the system analysis, the code for the implementation of the interface USERIMPL is as follows:
// UserImpl class inherits the USERPOA class defined in Userpoa.java
Public Class UserImpl Extends Telecom
.Userpoa
{Private int Anumber;
//Construction method
Public userIMPL (int Number)
{Anumber = Number;
}
/ / The method defined in the interface is used to return the phone number corresponding to the user object.
Public int getNumber ()
{Return Anumber;
}
}
(2) Implement the REGISTRYIMPL of the Registry interface
Depending on the functionality determined by system analysis, the code to implement the implementation class RegistryImpl in the interface registry is as follows:
// registryImpl class inherits defined in Registrypoa
RegistrypoA class in .java
Public Class RegistryImpl Extends Telecom
.Registrypoa
{public synchronized telecom.user register (String name)
{/ / Generate a registered phone number according to user name Name
/ / Generate the implementation class USERIMPL for the User interface according to the specified phone number
// Activate the portable object adapter
// Deposit the registered user object into the object library
}
/ / Return to the user object
}
3. Implement server-side applications
Depending on the function description and the ORB naming object service policy, the server-side application is implemented as follows:
First initialize ORB and get references to root POA (rootpoa). By analyzing the naming service in the root POA to obtain the name service context, and create user POA according to the corresponding policy according to the function of the service object, and use the user POA to complete the communication of the service object ORB and the service object. The code framework of the service object is:
Public Class Server
{public static void main (String [] ARGS)
{// Initialization Object Request Agent
Org.omg.corba.orb orb = org.omg
.CORBA.ORB.INIT (ARGS, NULL);
// Get reference to the root POA
Poa rootpoa = poahelper.narrow (orb.resolve_initial_reference));
/ / Quote Name Service and get context content
Org.omg.corba.object rootobj =
Orb.resolve_initial_references ("Nameservice");
NamingContexText root =
NamingContexTextHelper.narrow (rootobj);
// Create a POA service policy
Org.omg.corba.policy [] policies =
{rootpoa.create_lifespan_policy (lifesspanpolicyvalue.Persistent)}
/ / Create a user-portable object adapter according to service strategy
Poa mypoa = rootpoa.create_poa ("telecom_poa", rootpoa.the_poamanager (), policies);
/ / Generate a service object
// Apply for service object identity
/ / Activate the service object
// Activate the portable object manager
Rootpoa.The_Poamanager (). Activate ();
// Start ORB
Orb.run ();
}
}
4. Implement client applications
Based on the name service type provided by the service object, generate the corresponding object request agency, and use the naming service to locate the service object, and propose service requests.
Public Class Client
{public static void main (String [] ARGS)
{// Initialization Object Request Agent
Org.omg.corba.orb orb = org.omg
.CORBA.ORB.INIT (ARGS, NULL);
/ / Quote Name Service and get context content
Org.omg.corba.object rootobj = orb.resolve_initial_references ("nameservice");
NamingContexText root = naming-
CONTEXTEXTHELPER.NARROW (rootobj);
// Use the naming service to locate the service object
// The service object name is already defined in Server.java
Org.omg.corba.object mgrobj = (namingcontext) root .resolve (Root.to_Name ("TelecomManager");
Telecom.registry Manager = Telecom
.Registry.narrow (mgrobj);
// Get account name Name
/ / Apply for a user account according to the specific account name
Telecom.registry user = manager.open (name);
/ / Get the phone number assigned by the user
INT number = user.getnumber ();
// Print account information and other operations
}
}
