diff options
author | schmidt <douglascraigschmidt@users.noreply.github.com> | 1999-12-21 18:20:32 +0000 |
---|---|---|
committer | schmidt <douglascraigschmidt@users.noreply.github.com> | 1999-12-21 18:20:32 +0000 |
commit | f6c3022b9e824a7f81180d566b990a9b8cac5076 (patch) | |
tree | f0de331ba9d12a77ac3921c9b59e332f215a38ac /TAO/docs | |
parent | 8d572e0e3b8bccd0ad3a148fe43d86a60a50a5a5 (diff) | |
download | ATCD-f6c3022b9e824a7f81180d566b990a9b8cac5076.tar.gz |
ChangeLogTag:Tue Dec 21 08:02:43 1999 Douglas C. Schmidt <schmidt@tango.cs.wustl.edu>
Diffstat (limited to 'TAO/docs')
-rw-r--r-- | TAO/docs/Smart_Proxies.html | 98 | ||||
-rw-r--r-- | TAO/docs/index.html | 2 | ||||
-rw-r--r-- | TAO/docs/interceptors.html | 25 | ||||
-rw-r--r-- | TAO/docs/minimumTAO.html | 41 | ||||
-rw-r--r-- | TAO/docs/pluggable_protocols/index.html | 116 |
5 files changed, 182 insertions, 100 deletions
diff --git a/TAO/docs/Smart_Proxies.html b/TAO/docs/Smart_Proxies.html index 2324124556c..ed7368aa927 100644 --- a/TAO/docs/Smart_Proxies.html +++ b/TAO/docs/Smart_Proxies.html @@ -1,26 +1,15 @@ <!-- $Id$--> -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML> <TITLE>Smart Proxies</TITLE> <BODY> -<CENTER><H1>Smart Proxies</H1></CENTER> <BODY text = "#000000" link="#000fff" vlink="#ff0f0f" bgcolor="#ffffff"> -<h3><a name="toc">Table of Contents</a></h3> -<ul> - <li><a href="#Introduction">Introduction</a> - <li><a href="#Design Issues">Design Issues</a> - <li><a href="#Design Overview">Design Overview</a> - <li><a href="#Implementation Issues">Implementation Issues</a> - <li><a href="#Acknowledgements">Acknowledgements</a> - <li><a href="#ref">References</a> -</ul> - -<h2><a name="Introduction">Introduction</a></h2> +<Hr><P> +<H3>Smart Proxies</H3> <P>Smart Proxies (or Smart Stubs) are basically user-defined proxy classes.</p> @@ -31,15 +20,27 @@ invocations are to be made by the client, i.e. it has the same methods as the targeting interface. A proxy packadges the request which gets marshalled and sent to the target object.</p> +<Hr><P> +<h3><a name="toc">Table of Contents</a></h3> +<ul> + <li><a href="#Examples">Examples</a> + <li><a href="#Design Issues">Design Issues</a> + <li><a href="#Design Overview">Design Overview</a> + <li><a href="#Implementation Issues">Implementation Issues</a> + <li><a href="#Acknowledgements">Acknowledgements</a> + <li><a href="#ref">References</a> +</ul> + +<Hr><P> +<h3><a name="Examples">Examples</a></h3> + <P>The user may wish to manually change the proxy code for the following reasons: -<P> -<h3><a name="Examples">Examples</a></h3> -<P>1) Cache information about the remote object locally to save the -expense of going across the wire for every request. +<UL> <LI> Cache information about the remote object locally to save +the expense of going across the wire for every request. <P> -<P>2) Batch updates/accesses to the remote object. +<LI> Batch updates/accesses to the remote object. <p>For instance:<br> Consider a remote Database which has an API which can update either a single record or 10 records at one shot. To leverage performance, one @@ -47,7 +48,7 @@ would want to use this method. So a user can use the smart proxy to implement the 10 record update method by caching single record update requests.</p> -<P> It is not certain whether this usecase might not induce extra +<P>It is not certain whether this usecase might not induce extra overhead and whether the proxy can be smart enough to deduce the use of this kind of batch processing. Also, this scheme wont work for two-way calls.The "cached-oneways" feature might make more sense in @@ -55,7 +56,7 @@ this scenario. Thus the application programmer will have to determine how this caching optimisation changes the semantics of the original interface.</p> -<P>3) The client can make a single request which results in a sequence +<LI> The client can make a single request which results in a sequence of invocations to one or possibly more objects. <p> For instance:<br> @@ -64,18 +65,22 @@ this should be possible) which do validation of the request to be made. The remote call could result in another call wherein the validation occurs before it is shoved over the wire.</p> -<P>4) Quality of Service features like load-balancing can be considered +<LI> Quality of Service features like load-balancing can be considered by the smart proxy before making the invocation on the appropriate target object.</p> +</UL> -<h2><a name="Design Issues">Design Issues</a></h2> +<Hr><P> +<h3><a name="Design Issues">Design Issues</a></h3> -<P>1) How will the smart proxy be created? -<P>2) Who will create the smart proxy? -<P>3) It has to be done before the invocations on the target object are +<UL> +<LI> How will the smart proxy be created? +<LI> Who will create the smart proxy? +<LI> It has to be done before the invocations on the target object are done, so when will it get created? -<P>4) What about collocation? Will those stubs fall under this category?</p> -<p>5) Will smart proxies work for collocated object references?</p> +<LI> What about collocation? Will those stubs fall under this category? +<LI> Will smart proxies work for collocated object references? +</UL> <h3>Design Needs and discussion points</h3> @@ -100,34 +105,39 @@ collcated stubs.</p> <P>Classses to be generated by TAO_IDL in addition to the Default Stub:</p> -<P>1. TAO_Proxy_Factory_Adapter +<UL> +<LI> <CODE>TAO_Proxy_Factory_Adapter</CODE> <p>The singleton which has the different proxies (stubs) factories registered with it.</p> -<P>2.TAO_Test_Default_Proxy_Factory +<LI> <CODE>TAO_Test_Default_Proxy_Factory</CODE> <p>The factory which returns the proxy_ptr which is used in the <code>unchecked_narow</code> method to create the appropriate proxy object. -<P>3. TAO_Smart_Proxy_Base +<LI> <CODE>TAO_Smart_Proxy_Base</CODE> <p>The smart proxy interface which makes it easier for the user to simply implement only the methods he wishes to change and also provides a <br>common interface to address remote as well as collocated stubs.</p> +</UL> <P>Classes to be defined by the user:</p> -<P>1. SmartFactory - inherits from TAO_Default_Proxy_Factory class. +<UL> +<LI> <CODE>SmartFactory</CODE> - inherits from TAO_Default_Proxy_Factory class. <p>The factory which will create the smart proxy which the user wants. Its necessary that an object of this class is created.</p> -<P>2. SmartProxy - derivative of the TAO_Smart_Proxy_Base class. +<LI> <CODE>SmartProxy</CODE> - derivative of the TAO_Smart_Proxy_Base class. <p>The proxy which has the user desired extra functionality.</p> <P>*Note: Names are as they are to make it easier to comprehend the concept.</p> +</UL> -<h3>In more detail</h3> +<Hr><P> +<h3>Detailed Example</h3> <pre> //------------------------ Generated by TAO_IDL------------------------ @@ -320,33 +330,39 @@ interface_ptr _unchecked_narrow (CORBA::Object obj, } </pre> -<h2><a name="Implementation Issues">Implementation Issues</a></h2> +<Hr><P> +<h3><a name="Implementation Issues">Implementation Issues</a></h3> -<p> 1) Native exceptions? How are these to be handled?</p> +<UL> +<LI> Native exceptions? How are these to be handled?</p> <p> This not an issue really because the actual method call is simply to the application level which will catch it as the exception is propogated upwards from the proxy level.</p> -<p> 2) What if the user wants to have a smart proxy which inherits from -many interfaces?</p> +<LI> What if the user wants to have a smart proxy which inherits from +many interfaces? <p> First have different smart proxies which inherit from the TAO_Smart_Proxy_Base (every default smart proxy is for an interface) and then have a new smart proxy inheriting from the previously created smart proxies. But remember: the SmartProxyFactory should create the final smart proxy thru its create_proxy () method. +</UL> -<h2><a name="Acknowledgements">Acknowledgements</a></h2> +<Hr><P> +<h3><a name="Acknowledgements">Acknowledgements</a></h3> <P><a href="mailto:nanbor@cs.wustl.edu">Nanbor Wang</a> and <a href="mailto:schmidt@cs.wustl.edu">Dr.Schmidt</a> for their help in -designing and discussing this feature. +designing and discussing this feature. <P> -<h2><a name="ref">References</a></h2> +<Hr><P> +<h3><a name="ref">References</a></h3> <p> CORBA Distributed Objects using Orbix - Sean Baker </p> <p> Visigenic Documentation </p> -<p><h2>Last update:</h2></p> +<Hr><P> +<p><h3>Last Update</h3></3> <p> Date: 21thSept99</p> <p> By: <a href="mailto:kirthika@cs.wustl.edu">Kirthika Parameswaran</a></p> diff --git a/TAO/docs/index.html b/TAO/docs/index.html index 7aa2b77be70..df1c8db9946 100644 --- a/TAO/docs/index.html +++ b/TAO/docs/index.html @@ -30,7 +30,7 @@ HREF="http://www.omg.org/library/c2indx.html">CORBA</a> Documentation</h3> <td><font SIZE="+1"><dl> <dt><a HREF="INS.html">Interoperable Naming Service</a> </dt><P> <dt><a HREF="implrepo/">Implementation Repository</a> </dt><P> - <dt><a HREF="minimumTAO.html">Minimum TAO</a> </dt><P> + <dt><a HREF="minimumTAO.html">TAO Subsetting</a> </dt><P> <dt><p><a href="../../docs/exceptions.html">Exception Handling</a></p> <dt><a HREF="Tags.html">Tags and Magic Numbers</a> </dt><P> <dt><a HREF="pluggable_protocols/index.html">Writing Pluggable Protocols</a> </dt><P> diff --git a/TAO/docs/interceptors.html b/TAO/docs/interceptors.html index 45c69950e7a..1e2935d99e6 100644 --- a/TAO/docs/interceptors.html +++ b/TAO/docs/interceptors.html @@ -1,7 +1,9 @@ <HTML> <TITLE>Portable Interceptors</TITLE> <BODY> -<CENTER><H1>Portable Interceptors</H1></CENTER> + +<Hr><P> +<H3>Portable Interceptors</H3> <BODY text = "#000000" link="#000fff" @@ -18,6 +20,7 @@ once we have the new mechanism in place.</p> <p>The revised interceptor implementation will be available shortly.</p> +<Hr><P> <h3><a name="toc">Table of Contents</a></h3> <ul> <li><a href="#context">Context</a> @@ -27,6 +30,7 @@ once we have the new mechanism in place.</p> <li><a href="#ref">References</a> </ul> +<Hr><P> <h2><a name="context">Context</a></h2> <p>Interceptors allow you to interpose other CORBA services to the ORB @@ -43,8 +47,9 @@ Portable Interceptor</a>" specification which will remedy the problems and allow application users to use interceptos from different venders with their ORBs. </p> -<h2><a name="implement">TAO's Implementation of "Portable -Interceptors"</a></h2> +<Hr><P> +<h3><a name="implement">TAO's Implementation of "Portable +Interceptors"</a></h3> <p>TAO's portable interceptor implementation was developped before even a joint submission was available. There were several proposed @@ -60,8 +65,9 @@ finalized.</p> proposed spec., this document provide some guidelines on how you can revise your portable interceptors to work with the "standard." </p> -<h2><a name="api">Guide for Transitting from TAO's Old "Portable" -Interceptor APIs to the Standard Portable Interceptor APIs</a></h2> +<Hr><P> +<h3><a name="api">Guide for Transitting from TAO's Old "Portable" +Interceptor APIs to the Standard Portable Interceptor APIs</a></h3> <p>Please refer to the working draft for details on the proposed Portable Interceptor interfaces.</p> @@ -261,13 +267,15 @@ module PortableInterceptor #pragma prefix "" </pre> -<h2><a name="status">Current Status</a></h2> +<Hr><P> +<h3><a name="status">Current Status</a></h3> <ul> <li>We will change the temporary interceptor implementation to conform with the proposed spec. shortly. </ul> -<h2><a name="future">Future Works</a></h2> +<Hr><P> +<h2><a name="future">Future Work</a></h2> <ol> <li><p>There will only be request-level interceptors.</p></li> @@ -276,7 +284,8 @@ module PortableInterceptor <li><p>Add support for "standard" portable interceptors.</p></li> </ol> -<H3><a name="ref">References:</a></H3> +<Hr><P> +<H3><a name="ref">References</a></H3> <UL> <LI><a href="ftp://ftp.omg.org/pub/docs/orbos/99-10-01.pdf"> 99-10-01</a> Portable Interceptors Working Draft -- Joint Revised diff --git a/TAO/docs/minimumTAO.html b/TAO/docs/minimumTAO.html index 8eca7208b10..66a65a3c243 100644 --- a/TAO/docs/minimumTAO.html +++ b/TAO/docs/minimumTAO.html @@ -44,31 +44,38 @@ ACE to support only those <a href = "http://www.cs.wustl.edu/~schmidt/ACE_wrappers/docs/ACE-subsets.html">components</a> that are required by TAO. Secondly, we <a href = "http://www.cs.wustl.edu/~schmidt/ACE_wrappers/TAO/TAO-INSTALL.html">configure</a> -TAO to only support the components specified by the <em>minimumCORBA</em> -specification. The following two tables show the footprint reduction -achieved. Note that the IDL Compiler column refers to the code -required to collaborate between the IDL compiler and the ORB, and not -to the code for the IDL compiler itself. - +TAO to only support the components specified by the +<em>minimumCORBA</em> specification. The following two tables show +the footprint reduction achieved. Note that the IDL Compiler column +refers to the code required to collaborate between the IDL compiler +and the ORB, and not to the code for the IDL compiler itself. <p> <hr> <p> -<em>Note: All measurement are for ACE 5.0 and TAO 1.0 using -egcs-2.91.60 on SunOS5.7<br> - -Make options used were: +Note: All measurement are for ACE 5.0 and TAO 1.0 using egcs-2.91.60 +on SunOS5.7<P> -<code> debug=0 optimize=1 static_libs_only=1 DEFFLAGS=-DACE_USE_RCSID=0 </code> <br> +The <a +href="http://www.cs.wustl.edu/~schmidt/ACE_wrappers/ACE-INSTALL.html#flags">make +flags</a> options used were: <P> -The above make options translate into: +<code> debug=0 optimize=1 static_libs_only=1 DEFFLAGS=-DACE_USE_RCSID=0 </code> <P> -(a) No debugging, -(b) Optimization is set to -O2, -(c) Static ACE and TAO libraries, and -(d) Use of RCS Ids is turned off. <br> +These options translate into:<P> +<UL> +<LI> No debugging +<LI> Optimization is set to -O2 +<LI> Static ACE and TAO libraries +<LI> Use of RCS Ids is turned off +</UL> +<p> -<p></em> +To build a TAO static library, if shared libraries are the default, +use <code>make static_libs_only=1</code> (make sure to do this for +ACE, as well). If you're using recent versions of GNU GCC, you can +use the <A HREF="../ACE-INSTALL.html#repo">-frepo</A> option, which +typically reduces the footprint by another 25 percent. <P> <p> <hr> diff --git a/TAO/docs/pluggable_protocols/index.html b/TAO/docs/pluggable_protocols/index.html index 754157fd840..fad4561a3c4 100644 --- a/TAO/docs/pluggable_protocols/index.html +++ b/TAO/docs/pluggable_protocols/index.html @@ -20,8 +20,12 @@ <P> <H1 ALIGN="CENTER">Implementing Pluggable Protocols for TAO</H1> -<P ALIGN="CENTER"><STRONG>Fred Kuhns, Douglas C. Schmidt, Carlos - O'Ryan, Ossama Othman, Bruce Trask</STRONG></P> +<P ALIGN="CENTER"><STRONG> +<A HREF="http://www.cs.wustl.edu/~fredk">Fred Kuhns</A>, +<A HREF="http://www.eng.uci.edu/~schmidt/">Douglas C. Schmidt</A>, +<A HREF="http://www.cs.wustl.edu/~coryan">Carlos O'Ryan</A>, +<A HREF="http://www.cs.wustl.edu/~othman/">Ossama Othman</A>, +and <A HREF="mailto:BTRASK@contactsystems.com">Bruce Trask</A></STRONG></P> <P ALIGN="CENTER"> @@ -29,9 +33,35 @@ Center for Distributed Object Computing<BR> Washington University at St.Louis </P> +<P><HR><P> +<H3>Overview</H3><P> + +To be an effective platform for performance-sensitive real-time and +embedded applications, off-the-shelf CORBA middleware must preserve +the communication-layer quality of service (QoS) properties of +applications end-to-end. However, the standard CORBA GIOP/IIOP +interoperability protocols are not well suited for applications that +cannot tolerate the message footprint size, latency, and jitter +associated with general-purpose messaging and transport protocols. It +is essential, therefore, to develop standard <EM>pluggable protocols +frameworks</em> that allow custom messaging and transport protocols to +be configured flexibly and used transparently by applications. +This document explains how to develop pluggable protocols using TAO's +pluggable protocols framework. <P> + +Here are some links that describe TAO's pluggable protocols framework, +though not how to implement one: <BLOCKQUOTE> +<A +HREF="../releasenotes/index.html#pp">http://www.cs.wustl.edu/~schmidt/ACE_wrappers/TAO/docs/releasenotes/index.html#pp</A><BR> + +<A HREF="http://www.cs.wustl.edu/~schmidt/PfHSN.ps.gz">http://www.cs.wustl.edu/~schmidt/PfHSN.ps.gz</A><BR> +<A +HREF="http://www.cs.wustl.edu/~schmidt/pluggable_protocols.ps.gz">http://www.cs.wustl.edu/~schmidt/pluggable_protocols.ps.gz</A> +</BLOCKQUOTE> + <P> -<BR><HR> -<!-- Table of Contents --> +<HR> +<H3>Table of Contents</H3><P> <UL> <LI><A NAME="TOC_SECTION100" HREF="#SECTION100">Overview of Implementation of Pluggable Protocols for TAO</A> <UL> @@ -189,7 +219,8 @@ For example, ACE wraps the <I>socket</I> API to create an <TT>ACE_INET_Addr</TT> protocol layer 4, aka <I>TP4</I>, should be implemented similarly. A TP4 implementation could have an <TT>ACE_TP4_Addr</TT>, <TT>ACE_TP4_Acceptor</TT>, <TT>ACE_TP4_Connector</TT> and an <TT>ACE_TP4_Stream</TT>. Any new implementation should retain the interface -provided by the base <TT>IPC_SAP</TT> classes in ACE.</LI> +provided by the base <TT>IPC_SAP</TT> classes in ACE.</LI> <P> + <LI>Once the above ACE <TT>IPC_SAP</TT> components have been implemented, creating the necessary TAO pluggable protocol components should be fairly easy. In fact, much of the code can be ``cut and pasted'' from existing TAO pluggable protocol @@ -2631,34 +2662,33 @@ TAO's existing pluggable protocols use those ACE classes/interfaces. As long as you use the same interface for your protocol as the interface for ace/ACE_SOCK* and tao/IIOP* then you shouldn't have much -of a problem.</BLOCKQUOTE> <P>Here are some links that describe -the pluggable protocols framework, though not how to implement one: -<BLOCKQUOTE> <A -HREF="../releasenotes/index.html#pp">http://www.cs.wustl.edu/~schmidt/ACE_wrappers/TAO/docs/releasenotes/index.html#pp</A><BR> - -<A HREF="http://www.cs.wustl.edu/~schmidt/PfHSN.ps.gz">http://www.cs.wustl.edu/~schmidt/PfHSN.ps.gz</A> -<A -HREF="http://www.cs.wustl.edu/~schmidt/pluggable_protocols.ps.gz">http://www.cs.wustl.edu/~schmidt/pluggable_protocols.ps.gz</A> -</BLOCKQUOTE> - -<P>Note also that the TAO files pluggable.* are important to review and understand as they contain -the abstract classes that form the common inteface for TAO's pluggable protocol framework. -<BR> -<P>Getting a full understanding on how IIOP was implemented (GIOP over TCP/IP) and also seeing -how provisions were made to add UIOP, was very helpful to adding my own protocol. -In understanding IIOP, I needed to review the section of the OMG CORBA spec on GIOP, -IIOP and Object references and see how this would apply to my protocol. -<BR> -<P>In my case, I added a transport layer that uses SCRAMNet (from Systran Corp) replicated shared memory hardware. This is actual physical memory cards located on two different machines. When a change is made to one memory then that change appears very quickly (very low latency here) in -the other memory. I decided that I would implement GIOP over SCRAMNet as this seemed -to be the simplest. With SCRAMNet, one could implement this transport layer into the TAO ORB -in a few different ways, GIOP over SCRAMNet, Environment-specific inter-ORB protocol (ESIOP) -or using collocation (since it is shared replicated memory). I have not done the latter two, only -GIOP over SCRAMNet just to get a proof of concept working. -<BR><P> -For a graphical representation of the extensions for the new SCRAMNet classes I have may a skeletal -Rose diagram showing (at this point) the inheritance relationships of the new and existing classes. +of a problem.</BLOCKQUOTE> <P>Note also that the TAO files pluggable.* +are important to review and understand as they contain the abstract +classes that form the common inteface for TAO's pluggable protocol +framework. <BR> <P>Getting a full understanding on how IIOP was +implemented (GIOP over TCP/IP) and also seeing how provisions were +made to add UIOP, was very helpful to adding my own protocol. In +understanding IIOP, I needed to review the section of the OMG CORBA +spec on GIOP, IIOP and Object references and see how this would apply +to my protocol. <BR> + +<P>In my case, I added a transport layer that uses SCRAMNet (from +Systran Corp) replicated shared memory hardware. This is actual +physical memory cards located on two different machines. When a +change is made to one memory then that change appears very quickly +(very low latency here) in the other memory. I decided that I would +implement GIOP over SCRAMNet as this seemed to be the simplest. With +SCRAMNet, one could implement this transport layer into the TAO ORB in +a few different ways, GIOP over SCRAMNet, Environment-specific +inter-ORB protocol (ESIOP) or using collocation (since it is shared +replicated memory). I have not done the latter two, only GIOP over +SCRAMNet just to get a proof of concept working. + +<BR><P> For a graphical representation of the extensions for the new +SCRAMNet classes I have may a skeletal Rose diagram showing (at this +point) the inheritance relationships of the new and existing classes. See (TBD) ftp site for this Rose diagram. + <BR><P> The new classes created were. <BR> @@ -3254,6 +3284,26 @@ H. Hueni, R. Johnson, and R. Engel, ``A Framework for Network Protocol F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal, <EM> Pattern-Oriented Software Architecture - A System of Patterns</EM>. <BR>Wiley and Sons, 1996. +<P></P><DT><A NAME="Schmidt:99x">6</A> +<DD> +Carlos O'Ryan, Fred Kuhns, Douglas C. Schmidt, Ossama Othman, and Jeff +Parsons, <A +HREF="http://www.cs.wustl.edu/~schmidt/pluggable_protocols.ps.gz"> The +Design and Performance of a Pluggable Protocols Framework for +Real-time Distributed Object Computing Middleware</A>, Proceedings of +the IFIP/ACM <A +HREF="://www.research.ibm.com/Middleware2000/">Middleware 2000</A> +Conference, Pallisades, New York, April 3-7, 2000. <P> + +<P></P><DT><A NAME="Schmidt:99c">7</A> <DD> Fred Kuhns, Carlos O'Ryan, +Douglas C. Schmidt, Ossama Othman, and Jeff Parsons, <A +HREF="http://www.cs.wustl.edu/~schmidt/PfHSN.ps.gz">The Design and +Performance of a Pluggable Protocols Framework for Object Request +Broker Middleware,</A> Proceedings of the <A +HREF="http://www.isi.edu/pfhsn99/call.html">IFIP Sixth International +Workshop on Protocols For High-Speed Networks (PfHSN '99)</A>, Salem, +MA, August 25--27, 1999. <P> + </DL> <P> @@ -3270,7 +3320,7 @@ examples of the Layers architecture. <ADDRESS><a href="mailto:othman@cs.wustl.edu">Ossama Othman</a></ADDRESS> <!-- Created: Tue Dec 14 16:53:58 CST 1999 --> <!-- hhmts start --> -Last modified: Sat Dec 18 14:39:35 CST 1999 +Last modified: Sun Dec 19 13:26:43 CST 1999 <!-- hhmts end --> </BODY> </HTML> |