VFP Apps In The Dot Net Era
Whether we are eager to jump on it or not, the Visual Studio Net wave will have -already has?- a major influence in the way Web and Win32 apps are thought of from now on.
The purpose of this topic is to discuss ways to structure a "typical" VFP distributed application (Web apps should require a separate analysis) with the following goals in mind:
”Deliver now”: Being able to build its components today with available and reliable VFP 6 technology.
”Dot Net Ready”: being able to interact / extend / replace some of its components with .Net components built in any other language or in VFP7.
IMO these design goals may unlock the developing activities while the exciting-but-somehow-futile discussions about the merits of Visual Studio Net take place, and -more important- while we wait for the product to be released and stress-tested.
Of course, there is an opposite point of view -also valid though I don't share it- : "Use the .Net platform for the Web apps, which is, in fact, what it is mainly intended for, and for the VB Win32 apps. On the other hand, Visual Fox Pro apps -even distributed ones- can only lose by moving into that platform".
A proposal: VFP n-Tier Apps Through Web Services
A model which I consider -in theory- particulary promising is the combination of a VFP user interface with "thin" (or "proxy") business components, linked through SOAP Web Services calls to the real behavior and data layers on the server(s). A more detailed explanation and some implementation choices are described in a separate page: Vfp NTier Apps Through Web Services
Effective centralization of behavior and data processing
IMO, this model gives a more reliable and open mechanism than DCOM for taking the data and business logic out of the client machines, into application servers which can be more powerful, closely monitored and mantained, and with faster and more reliable network connections to the data server.
Of course, the "currently more common" data access model is still a valid alternative for VFP apps -opening data connections from the workstations and keeping the bulk of the three layers on the client side except for the data processing in the DBMS- but it lacks the advantages mentioned above.
Flexibility. This approach opens multiple evolution paths:
Which of these ways will we actually choose in the future? Probably all of them, according to the situation.. we’ll see. (Survival of the fittest? )
- VFP components of the Web Services may be upgraded with VFP7 new features, in particular the ability of COM debugging, generating XML output, etc.
- The VFP client may remain, while Web services are replaced or new ones added. These may include Visual Studio Net Web services, or SOAP services based on entirely different platforms / development tools.
- A Web UI may be added (through Web Forms or other technique) making use of the same Web Services already developed
- Eventually a significant part of the application might be rewritten with the Visual Studio Net suite... but one step at a time.
And I don't see a reason why VFP-powered web services shouldn't stand side by side with brand new .Net Web Services, as long as they expose the same interface, consume the same data / stored procedures / etc. , and maybe even do it faster.
Cons (to be evaluated)
SOAP protocol and XML conversions overhead?
The "Mixed Model" alternative
The SOAP wrapper itself shouldn't add a significant overhead. But transforming large or not-so-large data sets to XML on the server side (if not using SQL Server 2000 XML output option) and specially converting them to VFP cursors on the client side (if needed by the VFP user interface) could impose a significant performance penalty. This has to be measured against the time reduction achieved by central processing.
IIS / ISAPI bottleneck?
The currently used internet interfaces are well dimensioned for the expected browser response times (even on intranets)... but will they provide a fast-enough response for VFP "web services intensive" applications, within the expected response interval of a Win32 app user?. I just don't know, maybe the ability to scale for huge numbers of Web users overcompensate the more demanding but much smaller number of workstations using the VFP app.
Considering the expected response time of a VFP user interface, a more conservative but maybe valid approach could be to combine:
- The classic "direct data access" from the workstations (keeping part of the behavior and data layers on the client side) for all the "non critical and easy-to-code-again functions"; i.e loading the Countries list, and so on.
- SOAP Web Services for all system functions that are either logic-heavy, frecuently modified, or sensitive.
For example: determining a price for a product/client, reading or saving an invoice, or validating a user login.
This compromise could allow for fast-response -and not so radically changed- applications, while achieving a good level of flexibility in terms of future technology moves.
- - -
Other contributions and rebuttals are welcomed. Thanks. -- Jose Marcenaro
Contributors: Jose Marcenaro
( Topic last updated: 2000.10.14 08:36:40 AM )