diff options
Diffstat (limited to 'TAO/CIAO/docs/tutorial/Hello/README')
-rw-r--r-- | TAO/CIAO/docs/tutorial/Hello/README | 104 |
1 files changed, 0 insertions, 104 deletions
diff --git a/TAO/CIAO/docs/tutorial/Hello/README b/TAO/CIAO/docs/tutorial/Hello/README deleted file mode 100644 index 182f5e5baee..00000000000 --- a/TAO/CIAO/docs/tutorial/Hello/README +++ /dev/null @@ -1,104 +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_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 |