diff options
Diffstat (limited to 'TAO/CIAO/docs/tutorial/Hello/README')
| -rw-r--r-- | TAO/CIAO/docs/tutorial/Hello/README | 104 |
1 files changed, 104 insertions, 0 deletions
diff --git a/TAO/CIAO/docs/tutorial/Hello/README b/TAO/CIAO/docs/tutorial/Hello/README new file mode 100644 index 00000000000..182f5e5baee --- /dev/null +++ b/TAO/CIAO/docs/tutorial/Hello/README @@ -0,0 +1,104 @@ +// $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_exec Executor implementations. + + +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_svant 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_exec 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: +---------- + +Run with + + run_test.pl to start the test using CIAO_Daemon and ComponentServer + +or + + run_simple_test.pl to start the test using Simple_Component_Server + Note: I am having trouble with the simple component server.
\ No newline at end of file |