Presented by Elizabeth M. Parker and Brian Randell
Elizabeth M. Parker is a Product Manager in the Developer Division for the Microsoft® Corporation. Previously, she was a Senior Consultant with Ernst & Young LLP. She is Microsoft Certified in Visual Basic® Development, version 3.0. She has five years of development experience utilizing Visual Basic, FoxPro®, and Microsoft Access. Her development experience includes sales force automation, human resources, multi-unit retail and general business software. She has worked with small and large organizations to design and implement custom business solutions.
Brian Randell is a Senior Software Engineer with over nine years of experience developing vertical applications. His areas of expertise include Microsoft Access and Visual Basic as well as Hewlett-Packard Image 3000 databases. He has worked extensively with small and large organizations implementing single user applications to multi-site mail enabled WAN systems. Brian is currently managing M1 Software's training operation. Brian is Microsoft Certified in Access 2.0 and Windows NT® Server and was a technical contributor to the Microsoft Access 95 Certification Exam.
Niels Hanson is a Senior Software Engineer with over five years of experience in developing custom software solutions. Niels has extensive experience with Microsoft Visual Basic as well as C/C++. Niels is currently the lead on a large team development effort for a multi-national merchandising firm using Visual Basic 4.0, Exchange, and SQL Server 6.0. Niels is Microsoft Certified in Visual Basic 3.0 Application Development. Niels' areas of expertise include RAS, MAPI, and OLE Custom controls.
M1 Software is a Santa Monica based Solution Provider specializing in Access, Visual Basic, SQL Server, and the Internet. M1 Software is has been providing custom solutions since 1989 to Fortune 1000 companies nationwide. With a full staff of software engineers and a complete multimedia department, M1 Software provides custom training, vertical applications, and corporate development programs to diverse clientele.
M1 Software
1119 Colorado Blvd.
Suite 112
Santa Monica, CA 91401
310.395.7121
www.m1soft.com
Developing large scale business solutions is a challenge to many today. As the technology race continues, ease of maintaining and manipulating information is a competitive advantage for organizations. Re-engineering of legacy systems and development and automation of processes are what many organizations are investigating. However, understanding the issues for a successful development and deployment environment can remain a mystery or become somewhat overwhelming to the decision makers.
This presentation is going to examine those issues. Visual Basic will be utilized as a technical example. These points will be illustrated by technical examples, wrapping up with questions to ask as you move foreword in your development effort.
The following are pieces from various documents credited at the bottom which provide in-depth information about the subject matter in the presentation:
Accelerated Systems Development (ASD) was developed as an alternative to the phase sequential solution development paradigm by Ernst & Young LLP. The IS community was process of its record of on-time, on-budget, on specification system delivery. At the same time, the client community felt that the IS department took too long, cost too much, and didn't deliver usable systems. Careful examination reveled that both parties were correct.
ASD is an improvement process. The ASD process utilizes three methodologies: organizational effectiveness (OE), information engineering (IE), and enterprise engineering (EE). Each of these three methodologies contributes a different aspect to the overall task structure. IE brings the tasks relevant to information systems development. OE beings the tasks relevant to human development, and EE brings the tasks relevant to discovery and innovation.
The ASD process is focused on the delivery of an adequate solution to a business problem in the most compressed time frame possible. There is an inherent belief that the quality of a solution is defined by the solution's fit at the time of delivery. To achieve that quality objective, which is the only ASD objective, the process focuses on being adaptive to the human aspects of solution development. ASD incorporates the following concepts:
The ASD process is represented as a set of six phases. Each phase has a specific purpose.
The ASD process is focused and controlled through the application of evolution completeness and correctness criteria. As a result, ASD can be adapted to fit any tool or technique set provided the appropriate criteria is met. The true goal of ASD is to produce an adequate, quality solution in time to meet the business need. The only realistic way to achieve that goal is through motivated people operating as a team, that understand and focus on the business need. If that is achieved, inspired results will follow.
In the beginning there was nothing! Not true for most projects/programs. Normally there is a great deal of confusion and a ton of information: only 10% of which is relevant. The first step in any project is to get organized because there won't be time later!
The primary deliverable of the proposal phase is a documented (to me the documentation is not important; it's the agreed understanding and convergence of ideas that is important during this part of the life cycle; if it helps the team to write some of that down, by all means have at it, but don't not think that because is written down that people agree or have a common understanding) understanding of the proposed project or program. The understanding should include scope, roles, responsibilities, timetables, prototypes and any models. Every organization has its own style of qualifying and establishing projects and programs. Project Charters effectively communicate the pertinent information concerning such endeavors, and this information is vital to obtaining organizational support. Don't underestimate the importance of expectation setting. That is a reason to do some proposal work even if everything seems perfect on the surface.
Furthermore communicating this information in Microsoft Project is a simple and effective medium. It also establishes timetables and ownership not only for management, but development as well.
The solution definition phase focuses on producing a defined solution to a business problem or need, to an adequate level of completion. The success in meeting that objective is measured by the ability of the project team to quantitatively and qualitatively describe the components and their interactions which must exist for the business problem or opportunity to be adequately addressed. In simple terms, the team needs to know what must be done to meet the business needs.
The primary vehicle used by the team to achieve the objective is a conceptual application model (CAM). The CAM is a physical model of the solution to the business problem. The CAM focuses on the proposed business process and the physical prototype of what the application(s) supporting that process might look like and act. It is through the refinement of the physical prototype that the requirements and specifications of the proposed solutions are proposed and agreed to. THE PROTOTYPE IS THE COMMUNICATION VEHICLE BETWEEN THE CUSTOMER AND THE SERVICER.
Visual Basic is an effective prototyping tool. Many times the first iteration of an application is the prototype, thus it makes perfect sense to develop the prototype in the same development language. Visual Basic Forms used in prototyping can be used immediately in the development environment. Granted, the code in a prototype may not meet the coding standards for the development environment, but it is a good start in the process.
Once the conceptual model has reached an adequate level of completion, then the strategy and path forward for the remainder of the project(s) is developed. The technical information is gathered into a central source called the solution definition report,, and the project management information is gathered into the initial project charter(s).
Solution Hub can be viewed as either the design portion of the project or the application infrastructure portion of the project depending on your point of view. It in fact addresses both aspects. There are six stages in all and three of those stages are distinct to Solution Hub. Each of the distinct stages can be exercised independently of the other two.
The first distinct stage focuses on designing and building the development and production databases. The databases are logically and physically designed and developed prior to actual database allocation. In addition, utilities and database support procedures are designed and developed to support the resulting physical databases.
The second distinct stage, Reusable Component Development, focused on components that cross application boundaries. These components are typically housed in a shareable library and are designed to be more generic. During this stage, the identified shareable components are either developed or enhanced if an existing component is used. In addition, the needed work is done to set up any class libraries or hierarchies that will enhance the productivity during full development.
The third distinct stage, Reusable Application Component Development, focuses on the components that are shareable within the application. These components (e.g., a customer look up window) are shared among the application fragments within the application, but have limited value outside the context of the application.
The second and third distinct stages follow a very similar process workflow but operate on different objects and have a slightly different audience. All three stages are executed, to varying degrees, with the intention of enhancing the productivity and speed of the later timebox development.
The timebox is where all of the efforts from previous phases come together. The intent is to assemble all of the components required to satisfy the timebox objective, integrate those components, and validate that the assembled fragments work to the satisfaction of the targeted user community.
The initial effort of the timebox phase is to ascertain what is to be accomplished during the timebox. A significant period of time may have elapsed between development planning where the timeboxes were planned and the actual start of the timebox. Therefore, expend some effort to find out what may have changed in the interim. Identify those changes and obtain any additional information needed to proceed. As a result, it is possible that some of the efforts typically done in the solution definition phase will need to be redone to provide a solid starting point for the timebox.
Another area of concern is reusability. Each timebox may contribute to the library of reusable components. At the beginning of each timebox, the use of and contribution to reusability needs to be revisited with the results dialed into the timebox plan. Also, review carefully any database changes which may have occurred since the completion of the solution definition phase. If changes have occurred, then some of the technical assumptions of the solution prototype need to be revisited.
Once the preparation is complete, follow the plan in evolving the components and fragments over the number of iterations recommended. Normally use three to five iterations. During each iteration, enhance the fragments and components from both technical and functional perspectives. Integrate those enhanced fragments and components for review and test them to ensure they do what is needed. Review the results with the designated user representatives to ensure the evolving applications conforms to the user community's expectations and needs.
Evaluate the results of the review, adjust the timebox plan accordingly and repeat the iteration cycle. Repeat this cycle until the components and fragments are accepted by the user community as meeting their needs. The Information Systems representatives also assure that the relevant application meets the needs of the IS community and the fragments and components are available for the formal implementation.
At the completion of the timebox, compare the results to the expectations and note any differences. Of particular concern is any changes in scope or design. Communicate those to succeeding timeboxes to be included in their startup and preparation to ensure all of the timeboxes are coordinated to an overall goal.
What can you say about implementation? It's the same as in other development approaches: Establish the production environment, implement the new user and IS procedures, and upon management approval, move the new system and concerted data into production. During the transition period, monitor and tune the new system and procedures. At the end of this period, finalize the procedure manuals and training programs. Archive the old system and phase it out.
Establish the maintenance testing environment and monitor the system performance and realization of benefits. Develop and have management approve the Evolution Plan that defines the continuing development of the system during the next planning horizon.
Data Conversion is the same all over. Convert existing manual and automated data into the format required by the new application. This conversion is done using the data conversion procedures.
Establish the data conversion environment, train the data conversion team, and prepare any required source data documents. Validate the results and check the integrity of the data after each step of the process.
The infrastructure development phase focuses on planning, designing, and building the components needed to transition the current environment to the future environment required by the application being developed. Also address enabling components such as communication networks.
This phase describes the processes for developing support material for the new application (e.g. user procedures and a training program). Most of the stages that make up this process are optional. The circumstances surrounding the application being developed will dictate which of these stages are required and how much time should be spent on each. Some of the factors that affect which process in this phase that you might do are:
Tech·Ed 1995. Written by Elizabeth Parker
Beware, this can be a religious issue for some developers. Style and ego come into play when discussing coding guidelines, otherwise known as standards. The term coding guidelines is a positive term encouraging input. Whereas, standards says "set in stone." There are certain areas of coding which can be freeform in a large development effort. However, for code maintainability some areas must have some hard and fast rules.
Make sure to include the development team in this process as much as possible. A keeper of the guidelines should be assigned. They are in change of the document with the specifics. This document can be placed into Visual SourceSafe for easy reference and help in bringing new developers up to speed. In a large development effort, there are typically many modules to the entire deliverable. Because of this, a standard look and feel to the code is important for maintainability. Examples of what to place in coding guidelines are as follows: (These utilize Visual Basic as the example)
A beginning for naming conventions is a prefix for the module. For example, in an inventory module, the prefix may be inv. Making the names meaningful is also important. For example, if a list box was named inv_LbRptNm, a developer familiar with the environment could tell this is a reporting list box. Whereas, ListBox1 is not as clear about what the function of the control is. Thus every thing in the app, bas files, controls, and the like should begin with this prefix. Beware the tendency of programmers to use abbreviations where none are necessary. Make the most of name lengths allowed. Given that short object names don't make the code run any faster, hardly save typing in this day of drop down lists of objects and often make one person's code almost unintelligible to another, they are just not worth it.
Hungarian notation is a suggested technique and is illustrated below:
Option Explicit ' PUBLIC Variables ' They can be changed from any Object that is ' an Instance of the Talent Class. Public FirstName As String Public LastName As String Public MiddleName As String Public TitleID As Integer Public SuffixID As Integer Public StageName As String Public Phone As String Public Fax As String Public Pager As String Public PagerPIN As String Public AltPhone As String Public Internet As String Public Address1 As String Public Address2 As String Public CityID As Integer
The files in Visual Basic applications are structured into BAS files (where code is stored) and Ocx files (DLL-type files such as custom controls). Setting up a structure for the MAK file (project file where all of the code files are stored) is important. When looking at maintainability, if the structure is similar, the developer will know exactly where to look for specific source code.
It is also important to modularize BAS files. This means keeping all code related to a specific business function in the same BAS file or a clearly related set of BAS files. When a function is called, the entire BAS file is loaded into memory. If all of the related function calls are in the same BAS file, only one is loaded into memory. Thus, speed is increased and computer resources are leveraged. For the same reason, don't include unrelated functions in a BAS file, separate them out.
The question here is to comment or not to comment. The overall consensus on comments is as follows.
Comments are useful if:
Comments are not useful if:
Thus, comments are helpful in application development, as long as the "how to" of writing comments is enforced. In general, provided these points are taken into account, you cannot write too many comments. Several leading writers have proposed ratios of comments to code in the order of N:m Poorly commented code is one of several unforgivable sins of programming—anyone can comment their code effectively.
Never allow a programmer to argue that "no one else will ever edit this code". Most organizations have code running today, in mission critical systems, which is over 20 years old. Your code will be no different!
It is important to enforce the use of function calls in large development environments. Placing code behind buttons, although effective, can be cumbersome for maintenance. It becomes difficult for the developer to find pieces of code, since more than one developer will be working with the code during the development life cycle. Also if the control changes or is deleted, this makes for a lot of cutting, pasting and changing of names. The code should remain generic and not be hard coded, stored in functions. This also allows for reusability of the code in the app. A function also returns a value of success or failure, which becomes important in error handling.
This is critical in large application development with Visual Basic. Visual Basic does not handle code errors gracefully. What happens is it boots the user right out of the app with a cryptic message or no description of what happened at all. If code is called directly from the function with a success or return value, the developer can trap the error and deal with it. A message box can be displayed with a description. This makes life much easier for those in software support and testing. The application can be terminated if the error was critical, or it can move on leaving out the functionality.
Poorly written error messages are another unforgivable sin. Error messages are first and foremost for users and only secondly for you. One useful reusable component or reusable application component is a subsystem for errors so that each error message has a unique number, is managed in a standard way, can call a standard "state of the application" function to generate a useful error report, etc.
FormatPhone_Err:
Select Case ErrorProc(Err, Err.Description, conProc, mconMod)
Case gconResume
Resume
Case gconResumeNext
Resume Next
Case gconExit
Resume FormatPhone_Exit
Case Else
Resume FormatPhone_Exit
End Select
End Function
UI standards use the term standards because they are cast in stone. This is important for the overall look and feel of the application, as it provides consistency. This gives the application a polished look and is important for the training department. When a trainer comes in and sees that all of a user's applications have this standard look and feel, it makes training easier. It also provides a confidence booster for users. Once a user is comfortable with one application, they can move into another with some familiarity. Such items as colors, fonts, position of buttons, and so on are addressed.
Tech·Ed 1996. Written by Elizabeth Parker
Visual programming tools, such as Visual Basic, are much more intuitive to use. It seems that it is becoming easier and easier to develop applications. However, the issue of programmatic architecture continues to be an issue. As always, with any development effort, there are many ways to structure the program.
Visual Basic applications contain forms, "vbp" files, "bas" files, and "ocx" files (custom controls). Most programmatic environments encourage as much reuse of modules as humanly possible. This cuts the development time. A sample environment that takes advantage of modular code may contain the following:
The file structure may look like this:
The following is a sample file structure for an Accounts Payable application. The main directory is Accounts Payable. Within the main directory are sub-directories containing various pieces of the application as well as the main project file.
As we will see later, this file structure translates nicely to SourceSafe®.
Furthermore, there may be some generic bas files that contain standard functions that every application may utilize. For example, every application will be making calls to the database. Thus, it makes sense this function resides in a bas file that contains similar functions. Each developer adds the library bas files to "vbp" (project) file of each application. Library functionality encourages and allows for re-usable, parameterized code that reduces the development time. It also follows that all application modules contain application specific code.
The following is a sample file structure for library functionality for an entire development effort. The main directory is VB Library. Within the main directory are sub-directories containing library level functionality.
A sample function may look something like this:
'********************************************************
'
' lib_Screen_Center
'
' This function centers a form on loading.
'
' Author: Liz Parker
'
' Arguments: ms_OK as Success
' ms _FAIL as Failure
' lib_Form as form to be centered
'
'********************************************************
'
Function lib_Screen_Center(lib_form As Form)
'*** Set up Error handler ***
On Error GoTo lib_Screen_Centererr
'*** Set the return value to faliure ***
lib_Screen_Center = ms_fail
lib_form.Left = (Screen.Width / 2)—(lib_form.Width / 2)
lib_form.Top = (Screen.Height / 2)—(lib_form.Height / 2)
lib_form.Show
'*** Set a successful return value ***
lib_Screen_Center = ms _ok
Exit Function
lib_Screen_Centererr:
GmsRet = lib_err_Fatal_Exit(lib_Screen_Center_Err_Msg, lib_Screen_Center_Err)
End Function
The development team may want to put in place some coding standards such as:
Usually the technical architect will compose a document of all of the development standards. This could include palette choices for screen appearance, file structures, and coding standards. Placement of this document in SourceSafe ensures proper management and distribution. SourceSafe stores binary files and allows for archival. Thus, new developers can get this document to understand the development environment. Also, other developers can add information to the standards document as the application evolves.
MSDK, Version 2.0, 1996. Written by Craig Lokken
The Microsoft Visual Basic 4.0 programming system includes a powerful new feature: the ability to create OLE servers. An OLE server is an application that exposes functionality that can be used and reused by other applications through OLE Automation. For example, using Visual Basic 4.0 a developer can create an OLE server that displays reusable forms, implements business rules, or packages a complex routine into a simple component that other programmers can use.
The Enterprise Edition of Visual Basic version 4.0 includes an additional new feature, Remote Automation. Remote Automation enables developers to run an OLE server on one machine and the client application on a separate machine on the network. This feature is extremely useful for three-tier client/server, asynchronous processing; offloading work to underused machines; and reducing client maintenance.
Together these new features provide the foundation for building sophisticated reusable application components and distributing those components throughout the enterprise.
This document provides an overview of OLE servers and explains how to use Visual Basic 4.0 to create an OLE server.
An OLE server is an application that exposes objects that can be used by other applications. An OLE server provides code that you do not have to write. Any application that supports OLE Automation can control an OLE server.
For example, Microsoft Excel is an OLE server. Microsoft Excel exposes objects such as worksheets, charts, and so forth. From a Visual Basic 4.0 application, you can send data to Microsoft Excel and create a chart. You need not know the details of creating a chart; instead, you simply create an instance of the object you want, set properties, and execute a method to create the chart.
The following figure shows how an OLE server created with Visual Basic 4.0 can be used by any number of other applications.
Figure 1. An OLE server available for use by various applications
When you are creating OLE servers in Visual Basic 4.0, the first step is to define objects within your Visual Basic 4.0 project. These objects can then be used within your Visual Basic 4.0 project or exposed to other applications.
Visual Basic 4.0 includes a new type of code module called a class module. Each class module defines a blueprint for an object. After you have added a class module to your project, you can define custom methods and properties for that class. To define methods for a class, you simply create Public Sub and Function procedures within the class module. To define a property for the class, you either create Property procedures or define public variables. Property procedures enable you to execute code when a property is set or retrieved. Public variables simply hold the property value.
For example, suppose you want to create an Employee object with the following characteristics:
Create a class module as follows:
Figure 2. Using a Class Module to create an Employee object
Once you have created your class, you programmatically create instances of that class. The instance of the class is the object. You can create multiple objects of the same class. You use the Dim statement to create an instance of the class. For example:
Dim Employee1 As New Class1 Dim Employee2 As New Class1 Employee1.EmployeeName = "Joe" Employee2.EmployeeName = "Mary" Employee1.Hours = 45 Employee2.Hours = 50 Employee1.HourlyWage = 10 Employee2.HourlyWage = 12 MsgBox Employee1.ComputeSalary MsgBox Employee2.ComputeSalary
Once you have objects defined in your Visual Basic 4.0 application, you can easily turn your application into an OLE server and make those objects available to other applications.
To create an OLE server, you must set some project options and some properties of the class modules that you want to expose.
The first step in creating an OLE server is to set the Project options. You can do this from the Project tab in the Options dialog.
Figure 3. Setting the Project options for an OLE server
For most OLE servers, you set the startup form to Sub Main. The code in the Sub Main procedure executes when the OLE server starts. Define the Sub Main procedure in a Standard module.
The project name is the name that the client application programmatically uses to refer to your server. The following example shows the code from a client application to create an instance of a class named EmployeeClass in a server named MyServer.
Dim x As Object
Set x = CreateObject ("MyServer.EmployeeClass")
You can run multiple instances of Visual Basic 4.0. This is very useful for debugging OLE servers. You can run a client in one instance and a server in another.
To test your OLE Server, set StartMode to OLE server. This causes Visual Basic 4.0 to keep the project running even though no code is executing. This enables you to start a client application to test your OLE server application in the Visual Basic 4.0 development environment.
To make your objects available to other applications, set the class module Public property and the Instancing property.
Figure 4. Setting class-module properties
The Public property determines whether the class is visible to other applications. If Public is False, the class is unavailable to other applications and the Instancing property is ignored.
If Public is True and Instancing is 1 or 2, the class can be created and controlled by other applications. If Public is True and Instancing is 0 (Not Creatable), other applications can control an existing instance of the class but cannot create new instances.
The Instancing property determines whether applications outside your project can declare new instances of your class.
If you set Instancing to 1, Creatable SingleUse, a separate OLE server executable is started for each instance of this class. For example, if a client application creates two instances of Class1, Visual Basic 4.0 starts two separate server executables.
If you set Instancing to 2, Creatable MultiUse, one OLE server executable can service multiple clients. For example, if a client application creates two instances of Class1, Visual Basic 4.0 starts one server executable. That executable creates two instances of Class1.
Setting Instancing to Creatable MultiUse minimizes resource use because you run only one copy of the OLE server. However, all requests from client applications are processed serially; that is, the server will not execute a second request until it has completed the first request. If you set Instancing to Creatable SingleUse, each OLE server executable can process requests independently. This is especially important with remote automation where many clients may be making requests at the same time.
The Name property is the name the client application uses to create an instance of the class.
Once you have created your OLE server, you can use the objects your server exposes from any application that supports OLE automation. For example, from Microsoft Excel you can make a reference to the OLE server and then use any of the objects exposed by that server.
Note: To make a reference in Microsoft Excel you must have a module active. From the Tools menu, choose References to display the References dialog box.
The following figure illustrated the References dialog box.
Figure 5. Activating a module sheet through the References dialog box
Making a reference to the OLE server enables you to use the Object Browser to display the objects that the server provides. To open the Object Browser in Microsoft Excel, choose Object Browser from the View menu. For example, the server created previously would appear as follows in the Object Browser.
Figure 6. An OLE server as shown in the Object Browser
After you have made a reference to the OLE server, you can begin to work with the server's objects. The following example illustrates using the server's objects from Microsoft Excel. Note that this same code can be run in Microsoft Access, Microsoft Project, or another instance of Microsoft Visual Basic 4.0.
Figure 7. Using an OLE server from within Microsoft Excel
Once you have tested your OLE server, you are ready to compile it. You can compile your OLE server as an executable file (.EXE) or as an OLE dynamic-link library (.DLL).
If you choose Make EXE File from the Visual Basic File menu, the OLE Server is created as an out-of-process server. When a client application uses an out-of-process server, the server runs in its own process space (a separate application). Calls between a client and the server pass through the OLE interface.
If you choose Make OLE DLL from the File menu, the OLE server is created as an in-process OLE server (a DLL). When a client application uses an in-process server, the server runs in the same address space as the client application and is significantly faster than calling an out-of process server.
When choosing between an OLE executable file and an OLE DLL, your main consideration is speed versus flexibility. An OLE DLL is usually much faster than an OLE executable because the OLE DLL runs in the same process space as the client application.
There are times, however, when you need an OLE executable in order to achieve a desired result. For example, you might want to run an OLE server asynchronously (asynchronous operations must execute in a separate process), to run an OLE server on a different machine, or to display modeless forms from an OLE server.
Remote Automation enables you to run your OLE server on one machine and your client application on a separate machine. With Remote Automation you can easily create applications that divide their processing across the network, thereby increasing scalability and improving client maintenance and performance.
As shown in the following diagram, Remote Automation takes OLE Automation requests from the client, sends them across the network using Remote Procedure Calls (RPCs), and receives them on the server. The components necessary for Remote Automation are available in the Enterprise Edition of Visual Basic 4.0.
Figure 8. Remote Procedure Calls between client and server systems
Neither the client nor the server knows that the connection is remote. No special coding is required in the server. Even though a client application is accessing an OLE server on another machine, Remote Automation makes the transaction "look like" local OLE Automation to both the client application and the OLE server.
Remote Automation is a key enabling technology for building distributed three-tier client/server applications, as well as for offloading processing and decreasing client-maintenance costs.
You may want to enable your users to start a long procedure on an OLE server and continue working without waiting for the procedure to finish. This can be done by running your OLE server application asynchronously with your OLE client application. The server sends a message to the client application when the process finishes.
For example, if you have a lengthy report-generation task to do, you can have it execute in the background, freeing up the client application to perform other tasks.
To enable an asynchronous method, do the following:
The client application invokes a server method to start a background process. The client passes an object to the server that the server can use to notify the client when the process has finished.
When the process is finished, the server application invokes a method on the object received from the client application.
The following code provides an example of calling an OLE server asynchronously. The first procedure is from the client application. It creates an instance of the object it will pass to the OLE server (to receive notification back from the server when it is finished processing) as well as an instance of the server itself. It then calls a method in the server. The second procedure is the method being called in the OLE server application. Note that the last line in this procedure enables a Timer control. The code in the Timer control does the actual processing in the server application. This allows the method in the server to complete processing and return control to the client application.
Client-server computing continues to represent an increasingly popular alternative to legacy host-based solutions. It offers faster and more cost-effective performance and enables the development of entirely new solutions based on the broad-based availability of information and analysis at all levels of the user organization. Client-server solutions are becoming larger—enterprise-wide—and increasingly support the corporation's mission-critical functions.
But the classic two-tiered client-server model fails to provide adequate scalability, performance and ease of management—a necessity for any business-critical solution. For this reason many leading-edge customers and leading-edge systems vendors are adopting a three-tiered, distributed-computing model. This new model, called a "services model," modifies the role of traditional "server" and "client" and adds a new architectural component, "business services." To date however, no vendor has offered the combination of a three-tiered application architecture with high-productivity rapid application development tools.
In first-generation client-server architectures, business logic is captured in one of two ways: it's either coded into the client graphical user interface, necessitating that any maintenance change be reinstalled to perhaps hundreds or thousands of desktops, or it's coded into stored procedures on the server machine. While SQL is a widely accepted standard, it is primitive in its control flow and data structures and extremely difficult to maintain or debug. In the three-tier model, volatile business-service logic is discrete from client and data services, maintained in a secure, centralized business object.
As business conditions become more competitive, custom business solutions must be adapted much more quickly to meet competitive threats and sales opportunities. The average client-server application now has a maintenance cycle of less than six months.
This services model is a way of viewing applications as a set of features or services that are used to fulfill end-user requests. By encouraging the developer to model an application as a collection of discrete services, features and functionality can be packaged for reuse, sharing and distribution across functional and computational (i.e., hardware) boundaries. For example, an airline reservation system can maintain the business rules describing pricing and availability in a separate pricing and availability service that is shared by thousands of users. When prices change these services are easily updated. Through this networked service architecture many services are available to an application builder in "ready-to-use" form. The components that provide these services can be developed in-house or purchased from a number of outside vendors.
There are three categories of services:
User services provide the visual interface for presenting information and gathering data. They also secure the business services needed to deliver the required business capabilities and integrate the user with the application to perform a business process. User services are generally identified with the user interface and normally reside in an executable program located on the client workstation. Even here, however, there are opportunities for identifying services to reside in separate components for shared application usage and easy updating.
Business services are the bridge between user and data services. They respond to requests from the user (or other business services) to execute a business task. Business services accomplish this by applying formal procedures and business rules to the relevant data. When the needed data resides on a database server, business services secure the data services needed to accomplish the business task or apply the business rule. This insulates the user from direct interaction with the database. Because business rules change more frequently than the specific business tasks they support, they are the ideal candidates for encapsulating components that are physically separate from the application logic itself. This makes it easier to update enterprise-level solutions without having to update a large number of individual clients or servers.
Data services define, maintain, access and update data, and manage and satisfy business services requests for data. They may be physically implemented in a particular database management system (DBMS) or by a heterogeneous collection of databases that reside on multiple platforms and combinations of servers and mainframe computers.
Developers and development managers are in need of mechanisms for controlling complex software development efforts. Rapid application development can involve many iterations of code from concept to deployment. It follows that in RAD, time is of the essence and project control is critical. Applications can become complex quickly and developers need to spend of the time programming. Furthermore, supporting documentation such as technical specs and coding standards needs effective management and availability to the team. Controlling all of the code, technical specifications, and supporting software can become an administrative nightmare. Microsoft SourceSafe provides a mechanism to manage the software development process. Microsoft SourceSafe is a powerful member of the development team performing tasks such as:
These tasks can keep a developer fully absorbed in code management issues. Allowing SourceSafe to perform these tasks for the team leverages the developers to spend most of their time programming and less of their time dealing with code management issues. When developers spend most of their time programming, application development effort progresses at a rapid pace.
Networks can function as a repository for source code. However, the maintenance and time investment in this process is overwhelming. There is usually a master copy of a file and an owner. Then a change/edit process is established to maintain the integrity of the file. When the files reside on the network, management of the files can turn into mass chaos, not to mention there is no way to really tell who did what, when, and why to a file. Microsoft SourceSafe resides on a server in a development environment. SourceSafe functions as a librarian for objects it stores. These objects may be code, forms, or technical specifications. These objects reside in the SourceSafe database on the server, as well as on one or many developers hard drives. The main organization metaphor for SourceSafe is at the project level. The project tree is organized very much like a directory tree. If a developer is working on a project, an association is made to a working directory on the developers hard drive. This is a user by user setting. The Visual SourceSafe Project is common to the whole group; the working directories are individual to each developer. SourceSafe utilizes four basic operations for code management as illustrated below:
Written by Elizabeth Parker
Developers can get Microsoft's Visual SourceSafe by purchasing it independently or Visual Basic enterprise edition includes a copy of Microsoft SourceSafe. SourceSafe functions with Visual C++® and other development tools as well as Word documents and Excel worksheets. Visual programming tools, such as Visual Basic, are much more intuitive to use. Visual SourceSafe is an effective tool to utilize with the Visual Basic development environment, either the professional or enterprise version. It seems that it is becoming easier and easier to develop applications. The user interface for development environments is very intuitive, and it is easier than ever to develop applications. However, the issue of programmatic architecture continues to be an issue. As always, with any development effort, there are many ways to structure the program. Modularity and re-usability are key concepts to reduce time in the development effort. Thus, the question arises of how to architect the development environment for use with SourceSafe?
Visual Basic applications contain forms, "vbp" files, "bas" files, and "ocx" files (custom controls). Most programmatic environments encourage as much re-use of modules as humanly possible. This cuts the development time. A sample environment that takes advantage of modular code may contain the following:
Visual SourceSafe organizes objects at the project level. This is not the same as a Visual Basic project. However, the Visual Basic project fits nicely into a SourceSafe project. Visual SourceSafe stores files that compose a Visual Basic project, such as forms and modules, in logical project hierarchies. Users can define their project hierarchies. These hierarchies map exactly to the file structure of the Visual Basic project and supporting documentation on the developers' hard drive.
The project structure in SourceSafe directly mirrors the file structure in Windows. The SourceSafe paradigm directly maps to the file structure, which is very intuitive for developers. SourceSafe allows the developer to specify a working directory for each project. The working directory corresponds to a directory on the developer's machine. Once the developer sets the working directory, each time the developer retrieves a new version of the objects they reside in the working directory by SourceSafe. The developer can check files in and out from SourceSafe within Visual Basic. The Visual Basic development environment allows for seamless integration of SourceSafe thought the add-in's menu as illustrated below:
Visual Basic provides seamless integration at its native menu. Furthermore, once added in to the Visual Basic Environment, login to SourceSafe appears upon opening Visual Basic. This enables the development team to allow SourceSafe to manage the application from within Visual Basic. The developer does not need to toggle between two applications to check code in and out. The developer can remain in the Visual Basic development environment. Once SourceSafe in integrated into the Visual Basic environment the developer has the ability to utilize the functionality of SourceSafe. Illustrated below are a few examples of how powerful this integration can be:
Situation: When a developer begins coding in Visual Basic, the application does not exist at the project level in SourceSafe.
SourceSafe solution: When SourceSafe is an active add-in in Visual Basic, SourceSafe reminds the developer to add the project or file to Source Safe if it does not exist. The options setting also provides a mechanism for Visual Basic to add files to SourceSafe automatically or with a warning, as illustrated below.
Benefit: As the development environment grows and becomes more complex with more files, it becomes increasingly difficult for a developer to remember what file is current and when it was last updated. SourceSafe can easily provide these reminders in the development environment. This ensures that all projects, versions, and files are current.
Situation: A developer needs to quickly and easily check in code.
SourceSafe solution: When source safe is an active add-in in Visual Basic, the developer can either check in code from the menu or by right clicking on the file within the project. Furthermore, the options setting allows for the customization of the environment by the developer. The following settings can be customized with a yes, no, or ask, as illustrated below.
Benefit: Partnering Visual Basic and SourceSafe allow the developer to not have to exit the development environment to update files and ensure SourceSafe has the current version to provide to the development team. This saves time for the developer. The developer can check code in and out either by using the menu, right clicking, or setting options. Furthermore, these settings are customized by the developer in their development environment to suit their working style. This also ensures that all projects, versions, and files are current.
Situation: A developer needs to view history of an application or retrieve a previous version.
SourceSafe solution: SourceSafe provides full history and archiving functionality.
Benefit: Archiving functionality allows developers to retrieve any prior version of existing code. Sometimes changes are made to code and a new version is created. The new version may have other issues that cause an impact to the entire system. At times, it becomes easier to revert to an older version of the code. Also, developers may want to create custom versions of the same application. SourceSafe allows for version labeling that can assist in keeping track of each flavor of the application. Versioning is also a helpful tool for tracking application issues and fixes. Manually tracking versions is very time consuming and frustrating. SourceSafe effectively manages this process.
In a team environment, it is critical to understand who is working with which code. The project rights window allows for developers to have rights to the modules they need to complete. This can be very important in a development environment. For example, if another developer changes code in another application for integration purposes, the application risks impact in other areas. A developer can spend hours trying to determine the source of the problem. This window also allows for other developers to get a read only copy of the application to check integration issues with their application. Administration of these rights is simple and easily changeable as developers' responsibilities change throughout the course of the project. The SourceSafe administrator provides that functionality in an easy to use administrative tool.
The developer enters information about bug fixes for tracking purposes in the comments window. Also, testers can enter comments about the application and its status. This information is an important audit trail. It is important to understand exactly what happened to the file as the development environment is moving forward towards deployment because key project management information is readily available. Anyone can examine the comments for a file and understand the status of the file within development and how far it is to completion. Furthermore, full tracking information concerning bugs and testing issues is provided.
The team development environment is one of constant re-iteration. The team can effectively partner SourceSafe with Visual Basic as an effective tool to manage the many components involved in a team development effort. Other features of SourceSafe, such as archiving, are also tools utilized in the team development environment. These features also add value in the single developer environment
Written by Elizabeth Parker
There are many tools for knowledge base type information in the development environment. These are necessary and important tools which can answer development and deployment questions. Sometimes trying to determine the cause of a bug can take hours These tools offer a wide range of technical support and help for developers. However, the question is often raised which tool do I use for what. The following provides a description:
The Microsoft Solutions Development Kit provides resources that are critical to developers who want to build applications for Office 95, BackOffice®, Windows 95® and Windows NT®. The Microsoft Solutions Development Kit is a single, easily-searchable CD with new Word, Excel, Project, Schedule+, PowerPoint®, Visual Basic, OLE, and BackOffice development information and sample code. The MSDK will jump-start your development efforts by showing you how to "glue" Office and BackOffice components together using Microsoft Visual development tools.
Microsoft Mastering Series titles are content-rich, self-paced, and interactive training tools designed to help you master application development with Microsoft development tools quickly. The courses combine high-level technical content with an intuitive learning methodology that lets you learn in the way that best suits your schedule and study approach. The titles include:
The Microsoft Developer Network (MSDN) is the official source from Microsoft for comprehensive programming information, development kits, and testing platforms. MSDN delivers all of this via a quarterly subscription, so our subscribers can be confident they're always working with the most up-to-date information and technology.
There are three levels to the MSDN subscription model which offer different levels of information to different customers.
Ernst & Young LLP, Hitchhiker's Guide, Ernst & Young LLP Navigator Systems SeriesSM Accelerated Systems Development, April 1995. Proprietary Material. All Rights Reserved.
Microsoft Corp., Microsoft Visual Basic 4.0 Enterprise Computing Strategy
Microsoft Corp., Tech·Ed 95 CD
Microsoft Corp., MSDK, Version 2.0, 1996
Craig Lokken, OLE Servers