home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: OtherApp / OtherApp.zip / client.zip / ARCH.TXT next >
Text File  |  1993-08-17  |  13KB  |  250 lines
  1.  
  2.   Client ID Technical Notes:
  3.  
  4.   This section reviews the architecture of the application and is not
  5.   required reading for someone who wish's to simply use the Client
  6.   Information program.
  7.  
  8.  
  9.  Client->Server to the MAX with the Work place shell
  10.  ----------------------------------------------
  11.  The New OS/2 2.0 Work place shell Application Architecture
  12.  -----------------------------------------
  13.  
  14.  Out with the Old...
  15.  -------------------
  16.  
  17.    Harnessing the true power of OS/2 and its work place shell requires
  18.  using a new OS/2 2.0 style of application architecture.  To understand what
  19.  this new approach to application design consist of, it is important to 
  20.  understand the most commonly used style of Architecture.
  21.  
  22.    For lack of a better word I will refer to this old style as "The Monolith".
  23.  This is the architectural style most common in MicroSoft Windows and 
  24.  OS/2 1.x applications. It is easily recognizable by the following traits:
  25.  
  26.     - A few Monolithic Process's
  27.     - Windows and Dialogs grouped in model Hierarchies in a single process.
  28.     - Highly integrated/specialized functions(Lack of modularity & reuse).
  29.  
  30.  The problems and limitations imposed by this monolithic windows style
  31.  of Architecture can include:
  32.  
  33.  1) Performance: Since you must load most of the code to run the
  34.     entire "Monolith just to do one dialog, performance for the end user
  35.     is often considered very bad.  The larger the application gets the worst
  36.     the performance gets with long load times and poor run time performance.
  37.     Since everything is loaded into memory at once, your application can
  38.     become a real "Resource Hog" by swallowing large amounts of memory and
  39.     generating a large swap file.  In extreme cases, with poorly organized
  40.     code, thrashing will occur.  Thrashing is defined as a state were the
  41.     operating system is forced to constantly swap code and data in and
  42.     out of memory while the application is running. (Is your hard disk light
  43.     constantly "ON"? If so then OS/2 is thrashing ).
  44.  
  45.  2) Navigation: The developers must build thier own navigational hierarchy
  46.     into the "Monolith".  This application specific navigation often adds 
  47.     an extra learning burden on the end user as well as adding to the
  48.     development cost.  This development cost is incured with the
  49.     development of the code that performs the navigation logic.  Typically
  50.     this navigation logic is implemented in a way that restricts the user to
  51.     only one copy of a dialog at once (Non-re-entrant model dialogue).
  52.  
  53.  3) Flexibility: Since the application is highly integrated into a single
  54.     monolithic process, it is almost always necessary to have all of
  55.     the code of the application in one version of a language or toolset.
  56.     Thus updating the development tools will often require translating and
  57.     updating the ENTIRE application.  If also becomes harder to implement the
  58.     strategy of incrementally delivering parts of the application to the user
  59.     before all of the application is completed.
  60.  
  61.    All of this adds up to a higher development cost, a longer development
  62.    cycle and a less than satisfied end user.
  63.  
  64.  
  65.  In with the New...
  66.  ------------------
  67.  
  68.  The New OS/2 2.x architecture style is basically centered around 
  69.  multi-processing and the work place shell (OS/2 2.0 Desk Top).  The core
  70.  of this new architectural approach is not new but it has been significantly 
  71.  enhance by the power of the work place shell and OS/2's multi-tasking
  72.  capabilities.  Essentially each individual business function in the application
  73.  is  broken up into its own small standalone application.  These miniture
  74.  "Applications" (sometimes refered to as an "applet" or little application) are
  75.  organized into a group of program and data objects on the workplace shell. 
  76.  Each applet may consist of only a single window or it could consist of a
  77.  small hierchy of windows/dialogues.  Each standalone process can "Produce"
  78.  data objects or communicate with other applets with DDE, shared memory
  79.  or any of the other normal OS/2 interprocess communication methods.
  80.  
  81.  This new "work place shell" compliant style of architecture is unique to OS/2
  82.  2.0 & 2.1 and has a number of powerful advantages over the "Monolith".
  83.  
  84.  This new style of architecture is easily recognizable by the following trait's:
  85.  
  86.  1) Multiple process's: Many small programs ("Applets") each representing 
  87.     an single indivisable function.  These applets are represented
  88.     separately as icons on the work place shell and, with some
  89.     limitations, can be invoked in any order.  Usually multiple copies of an
  90.     applet can be run at the same time.
  91.  
  92.  2) Inter-process Communications: Each applet is started as a separate
  93.     OS/2 process and actively exchanges data with other applets using normal
  94.     OS/2 inter-process communications techniques.  This techniques could
  95.     included DDE, shared memory, Inter-process PM messaging, work place
  96.     shell data objects and data files.  This may take the form of a 
  97.     traditional client sever model with a "Client" applet requesting 
  98.     information or an action from a "sever" process.
  99.  
  100.  3) Workplace shell utilization: the work place shell is used to represent the
  101.     hierarchy of business functions and data objects that make up the
  102.     application.  Each business function may consist of a hierarch of dialogs
  103.     but the hierarchy between the major components is represented on the
  104.     workplace shell.  Thus the user navigates through the application by
  105.     manipulating work place shell folders, program Icons, data objects and
  106.     devices rather than working with an application specific navigation logic.
  107.  
  108.  Some of these triats should sound familiar to any developer who has built
  109.  a Client-Server style of application.  The new 
  110.  
  111.  Benefits of New Approach
  112.  ------------------------
  113.  
  114.  The benefits of the new architectural style are substantial.  To the end user
  115.  it translates into a faster application with a more capable and flexible
  116.  user interface.  To the software developer it translates into less time
  117.  spent organizing, coding and maintaining an application. To the project leader
  118.  and his management it means lower cost and an open door to interitive
  119.  development, incremental deliver, and to using new software tools/techniques
  120.  when they become available.
  121.  
  122.  Benefits to the End User:
  123.  
  124.  1) Performance: Faster LOAD and RUN TIMES. When loading a particular
  125.     "applet", only the code required for that particular applet is loaded.
  126.     Unlike the "monolithic" approach were all of the code for the entire
  127.     application has to be loaded before the user can do even a single action,
  128.     only the code and data for that specific function is loaded.  In addition
  129.     to faster load times, less system resources ( memory, window handles etc.)
  130.     are used by the smaller foot print of the applet.  This, in combination
  131.     with the naturally "tighter" code of a smaller program can lead to
  132.     faster run times and a substantially reduced chance of "thrashing"
  133.     or running out of system resources. (No more nasty "swapper.dat" disk
  134.     full messages!).
  135.  
  136.  2) Customization: Since the base part of the application is now using
  137.     the work place shell the user can easily customize his application by
  138.     reorganizing the folders, Program Icons and data objects to his own
  139.     liking. The developer can also provide several ways to install the
  140.     application based on the type of user or skill level.  By using IBM's
  141.     Restricted work place shell product or by using SOM this customization
  142.     can be limited or enhanced as required. This type of customization
  143.     could also be used as a basis of the applications design by utilizing
  144.     templates to provide the user with a selection of objects, "Actions"
  145.     (programs) and devices to create.  This does however require a high
  146.     level of sophistication and knowledge from the user.
  147.  
  148.  
  149.  Benefits to the Developer:
  150.  --------------------------
  151.  
  152.  The benefits to the software developer are just as important as the
  153.  advantages to the end user.
  154.  
  155.  Benefits to the Software Developer:
  156.  
  157.  1) Easier organization of development teams.  With the breakup of a
  158.     monolithic application into smaller, stand alone "Applets", the design,
  159.     implementation and testing of these "Applets" can be isolated from
  160.     each other.  This natural breakup can simplify the organization of
  161.     a development project by leading to a naturally clear separation of
  162.     the major business functions in the application.  Thus the individual
  163.     business functions can be designed and implemented independently by
  164.     different developers with only minimal amount of time spent interacting
  165.     and coordinating with the developer (s) working on other parts of
  166.     the application.
  167.  
  168.  2) Less coding.  The work place shell is used as a "Replacement" for the
  169.     hierarchy of windows, Menus and buttons previously used to organize
  170.     interaction with the different business functions.  This means less
  171.     development effort as the code for this "Hierarch" does not have to be
  172.     designed and written.  Usually this also equates to a better interface
  173.     as the developer can now use the inherent functions of the Work Place
  174.     Shell, like drag/drop, data objects printer devices etc.
  175.  
  176.  3) Leverage off of future Improvements of the work place shell.  As
  177.     improvements are made to the work place shell and the SOM language (system
  178.     object model ) the work place shell is written it, you can capitalize on
  179.     these improvements with only minimal changes, and possible no changes at!
  180.     IBM has stated the strategic important of SOM and has made a long term
  181.     commitment to significant enhancement in the future releases of OS/2
  182.     with SOM/2 and DSOM (distributed SOM).  As OS/2 improves so will your
  183.     application, this in turn will increase the longevity of your application.
  184.  
  185.  4) Easier to stage Incremental deliver and testing.  Since the application
  186.     now consists of a series of discrete applets, each piece can be tested
  187.     individually with system testing and integration limited to the applets
  188.     interface to the rest of the system.  Each of these applets can also
  189.     be delivered as it is completed, rather than waiting for the whole
  190.     system to be completed before delivering it.  This role out strategy is
  191.     called INCREMENTAL DELIVERY.
  192.  
  193.  5) Easier Integration of off the shelf packages.  Easily integrate a Spread
  194.     sheet, word processor or other "Off the Shelf" packages as an integral
  195.     part of your application.
  196.  
  197.  6) Use Multiple tools sets and different versions of the same tools.  With
  198.     each applet organized as a discrete process, each one can be developed
  199.     with a different toolset or different version of the same toolset. One
  200.     applet can be developed in SmallTalk, another in AM, a third in C & PM
  201.     16 bit, a fourth in 32 bit.  You no longer have to develop the entire
  202.     application in one toolset or one language nor worry about having to
  203.     upgrade the entire application just to make use of the latest toolset.
  204.  
  205.  
  206.  Conclusion
  207.  ----------
  208.  
  209.  1) You are not a Windows Developer so don't act like one!  Use the OS/2
  210.     Desktop the way it is meant to be used.
  211.  
  212.  2) Use the WPS as the core of your application.  If you haven't yet, or
  213.     don't wish to develop SOM expertise use DipWriter or a similar tool
  214.     to maximise your Desktop interface.
  215.  
  216.  3) Architect your applications to be open to other tools and applications
  217.     and save your self a lot of work in the process.
  218.  
  219.  
  220.  IMPLEMENTATION NOTES:
  221.  ---------------------
  222.  
  223.  How ClientID works with the WorkPlace Shell.
  224.  --------------------------------------------
  225.  
  226.  The two executable files, ClientID.exe and Cnotes.exe are single window
  227.  "applets" that have a very simple design. The Client ID "applet" (small
  228.  Application) can take a data file name as a parameter when it is started
  229.  and save the client data to a file when it is closed.
  230.  
  231.  When the client data is saved the program first creates the directory
  232.  "\CLIENTID\CLIENTS\XXXXXXXX" were XXXXXXXX is the last name of the
  233.  client.  The client data is then written out to the file "ID.DAT" in that
  234.  directory.  When a data object is drag and dropped on the ClientID
  235.  program the Work Place shell starts ClientID with the file name that
  236.  the data object represents as a parameter.  You can drag and drop a "Folder"
  237.  object (Directory) onto either the ClientID or Cnotes programs rather than
  238.  the specific file objects because the programs check the file name passed
  239.  in and if the name is that of a directory it will add its appropriate
  240.  data file name.  Thus you can drop a Clients "Folder" object on two
  241.  different programs and have two different data files created.
  242.  
  243.  The Data Folder and Objects created by ClientID are in reality nothing more
  244.  than normal directory's and files.  These files are however created in
  245.  the directory "\CLIENTID\CLIENTS".  This directory has been created by
  246.  DipWriter as a "Shadow" work place shell object.  Thus any sub directories
  247.  or files created in this directory will be "Shadowed" onto the work place
  248.  shell as data objects.
  249.  
  250.