diff options
Diffstat (limited to 'TAO/CIAO/examples/handcrafted/Hello/README')
-rw-r--r-- | TAO/CIAO/examples/handcrafted/Hello/README | 131 |
1 files changed, 0 insertions, 131 deletions
diff --git a/TAO/CIAO/examples/handcrafted/Hello/README b/TAO/CIAO/examples/handcrafted/Hello/README deleted file mode 100644 index 84e837e673c..00000000000 --- a/TAO/CIAO/examples/handcrafted/Hello/README +++ /dev/null @@ -1,131 +0,0 @@ -// $Id$ - -This example showcases a component implementation in its simplest -form. The utmost purpose of this example is to demonstrate how easy -it is to implement a component and a system using CCM and to provide -ourselves an example implementation of how the CCIDL generated code -should look like. - -To implement a component, all you need to do is to define the -component, as in hello.idl. Then you have to define some aspects of -the component implementations using the CIDL definition, as we do here -with hello.cidl. And finally, the component implementor implement the -component and home executors according to the executor mapping. - - -User Defined Notes -Files ---------- --------------------------------------- -hello.idl Component and Home IDL definitions. - -hello.cidl Component and Home implementation definitions. - -hello_executors Executor implementations. - - -Handcrafted -Files Notes: They should relly be generated by some (C)IDL compiler ---------- --------------------------------------- -helloC.idl Equivalent IDL definitions. This file is used for double - checking the correctness of the generated code. - -helloE.idl Executor equivalent IDL definitions. Since TAO_IDL still - doesn't generate code for the exeutor definition, we manually - create define the executor mapping in this file and compile it - to get the executor mapping code. - -hello_servants Generic servant implementation for interfaces which should be - generated from hello.cidl using CCIDL (in the future. :-) - - -We also generate 3 libraries and 2 executables in this example. They -may look perplexing at the first glance, but when we have full CCM -support, all but one library and one executable will need to be -generated manually. The rest should be generated thru the tools provided by CIAO. -Below is the list of libraries and executable in this example: - -Files Notes ---------- --------------------------------------- -hello_stub A library contains the client stub implementation. - Client programs can link to this library instead of including - the stub implementation directly in the executable. The real - purpose of putting the stub code in a separate library is - to avoid code duplication when various interdependent components - are installed into one component server (where they will need to - interact with other components using the collocation code in the - stub library.) - -hello_servants This library contains the server side skeletons and CIDL generated - (currently handcrafted) servant implementation for the component - and home defined in CIDL. - -server This is a minimalist's implementaion of a simple "generic server". - We should be able to generalize the example into a "component server" - in CIAO which will support component deployment and server configuration - thru some property files. - -client A simple client program that access the component. - -hello_executors This library contains the CIDL generated executor definitions and the - actual component and home implementations (business logic.) It it not - clear to me whether we should package this file together with hello_servants - library as most of the stuff included in these libraries are generated - by CIDL compiler. We will see in the future. - - -** Here's a more detailed break down of the process. - -1. Define the component, as in hello.idl which defines the client-view - of the component. This view is equivalent to the interfaces - defined in helloC.idl (for component unawared client.) - -2. Define how the component should be implemented, as in hello.cidl. - CIDL compiler should generate the executor definitions as in - helloE.idl. - -3. CIDL also generate the component-specific skeleton (container?) - implementations as in HelloSkel.xxx. These skeleton - implementations determine how the component should be activated, - how to manage the servant lifecycle, their OID and such. - -4. If a component implementation needs to support more advanced - features, such as transactional behavior, the developer needs to - "extend" the executor definitions by inheriting from other - components callback interfaces, such as SessionSynchronization. - We don't have an example here because we want to keep this example - as simple as possible. - -5. Component executors are implemention by implementing the desired - executor definition. - -6. Packaging and deploying the component.... This example only shows - how to deploy a single component implementation. The servant - skeletons can either be packaged with the component implementation - in a single DLL, or be packaged in a separate DLL which, in turn, - can be deployed with the component implementation together as an - assembly, or be put in some sort of repository. - - -How to Run: ----------- - -1. Start the Name Service and store the name service IOR in some file - <w:\ior>. - - Naming_Service -o w:\ior - -2. Start the Component servier with the config file and the - NameService IOR we stored in the previous step: - - w:\ACE_wrappers\bin\Simple_Component_Server -ORBInitRef \ - NameService=file://w:\ior -i config -o ior - - The component server we use here will create the HomeFinder IOR. - Store the IOR in a file <ior>. - -3. Finally, start the client program as: - - client -ORBInitRef HomeFinder=file://ior - - The client will try to use all thru operations to find the - HelloHome interface.
\ No newline at end of file |