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.