<?xml version="1.0" encoding="GB2312"?>
<?xml-stylesheet type="text/xsl" href='links.xsl'?>
<root>
<class name="RT-CORBA">
	<link>
		<title>Real-Time CORBA Priority and Threadpool Mechanisms </title>
		<author>Richard Anthony, Senior Architect</author>
		<date>2002</date>
		<href>http://www.ociweb.com/cnb/CORBANewsBrief-200210.html</href>
		<descript>The Real-Time CORBA specification [1] defined several mechanisms to provide for end-to-end deterministic performance for CORBA operations. This specification was originally defined as an extension to CORBA 2.3 and the CORBA messaging specification. The RT CORBA extensions utilized and extended the quality-of-service (QoS) mechanisms defined in the CORBA messaging specification. The extensions defined by RT CORBA are used to support many distributed real-time and embedded (DRE) systems that require end-to-end support of quality-of-service characteristics, such as jitter and latency</descript>
		
	</link>
	<link>
		<title>Local Interfaces</title>
		<author>Paul Calabrese, Principal Software Engineer and Partner </author>
		<date>2002</date>
		<href>http://www.ociweb.com/cnb/CORBANewsBrief-200207.html</href>
		<descript>The Object Management Group (OMG) defines the Interface Definition Language (IDL) as part of the CORBA specification. The OMG has always used IDL to not only define unconstrained ( potentially remote) interfaces, but also those local to a particular process (or part of CORBA's API). Originally, this was done in an informal manner with what was described as Pseudo IDL (PIDL). </descript>
		
	</link>
	<link>
		<title>The CORBA Notification Service: JacORB and TAO Interoperability </title>
		<author>Heather Drury, Product Services Manager and Senior Software Engineer </author>
		<date>2002</date>
		<href>http://www.ociweb.com/cnb/CORBANewsBrief-200206.html</href>
		<descript>
		The  Notification Service Specification was originally produced by the Telecommunications Working Group within the Object Management Group (OMG), an international consortium of over 800 companies, and was later adopted as a standard service.  The goal was to extend the more basic OMG Event Service specification to support telecommunication applications yet remain backward compatible with the standard Event Service. The Notification Service preserves all the semantics specified for the OMG Event Service, allowing for interoperability between basic Event Service and Notification Service clients.   </descript>
		
	</link>
	</class>
</root>
