Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> Re: POWERBUILDER vs FORMS 4.5

Re: POWERBUILDER vs FORMS 4.5

From: Charlton B. Barreto <barreto_at_BIZ.NET>
Date: Sun, 14 Jan 1996 13:51:56 -0800
Message-Id: <9601142205.AA23660@alice.jcc.com>


Allen,

Your decision will need to be based upon what sort of project you are planning to use Dev/2k or Powerbuilder for. The issue is not which is a better tool; it is that they belong in two entirely different classes of tools. Dev/2k is a true 4GL, while Powerbuilder is a GUI Development Tool. And when it comes to applications development 4GLs and GUI Development Tools are appropriate for entirely different types of applications and environments.

Powerbuilder is a first-generation C/S Tool, and is used widely to develop graphical, event-driven apps that run on the client platform. It incorporates a GUI, customized prodecural logic, and transparent access to disributed data via ODBC. It (and other 1st-gen's) is well-suited toward the development of light, decision support applications and other user-friendly, desktop applications that do not require a high degree of data integrity or logical correctness, aswell as for quick prototypes (although VB is even quicker and easier to use toward that purpose).

Powerbuilder and other tools of its ilk allow you to build applications with greater ease and facility, and greater control over the GUI environment. They're easy and quick to learn, and given their limited scope, won't allow you to shoot yourself in the foot too badly. However, you'll be limited to small-scale, two-tier C/S apps with only ODBC support of DBMS connectivity.

The drawbacks of Powerbuilder and its like include:

--Lack of scalability to enterprise-scale applications   Scalability requires support for OLTP, distribution of processes, high data   integrity, and rigourous analysis and design techniques. PB and its like   are incapable of meeting the above requirements; they generate applications   that run only on the desktop, and do not support large numbers of on-line   users a high degree of data integrity, or the use of rigourous A&D   methodologies.

--Poor on-line performance
  PB and the like do not provide adequate response time for applications that   incorporate complex procedural logic or mulitple database queries. This   lack of on-line performance is caused by the fact that processing cannot   be split between client and server platforms, and that all generated code   must be interpreted at run-time. The use of interpretive code permits   prototype apps to be demonstrated rapidly to end-users; however, it imposes   a significant performance penalty at run-time.

--Lack of support for distribution of processes   PB and the like generate code only for the client; they DO NOT support   application partioning between the client and server platforms, or the   automatic generation of stored procedures and triggers.   To obtain adequate on-line performance with PB and the like, it is often   necessary to recode selected client processes in the form of stored procedures   on a server. Since the generation of stored procedures and triggers are not   supported PB and the like, these will have to coded in the language of the   installed DBMS, such as PL/SQL for Oracle, TransactSQL for Sybase, etc.   This will require your developers to learn two languages.   Also, your developers are forced to decide early in the design process   which processes will run on the client and which will run as stored procedures   or triggers on the specified servers. If reallocation of processes   subsequently becomes necessary due to operation inefficiencies, the   distributes procedures must be rewritten by hand for the new platform. This   severely restricts the developer's ability to allocate processes to   appropriate platforms for maximize performance.

--Limited support for middleware
  PB and the like don't provide the infrastructure required to support high-vol   transaction processing, security, RPCs, global naming, version control,   configuration mgmt, and network management. This is otherwise known as   middleware. Examples include SQL*Net for Oracle, Open Client and DB-LIB for   Sybase.

--Lack of support for OO business modelling   PB and the like use an early, rudimentary form of OO technology. You can   organize objects, such as DataWindows, into class libraries, based on   hierarchies of GUIs. Each object encapsulates a GUI, db access stmts, and   procedural logic. Lower-level objects inherit control structures from   higher-level objects. However, there is a growing need for more generalized
  class library structures that don't limit the library to hierarchies of GUIs.   More advanced, OO business modelling techniques enable developers to specify   applications from a knowledge base of low-level resuable components. PB and   its ilk don't support this.

--No common object repository
  Without an object repository, PB and the like don't support team-driven   development. It's not easy to maintain consistency, quality, etc. with   project-team development using PB and the like. It's a pain. You're forced   to use 3GL configuration management tools such as MKS to manage your code, and   this is serious mismatch for when you need to write 4GL applications.

Developer 2000, Uniface, Dynasty and the like are among the Second-generation C/S Tools. These are strategic, enterprise-wide tools that overcome the limitations the first-generation Tools. These 2nd-gen tools provide an intutive ,graphical development environment, high performance, scalabilty, transparent linkages to middleware, and tight integration with rigorous CASE specification techniques.

These products are designed to support complex, enterprise C/S that can run the
organization. Examples include on-line order entry systems, on-line trading systems, claims processing, customer service, reservation systems, manufacturing systems, inventory control, etc., etc., etc. These apps are transaction-oriented, often move money or update inventory, and are vital to the operation of the business.

These products support

With such tools most development staff do not require knowledge of specialized code needed to support different GUIs, SQL-based DBMS's, transaction management, and network communications, error handling, recovery and security. They'll have less low-level control of these features but have to deal less with them as these are abstracted. The ads you see in the magazines are true: what you'll write in the 71 lines of code with PB or Momentum you'll write in 0 lines of code with Oracle Dev2k, Uniface, Dynasty, etc. These tools also provide a set of intelligent editors that guide the analyst through all the details of building the components of the transaction processing system. The editors check for syntax errors, and perform semantic checks to through all the details of building the components of the transaction processing system. The editors check for syntax errors, and perform semantic checks to ensure that the transaction processing operations are logically correct.

The drawbacks of these tools include:

--Learning curve
These powerful, flexible tools are by nature more difficult to learn than the GUI tools. You'll code less but you'll have to understand more; i.e. be a better developer. You can shoot yourself in the foot if you don't know what you're doing.

--Complexity
The 2nd-gen's can be at times overwhelming with their complexity at times. Again, this is the nature of the beast. Your tools can do a lot more, and as such there are more tool components to consider. Tasks such as version migration can be more challenging to accomplish.

--Occasional user-unfriendliness
Dev2k is a good example here. Sometimes Dev2k can be a pain with its clunkiness here and there. And it and Uniface and Dynasty and the rest are not always easy to use. Thats the tradeoff of greater power and not having to deal with SQL. Again, one has to step back, look at the big picture ,and be a better developer when working with these tools. This is often the basis for going with a tool like Powerbuilder or SQLWindows. It's the wrong reason.

--Do not directly support GUI Objects and Controls as do GUI Dvpt Tools With GUI Dvpt Tools, you can really dig into low-level manipulation of MDI Windows, OLE Objects, Custom Controls and DDE in MSWindows, directly through the Tools themselves. With 4GLs and their positioning for platform independence and flexibility, such direct control is not supported, and the developer will have to utilize custom modules written in a 3GL (e.g. DLL written in C for MSW) utilizing the 4GL's API. This makes for some more work on the developer's part if such support is important.

What this gets down to is if you're
building an enterprise-scale IS, PB, SQLWindows and the like are NOT for you. You should go with Dev/2k or UNIFACE (UNIFACE if you want improved portability of apps across multiple platforms, and superior model-driven development). If you want to build a small-time, one-platform application where you'll need to have 3GL-like control over the GUI environment but for which you don't expect to scale for use beyond 2-3 years, don't need referential integrity, model-driven development, etc. go with PB, SQLWindows, etc.

If you want to get an
enterprise-scale solution yet want a small-timer to prototype with, get Delphifor the prototyper. Its cheaper, easier to use, and far more powerful for prototyping than PB or SQLWindows.

I hope this information is of some help to you.

Regards,

-Charlton.

>We are debating on whether POWERBUILDER or FORMS v4.5 (DEVELOPER 2000)
>would fit our needs better as a frontend application developing tool
>in a Windows environment on client workstations to our ORACLE server.
>We are presently running ORACLE on OS NOVELL on a 486 60Mhz PC Server,
>but possibly in the future could move to a UNIX box. We will be
>developing 2 or more applications in 1996 and have 2 - 3 developers.
>
>We presently have DEVELOPER 2000 with FORMS but have not done any
>developing with it. We would need to purchase POWERBUILDER.
>One of my associates seems to believe that POWERBUILDER is a better
>product (His reasons - its been around for a long time - has a good
>reputation - POWERBUILDER is compatible to many other tools).
>He seems to have convinced my boss to go with POWERBUILDER.
>Training and coming up to speed is also a issue. We have no
>experience on either, so would need training on both ( although
>I am familiar with ORACLE and SQL). We both are completely new to
>POWERBUILDER so would need to be trained in it..
>
>I would appreciate your opnion (especially if you have developed
>applications with both FORMS and POWERBUILDER or have gathered
>comparison facts between them). I realize this list might be
>somewhat biased for ORACLE FORMS. In your reply, please
>attempt to give good reasons based on your experience or facts you
>know.
>
>THANK YOUAllen G. Wells (612)627-5492 FAX: (612)627-5479
>MN Dept of Health, Enviromental Health Division
>Internet: Allen.Wells_at_health.state.mn.us

+-------------------------------------------------------------------------+
| charlton barreto                          barreto_at_Biz.net * active *    |
| software engineer                         charlton.barreto_at_ebay.sun.com |
| sun microsystems computer company         cbarreto_at_ocf.berkeley.edu     |
+-------------------------------------------------------------------------+
| TCHAR szDisc[] = _T("These words are my own; I do not speak for Sun."); |
+-------------------------------------------------------------------------+

Received on Sun Jan 14 1996 - 17:06:13 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US