
  Client ID Technical Notes:

  This section reviews the architecture of the application and is not
  required reading for someone who wish's to simply use the Client
  Information program.


 Client->Server to the MAX with the Work place shell
 ----------------------------------------------
 The New OS/2 2.0 Work place shell Application Architecture
 -----------------------------------------

 Out with the Old...
 -------------------

   Harnessing the true power of OS/2 and its work place shell requires
 using a new OS/2 2.0 style of application architecture.  To understand what
 this new approach to application design consist of, it is important to 
 understand the most commonly used style of Architecture.

   For lack of a better word I will refer to this old style as "The Monolith".
 This is the architectural style most common in MicroSoft Windows and 
 OS/2 1.x applications. It is easily recognizable by the following traits:

    - A few Monolithic Process's
    - Windows and Dialogs grouped in model Hierarchies in a single process.
    - Highly integrated/specialized functions(Lack of modularity & reuse).

 The problems and limitations imposed by this monolithic windows style
 of Architecture can include:

 1) Performance: Since you must load most of the code to run the
    entire "Monolith just to do one dialog, performance for the end user
    is often considered very bad.  The larger the application gets the worst
    the performance gets with long load times and poor run time performance.
    Since everything is loaded into memory at once, your application can
    become a real "Resource Hog" by swallowing large amounts of memory and
    generating a large swap file.  In extreme cases, with poorly organized
    code, thrashing will occur.  Thrashing is defined as a state were the
    operating system is forced to constantly swap code and data in and
    out of memory while the application is running. (Is your hard disk light
    constantly "ON"? If so then OS/2 is thrashing ).

 2) Navigation: The developers must build thier own navigational hierarchy
    into the "Monolith".  This application specific navigation often adds 
    an extra learning burden on the end user as well as adding to the
    development cost.  This development cost is incured with the
    development of the code that performs the navigation logic.  Typically
    this navigation logic is implemented in a way that restricts the user to
    only one copy of a dialog at once (Non-re-entrant model dialogue).

 3) Flexibility: Since the application is highly integrated into a single
    monolithic process, it is almost always necessary to have all of
    the code of the application in one version of a language or toolset.
    Thus updating the development tools will often require translating and
    updating the ENTIRE application.  If also becomes harder to implement the
    strategy of incrementally delivering parts of the application to the user
    before all of the application is completed.

   All of this adds up to a higher development cost, a longer development
   cycle and a less than satisfied end user.


 In with the New...
 ------------------

 The New OS/2 2.x architecture style is basically centered around 
 multi-processing and the work place shell (OS/2 2.0 Desk Top).  The core
 of this new architectural approach is not new but it has been significantly 
 enhance by the power of the work place shell and OS/2's multi-tasking
 capabilities.  Essentially each individual business function in the application
 is  broken up into its own small standalone application.  These miniture
 "Applications" (sometimes refered to as an "applet" or little application) are
 organized into a group of program and data objects on the workplace shell. 
 Each applet may consist of only a single window or it could consist of a
 small hierchy of windows/dialogues.  Each standalone process can "Produce"
 data objects or communicate with other applets with DDE, shared memory
 or any of the other normal OS/2 interprocess communication methods.
 
 This new "work place shell" compliant style of architecture is unique to OS/2
 2.0 & 2.1 and has a number of powerful advantages over the "Monolith".

 This new style of architecture is easily recognizable by the following trait's:

 1) Multiple process's: Many small programs ("Applets") each representing 
    an single indivisable function.  These applets are represented
    separately as icons on the work place shell and, with some
    limitations, can be invoked in any order.  Usually multiple copies of an
    applet can be run at the same time.

 2) Inter-process Communications: Each applet is started as a separate
    OS/2 process and actively exchanges data with other applets using normal
    OS/2 inter-process communications techniques.  This techniques could
    included DDE, shared memory, Inter-process PM messaging, work place
    shell data objects and data files.  This may take the form of a 
    traditional client sever model with a "Client" applet requesting 
    information or an action from a "sever" process.

 3) Workplace shell utilization: the work place shell is used to represent the
    hierarchy of business functions and data objects that make up the
    application.  Each business function may consist of a hierarch of dialogs
    but the hierarchy between the major components is represented on the
    workplace shell.  Thus the user navigates through the application by
    manipulating work place shell folders, program Icons, data objects and
    devices rather than working with an application specific navigation logic.

 Some of these triats should sound familiar to any developer who has built
 a Client-Server style of application.  The new 

 Benefits of New Approach
 ------------------------

 The benefits of the new architectural style are substantial.  To the end user
 it translates into a faster application with a more capable and flexible
 user interface.  To the software developer it translates into less time
 spent organizing, coding and maintaining an application. To the project leader
 and his management it means lower cost and an open door to interitive
 development, incremental deliver, and to using new software tools/techniques
 when they become available.

 Benefits to the End User:

 1) Performance: Faster LOAD and RUN TIMES. When loading a particular
    "applet", only the code required for that particular applet is loaded.
    Unlike the "monolithic" approach were all of the code for the entire
    application has to be loaded before the user can do even a single action,
    only the code and data for that specific function is loaded.  In addition
    to faster load times, less system resources ( memory, window handles etc.)
    are used by the smaller foot print of the applet.  This, in combination
    with the naturally "tighter" code of a smaller program can lead to
    faster run times and a substantially reduced chance of "thrashing"
    or running out of system resources. (No more nasty "swapper.dat" disk
    full messages!).

 2) Customization: Since the base part of the application is now using
    the work place shell the user can easily customize his application by
    reorganizing the folders, Program Icons and data objects to his own
    liking. The developer can also provide several ways to install the
    application based on the type of user or skill level.  By using IBM's
    Restricted work place shell product or by using SOM this customization
    can be limited or enhanced as required. This type of customization
    could also be used as a basis of the applications design by utilizing
    templates to provide the user with a selection of objects, "Actions"
    (programs) and devices to create.  This does however require a high
    level of sophistication and knowledge from the user.


 Benefits to the Developer:
 --------------------------

 The benefits to the software developer are just as important as the
 advantages to the end user.

 Benefits to the Software Developer:

 1) Easier organization of development teams.  With the breakup of a
    monolithic application into smaller, stand alone "Applets", the design,
    implementation and testing of these "Applets" can be isolated from
    each other.  This natural breakup can simplify the organization of
    a development project by leading to a naturally clear separation of
    the major business functions in the application.  Thus the individual
    business functions can be designed and implemented independently by
    different developers with only minimal amount of time spent interacting
    and coordinating with the developer (s) working on other parts of
    the application.

 2) Less coding.  The work place shell is used as a "Replacement" for the
    hierarchy of windows, Menus and buttons previously used to organize
    interaction with the different business functions.  This means less
    development effort as the code for this "Hierarch" does not have to be
    designed and written.  Usually this also equates to a better interface
    as the developer can now use the inherent functions of the Work Place
    Shell, like drag/drop, data objects printer devices etc.

 3) Leverage off of future Improvements of the work place shell.  As
    improvements are made to the work place shell and the SOM language (system
    object model ) the work place shell is written it, you can capitalize on
    these improvements with only minimal changes, and possible no changes at!
    IBM has stated the strategic important of SOM and has made a long term
    commitment to significant enhancement in the future releases of OS/2
    with SOM/2 and DSOM (distributed SOM).  As OS/2 improves so will your
    application, this in turn will increase the longevity of your application.

 4) Easier to stage Incremental deliver and testing.  Since the application
    now consists of a series of discrete applets, each piece can be tested
    individually with system testing and integration limited to the applets
    interface to the rest of the system.  Each of these applets can also
    be delivered as it is completed, rather than waiting for the whole
    system to be completed before delivering it.  This role out strategy is
    called INCREMENTAL DELIVERY.

 5) Easier Integration of off the shelf packages.  Easily integrate a Spread
    sheet, word processor or other "Off the Shelf" packages as an integral
    part of your application.

 6) Use Multiple tools sets and different versions of the same tools.  With
    each applet organized as a discrete process, each one can be developed
    with a different toolset or different version of the same toolset. One
    applet can be developed in SmallTalk, another in AM, a third in C & PM
    16 bit, a fourth in 32 bit.  You no longer have to develop the entire
    application in one toolset or one language nor worry about having to
    upgrade the entire application just to make use of the latest toolset.


 Conclusion
 ----------

 1) You are not a Windows Developer so don't act like one!  Use the OS/2
    Desktop the way it is meant to be used.

 2) Use the WPS as the core of your application.  If you haven't yet, or
    don't wish to develop SOM expertise use DipWriter or a similar tool
    to maximise your Desktop interface.

 3) Architect your applications to be open to other tools and applications
    and save your self a lot of work in the process.


 IMPLEMENTATION NOTES:
 ---------------------

 How ClientID works with the WorkPlace Shell.
 --------------------------------------------

 The two executable files, ClientID.exe and Cnotes.exe are single window
 "applets" that have a very simple design. The Client ID "applet" (small
 Application) can take a data file name as a parameter when it is started
 and save the client data to a file when it is closed.

 When the client data is saved the program first creates the directory
 "\CLIENTID\CLIENTS\XXXXXXXX" were XXXXXXXX is the last name of the
 client.  The client data is then written out to the file "ID.DAT" in that
 directory.  When a data object is drag and dropped on the ClientID
 program the Work Place shell starts ClientID with the file name that
 the data object represents as a parameter.  You can drag and drop a "Folder"
 object (Directory) onto either the ClientID or Cnotes programs rather than
 the specific file objects because the programs check the file name passed
 in and if the name is that of a directory it will add its appropriate
 data file name.  Thus you can drop a Clients "Folder" object on two
 different programs and have two different data files created.

 The Data Folder and Objects created by ClientID are in reality nothing more
 than normal directory's and files.  These files are however created in
 the directory "\CLIENTID\CLIENTS".  This directory has been created by
 DipWriter as a "Shadow" work place shell object.  Thus any sub directories
 or files created in this directory will be "Shadowed" onto the work place
 shell as data objects.

